From netbeans at gatworks.com Fri Jun 1 05:38:50 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 07:38:50 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <465F7ADD.1010501@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> Message-ID: <4660054A.2040202@gatworks.com> Manuel Naranjo wrote: In the case of my module, you can > unplug the device but it will not delete the symlink until those apps > that had opened the port has closed it. This is done this way to avoid > kernel panics. What does this mean to user code ? I have tried the alternate route ( other than closing ) which is sleep inbetween the I/O errors ( an unplugged USB device). When the device is plugged back in, The writes to the device still get an I/O error. This would seem to be a lost cause for the application. From netbeans at gatworks.com Fri Jun 1 06:35:48 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 08:35:48 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <465F7ADD.1010501@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> Message-ID: <466012A4.90608@gatworks.com> Manuel Naranjo wrote: In the case of my module, you can > unplug the device but it will not delete the symlink until those apps > that had opened the port has closed it. T Did u also mean for this to happen? USB0 was not closed by application. Apparently USB1 got created when USB device was plugged back in. There is only one USB device on a 4 port USB hub. This also seems to suggest that application recovery to be impossible. > Jun 1 07:10:08 mylaptop kernel: garmin_gps 1-1.4:1.0: Garmin GPS usb/tty converter detected > Jun 1 07:10:08 mylaptop kernel: usb 1-1.4: Garmin GPS usb/tty converter now attached to ttyUSB0 > Jun 1 07:15:17 mylaptop kernel: usb 1-1: USB disconnect, address 4 > Jun 1 07:15:17 mylaptop kernel: usb 1-1.4: USB disconnect, address 5 > Jun 1 07:15:17 mylaptop kernel: garmin_gps 1-1.4:1.0: device disconnected > Jun 1 07:15:26 mylaptop kernel: usb 1-1: new full speed USB device using uhci_hcd and address 6 > Jun 1 07:15:26 mylaptop kernel: hub 1-1:1.0: USB hub found > Jun 1 07:15:26 mylaptop kernel: hub 1-1:1.0: 4 ports detected > Jun 1 07:15:27 mylaptop kernel: usb 1-1.4: new full speed USB device using uhci_hcd and address 7 > Jun 1 07:15:27 mylaptop kernel: garmin_gps 1-1.4:1.0: Garmin GPS usb/tty converter detected > Jun 1 07:15:27 mylaptop kernel: usb 1-1.4: Garmin GPS usb/tty converter now attached to ttyUSB1 From naranjo.manuel at gmail.com Fri Jun 1 09:17:22 2007 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Fri, 01 Jun 2007 12:17:22 -0300 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <466012A4.90608@gatworks.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> <466012A4.90608@gatworks.com> Message-ID: <46603882.5050701@gmail.com> Uncle George escribi?: > Manuel Naranjo wrote: > In the case of my module, you can > >> unplug the device but it will not delete the symlink until those apps >> that had opened the port has closed it. T >> > > Did u also mean for this to happen? USB0 was not closed by application. > > Apparently USB1 got created when USB device was plugged back in. There > is only one USB device on a 4 port USB hub. > > This also seems to suggest that application recovery to be impossible. > Exactly there's a dead symlink (you can read and write to it and nothing will happen) and a new port will be created when a new device is connencted. From netbeans at gatworks.com Fri Jun 1 10:20:46 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 12:20:46 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <46603882.5050701@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> <466012A4.90608@gatworks.com> <46603882.5050701@gmail.com> Message-ID: <4660475E.5090202@gatworks.com> Not sure what u mean by "symlink". U cant read/write to it anymore. U get I/O error. In this scenario the device effectively went dead, and only solution is to close the channel. reconnecting the USB device, although dead, but not closed, will create a second device. This does not seem to be a desirable side-effect. The user will now have ttyUSB1, wondering where did ttyUSB0 go to. The application will also be in a confused state, as well as RXTX, because RXTX wont know about ttyUSB1. Manuel Naranjo wrote: > Uncle George escribi?: >> Manuel Naranjo wrote: >> In the case of my module, you can >> >>> unplug the device but it will not delete the symlink until those apps >>> that had opened the port has closed it. T >>> >> Did u also mean for this to happen? USB0 was not closed by application. >> >> Apparently USB1 got created when USB device was plugged back in. There >> is only one USB device on a 4 port USB hub. >> >> This also seems to suggest that application recovery to be impossible. >> > Exactly there's a dead symlink (you can read and write to it and nothing > will happen) and a new port will be created when a new device is connencted. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From arnab.bhaumik at gmail.com Mon Jun 4 01:40:16 2007 From: arnab.bhaumik at gmail.com (arnab bhaumik) Date: Mon, 4 Jun 2007 13:10:16 +0530 Subject: [Rxtx] full duplex com port with rxtx Message-ID: hi , till now i did half duplex communication with rxtx package on com package. my question is : is it possible to use com port with full duplex mode with rxtx package . ther is example of SimpleRead class and SimpleWrite class. it is clear that if i can use both the class simultaneously then full duplex is possible......... arnab/vu2bpw -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070604/6edb0453/attachment-0002.html From lists at iDIAcomputing.com Mon Jun 4 07:53:17 2007 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Mon, 04 Jun 2007 09:53:17 -0400 Subject: [Rxtx] full duplex com port with rxtx In-Reply-To: References: Message-ID: <4664194D.90301@iDIAcomputing.com> arnab bhaumik wrote: > hi , > > till now i did half duplex communication with rxtx package on com > package. > > my question is : is it possible to use com port with full duplex mode > with rxtx package . > > > ther is example of SimpleRead class and SimpleWrite class. it is > clear that if i can use both the class simultaneously then full duplex > is possible......... I haven't looked at the SimpleRead and SimpleWrite classes (I originally wrote my code for the javax.comm api), but full duplex is certainly possible. My CommReader class requires an object analogous to a OutputStream or Writer. When started, it spawns a thread that reads the comm port and writes to that output device. In this way the input is asynchronous and dependent on the actual input data. For full duplex, I extend that class with CommReaderWriter, which adds synchronous output methods. Hope that helps, George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From supsoop at hotmail.com Mon Jun 4 15:21:06 2007 From: supsoop at hotmail.com (soop soop) Date: Mon, 04 Jun 2007 21:21:06 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- Message-ID: Hi Guys, Looked through the archives but still cannot figure this out. I have a Motorola G24 GPRS/GSM modem that I am connecting to my server running Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not detecting the port, CommPortIdentifier.getPortIdentifiers(). I have added the line to RXTXCommDriver: "ttyACM" // for USB Modems Rxtx still does not seem to find the port. Is there something I am missing to make this port visable? [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control Model driver for USB modems and ISDN adapters I really need your help as I have moved my server from windows to Linux and have been down for a few days because of this .. Thanks so much! _________________________________________________________________ PC Magazine’s 2007 editors’ choice for best Web mail—award-winning Windows Live Hotmail. http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 From tjarvi at qbang.org Mon Jun 4 16:17:35 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Jun 2007 16:17:35 -0600 (MDT) Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: On Mon, 4 Jun 2007, soop soop wrote: > Hi Guys, > > Looked through the archives but still cannot figure this out. I have a > Motorola G24 GPRS/GSM modem that I am connecting to my server running Ubuntu. > I can see my modem as is shows up as ttyACM0, but RXTX is not detecting the > port, CommPortIdentifier.getPortIdentifiers(). > > I have added the line to RXTXCommDriver: > > "ttyACM" // for USB Modems > > Rxtx still does not seem to find the port. Is there something I am missing to > make this port visable? > > [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver > [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device > [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control Model > driver for USB modems and ISDN adapters > > I really need your help as I have moved my server from windows to Linux and > have been down for a few days because of this .. Thanks so much! > You could try the INSTALL documentation that comes with the source for possible solutions. Those usually involve lockfile creation, permissions on the device file or the device is in use by another application (even another session of your application). The usual commands: ls -l /dev/ttyACM0 fuser /dev/ttyACM0 touch /var/lock/LCK.testfile && rm -f /var/lock/LCK.testfile whoami To disable lockfiles: ../configure --disable-lockfiles && make install -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Jun 4 16:22:52 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 04 Jun 2007 18:22:52 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <466490BC.3090801@gatworks.com> soop soop wrote: > I really need your help as I have moved my server from windows to Linux > and have been down for a few days because of this .. Thanks so much! can u open the device ? ie is the file protection/permissions keeping you out? From supsoop at hotmail.com Mon Jun 4 16:44:40 2007 From: supsoop at hotmail.com (soop soop) Date: Mon, 04 Jun 2007 22:44:40 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <466490BC.3090801@gatworks.com> Message-ID: Thanks for the reply, I see no exceptions being thrown, just no detection of the port whats so ever. I will run rxtx in debug mode and log. If this were a permissions issue would I not see some exceptions being thrown? >From: Uncle George >Reply-To: RXTX Developers and Users >To: RXTX Developers and Users >Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >Date: Mon, 04 Jun 2007 18:22:52 -0400 > >soop soop wrote: > > > I really need your help as I have moved my server from windows to Linux > > and have been down for a few days because of this .. Thanks so much! > >can u open the device ? ie is the file protection/permissions keeping >you out? >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ Get a preview of Live Earth, the hottest event this summer - only on MSN http://liveearth.msn.com?source=msntaglineliveearthhm From netbeans at gatworks.com Mon Jun 4 17:06:15 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 04 Jun 2007 19:06:15 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <46649AE7.10405@gatworks.com> Exceptions on what? On startup it wants to lookup all devices in /dev that it is capable of opening ( within the list of specific 'comm' devices ). If it cannot open, then does not get onto list. Part of this process, if configured, will also test if the "LOCK" schema can also be opened for the device. then it gets on the list of avail comm port. soop soop wrote: > Thanks for the reply, > > I see no exceptions being thrown, just no detection of the port whats so > ever. I will run rxtx in debug mode and log. If this were a permissions > issue would I not see some exceptions being thrown? > > >> From: Uncle George >> Reply-To: RXTX Developers and Users >> To: RXTX Developers and Users >> Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >> Date: Mon, 04 Jun 2007 18:22:52 -0400 >> >> soop soop wrote: >> >>> I really need your help as I have moved my server from windows to Linux >>> and have been down for a few days because of this .. Thanks so much! >> can u open the device ? ie is the file protection/permissions keeping >> you out? >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _________________________________________________________________ > Get a preview of Live Earth, the hottest event this summer - only on MSN > http://liveearth.msn.com?source=msntaglineliveearthhm > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From alex.flint at gmail.com Mon Jun 4 21:31:49 2007 From: alex.flint at gmail.com (Alex Flint) Date: Tue, 5 Jun 2007 13:01:49 +0930 Subject: [Rxtx] random EXCEPTION_ACCESS_VIOLATION errors Message-ID: Hi All, I'm running winXP and RXTX 2.1-7r2 (the latest from the webpage as of June 2007). I'm sending sequences of 64 lines (each line has about 15 chars) at various intervals. The strings are sent fine, until I get the following error (from hs_err_pid3316.log, at the end of this email). What can I do to avoid the error? Obviously this is a low-level memory exception, but is there any way I can keep the JVM running after such an error? I noticed the exact same problem here: http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20070129/1180520.html Cheers, Alex # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x100034fb, pid=3316, tid=2400 # # Java VM: Java HotSpot(TM) Client VM (1.6.0_01-b06 mixed mode, sharing) # Problematic frame: # C [rxtxSerial.dll+0x34fb] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # --------------- T H R E A D --------------- Current thread (0x00386400): JavaThread "main" [_thread_in_native, id=2400] siginfo: ExceptionCode=0xc0000005, reading address 0x20726f78 Registers: EAX=0x20726f20, EBX=0x6d8922c0, ECX=0x00000005, EDX=0x20726f20 ESP=0x003efa30, EBP=0x003efb68, ESI=0x269728a0, EDI=0x00386400 EIP=0x100034fb, EFLAGS=0x00010212 Top of Stack: (sp=0x003efa30) 0x003efa30: 003efa3c 003efa64 0000000f ffffffff 0x003efa40: 003efa40 2a97f808 003efa6c 2b190ca8 0x003efa50: 00000000 2b190ec0 003efa90 008e2dd7 0x003efa60: 003efa90 008e2dd7 26977f88 6d815e72 0x003efa70: 00000004 2696eae0 0000008a 003efb0c 0x003efa80: 6d852b4a 2696eae0 00000003 26970930 0x003efa90: 000000cb 2696eae0 6d86b264 00385d40 0x003efaa0: 0000003f 003efb0c 26977f90 2ace65d8 Instructions: (pc=0x100034fb) 0x100034eb: ff ff 8d 76 00 eb 02 89 f6 90 8b 45 f8 8b 55 f8 0x100034fb: 8b 4a 58 83 c9 04 89 48 58 83 c4 f8 8b 45 f8 8b Stack: [0x003a0000,0x003f0000), sp=0x003efa30, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x34fb] Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j gnu.io.RXTXPort.writeArray([BIIZ)V+0 j gnu.io.RXTXPort$SerialOutputStream.write([B)V+76 j com.bjt.media.server.CommLink.send(Ljava/lang/String;)V+48 j com.bjt.media.server.DigitoolConnection.select(I)V+73 j com.bjt.media.server.DigitoolConnection.main([Ljava/lang/String;)V+74 v ~StubRoutines::call_stub --------------- P R O C E S S --------------- Java Threads: ( => current thread ) 0x02a69400 JavaThread "Thread-0" [_thread_in_native, id=3052] 0x02a4d000 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=3920] 0x02a48400 JavaThread "CompilerThread0" daemon [_thread_blocked, id=1968] 0x02a47400 JavaThread "Attach Listener" daemon [_thread_blocked, id=2984] 0x02a46400 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=2660] 0x02a41c00 JavaThread "Finalizer" daemon [_thread_blocked, id=3924] 0x02a3d800 JavaThread "Reference Handler" daemon [_thread_blocked, id=4008] =>0x00386400 JavaThread "main" [_thread_in_native, id=2400] Other Threads: 0x02a34400 VMThread [id=3708] 0x02a4e800 WatcherThread [id=3964] VM state:not at safepoint (normal execution) VM Mutex/Monitor currently owned by a thread: None Heap def new generation total 960K, used 131K [0x22960000, 0x22a60000, 0x22e40000) eden space 896K, 7% used [0x22960000, 0x22970ea8, 0x22a40000) from space 64K, 99% used [0x22a50000, 0x22a5fff8, 0x22a60000) to space 64K, 0% used [0x22a40000, 0x22a40000, 0x22a50000) tenured generation total 4096K, used 76K [0x22e40000, 0x23240000, 0x26960000) the space 4096K, 1% used [0x22e40000, 0x22e53060, 0x22e53200, 0x23240000) compacting perm gen total 12288K, used 137K [0x26960000, 0x27560000, 0x2a960000) the space 12288K, 1% used [0x26960000, 0x26982518, 0x26982600, 0x27560000) ro space 8192K, 62% used [0x2a960000, 0x2ae5e4e8, 0x2ae5e600, 0x2b160000) rw space 12288K, 52% used [0x2b160000, 0x2b7a0e78, 0x2b7a1000, 0x2bd60000) Dynamic libraries: 0x00400000 - 0x00423000 C:\Program Files\Java\jre1.6.0_01\bin\javaw.exe 0x7c900000 - 0x7c9b0000 C:\WINDOWS\system32\ntdll.dll 0x7c800000 - 0x7c8f4000 C:\WINDOWS\system32\kernel32.dll 0x77dd0000 - 0x77e6b000 C:\WINDOWS\system32\ADVAPI32.dll 0x77e70000 - 0x77f01000 C:\WINDOWS\system32\RPCRT4.dll 0x7e410000 - 0x7e4a0000 C:\WINDOWS\system32\USER32.dll 0x77f10000 - 0x77f57000 C:\WINDOWS\system32\GDI32.dll 0x76390000 - 0x763ad000 C:\WINDOWS\system32\IMM32.DLL 0x7c340000 - 0x7c396000 C:\Program Files\Java\jre1.6.0_01\bin\msvcr71.dll 0x6d7c0000 - 0x6da07000 C:\Program Files\Java\jre1.6.0_01\bin\client\jvm.dll 0x76b40000 - 0x76b6d000 C:\WINDOWS\system32\WINMM.dll 0x5cd70000 - 0x5cd77000 C:\WINDOWS\system32\serwvdrv.dll 0x5b0a0000 - 0x5b0a7000 C:\WINDOWS\system32\umdmxfrm.dll 0x6d310000 - 0x6d318000 C:\Program Files\Java\jre1.6.0_01\bin\hpi.dll 0x76bf0000 - 0x76bfb000 C:\WINDOWS\system32\PSAPI.DLL 0x6d770000 - 0x6d77c000 C:\Program Files\Java\jre1.6.0_01\bin\verify.dll 0x6d3b0000 - 0x6d3cf000 C:\Program Files\Java\jre1.6.0_01\bin\java.dll 0x6d7b0000 - 0x6d7bf000 C:\Program Files\Java\jre1.6.0_01\bin\zip.dll 0x10000000 - 0x10012000 C:\Documents and Settings\Alex\workspace\MediaServer\rxtxSerial.dll 0x73d90000 - 0x73db7000 C:\WINDOWS\system32\crtdll.dll VM Arguments: jvm_args: -Djava.library.path=C:\Documents and Settings\Alex\workspace\MediaServer java_command: com.bjt.media.server.DigitoolConnection Launcher Type: SUN_STANDARD Environment Variables: CLASSPATH=.;C:\Program Files\Java\j2re1.4.2_07\lib\ext\QTJava.zip PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\wbem;c:\applications\php;C:\Program Files\MATLAB\R2006a\bin\win32;C:\Roger\Projects\UAV\Bin\Debug;C:\Program Files\Microsoft SQL Server\80\Tools\Binn\;c:\Program Files\Microsoft SQL Server\90\Tools\binn\;C:\Program Files\QuickTime\QTSystem\;C:\Pfps\system;C:\Program Files\Java\jdk1.6.0_01\bin;C:\Program Files\Java\jdk1.6.0_01\jre\bin USERNAME=Alex OS=Windows_NT PROCESSOR_IDENTIFIER=x86 Family 15 Model 4 Stepping 1, GenuineIntel --------------- S Y S T E M --------------- OS: Windows XP Build 2600 Service Pack 2 CPU:total 1 family 15, cmov, cx8, fxsr, mmx, sse, sse2 Memory: 4k page, physical 1046508k(275288k free), swap 2522816k(1909176k free) vm_info: Java HotSpot(TM) Client VM (1.6.0_01-b06) for windows-x86, built on Mar 14 2007 00:24:02 by "java_re" with unknown MS VC++:1310 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070604/c87ae1f0/attachment-0002.html From alwyn.schoeman at gmail.com Tue Jun 5 00:10:19 2007 From: alwyn.schoeman at gmail.com (Alwyn Schoeman) Date: Tue, 5 Jun 2007 08:10:19 +0200 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Hi, I'm using a similar modem. By default rxtx doesn't look for devices that start with ACM, so you need to modify the source code and recompile. Look in RXTXCommDriver and add values for ACM in the registerScannedPorts method in the Linux specific parts. Look for osName.equals("Linux")... On 6/4/07, soop soop wrote: > > Hi Guys, > > Looked through the archives but still cannot figure this out. I have a > Motorola G24 GPRS/GSM modem that I am connecting to my server running > Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not > detecting the port, CommPortIdentifier.getPortIdentifiers(). > > I have added the line to RXTXCommDriver: > > "ttyACM" // for USB Modems > > Rxtx still does not seem to find the port. Is there something I am missing > to make this port visable? > > [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver > [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device > [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control > Model > driver for USB modems and ISDN adapters > > I really need your help as I have moved my server from windows to Linux > and > have been down for a few days because of this .. Thanks so much! > > _________________________________________________________________ > PC Magazine's 2007 editors' choice for best Web mail?award-winning Windows > Live Hotmail. > > http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -- Alwyn Schoeman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/b6cb3053/attachment-0002.html From naranjo.manuel at gmail.com Tue Jun 5 06:48:45 2007 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Tue, 05 Jun 2007 09:48:45 -0300 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> References: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Message-ID: <46655BAD.7010501@gmail.com> That's right, an easier solution is creating symlinks to acm. For example make ttyS70 to 79 point to ACM0 to 9 and that will help you a lot, and doesn't even require compile. > Hi, > > I'm using a similar modem. By default rxtx doesn't look for devices > that start with ACM, so you need to modify the > source code and recompile. > > Look in RXTXCommDriver and add values for ACM in the > registerScannedPorts method in the Linux specific parts. Look for > osName.equals("Linux")... > From juanemc2 at gmail.com Tue Jun 5 07:02:43 2007 From: juanemc2 at gmail.com (Juan) Date: Tue, 5 Jun 2007 10:02:43 -0300 Subject: [Rxtx] Problems with Epson TMU220B POSPrinter using XON/XOFF Flow Control and rxtx jar and dll's with the serial port. Message-ID: Hi!, I?m having trouble printing to the serial port using the latest version of rxtx jar and dll's with an Epson POSPrinter. I`ve switched the printer to work with XON/XOFF Flow Control and have watched the serial port to be sure the printer is sending the XON XOFF stop and go characters. I`ve setted the port like this: CommPortIdentifier commPortIdentifier = CommPortIdentifier.* getPortIdentifier*(_portName); SerialPort serialPort = (SerialPort)commPortIdentifier.open(*this*.getClass().getName(), 2000); serialPort.setSerialPortParams(_baudRate, _dataBits, _stopBits, _parity); serialPort.setFlowControlMode( SerialPort.*FLOWCONTROL_XONXOFF_IN* | SerialPort.*FLOWCONTROL_XONXOFF_OUT*); where the baudRate is 9600 the dataBits is 8 the stopBits is 1 and the parity is 0 It seems as the library isn`t taking into account the XON XOFF setting. I would like to know if I`m setting correctly the Flow Control and if you had had any experiences using XON XOFF flow control and could give me some help to solve my problem. I`m very thankful in advance, Yours, Juan Polero -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/b080995a/attachment-0002.html From ehdez.correo at gmail.com Tue Jun 5 07:12:53 2007 From: ehdez.correo at gmail.com (=?ISO-8859-1?Q?Enrique_Hern=E1ndez?=) Date: Tue, 5 Jun 2007 09:12:53 -0400 Subject: [Rxtx] problem with rxtx Message-ID: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Hello: I doing a simple test to show the serial ports. This is the code: import java.util.Enumeration; import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; public class Show { private Enumeration portList; private CommPortIdentifier portId; private SerialPort port; /** Creates a new instance of Show */ public Show() { } public static void main(String args[]){ Show show = new Show(); show.portList = CommPortIdentifier.getPortIdentifiers(); String tPort = ""; System.out.println("========================================="); while(show.portList.hasMoreElements()){ show.portId = (CommPortIdentifier)show.portList.nextElement(); if(show.portId.getPortType() == CommPortIdentifier.PORT_SERIAL) tPort = "Serial"; else tPort = "Parallel"; System.out.println(show.portId.getName() + " " + tPort); } } } whit The problem is that this code not show the serial ports, this show the no use serial ports. I want to connect whit the modem but when windows open and connect the modem my application don't see the port(COMM3) when it is connect. what I can do? Is that the correct way to know the ports? thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/eedd744b/attachment-0002.html From ehdez.correo at gmail.com Tue Jun 5 07:42:13 2007 From: ehdez.correo at gmail.com (=?ISO-8859-1?Q?Enrique_Hern=E1ndez?=) Date: Tue, 5 Jun 2007 09:42:13 -0400 Subject: [Rxtx] serial port Message-ID: <4a814e1f0706050642p4ce9ac7bka80f9479c524c5ea@mail.gmail.com> Hello: How I can ask to the port what device is connect and information about this device. thanks. bye. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/4d10d26a/attachment-0002.html From supsoop at hotmail.com Tue Jun 5 09:29:00 2007 From: supsoop at hotmail.com (soop soop) Date: Tue, 05 Jun 2007 15:29:00 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Message-ID: Hi Guys, Thanks for all your help. I found the problem. I created a user, Tomcat55, for my tomcat but it did not belong to any group. I then added this user to dialout group to have access to the device ttyACM0. Works perfectly! Again permissions was the issue. This also seems to be persistent as a server reboot does not effect the access. Cheers! >From: "Alwyn Schoeman" >Reply-To: RXTX Developers and Users >To: "RXTX Developers and Users" >Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >Date: Tue, 5 Jun 2007 08:10:19 +0200 > >Hi, > >I'm using a similar modem. By default rxtx doesn't look for devices that >start with ACM, so you need to modify the >source code and recompile. > >Look in RXTXCommDriver and add values for ACM in the registerScannedPorts >method in the Linux specific parts. Look for osName.equals("Linux")... > >On 6/4/07, soop soop wrote: >> >>Hi Guys, >> >>Looked through the archives but still cannot figure this out. I have a >>Motorola G24 GPRS/GSM modem that I am connecting to my server running >>Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not >>detecting the port, CommPortIdentifier.getPortIdentifiers(). >> >>I have added the line to RXTXCommDriver: >> >>"ttyACM" // for USB Modems >> >>Rxtx still does not seem to find the port. Is there something I am missing >>to make this port visable? >> >>[ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver >>[ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device >>[ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control >>Model >>driver for USB modems and ISDN adapters >> >>I really need your help as I have moved my server from windows to Linux >>and >>have been down for a few days because of this .. Thanks so much! >> >>_________________________________________________________________ >>PC Magazine's 2007 editors' choice for best Web mail—award-winning Windows >>Live Hotmail. >> >>http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 >> >> >>_______________________________________________ >>Rxtx mailing list >>Rxtx at qbang.org >>http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > >-- >Alwyn Schoeman >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ Need a break? Find your escape route with Live Search Maps. http://maps.live.com/default.aspx?ss=Restaurants~Hotels~Amusement%20Park&cp=33.832922~-117.915659&style=r&lvl=13&tilt=-90&dir=0&alt=-1000&scene=1118863&encType=1&FORM=MGAC01 From netbeans at gatworks.com Tue Jun 5 09:42:31 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 11:42:31 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <46658467.20101@gatworks.com> soop soop wrote: > > Hi Guys, > > Thanks for all your help. I found the problem. I created a user, > Tomcat55, for my tomcat but it did not belong to any group. I then added Look at man pages for the program udev. From tjarvi at qbang.org Tue Jun 5 18:18:17 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Jun 2007 18:18:17 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Message-ID: On Tue, 5 Jun 2007, Enrique Hern?ndez wrote: > The problem is that this code not show the serial ports, this show the no > use serial ports. I want to connect whit the modem but when windows open and > connect the modem my application don't see the port(COMM3) when it is > connect. > what I can do? > Is that the correct way to know the ports? > Hello, We may have problems understanding each other. On windows, the port will not be an available serial port if another application has the port open. That is just how the library behaves. If you can not see the port in the enumerated list, you could not open it. Also note that enumeration only happens once. If you add a port such as a new USB dongle, the port will not be visible until the next time your application runs. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Tue Jun 5 18:45:01 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 20:45:01 -0400 Subject: [Rxtx] problem with rxtx In-Reply-To: References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Message-ID: <4666038D.8090700@gatworks.com> Trent Jarvi wrote: > > > Also note that enumeration only happens once. If you add a port such as > a new USB dongle, the port will not be visible until the next time your > application runs. Is this written in stone ? somewhere? From tjarvi at qbang.org Tue Jun 5 18:54:36 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Jun 2007 18:54:36 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <4666038D.8090700@gatworks.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> Message-ID: On Tue, 5 Jun 2007, Uncle George wrote: > Trent Jarvi wrote: >> >> >> Also note that enumeration only happens once. If you add a port such as >> a new USB dongle, the port will not be visible until the next time your >> application runs. > > Is this written in stone ? somewhere? It is just the current behavior. There is nothing preventing a fix that allows reenumeration. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Tue Jun 5 19:55:19 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 21:55:19 -0400 Subject: [Rxtx] problem with rxtx In-Reply-To: References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> Message-ID: <46661407.4020308@gatworks.com> >> Is this written in stone ? somewhere? > > It is just the current behavior. There is nothing preventing a fix that > allows reenumeration. With usb, ..... , things come and go. Seems a shame that you have to kill application to get at the device u just plugged in. From joachim at buechse.ch Wed Jun 6 01:50:06 2007 From: joachim at buechse.ch (Joachim Buechse) Date: Wed, 6 Jun 2007 09:50:06 +0200 Subject: [Rxtx] problem with rxtx In-Reply-To: <46661407.4020308@gatworks.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> <46661407.4020308@gatworks.com> Message-ID: <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> On MacOS RXTX's enumeration handling is more flexible. It will find new ports that are added during the lifetime of the application. But this is inherently incompatible with suns javax.comm implementation... Regards, Joachim On 06.06.2007, at 03:55, Uncle George wrote: > >>> Is this written in stone ? somewhere? >> >> It is just the current behavior. There is nothing preventing a >> fix that >> allows reenumeration. > > With usb, ..... , things come and go. Seems a shame that you have to > kill application to get at the device u just plugged in. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Jun 6 06:06:48 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Jun 2007 06:06:48 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> <46661407.4020308@gatworks.com> <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> Message-ID: Sun's javax.comm is not a major concern going forward. As long as we do not break old applications using rxtx, I see no reason to limit rxtx to that convention. We have already rejected version 3 from Sun as a dead end and limited our compatability to version 2. That does not mean we will not try to work with Sun and others but the current javax.comm convention (v3) is not a well conceived path. There has been discussion about doing a JSR which is one valid option. On Wed, 6 Jun 2007, Joachim Buechse wrote: > On MacOS RXTX's enumeration handling is more flexible. It will find > new ports that are added during the lifetime of the application. But > this is inherently incompatible with suns javax.comm implementation... > > Regards, > Joachim > > On 06.06.2007, at 03:55, Uncle George wrote: > >> >>>> Is this written in stone ? somewhere? >>> >>> It is just the current behavior. There is nothing preventing a >>> fix that >>> allows reenumeration. >> >> With usb, ..... , things come and go. Seems a shame that you have to >> kill application to get at the device u just plugged in. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From yvespielusenet at free.fr Wed Jun 6 08:46:35 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 16:46:35 +0200 Subject: [Rxtx] [PARALLEL] resource in use Message-ID: <1181141195.3407.20.camel@localhost.localdomain> Hello, I want to use rxtx in my application. I haveto send data to a very old printer (which have a drum and hammers http://perso.orange.fr/tiie/page00010017.html) This is printer is connecter with centronics. It works well but, while it's writting and I putthe printer off-line, after about 45 seconds, I have this error : ------------------------------------- java.io.IOException: La ressource demand?e est en cours d'utilisation. in writeArray at gnu.io.LPRPort.writeArray(Native Method) at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:292) at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:161) at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:156) at mce.buffer.bufferManager.BufferManager$PrintBuffer.run(BufferManager.java:141) The IOexception means "The wanted resource is in use" ------------------------------------- Here is the line 141 of BufferManager : ------------------------------------- while(send){ try{ fos.write(bb); <=== line 141 send = false; } catch(Exception e){ javax.swing.JOptionPane.showMessageDialog(null, "Erreur d'envoie. Veuillez cliquer sur OK pour relancer l'impression de la vignette.\nV?rifiez votre impression !", "Erreur d'envoie", javax.swing.JOptionPane.WARNING_MESSAGE); e.printStackTrace(System.err); System.err.flush(); System.out.println(e); send = true; } } -------------------------------- 'fos' is an outputstream which contains the rxtx stream (this.os is the rxtx outputstream) : -------------------------------- public void write(byte[] bb) throws IOException{ this.write(bb, 0, bb.length); } public void write(byte[] bb, int off, int len) throws IOException{ while(!imp1.isPrinterSelected() || !imp2.isPrinterSelected()){ } this.os.write(bb, off, len); } -------------------------------- Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( can you help me ? thank you :) -- yves piel From yvespielusenet at free.fr Wed Jun 6 09:11:15 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 17:11:15 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181141195.3407.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> Message-ID: <1181142675.3407.23.camel@localhost.localdomain> I forgot to tell that It's under windows XP and java 1.5. Le mercredi 06 juin 2007 ? 16:46 +0200, yves pielusenet a ?crit : > Hello, > I want to use rxtx in my application. I haveto send data to a very old > printer (which have a drum and hammers > http://perso.orange.fr/tiie/page00010017.html) > This is printer is connecter with centronics. It works well but, while > it's writting and I putthe printer off-line, after about 45 seconds, I > have this error : > ------------------------------------- > java.io.IOException: La ressource demand?e est en cours d'utilisation. > in writeArray > at gnu.io.LPRPort.writeArray(Native Method) > at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:292) > at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:161) > at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:156) > at mce.buffer.bufferManager.BufferManager$PrintBuffer.run(BufferManager.java:141) > > The IOexception means "The wanted resource is in use" > ------------------------------------- > > Here is the line 141 of BufferManager : > > ------------------------------------- > while(send){ > try{ > fos.write(bb); <=== line 141 > send = false; > } > catch(Exception e){ > javax.swing.JOptionPane.showMessageDialog(null, "Erreur d'envoie. Veuillez cliquer sur OK pour relancer l'impression de la vignette.\nV?rifiez votre impression !", "Erreur d'envoie", javax.swing.JOptionPane.WARNING_MESSAGE); > e.printStackTrace(System.err); > System.err.flush(); > System.out.println(e); > send = true; > } > } > -------------------------------- > 'fos' is an outputstream which contains the rxtx stream (this.os is the rxtx outputstream) : > > -------------------------------- > public void write(byte[] bb) throws IOException{ > this.write(bb, 0, bb.length); > } > public void write(byte[] bb, int off, int len) throws IOException{ > while(!imp1.isPrinterSelected() || !imp2.isPrinterSelected()){ > } > this.os.write(bb, off, len); > } > -------------------------------- > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > can you help me ? > > thank you :) > From netbeans at gatworks.com Wed Jun 6 09:21:46 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 11:21:46 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181141195.3407.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> Message-ID: <4666D10A.8000507@gatworks.com> } > -------------------------------- > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > can you help me ? > > thank you :) > windoz or linux? ( I guess windoz ) for windoz, there appears to be a timeout ( as Comments suggest ) of about 40seconds. > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } for linux, there is no implied timeout. > if( write( fd, bytes, count ) < 0 ) > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); From netbeans at gatworks.com Wed Jun 6 09:39:41 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 11:39:41 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666D10A.8000507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> Message-ID: <4666D53D.90000@gatworks.com> Uncle George wrote: > } >> -------------------------------- >> >> Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( >> >> can you help me ? From reading the code, I can see your concern. And it appears you are correct, because some of the data will be sent to the OS printer buffers, and then it will refuse to accept anymore. Unfortunately, writeArray does not return the num of characters written :{ So application has no idea to how many characters were accepted by the OS. I dont do windoz, so I cant say with absolute certainty what windoz will do with an off-line condition. If you have the source, and can compile, then maybe u can increase the loop count to hit 4hours? From yvespielusenet at free.fr Wed Jun 6 09:53:25 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 17:53:25 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666D10A.8000507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> Message-ID: <1181145205.3407.35.camel@localhost.localdomain> Thank you for your explanation :) This timeout comes when no data has been send to the printer after 40seconds if I well understand. But why there is such a timeout ? If I setthe printer offline while it's printing I mustn't have an exception. I don't understand why the "printer should solv all problems like buffer full" in 40 seconds. If I pause the printer the buffer will not be emptied, isn't it ? I not very familiar with C/C++, but it seem that the exception is thrown only when countWritten == 0, that means no data at all has been sent. So Is my code is good since when I intercept this exception I send all my buffer again. There is no way that the printer receive two times same bytes ? thanks ps: yes the application is running on windows XP since I developpe under Debian Le mercredi 06 juin 2007 ? 11:21 -0400, Uncle George a ?crit : > } > > -------------------------------- > > > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > > > can you help me ? > > > > thank you :) > > > > windoz or linux? ( I guess windoz ) > > for windoz, there appears to be a timeout ( as Comments suggest ) of > about 40seconds. > > while( count > 0 ){ > > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > > /* > > this are 20 * 2 seconds, in this time a printer (or other parallel device) > > should solv all problems like buffer full, etc > > */ > > if(errorCount++ < 20){ > > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > > continue; > > } > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > for linux, there is no implied timeout. > > if( write( fd, bytes, count ) < 0 ) > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Wed Jun 6 10:34:24 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 12:34:24 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181145205.3407.35.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> Message-ID: <4666E210.30507@gatworks.com> yves pielusenet wrote: > Thank you for your explanation :) > This timeout comes when no data has been send to the printer after > 40seconds if I well understand. But why there is such a timeout ? If I > setthe printer offline while it's printing I mustn't have an exception. > I don't understand why the "printer should solv all problems like buffer > full" in 40 seconds. If I pause the printer the buffer will not be > emptied, isn't it ? > > I not very familiar with C/C++, but it seem that the exception is thrown > only when countWritten == 0, that means no data at all has been sent. So > Is my code is good since when I intercept this exception I send all my > buffer again. There is no way that the printer receive two times same > bytes ? More technically, the function call returns and reports that 0 characters was written in this call. when 0 characters are written, it will check how many times 0 characters was written. If it has tried LESS than 20 times(errorCount), it will sleep() and try to write again. After 20 times, it wont sleep, but throw you the exception. Now suppose you are writing a 120 character line. you off-lined/paused your printer. The OS has room for 80 more characters in it's printer buffer. The WriteFile() will have a char count of 120, but on return the countWritten = 80. You still have 40 more characters to print. Since countWritten != 0, the counters: bytes += countWritten; count -= countWritten; get updated, and the Writefile now has a count of 40 characters. Since the printer is off-line, the countwritten is 0. And so the loop continues, till 40 seconds is up. As to why it is this way, i dont know ( not a windoz maven ); Also the sleep(20) in the loop is not so intuitive to suggest 2 seconds of sleep. I would have guessed 20seconds, or 20milliseconds. But go figure. BTW: Since your computer sends you error messages in French, does it curse in English? :)))) From yvespielusenet at free.fr Thu Jun 7 02:27:44 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Thu, 07 Jun 2007 10:27:44 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666E210.30507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> Message-ID: <1181204864.3501.10.camel@localhost.localdomain> Maybe in my case I should re-compile rxtx and change the code. Instead of send an exception I should display a dialog box to ask if it's printer problem or if it should trie to send bytes. Something like : while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } if(displayDialogBox("Try again to send datas ??")){ errorCount = 0; } else{ throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } } Le mercredi 06 juin 2007 ? 12:34 -0400, Uncle George a ?crit : > yves pielusenet wrote: > > Thank you for your explanation :) > > This timeout comes when no data has been send to the printer after > > 40seconds if I well understand. But why there is such a timeout ? If I > > setthe printer offline while it's printing I mustn't have an exception. > > I don't understand why the "printer should solv all problems like buffer > > full" in 40 seconds. If I pause the printer the buffer will not be > > emptied, isn't it ? > > > > I not very familiar with C/C++, but it seem that the exception is thrown > > only when countWritten == 0, that means no data at all has been sent. So > > Is my code is good since when I intercept this exception I send all my > > buffer again. There is no way that the printer receive two times same > > bytes ? > More technically, the function call returns and reports that 0 > characters was written in this call. > when 0 characters are written, it will check how many times 0 characters > was written. If it has tried LESS than 20 times(errorCount), it will > sleep() and try to write again. > After 20 times, it wont sleep, but throw you the exception. > > Now suppose you are writing a 120 character line. you off-lined/paused > your printer. The OS has room for 80 more characters in it's printer > buffer. The WriteFile() will have a char count of 120, but on return the > countWritten = 80. You still have 40 more characters to print. > Since countWritten != 0, the counters: > bytes += countWritten; > count -= countWritten; > get updated, and the Writefile now has a count of 40 characters. Since > the printer is off-line, the countwritten is 0. And so the loop > continues, till 40 seconds is up. > > As to why it is this way, i dont know ( not a windoz maven ); > Also the sleep(20) in the loop is not so intuitive to suggest 2 seconds > of sleep. I would have guessed 20seconds, or 20milliseconds. But go figure. > > BTW: Since your computer sends you error messages in French, does it > curse in English? :)))) > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 06:11:43 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 08:11:43 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181204864.3501.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> Message-ID: <4667F5FF.8070903@gatworks.com> your suggestion appears good. I dont know what displayDialogBox exactly will do, so all I can say it that it looks good. But I'd like to wait 10min before first dialog box And a 5 min wait for every dialog box there after. And since these are custom solution/choices, maybe a more exact explanation of what the issue is. if(errorCount++ < 300){ // wait 10min ( 10min * 60sec / 2 ) Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } if(displayDialogBox("Printer has Paused. Retry sending data?")){ errorCount = 150; // Wait for 5 min thereafter continue; } > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } yves pielusenet wrote: > Maybe in my case I should re-compile rxtx and change the code. Instead > of send an exception I should display a dialog box to ask if it's > printer problem or if it should trie to send bytes. Something like : > > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > > if(displayDialogBox("Try again to send datas ??")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > } > From yvespielusenet at free.fr Thu Jun 7 07:17:21 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Thu, 07 Jun 2007 15:17:21 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4667F5FF.8070903@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <4667F5FF.8070903@gatworks.com> Message-ID: <1181222241.3501.20.camel@localhost.localdomain> thank you :) 'displayDialogBox()' I think doesn't exist. It was just for the example :) But I think It should not be so complicated to display a dialog box under windows with YES/NO buttons. When yes is clicked it return 0 other it returns 1. Le jeudi 07 juin 2007 ? 08:11 -0400, Uncle George a ?crit : > your suggestion appears good. I dont know what displayDialogBox exactly > will do, so all I can say it that it looks good. > > But I'd like to wait 10min before first dialog box And a 5 min wait for > every dialog box there after. And since these are custom > solution/choices, maybe a more exact explanation of what the issue is. > > if(errorCount++ < 300){ // wait 10min ( 10min * 60sec / 2 ) > Sleep( 20 ); /* make a small pause to execute all other requests > in all other threads */ > continue; > } > > if(displayDialogBox("Printer has Paused. Retry sending data?")){ > errorCount = 150; // Wait for 5 min thereafter > continue; > } > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > > yves pielusenet wrote: > > Maybe in my case I should re-compile rxtx and change the code. Instead > > of send an exception I should display a dialog box to ask if it's > > printer problem or if it should trie to send bytes. Something like : > > > > while( count > 0 ){ > > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > > /* > > this are 20 * 2 seconds, in this time a printer (or other parallel device) > > should solv all problems like buffer full, etc > > */ > > if(errorCount++ < 20){ > > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > > continue; > > } > > > > if(displayDialogBox("Try again to send datas ??")){ > > errorCount = 0; > > } > > else{ > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > } > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 07:41:43 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 09:41:43 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181222241.3501.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <4667F5FF.8070903@gatworks.com> <1181222241.3501.20.camel@localhost.localdomain> Message-ID: <46680B17.8050109@gatworks.com> yves pielusenet wrote: > thank you :) > 'displayDialogBox()' I think doesn't exist. It was just for the > example :) too bad. Good luck. From rtrout at webbresearch.com Thu Jun 7 11:23:04 2007 From: rtrout at webbresearch.com (Robert Trout) Date: Thu, 07 Jun 2007 13:23:04 -0400 Subject: [Rxtx] Disconnected PortServer TS causes Java to hang Message-ID: <1181236984.14186.33.camel@sisyphus.DinkumSoftware.com> I'm running Linux with sun's Java 1.4.2, Java comm API 2.0, RXTX 2.0-7pre1, and the RealPort digi driver. "/dev/ttyrp00" is a RealPort device. My Java application never returns from a ComPortIdentifier.getPortIdentifier("/dev/ttyrp00") call while the Digi PortServer TS 4 is disconnected from the network. If I later re-connect the PortServer, the call returns about 30 seconds later (it's like a serial port read or write is blocking until the PortServer is re- connected). With the PortServer disconnected, minicom immediately responds with "cannot open /dev/ttyrp00: No such file or directory". I would like my Java application to behave similarly. That is, respond with an error condition instead of hanging when the PortServer is not connected. Since minicom and Java behave differently, I think this "hanging" behavior may be due to RXTX or Java? Has anyone had a similar issue? Solutions? Suggestions? Thanks, Robert From vicnevicne at gmail.com Thu Jun 7 12:16:02 2007 From: vicnevicne at gmail.com (Vicne) Date: Thu, 07 Jun 2007 20:16:02 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181204864.3501.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> Message-ID: <46684B62.7080802@gmail.com> yves pielusenet wrote: > Maybe in my case I should re-compile rxtx and change the code. Instead > of send an exception I should display a dialog box to ask if it's > printer problem or if it should trie to send bytes. Something like : > > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > > if(displayDialogBox("Try again to send datas ??")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > } > Sorry to step in without a specific solution to your problem, but I wanted to share my feeling regarding this proposal. AFAIK, it's generally considered bad practice to pop-up a prompt from a library. The main reason is that in general use, you can't guarantee that someone is actually present behind the console. Imagine a print server in a machine room, connected to a park of printers. In that case, when one printer fails, the logical behaviour would be to use an other one. If you change RxTx the way you propose, the printer queue will simply be stuck with a useless "Try again to send data ?" prompt until an administrator opens a remote connection to the print server's console and clicks "no". Second, it would create a dependency upon the existence of a graphical console (if you go the graphical "dialogBox" way). On many applications (typically server or embedded ones), the JVM is "headless" and if you try to pop-up a dialog, your app would throw an exception (at best) or just wouldn't display the prompt anywhere... Going the "text console" way is not more reliable, because on graphical environments, the text console is hidden unless explicitly requested. My advice would be to think again and find another solution. Ideas are : - make the number of retries a parameter so that you can tune it to what you think is reasonable - throw a more specific exception when the number of retries has been reached, so that a specific prompt can be shown at a higher level Anyway, if you feel that the prompt is the way to go in your case, I would at least make that prompt conditional. The least intrusive way would probably be using a system property, like if("true".equals(System.getProperty("org.rxtx.usePrompt")) && displayDialogBox("Retry sending data ?")){ errorCount = 0; } else{ throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } By default, the behaviour would remain as it is now, but you could force the prompts by defining the property at VM launch if desired. (for example : java.exe -Dorg.rxtx.usePrompt=true myApp) Also, you seemed to say you wanted the printer to start again exactly where is stopped. It would indeed be the best way when the printer is put offline for a few seconds. On the other hand, if the printer is turned off (or the printer runs out of paper, or someone steps on the mains cable), then the only way to go back to a "stable" situation would be by printing the item (page, label, etc.) again from scratch... Just my two cents. Vicne PS : By the way, the dialog box thing is very platform dependant on the C-side, and I think the simplest way would probably be to bridge it to a Java call where you can implement it like you proposed : public boolean displayDialogBox(prompt) { return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); } From netbeans at gatworks.com Thu Jun 7 14:08:24 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 16:08:24 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46684B62.7080802@gmail.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> Message-ID: <466865B8.4060004@gatworks.com> My feeling is that the code that was suggested was for his environs ( his shop ). The issue here is that after a 40+ second wait, an exception will be thrown. But you really dont have a way of 'cancelling' all the WriteFiles() that have already occured before the exception so that your writeArray and the Commapi can backtrack to a position in which they are in sync. The main ( really mine ) concern is not to lose data, or replicate data. After 40seconds, 300 seconds, 55min, no matter how long, data should not be lost or duplicated. But as soon as the exception is thrown, that possibility exists. Maybe an event should be thrown instead? Vicne wrote: > yves pielusenet wrote: >> Maybe in my case I should re-compile rxtx and change the code. Instead >> of send an exception I should display a dialog box to ask if it's >> printer problem or if it should trie to send bytes. Something like : >> >> while( count > 0 ){ >> if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ >> /* >> this are 20 * 2 seconds, in this time a printer (or other parallel device) >> should solv all problems like buffer full, etc >> */ >> if(errorCount++ < 20){ >> Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ >> continue; >> } >> >> if(displayDialogBox("Try again to send datas ??")){ >> errorCount = 0; >> } >> else{ >> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >> break; >> } >> } >> > > Sorry to step in without a specific solution to your problem, but I > wanted to share my feeling regarding this proposal. AFAIK, it's > generally considered bad practice to pop-up a prompt from a library. > The main reason is that in general use, you can't guarantee that > someone is actually present behind the console. Imagine a print server > in a machine room, connected to a park of printers. In that case, when > one printer fails, the logical behaviour would be to use an other one. > If you change RxTx the way you propose, the printer queue will simply be > stuck with a useless "Try again to send data ?" prompt until an > administrator opens a remote connection to the print server's console > and clicks "no". > Second, it would create a dependency upon the existence of a > graphical console (if you go the graphical "dialogBox" way). On many > applications (typically server or embedded ones), the JVM is "headless" > and if you try to pop-up a dialog, your app would throw an exception (at > best) or just wouldn't display the prompt anywhere... Going the "text > console" way is not more reliable, because on graphical environments, > the text console is hidden unless explicitly requested. > > My advice would be to think again and find another solution. Ideas are : > - make the number of retries a parameter so that you can tune it to what > you think is reasonable > - throw a more specific exception when the number of retries has been > reached, so that a specific prompt can be shown at a higher level > > Anyway, if you feel that the prompt is the way to go in your case, I > would at least make that prompt conditional. The least intrusive way > would probably be using a system property, like > > if("true".equals(System.getProperty("org.rxtx.usePrompt")) > && displayDialogBox("Retry sending data ?")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > > > By default, the behaviour would remain as it is now, but you could > force the prompts by defining the property at VM launch if desired. (for > example : java.exe -Dorg.rxtx.usePrompt=true myApp) > > > Also, you seemed to say you wanted the printer to start again > exactly where is stopped. It would indeed be the best way when the > printer is put offline for a few seconds. On the other hand, if the > printer is turned off (or the printer runs out of paper, or someone > steps on the mains cable), then the only way to go back to a "stable" > situation would be by printing the item (page, label, etc.) again from > scratch... > > > Just my two cents. > > > Vicne > > PS : By the way, the dialog box thing is very platform dependant on the > C-side, and I think the simplest way would probably be to bridge it to a > Java call where you can implement it like you proposed : > > public boolean displayDialogBox(prompt) { > return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", > JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); > } > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Thu Jun 7 17:48:11 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 Jun 2007 17:48:11 -0600 (MDT) Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <466865B8.4060004@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> Message-ID: An event is possible. I'm amazed this is the largest problem encountered while using the parallel code. How would the write ever exit if we throw events? Isn't this going to lead to hung applications? On Thu, 7 Jun 2007, Uncle George wrote: > My feeling is that the code that was suggested was for his environs ( > his shop ). > > The issue here is that after a 40+ second wait, an exception will be > thrown. But you really dont have a way of 'cancelling' all the > WriteFiles() that have already occured before the exception so that your > writeArray and the Commapi can backtrack to a position in which they are > in sync. > > The main ( really mine ) concern is not to lose data, or replicate data. > After 40seconds, 300 seconds, 55min, no matter how long, data should > not be lost or duplicated. But as soon as the exception is thrown, that > possibility exists. > > Maybe an event should be thrown instead? > > Vicne wrote: >> yves pielusenet wrote: >>> Maybe in my case I should re-compile rxtx and change the code. Instead >>> of send an exception I should display a dialog box to ask if it's >>> printer problem or if it should trie to send bytes. Something like : >>> >>> while( count > 0 ){ >>> if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ >>> /* >>> this are 20 * 2 seconds, in this time a printer (or other parallel device) >>> should solv all problems like buffer full, etc >>> */ >>> if(errorCount++ < 20){ >>> Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ >>> continue; >>> } >>> >>> if(displayDialogBox("Try again to send datas ??")){ >>> errorCount = 0; >>> } >>> else{ >>> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >>> break; >>> } >>> } >>> >> >> Sorry to step in without a specific solution to your problem, but I >> wanted to share my feeling regarding this proposal. AFAIK, it's >> generally considered bad practice to pop-up a prompt from a library. >> The main reason is that in general use, you can't guarantee that >> someone is actually present behind the console. Imagine a print server >> in a machine room, connected to a park of printers. In that case, when >> one printer fails, the logical behaviour would be to use an other one. >> If you change RxTx the way you propose, the printer queue will simply be >> stuck with a useless "Try again to send data ?" prompt until an >> administrator opens a remote connection to the print server's console >> and clicks "no". >> Second, it would create a dependency upon the existence of a >> graphical console (if you go the graphical "dialogBox" way). On many >> applications (typically server or embedded ones), the JVM is "headless" >> and if you try to pop-up a dialog, your app would throw an exception (at >> best) or just wouldn't display the prompt anywhere... Going the "text >> console" way is not more reliable, because on graphical environments, >> the text console is hidden unless explicitly requested. >> >> My advice would be to think again and find another solution. Ideas are : >> - make the number of retries a parameter so that you can tune it to what >> you think is reasonable >> - throw a more specific exception when the number of retries has been >> reached, so that a specific prompt can be shown at a higher level >> >> Anyway, if you feel that the prompt is the way to go in your case, I >> would at least make that prompt conditional. The least intrusive way >> would probably be using a system property, like >> >> if("true".equals(System.getProperty("org.rxtx.usePrompt")) >> && displayDialogBox("Retry sending data ?")){ >> errorCount = 0; >> } >> else{ >> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >> break; >> } >> >> >> By default, the behaviour would remain as it is now, but you could >> force the prompts by defining the property at VM launch if desired. (for >> example : java.exe -Dorg.rxtx.usePrompt=true myApp) >> >> >> Also, you seemed to say you wanted the printer to start again >> exactly where is stopped. It would indeed be the best way when the >> printer is put offline for a few seconds. On the other hand, if the >> printer is turned off (or the printer runs out of paper, or someone >> steps on the mains cable), then the only way to go back to a "stable" >> situation would be by printing the item (page, label, etc.) again from >> scratch... >> >> >> Just my two cents. >> >> >> Vicne >> >> PS : By the way, the dialog box thing is very platform dependant on the >> C-side, and I think the simplest way would probably be to bridge it to a >> Java call where you can implement it like you proposed : >> >> public boolean displayDialogBox(prompt) { >> return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", >> JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); >> } >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 19:18:51 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 21:18:51 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> Message-ID: <4668AE7B.3060409@gatworks.com> The UNIX version of writeArray is not too great either. It is possible that the write will only process some of the bytes. #else if( write( fd, bytes, count ) < 0 ) throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); #endif -------------------------------- Maybe it might be better to have the native function inform the caller of the # of characters written, then the commapi/output-buffer can be modified to reflect the #of chars written. If an exception is to be thrown, for too many loops of chars written == 0, then exception wont affect the state of the output buffer. Then a ParallelPort.restart() can be called to resume printing whats in the buffer. Trent Jarvi wrote: > An event is possible. I'm amazed this is the largest problem encountered > while using the parallel code. > > How would the write ever exit if we throw events? Isn't this going to > lead to hung applications? Sure. If you dont time out, then there is nothing that will force an EXIT from the write(). Issue is what has the OS done with the write. > > On Thu, 7 Jun 2007, Uncle George wrote: > >> My feeling is that the code that was suggested was for his environs ( >> his shop ). From yvespielusenet at free.fr Fri Jun 8 01:09:01 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Fri, 08 Jun 2007 09:09:01 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4668AE7B.3060409@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> Message-ID: <1181286541.3674.10.camel@localhost.localdomain> It is not possible that the rxtx java method write(byte[], int offset, int length) return anint which contains the number of byte really send to the printer instead of an exception ? So this is the programm which will see if all bytes have been sent. If not it can retry to send the unsended bytes. -------------------------------------------------------- int sended = 0; while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ sended += countWritten; /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } return sended; /*throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break;*/ } ... ... return countWritten; ------------------------------------------------ Le jeudi 07 juin 2007 ? 21:18 -0400, Uncle George a ?crit : > The UNIX version of writeArray is not too great either. It is possible > that the write will only process some of the bytes. > > #else > if( write( fd, bytes, count ) < 0 ) > throw_java_exception_system_msg( env, IO_EXCEPTION, > "writeArray" ); > #endif > -------------------------------- > > Maybe it might be better to have the native function inform the caller > of the # of characters written, then the commapi/output-buffer can be > modified to reflect the #of chars written. If an exception is to be > thrown, for too many loops of chars written == 0, then exception wont > affect the state of the output buffer. Then a ParallelPort.restart() can > be called to resume printing whats in the buffer. > > > Trent Jarvi wrote: > > An event is possible. I'm amazed this is the largest problem encountered > > while using the parallel code. > > > > How would the write ever exit if we throw events? Isn't this going to > > lead to hung applications? > Sure. If you dont time out, then there is nothing that will force an > EXIT from the write(). Issue is what has the OS done with the write. > > > > On Thu, 7 Jun 2007, Uncle George wrote: > > > >> My feeling is that the code that was suggested was for his environs ( > >> his shop ). > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Fri Jun 8 03:45:00 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 11:45:00 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181286541.3674.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> Message-ID: <20070608094500.GC21069@elberon.bln.de.ingenico.com> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > It is not possible that the rxtx java method write(byte[], int offset, > int length) return anint which contains the number of byte really send > to the printer instead of an exception ? > So this is the programm which will see if all bytes have been sent. If > not it can retry to send the unsended bytes. I think write() is void because in Java people love to do this since OutputStream :-) Of course on such interfaces you cannot implement something nice. If you would have a int write, you would not implement the interface and no applications expecting this interface would link/work/compile. oki, Steffen P.S.: (OT) If you propose not to implement the Java interfaces (especially not on JNI level), maybe optionally offering a wrapper that removes e.g. the write return value and so on to downgrade the powerful classic old POSIX read/write style to the modern limited Java style, then I agree :-) Same for read. Instead of things like "int avialable()" it is more powerful to have an approach as select(2) offers (to guarante the caller that read/write will not block [nothing else make sense anyway IMHO] but may read/write less bytes then requested). The caller gets full control and the higher level protocols can care about timeouts, invoking read in some loops and/or implement retransmission. On top of such an implementation, where everything is controlled, defined, guaranteed and reliable, someone could use an InputStream or OutputStream style interface. Or even better: don't use them at all :) just BTW :-) St. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From yvespielusenet at free.fr Fri Jun 8 05:52:45 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Fri, 08 Jun 2007 13:52:45 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <20070608094500.GC21069@elberon.bln.de.ingenico.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> Message-ID: <1181303565.11203.3.camel@localhost.localdomain> So maybe a better way should be to create a new Exception class which has a method "int getWrittenByte()". So the Exception should be use to send again bytes which are not printed yet. yves Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : > * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > > It is not possible that the rxtx java method write(byte[], int offset, > > int length) return anint which contains the number of byte really send > > to the printer instead of an exception ? > > So this is the programm which will see if all bytes have been sent. If > > not it can retry to send the unsended bytes. > > I think write() is void because in Java people love to do this > since OutputStream :-) Of course on such interfaces you cannot > implement something nice. If you would have a int write, you > would not implement the interface and no applications expecting > this interface would link/work/compile. > > oki, > > Steffen > > P.S.: (OT) > If you propose not to implement the Java interfaces (especially > not on JNI level), maybe optionally offering a wrapper that > removes e.g. the write return value and so on to downgrade the > powerful classic old POSIX read/write style to the modern limited > Java style, then I agree :-) Same for read. Instead of things > like "int avialable()" it is more powerful to have an approach as > select(2) offers (to guarante the caller that read/write will not > block [nothing else make sense anyway IMHO] but may read/write > less bytes then requested). The caller gets full control and the > higher level protocols can care about timeouts, invoking read in > some loops and/or implement retransmission. On top of such an > implementation, where everything is controlled, defined, > guaranteed and reliable, someone could use an InputStream or > OutputStream style interface. Or even better: don't use them at > all :) just BTW :-) > St. > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > 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. > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > 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. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Fri Jun 8 06:46:21 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 08:46:21 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181303565.11203.3.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> Message-ID: <46694F9D.5080501@gatworks.com> It seems that with outputstream.write(b[]), you become terribly uncoordinated as soon as an exception is thrown. Docs do not say what happens to the data. Yet from a practicable point of view, one would like to know if the write was accepted in-full, or rejected before any writes. There are no in betweens, as partial writes are not reportable. So for an outputstream.write(), in order for it to return, the full write request has to be taken, and stored in an internal output buffer. If there is no room, the write() is suspended, till there is room. Or throw's an IOException( "no room in buffer") ; As the select() loop for write reports buffer room avail, then more of the internal buffer is sent to the printer. yves pielusenet wrote: > So maybe a better way should be to create a new Exception class which > has a method "int getWrittenByte()". So the Exception should be use to > send again bytes which are not printed yet. > > yves > > Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : >> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: >>> It is not possible that the rxtx java method write(byte[], int offset, >>> int length) return anint which contains the number of byte really send >>> to the printer instead of an exception ? >>> So this is the programm which will see if all bytes have been sent. If >>> not it can retry to send the unsended bytes. >> I think write() is void because in Java people love to do this >> since OutputStream :-) Of course on such interfaces you cannot >> implement something nice. If you would have a int write, you >> would not implement the interface and no applications expecting >> this interface would link/work/compile. >> >> oki, >> >> Steffen >> >> P.S.: (OT) >> If you propose not to implement the Java interfaces (especially >> not on JNI level), maybe optionally offering a wrapper that >> removes e.g. the write return value and so on to downgrade the >> powerful classic old POSIX read/write style to the modern limited >> Java style, then I agree :-) Same for read. Instead of things >> like "int avialable()" it is more powerful to have an approach as >> select(2) offers (to guarante the caller that read/write will not >> block [nothing else make sense anyway IMHO] but may read/write >> less bytes then requested). The caller gets full control and the >> higher level protocols can care about timeouts, invoking read in >> some loops and/or implement retransmission. On top of such an >> implementation, where everything is controlled, defined, >> guaranteed and reliable, someone could use an InputStream or >> OutputStream style interface. Or even better: don't use them at >> all :) just BTW :-) >> St. >> >> About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. >> 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. >> >> About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. >> 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. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From Steffen.DETTMER at ingenico.com Fri Jun 8 08:12:18 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 16:12:18 +0200 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <46694F9D.5080501@gatworks.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: <20070608141218.GE21069@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 08:46 -0400: > It seems that with outputstream.write(b[]), you become terribly > uncoordinated as soon as an exception is thrown. Docs do not say what > happens to the data. (yes, so avoiding it seems to be good :)) > Yet from a practicable point of view, one would like to know if the > write was accepted in-full, or rejected before any writes. There are no > in betweens, as partial writes are not reportable. (which is an artificial API limitation. I never understood how this happend when they invented JDK because the well-known BSD socket API and thus [probably] WinSock does this correct, but anyway) > So for an outputstream.write(), in order for it to return, the full > write request has to be taken, and stored in an internal output buffer. > If there is no room, the write() is suspended, till there is room. Or > throw's an IOException( "no room in buffer") ; As the select() loop for > write reports buffer room avail, then more of the internal buffer is > sent to the printer. yes, might be good in case of a printer. May be horrible in case of PPP/TCP or some other transmission control protocol which may e.g. repeat data or even omit parts of it (e.g. internet realtime radio station broadcasting)... So I think the idea of "int write" (e.g. BSD sockets, linux files and so on) still is the best. A clean API / implementation should guarantee and allow implementations (users) to rely on that; assumptions and automatic background-sending and so on may look pragmatic and may even work on the first look, but may fail in other situations. BTW, if e.g. BSD socket API is known, why not simply copy it (until something better is invented :)) instead of fiddling around with JDK APIs? anyway, have a nice weekend everyone :-) oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Fri Jun 8 08:55:56 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 10:55:56 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070608141218.GE21069@elberon.bln.de.ingenico.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> Message-ID: <46696DFC.7000801@gatworks.com> >> write reports buffer room avail, then more of the internal buffer is >> sent to the printer. > > yes, might be good in case of a printer. May be horrible in case > of PPP/TCP or some other transmission control protocol which > may e.g. repeat data or even omit parts of it (e.g. internet > realtime radio station broadcasting)... So I think the idea of > "int write" (e.g. BSD sockets, linux files and so on) still is > the best. A clean API / implementation should guarantee and allow > implementations (users) to rely on that; assumptions and > automatic background-sending and so on may look pragmatic and may > even work on the first look, but may fail in other situations. > BTW, if e.g. BSD socket API is known, why not simply copy it > (until something better is invented :)) instead of fiddling > around with JDK APIs? But we were talking about the Parallel Port, and the transmission of data over the commapi/parallel-port schema. There isn't much in bi-directional software communication. Its a simple write one byte at a time interface. I'm not looking to change the comm-api. I'm just looking to alter the interaction between the Native ParallelPort functions, and the java ParallelPort functions that call them. This might be more readily doable than to get a committee to re-specify java-API specs. BTW: Whats is off-topic? ( help: not looking for def of off-topic ) From j.kenneth.gentle at acm.org Fri Jun 8 08:58:59 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Fri, 08 Jun 2007 10:58:59 -0400 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <20070608141218.GE21069@elberon.bln.de.ingenico.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> Message-ID: <200706081459.l58Ex5rA019991@qbang.org> Perhaps it is a bit late to jump in on this one, but here goes anyway. If the solutions all seem to "break" the contract with "java.io.outputstream", then, as noted, that may not be the appropriate contract. At the risk of being heretical, JDK1.4 introduced the "nio" package to address some of the compatibility issues with C apis mentioned in previous posts. The interface "java.nio.channels.WriteableByteChannel" defines the following single method: int write(ByteBuffer source); int, strangely enough, is the actual number of bytes written. So, if RXTX as written, against the JavaCOMM api and OutputStream, doesn't do what we want, how about writing a different set of bindings using the java.nio classes and as much of the underlying native code as possible. Note that just because the java.nio.channels.WriteableByteChannel sends back a result, OutputStream.write doesn't have to - and they could both call the same underlying native code. My 2 cents - maybe not worth even that... Ken From netbeans at gatworks.com Fri Jun 8 10:37:28 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 12:37:28 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <200706081459.l58Ex5rA019991@qbang.org> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> Message-ID: <466985C8.8000505@gatworks.com> Ken Gentle wrote: > Perhaps it is a bit late to jump in on this one, but here goes anyway. Common in, the waters fine. > > If the solutions all seem to "break" the contract with > "java.io.outputstream", then, as noted, that may not be the > appropriate contract. > How would the contract be broken? The machinery underneath is handling the contract. From j.kenneth.gentle at acm.org Fri Jun 8 10:48:01 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Fri, 08 Jun 2007 12:48:01 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466985C8.8000505@gatworks.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> Message-ID: <200706081648.l58Gm7YA022904@qbang.org> At 12:37 2007-06-08, you wrote: >Ken Gentle wrote: > > > > If the solutions all seem to "break" the contract with > > "java.io.outputstream", then, as noted, that may not be the > > appropriate contract. > > >How would the contract be broken? The machinery underneath is handling >the contract. It seems that a lot of the discussion has been about not only the timeout and being able to adjust it in the "machinery layer", but also about knowing in the Java layer, in the event of a timeout or exception, how many characters have been written to the device. An OutputStream won't ever do this with out an extension and including a return value "breaks" the contract, right? So, go with a Java IO api that *does* return the number of bytes written, out of the NIO package. I know it doesn't allow for a strict implementation of the JavaCOMM API - however, using NIO classes in place of the IO classes isn't that big a break and would allow those applications that need such information a way to get it. Maybe I'm misunderstanding the problem... Ken From netbeans at gatworks.com Fri Jun 8 11:24:14 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 13:24:14 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <200706081648.l58Gm7YA022904@qbang.org> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> Message-ID: <466990BE.7040100@gatworks.com> Ken Gentle wrote: An > OutputStream won't ever do this with out an extension and including a > return value "breaks" the contract, right? > i was not thinking of change the API to OutputSream. Are there specs for how output stream should work internally? for instance: String data = "Hello this is a line of data"; Outputstream.write( data.getbytes() ); ParallelPort.suspend(); int free = ParallelPort.getoutputbufferfree(); There is a symbiotic relationship between outputstream and the functionality of ParallelPort. From Steffen.DETTMER at ingenico.com Fri Jun 8 11:15:39 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 19:15:39 +0200 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <200706081459.l58Ex5rA019991@qbang.org> References: <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> Message-ID: <20070608171539.GK21069@elberon.bln.de.ingenico.com> * Ken Gentle wrote on Fri, Jun 08, 2007 at 10:58 -0400: > If the solutions all seem to "break" the contract with > "java.io.outputstream", then, as noted, that may not be the > appropriate contract. > > At the risk of being heretical, JDK1.4 introduced the "nio" package > to address some of the compatibility issues with C apis mentioned in > previous posts. The interface > "java.nio.channels.WriteableByteChannel" defines the following single method: > > int write(ByteBuffer source); > > int, strangely enough, is the actual number of bytes written. Yes, AFAIK one of the motivations for the NIO interface was, that the JDK-1.3 APIs (InputStream, e.g.) were not powerfull enough, especially for multi-connection-TCP servers or so. I don't know much about it but I've heard of a project where NIO usage was removed because of stability issues in multi-threaded environments and performance limitations under some circumstances. IIRC the "nio.ByteBuffer" is something very special (namely something you cannot implement in Java, it is "magic" or part of the language itself). Not sure if this is such a great idea (but for performance in the end sometimes heavy prices must be paid) :) > So, if RXTX as written, against the JavaCOMM api and OutputStream, > doesn't do what we want, how about writing a different set of > bindings using the java.nio classes and as much of the underlying > native code as possible. Yes, this would be an idea: use a full-featured interface on JNI, and, if wanted, deliver some wrappers converting this to a less-featured Java-compliant interface. However, powerful things as e.g. "select" are difficult to "emulate" if you are e.g. on some (older?) windows. But if you expose the full-featured APIs, you need to emulate them full-featured, theoretically. In the end it depends what you do on the serial line. If you just want to talk to a modem, then you may not need precise timeouts. But if you need to implement complexer protocols which define response times and timeouts, you may quickly get into difficulties. For instance, AFAIK, rxtx 1.7.2 (?) for windows is very messy with timeouts (there is a maximum, higher values are truncated; resolution is 100ms only; the function may take up to twice the timeout because internally it may be called twice). Probably for most people this is OK, but probably not for all. But having precise timeouts should be OK for all :-) Well, in the end it is nice to wish but somewhat hard to implement (many platforms, connections, USB, BlueTooth, whatever). oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Steffen.DETTMER at ingenico.com Fri Jun 8 11:04:22 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 19:04:22 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <46696DFC.7000801@gatworks.com> References: <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <46696DFC.7000801@gatworks.com> Message-ID: <20070608170422.GJ21069@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 10:55 -0400: > > BTW, if e.g. BSD socket API is known, why not simply copy it > > (until something better is invented :)) instead of fiddling > > around with JDK APIs? > > But we were talking about the Parallel Port, and the > transmission of data over the commapi/parallel-port schema. > There isn't much in bi-directional software communication. Its > a simple write one byte at a time interface. First, there are things like PLIP (http://en.wikipedia.org/wiki/Plip) - well, probably not widely used, sure ;) Second, I think if there is a good simple API known to support all that (with known "best practices") or so and there is no forcing need to invent a new one, why not simply using it? > I'm not looking to change the comm-api. I'm just looking to > alter the interaction between the Native ParallelPort > functions, and the java ParallelPort functions that call them. Ahh, yes. I think this is what I tried to ask. Having an usable JNI interface and on top (in pure java) some wrapper to InputStream or whatever could be done (e.g. by ignoring the return value of write or throwing if != length). Developers could then use the full-featured (non-JAVA-standard) API or select among various wrappers (as InputStream). > This might be more readily doable than to get a committee to > re-specify java-API specs. Yes, of course. I'm afraid that the Java APIs change regularily, but still yet with limited success it seems, so maybe they get it in one of the next iterations; who knows, maybe Java-9 has a BSD-like socket API :) SCNR. > BTW: Whats is off-topic? ( help: not looking for def of > off-topic ) I think I started some "re-specify java-API specs" which was OT probably. oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From lists at iDIAcomputing.com Fri Jun 8 18:48:54 2007 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Fri, 08 Jun 2007 20:48:54 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46684B62.7080802@gmail.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> Message-ID: <4669F8F6.3040101@iDIAcomputing.com> Vicne wrote: > Sorry to step in without a specific solution to your problem, but I > wanted to share my feeling regarding this proposal. AFAIK, it's > generally considered bad practice to pop-up a prompt from a library. ... > > My advice would be to think again and find another solution. Ideas are : > - make the number of retries a parameter so that you can tune it to what > you think is reasonable > - throw a more specific exception when the number of retries has been > reached, so that a specific prompt can be shown at a higher level You could also allow the client code to register a callback class which returns a boolean indicating whether to retry or cancel. This callback class could pop up a dialog, if appropriate, or follow some preset policy, or.... - George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From joachim at buechse.ch Sat Jun 9 09:43:16 2007 From: joachim at buechse.ch (Joachim Buechse) Date: Sat, 9 Jun 2007 17:43:16 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46694F9D.5080501@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: You should not forget, that in the case of an exception it may not even be known what happened to the data. You have a kernel buffer, outgoing chip buffer, incoming chip buffer, etc. So of course, it would be nice to know up to which point data was correctly processed, but this feedback does not exist on the hardware or protocol level and hence can in general not be magicly created on the software level... Regards, Joachim On 08.06.2007, at 14:46, Uncle George wrote: > It seems that with outputstream.write(b[]), you become terribly > uncoordinated as soon as an exception is thrown. Docs do not say what > happens to the data. > > Yet from a practicable point of view, one would like to know if the > write was accepted in-full, or rejected before any writes. There > are no > in betweens, as partial writes are not reportable. > > So for an outputstream.write(), in order for it to return, the full > write request has to be taken, and stored in an internal output > buffer. > If there is no room, the write() is suspended, till there is room. Or > throw's an IOException( "no room in buffer") ; As the select() loop > for > write reports buffer room avail, then more of the internal buffer is > sent to the printer. > > > > yves pielusenet wrote: >> So maybe a better way should be to create a new Exception class which >> has a method "int getWrittenByte()". So the Exception should be >> use to >> send again bytes which are not printed yet. >> >> yves >> >> Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : >>> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: >>>> It is not possible that the rxtx java method write(byte[], int >>>> offset, >>>> int length) return anint which contains the number of byte >>>> really send >>>> to the printer instead of an exception ? >>>> So this is the programm which will see if all bytes have been >>>> sent. If >>>> not it can retry to send the unsended bytes. >>> I think write() is void because in Java people love to do this >>> since OutputStream :-) Of course on such interfaces you cannot >>> implement something nice. If you would have a int write, you >>> would not implement the interface and no applications expecting >>> this interface would link/work/compile. >>> >>> oki, >>> >>> Steffen >>> >>> P.S.: (OT) >>> If you propose not to implement the Java interfaces (especially >>> not on JNI level), maybe optionally offering a wrapper that >>> removes e.g. the write return value and so on to downgrade the >>> powerful classic old POSIX read/write style to the modern limited >>> Java style, then I agree :-) Same for read. Instead of things >>> like "int avialable()" it is more powerful to have an approach as >>> select(2) offers (to guarante the caller that read/write will not >>> block [nothing else make sense anyway IMHO] but may read/write >>> less bytes then requested). The caller gets full control and the >>> higher level protocols can care about timeouts, invoking read in >>> some loops and/or implement retransmission. On top of such an >>> implementation, where everything is controlled, defined, >>> guaranteed and reliable, someone could use an InputStream or >>> OutputStream style interface. Or even better: don't use them at >>> all :) just BTW :-) >>> St. >>> >>> About Ingenico Throughout the world businesses rely on Ingenico >>> for secure and expedient electronic transaction acceptance. >>> Ingenico products leverage proven technology, established >>> standards and unparalleled ergonomics to provide optimal >>> reliability, versatility and usability. This comprehensive range >>> of products is complemented by a global array of services and >>> partnerships, enabling businesses in a number of vertical sectors >>> to accept transactions anywhere their business takes them. >>> 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. >>> >>> About Ingenico Throughout the world businesses rely on Ingenico >>> for secure and expedient electronic transaction acceptance. >>> Ingenico products leverage proven technology, established >>> standards and unparalleled ergonomics to provide optimal >>> reliability, versatility and usability. This comprehensive range >>> of products is complemented by a global array of services and >>> partnerships, enabling businesses in a number of vertical sectors >>> to accept transactions anywhere their business takes them. >>> 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. >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx 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 yvespielusenet at free.fr Mon Jun 11 03:15:12 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Mon, 11 Jun 2007 11:15:12 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: <1181553312.8335.14.camel@localhost.localdomain> So can someone tell a solution for my problem :( Must I say to the user to not put the printer off-line ? I can't since he has to do some pauses, verify print, paper conditioning etc... How do other people ? Before I use the parport librarry to read port status : http://www.geocities.com/Juanga69/parport/ (which doesn't work on windows XP) And I send data into the file LPT1 I use to have no problem when printer was disabled. thanks -- yves piel Le samedi 09 juin 2007 ? 17:43 +0200, Joachim Buechse a ?crit : > You should not forget, that in the case of an exception it may not > even be known what happened to the data. > > You have a kernel buffer, outgoing chip buffer, incoming chip buffer, > etc. So of course, it would be nice to know up to which point data > was correctly processed, but this feedback does not exist on the > hardware or protocol level and hence can in general not be magicly > created on the software level... > > Regards, > Joachim > > On 08.06.2007, at 14:46, Uncle George wrote: > > > It seems that with outputstream.write(b[]), you become terribly > > uncoordinated as soon as an exception is thrown. Docs do not say what > > happens to the data. > > > > Yet from a practicable point of view, one would like to know if the > > write was accepted in-full, or rejected before any writes. There > > are no > > in betweens, as partial writes are not reportable. > > > > So for an outputstream.write(), in order for it to return, the full > > write request has to be taken, and stored in an internal output > > buffer. > > If there is no room, the write() is suspended, till there is room. Or > > throw's an IOException( "no room in buffer") ; As the select() loop > > for > > write reports buffer room avail, then more of the internal buffer is > > sent to the printer. > > > > > > > > yves pielusenet wrote: > >> So maybe a better way should be to create a new Exception class which > >> has a method "int getWrittenByte()". So the Exception should be > >> use to > >> send again bytes which are not printed yet. > >> > >> yves > >> > >> Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : > >>> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > >>>> It is not possible that the rxtx java method write(byte[], int > >>>> offset, > >>>> int length) return anint which contains the number of byte > >>>> really send > >>>> to the printer instead of an exception ? > >>>> So this is the programm which will see if all bytes have been > >>>> sent. If > >>>> not it can retry to send the unsended bytes. > >>> I think write() is void because in Java people love to do this > >>> since OutputStream :-) Of course on such interfaces you cannot > >>> implement something nice. If you would have a int write, you > >>> would not implement the interface and no applications expecting > >>> this interface would link/work/compile. > >>> > >>> oki, > >>> > >>> Steffen > >>> > >>> P.S.: (OT) > >>> If you propose not to implement the Java interfaces (especially > >>> not on JNI level), maybe optionally offering a wrapper that > >>> removes e.g. the write return value and so on to downgrade the > >>> powerful classic old POSIX read/write style to the modern limited > >>> Java style, then I agree :-) Same for read. Instead of things > >>> like "int avialable()" it is more powerful to have an approach as > >>> select(2) offers (to guarante the caller that read/write will not > >>> block [nothing else make sense anyway IMHO] but may read/write > >>> less bytes then requested). The caller gets full control and the > >>> higher level protocols can care about timeouts, invoking read in > >>> some loops and/or implement retransmission. On top of such an > >>> implementation, where everything is controlled, defined, > >>> guaranteed and reliable, someone could use an InputStream or > >>> OutputStream style interface. Or even better: don't use them at > >>> all :) just BTW :-) > >>> St. > >>> > >>> About Ingenico Throughout the world businesses rely on Ingenico > >>> for secure and expedient electronic transaction acceptance. > >>> Ingenico products leverage proven technology, established > >>> standards and unparalleled ergonomics to provide optimal > >>> reliability, versatility and usability. This comprehensive range > >>> of products is complemented by a global array of services and > >>> partnerships, enabling businesses in a number of vertical sectors > >>> to accept transactions anywhere their business takes them. > >>> 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. > >>> > >>> About Ingenico Throughout the world businesses rely on Ingenico > >>> for secure and expedient electronic transaction acceptance. > >>> Ingenico products leverage proven technology, established > >>> standards and unparalleled ergonomics to provide optimal > >>> reliability, versatility and usability. This comprehensive range > >>> of products is complemented by a global array of services and > >>> partnerships, enabling businesses in a number of vertical sectors > >>> to accept transactions anywhere their business takes them. > >>> 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. > >>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx 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 > From Steffen.DETTMER at ingenico.com Mon Jun 11 03:56:18 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 11:56:18 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466990BE.7040100@gatworks.com> References: <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> Message-ID: <20070611095618.GA10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 13:24 -0400: > i was not thinking of change the API to OutputSream. Then I think either someone uses OutputStream (and has no reliable information about incomplete writes) or someone uses somethink else. > Are there specs for how output stream should work internally? > > for instance: > String data = "Hello this is a line of data"; > Outputstream.write( data.getbytes() ); > ParallelPort.suspend(); > int free = ParallelPort.getoutputbufferfree(); > > There is a symbiotic relationship between outputstream and the > functionality of ParallelPort. If you need OutputStream "plus something else", in short you're needing "something else". Personally I dislike the code above a lot. The stream "looks" like if it would be an OutputStream, but in fact it isn't. You need to call getoutputbufferfree later to check if write succeeded (but OutputStream promises that write succeedes synchronous, blocking, or throws an exception). So it is not an OutputStream. No application written for OutputStreams would work without change (because it won't know getoutputbufferfree at all). It is not abstracted from ParallelPort. I think this would be wrong. Then I think an alternative interface instead is better. Let's assume we had some "connection" (to distinguish between OutputStreams and Channels). Then why not working as on a file handle in POSIX: do { // ... select maybe using timer ... readyForWrite = ... if (readyForWrite) { int writtenBytes = connection.write(toWrite); toWrite.remove(0, writtenBytes); } while(readyForWrite && toWrite.length > 0); I think, having such a write isn't the big problem. I think, the difficult thing is around "select" - however this would look like. It should be OO, typesafe, performant, supporting multiple connections/channels/streams in various modes and should be orthogonal to other functionalities. Of course, this heavily depends on what the application is doing; for a simple situation (like reading a small, mandatory file from a local disk) this would be to uncomfortable (and offering unneeded features only). just BTW :) oki, Steffen -- // Modeline for VIM. Please don't remove. // (Help: autoindent, expandtab, shiftwidth=4, tabstop=4, textwidth=75) // vi: set ai et sw=4 ts=4 tw=75 ft=java: About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Mon Jun 11 05:38:33 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 07:38:33 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611095618.GA10821@elberon.bln.de.ingenico.com> References: <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> Message-ID: <466D3439.4020805@gatworks.com> Steffen DETTMER wrote: > (but OutputStream promises that write > succeedes synchronous, blocking, or throws an exception). Where is it so written? From Steffen.DETTMER at ingenico.com Mon Jun 11 06:36:50 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 14:36:50 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466D3439.4020805@gatworks.com> References: <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> <466D3439.4020805@gatworks.com> Message-ID: <20070611123650.GI10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Mon, Jun 11, 2007 at 07:38 -0400: > Steffen DETTMER wrote: > > > (but OutputStream promises that write > > succeedes synchronous, blocking, or throws an exception). > > Where is it so written? Now, as you ask, I think it is not written that clearly but follows from specification. mmm... Am I wrong? I understand the API doc in this way: * http://java.sun.com/j2se/1.4.2/docs/api/java/io/OutputStream.html#write(byte[]) > public void write(byte[] b) > throws IOException > > Writes b.length bytes from the specified byte array to this > output stream. The general contract for write(b) is that > it should have exactly the same effect as the call write(b, > 0, b.length). > > Parameters: > b - the data. > Throws: > IOException - if an I/O error occurs. > See Also: > write(byte[], int, int) and there is: > public void write(byte[] b, > int off, > int len) > throws IOException > > Writes len bytes from the specified byte array starting at > offset off to this output stream. The general contract for > write(b, off, len) is that some of the bytes in the array b > are written to the output stream in order; element b[off] > is the first byte written and b[off+len-1] is the last byte > written by this operation. > > The write method of OutputStream calls the write method of > one argument on each of the bytes to be written out. > Subclasses are encouraged to override this method and > provide a more efficient implementation. > > If b is null, a NullPointerException is thrown. > > If off is negative, or len is negative, or off+len is > greater than the length of the array b, then an > IndexOutOfBoundsException is thrown. > > Parameters: > b - the data. > off - the start offset in the data. > len - the number of bytes to write. > Throws: > IOException - if an I/O error occurs. In particular, an > IOException is thrown if the output stream is closed. In general, any specialisation (derived child class) must comform to this. So write in the end is specified (!) as "The write method ... calls the write method ... on each of the bytes to be written out". This is what must be implemented by ANY OutputStream. Of course, there is: "Subclasses are encouraged to override this method and provide a more efficient implementation." which IMHO does not contradict - the more efficient must behave in exactly the same way of course (just wasting less resources than a simple byte-by-byte write). So it does not matter here I think. The write that finally defines the behavior tells basically: > "Writes the specified byte to this output stream. The general > contract for write is that one byte is written to the output > stream. " > > Throws: > IOException - if an I/O error occurs. which IMHO is another way of saying "write writes the byte immediately and returns on success (only), otherwise an exception is thrown". Especially it cannot happen that zero bytes are written (i.e. the specified byte is NOT written) without an exception. So by this write must be synchronous and blocking, because otherwise it could not reliably know if an asynchronous operation will succeede or not (some getAsyncResult or so would be needed). Since write(byte[]) does this for each byte (or with a behavior beeing exactly the same as if it would do), I think this means that the write(byte[]) succeedes synchronous/blocking or throws an exception. Did I an error in reasoning or confused something or so? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From j.kenneth.gentle at acm.org Mon Jun 11 06:51:25 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 11 Jun 2007 08:51:25 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611123650.GI10821@elberon.bln.de.ingenico.com> References: <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> <466D3439.4020805@gatworks.com> <20070611123650.GI10821@elberon.bln.de.ingenico.com> Message-ID: <200706111251.l5BCpS9T017831@qbang.org> It is as Steffen describes. "InputStream" and "OutputStream" are inherently synchronous (which is why so many java programs resort to threads to use them). Anything outside of this "contract" is *not* an InputStream or OutputStream. That is why there is a new package for things that don't behave like the old *Stream classes - the NIO package. If you look carefully at the IO package, you'll note that almost all the classes are _Decorator_ pattern implementations of the *Stream classes - and the interface presents the _same_ behavior to the calling code in all cases - a synchronous operation that completes successfully or throws an exception (with the one exception of "read" that returns a "-1" on end-of-stream. I know I've read this numerous times - I'd suggest checking the Language Spec or one of the books by Bloch or Gosling. Ken At 08:36 2007-06-11, you wrote: >* Uncle George wrote on Mon, Jun 11, 2007 at 07:38 -0400: > > Steffen DETTMER wrote: > > > > > (but OutputStream promises that write > > > succeedes synchronous, blocking, or throws an exception). > > > > Where is it so written? > >Now, as you ask, I think it is not written that clearly but >follows from specification. mmm... > >Am I wrong? > >I understand the API doc in this way: > >* >http://java.sun.com/j2se/1.4.2/docs/api/java/io/OutputStream.html#write(byte[]) > > public void write(byte[] b) > > throws IOException > > > > Writes b.length bytes from the specified byte array to this > > output stream. The general contract for write(b) is that > > it should have exactly the same effect as the call write(b, > > 0, b.length). > > > > Parameters: > > b - the data. > > Throws: > > IOException - if an I/O error occurs. > > See Also: > > write(byte[], int, int) > > >and there is: > > > > public void write(byte[] b, > > int off, > > int len) > > throws IOException > > > > Writes len bytes from the specified byte array starting at > > offset off to this output stream. The general contract for > > write(b, off, len) is that some of the bytes in the array b > > are written to the output stream in order; element b[off] > > is the first byte written and b[off+len-1] is the last byte > > written by this operation. > > > > The write method of OutputStream calls the write method of > > one argument on each of the bytes to be written out. > > Subclasses are encouraged to override this method and > > provide a more efficient implementation. > > > > If b is null, a NullPointerException is thrown. > > > > If off is negative, or len is negative, or off+len is > > greater than the length of the array b, then an > > IndexOutOfBoundsException is thrown. > > > > Parameters: > > b - the data. > > off - the start offset in the data. > > len - the number of bytes to write. > > Throws: > > IOException - if an I/O error occurs. In particular, an > > IOException is thrown if the output stream is closed. > > >In general, any specialisation (derived child class) must comform >to this. So write in the end is specified (!) as "The write >method ... calls the write method ... on each of the bytes to be >written out". This is what must be implemented by ANY >OutputStream. > >Of course, there is: "Subclasses are encouraged to override this >method and provide a more efficient implementation." which IMHO >does not contradict - the more efficient must behave in exactly >the same way of course (just wasting less resources than a simple >byte-by-byte write). So it does not matter here I think. > > > >The write that finally defines the behavior tells basically: > > > "Writes the specified byte to this output stream. The general > > contract for write is that one byte is written to the output > > stream. " > > > > Throws: > > IOException - if an I/O error occurs. > > >which IMHO is another way of saying "write writes the byte >immediately and returns on success (only), otherwise an exception >is thrown". Especially it cannot happen that zero bytes are >written (i.e. the specified byte is NOT written) without an >exception. So by this write must be synchronous and blocking, >because otherwise it could not reliably know if an asynchronous >operation will succeede or not (some getAsyncResult or so would >be needed). > >Since write(byte[]) does this for each byte (or with a behavior >beeing exactly the same as if it would do), I think this means >that the write(byte[]) succeedes synchronous/blocking or throws >an exception. > >Did I an error in reasoning or confused something or so? > >oki, > >Steffen > >About Ingenico Throughout the world businesses rely on Ingenico for >secure and expedient electronic transaction acceptance. Ingenico >products leverage proven technology, established standards and >unparalleled ergonomics to provide optimal reliability, versatility >and usability. This comprehensive range of products is complemented >by a global array of services and partnerships, enabling businesses >in a number of vertical sectors to accept transactions anywhere >their business takes them. >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. > >About Ingenico Throughout the world businesses rely on Ingenico for >secure and expedient electronic transaction acceptance. Ingenico >products leverage proven technology, established standards and >unparalleled ergonomics to provide optimal reliability, versatility >and usability. This comprehensive range of products is complemented >by a global array of services and partnerships, enabling businesses >in a number of vertical sectors to accept transactions anywhere >their business takes them. >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. > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From alesinskyy at googlemail.com Mon Jun 11 07:25:33 2007 From: alesinskyy at googlemail.com (Oleksandr Alesinskyy) Date: Mon, 11 Jun 2007 15:25:33 +0200 Subject: [Rxtx] [OT] select :-) Message-ID: Sorry, but I have to disagree with following statement: "So write in the end is specified (!) as "The write method ... calls the write method ... on each of the bytes to be written out". This is what must be implemented by ANY OutputStream.". This is not part of the specification or contract, it is just revealed implementation detail of the OutputStream. It is not stated anywhere that behavoiur of derived classes shall conform with this one. Statement concerning "synchronous" nature of the output stream is invalid as well. Really synchronous stream does not require flush() but OutputStream has it. From Steffen.DETTMER at ingenico.com Mon Jun 11 08:21:16 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 16:21:16 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: Message-ID: <20070611142116.GN10821@elberon.bln.de.ingenico.com> * Oleksandr Alesinskyy wrote on Mon, Jun 11, 2007 at 15:25 +0200: > Sorry, but I have to disagree with following statement: > "So write in the end is specified (!) as "The write > method ... calls the write method ... on each of the bytes to be > written out". This is what must be implemented by ANY > OutputStream.". > > This is not part of the specification or contract, it is just > revealed implementation detail of the OutputStream. It is not > stated anywhere that behavoiur of derived classes shall conform > with this one. (I didn't meant that the implementation must really write byte by byte, but that it must "look as if it would do" - because all implementations of OutputStream must "look" in the same way [which is another way of saying "do abstract" I think]) I think the API doc is not "revealing implementation details" but it is the *specification* of that interface and derivations must (should) conform to this specification. Isn't this the idea of interfaces? A function that expects an OutputStream should work on ANY OutputStream, shouldn't it? just kidding: I mean, what would be the point in implementing a checksum function as OutputStream.write which throws its result as IOException? Or which requires to call close() as very first operation to tell that the application is about to transmit confidential data? :-) > Statement concerning "synchronous" nature of the output stream > is invalid as well. Really synchronous stream does not require > flush() but OutputStream has it. ahh, interesting point! I think this is another bug in the API. flush() is wrong. Because write specifies "The general contract for write is that one byte is written to the output stream." but not "a byte may be written or buffered". Actually, an application would need to call flush() after each write (or bunch of write calls) to ensure that write really did something otherwise I think. I didn't found in the spec of OutputStream that it would be required to call flush(). This should mean that calling flush is not required which in turn leads to the conclusion that write must be synchrous (private threads are forbidden because not specified :)) which in turn leads to the conclusion that flush() is not needed at all... I mean, what if someone would only store in write and do the "real write" in flush() and never else? An application could write in one stream and read on another one (e.g. in bidirectional communication) and would never get anything back, because nothing was actually written because no flush was called? Then someone could even think that on error in some write the data could remain buffered AND throw an exception, retrying to send the data in the next write. Ohh, and if there would be some message number inside, and underlaying write (e.g. a protocol offering InputStream/OutputStream) would check this and throw "DuplicatedMessageNumber" the stream would only throw it again and again beeing unusable... In short: I have no clue how someone could be able to implement an asynchrounos write (which is realiable and correct) without beeing specific to anything which is not specified by OutputStream. Well, I think in the end OutputStream was not intended for such communication or protocol implementations - but to read a local disk file or so. In case of I/O errors usually you can abort your application and change the hard disk :-) oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Bob_Jacobsen at lbl.gov Mon Jun 11 09:32:23 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Mon, 11 Jun 2007 08:32:23 -0700 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611142116.GN10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> Message-ID: At 4:21 PM +0200 6/11/07, Steffen DETTMER wrote: > > Statement concerning "synchronous" nature of the output stream >> is invalid as well. Really synchronous stream does not require >> flush() but OutputStream has it. > >ahh, interesting point! > >I think this is another bug in the API. flush() is wrong. Because >write specifies "The general contract for write is that one byte >is written to the output stream." but not "a byte may be written >or buffered". > >Actually, an application would need to call flush() after each >write (or bunch of write calls) to ensure that write really did >something otherwise I think. OutputStreams don't _have_ to be synchronous or asynchronous, but the OutputStream API was be arranged so that subclasses _can_ be synchronous or asynchronous. Such generality is the hardest part of getting an API right. Hence, if at some point a program using an OutputStream wants to be sure that the data has been pushed all the way out, flush() is available. For some subclasses, e.g. the buffered ones, this has important behavior. Others write the data from each call, and flush() doesn't do anything. You _can_ omit it in programs that are known to use this second type, but there's no requirement that you do so; the interface is general in that way. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From Steffen.DETTMER at ingenico.com Mon Jun 11 12:32:39 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 20:32:39 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> Message-ID: <20070611183239.GT10821@elberon.bln.de.ingenico.com> * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: > >Actually, an application would need to call flush() after each > >write (or bunch of write calls) to ensure that write really did > >something otherwise I think. > OutputStreams don't _have_ to be synchronous or asynchronous, > but the OutputStream API was be arranged so that subclasses > _can_ be synchronous or asynchronous. Ahh, oki. Thanks for the clarificaion. So in short, flush() MUST be called on OutputStream, this is just not documented correctly or so clearly (right?). So the overall usage semantics would be: 1. call write (multiple times if desired) 2. call flush only if both succeeded, write was successful. If flush fails it remains unknown if a part of the data was written and/or will be repeated. So the spec (API doc) is wrong. Correct would be to tell that write behaves as told as long as it is followed by a call to flush, otherwise data may or may not get lost (depending wheter close() is called and calls flush(), which seems not to be guaranteed/required). BTW, I think it is a little bit... erm... interesting to find the specification (java API doc reference) wrong, having a need to conclude it from the presence of some methods with "it would make no sense if they behave exactly as specified, so specification must be wrong (incomplete)". > Such generality is the hardest part of getting an API right. Yes, seems to be proven ;) > Hence, if at some point a program using an OutputStream wants > to be sure that the data has been pushed all the way out, > flush() is available. For some subclasses, e.g. the buffered > ones, this has important behavior. Others write the data from > each call, and flush() doesn't do anything. > You _can_ omit it in programs that are known to use this second > type, but there's no requirement that you do so; the interface > is general in that way. I think, it still it must be called always, otherwise the application could break if passing a different runtime type as OutputStream. I think, if the application/method needs a special "type of OutputStream" then the parameter type must be a subclass but not OutputStream, maybe a PrintStream or so - otherwise the compiler could not detect this error (passing wrong type). Is this correct? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Bob_Jacobsen at lbl.gov Mon Jun 11 13:00:52 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Mon, 11 Jun 2007 12:00:52 -0700 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611183239.GT10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> Message-ID: At 8:32 PM +0200 6/11/07, Steffen DETTMER wrote: >So the spec (API doc) is wrong. Correct would be to tell that >write behaves as told as long as it is followed by a call to >flush, otherwise data may or may not get lost (depending wheter >close() is called and calls flush(), which seems not to be >guaranteed/required). I'm not entirely sure that the spec is wrong, but reasonable people can differ on this. In the 1.5 JavaDocs, all that the docs say for the write methods is that they write to the _output_ _stream_; there is no guarantee of anything beyond that. Only the flush method has any guarantee about the data, which is >Flushes this output stream and forces any buffered output bytes to >be written out. The general contract of flush is that calling it is >an indication that, if any bytes previously written have been >buffered by the implementation of the output stream, such bytes >should immediately be written to their intended destination. People commonly use various OutputStreams without using flush(), and it often works, but it's a bad practice and will eventually bite them. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From netbeans at gatworks.com Mon Jun 11 13:31:57 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 15:31:57 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611183239.GT10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> Message-ID: <466DA32D.1010602@gatworks.com> Steffen DETTMER wrote: > * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: >>> Actually, an application would need to call flush() after each >>> write (or bunch of write calls) to ensure that write really did >>> something otherwise I think. > >> OutputStreams don't _have_ to be synchronous or asynchronous, >> but the OutputStream API was be arranged so that subclasses >> _can_ be synchronous or asynchronous. > > Ahh, oki. Thanks for the clarificaion. > > So in short, flush() MUST be called on OutputStream, this is just > not documented correctly or so clearly (right?). No. Flush can be called to force all current data in java buffer's to be written to the kernel - NOW. A flush() can also *imply* that, besides writing out the buffer's that java employs, may also imply/ask the kernel to write all data thusfar written to the kernel, to be physically placed on the destination device - NOW. For some OS's there is no need to do a kernel flush(), as the I/O is synchronized already. Since this is java, you never know what OS your on. From tjarvi at qbang.org Mon Jun 11 19:28:27 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Jun 2007 19:28:27 -0600 (MDT) Subject: [Rxtx] [OT] select :-) In-Reply-To: <466DA32D.1010602@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: On Mon, 11 Jun 2007, Uncle George wrote: > Steffen DETTMER wrote: >> * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: >>>> Actually, an application would need to call flush() after each >>>> write (or bunch of write calls) to ensure that write really did >>>> something otherwise I think. >> >>> OutputStreams don't _have_ to be synchronous or asynchronous, >>> but the OutputStream API was be arranged so that subclasses >>> _can_ be synchronous or asynchronous. >> >> Ahh, oki. Thanks for the clarificaion. >> >> So in short, flush() MUST be called on OutputStream, this is just >> not documented correctly or so clearly (right?). > No. > Flush can be called to force all current data in java buffer's to be > written to the kernel - NOW. > > A flush() can also *imply* that, besides writing out the buffer's that > java employs, may also imply/ask the kernel to write all data thusfar > written to the kernel, to be physically placed on the destination device > - NOW. > For some OS's there is no need to do a kernel flush(), as the I/O is > synchronized already. Since this is java, you never know what OS your on. To add to the confusion, flush on the C side throws away data. drain makes sure it is written. Looking at the ParallelImp.c we can probably do better. /* we set a timeout because all calls are sequentiell (also with asynchron) this means that the default timeout of unlimited blocks all calls (also close and status request) if the device is down */ GetCommTimeouts( (HANDLE)fd, &timeouts ); timeouts.WriteTotalTimeoutMultiplier = 0; timeouts.WriteTotalTimeoutConstant = 2000; /* 2000 is the min value for the default Windows NT and Windows 2000 driver */ SetCommTimeouts( (HANDLE)fd, &timeouts ); while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } errorCount = 0; bytes += countWritten; count -= countWritten; } LPRPort has some timeout code that appears to be doing nothing but flipping bits back and forth right now. The commapi rxtx follows allows for timeout control from javax.comm.CommPort. The above is a solution that worked in one specific use case. With timeouts in place, the original 'old printer going offline' problem could be solved. That printer code isn't written in stone. In fact it was ajusted from being able to print 'asdf' to a daisy wheel printer to working for one person. BTW, I've finished teaching after hours tonight and will be moving forward with a new rxtx release in my free time. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Jun 11 21:28:04 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 23:28:04 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: <466E12C4.1010305@gatworks.com> > Looking at the ParallelImp.c we can probably do better. > The problem stemmed from the possibility that the writev routine could have written some of the buffer, in chunks, printer pauses, refuses any more chunks, and a timeout occurs. Do you or do you not cause an exception to be thrown? Is there a way to set timeout for a ParallelPort data output stream? I cant find it. From tjarvi at qbang.org Mon Jun 11 22:17:23 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Jun 2007 22:17:23 -0600 (MDT) Subject: [Rxtx] [OT] select :-) In-Reply-To: <466E12C4.1010305@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> <466E12C4.1010305@gatworks.com> Message-ID: On Mon, 11 Jun 2007, Uncle George wrote: >> Looking at the ParallelImp.c we can probably do better. >> > The problem stemmed from the possibility that the writev routine could > have written some of the buffer, in chunks, printer pauses, refuses any > more chunks, and a timeout occurs. Do you or do you not cause an > exception to be thrown? > > Is there a way to set timeout for a ParallelPort data output stream? I > cant find it. hmm I looked again after you asked. The timeouts are only controllable on the receive side. This comes from CommPort; the parent. So what we are talking about is some bytes in memory that rxtx has and is supposed to write. A buffer perhaps? The approach with rxtx in the past has been to ignore output buffer sizes. The assumption is that the library does not know how to best handle buffers. There are buffered output streams that can do buffering on top of rxtx for instance. There is also a question regarding what was actually ment when the API was put together. My suspicion is that it was put together while looking at one OS API and was never ment to be anything more than a hook into that API. The comments are fairly telling combined with reading the w32 API. So looking at the problem again.. The current timeout behavior appears fairly arbitrary. Presumably this is to prevent a program from hanging instead of using a helper thread to write - heavy handed for new programmers. Even so, I don't think the write should timeout at all if it is not configurable. >From the API perspective, "What Timeout?" -- Trent Jarvi tjarvi at qbang.org From Steffen.DETTMER at ingenico.com Tue Jun 12 02:14:48 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 12 Jun 2007 10:14:48 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466DA32D.1010602@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: <20070612081447.GU10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Mon, Jun 11, 2007 at 15:31 -0400: > Steffen DETTMER wrote: > > Ahh, oki. Thanks for the clarificaion. > > > > So in short, flush() MUST be called on OutputStream, this is just > > not documented correctly or so clearly (right?). > No. hum (though now I got it, but...). > Flush can be called to force all current data in java buffer's to be > written to the kernel - NOW. > > A flush() can also *imply* that, besides writing out the > buffer's that java employs, may also imply/ask the kernel to > write all data thusfar written to the kernel, to be physically > placed on the destination device - NOW. > > For some OS's there is no need to do a kernel flush(), as the I/O is > synchronized already. Since this is java, you never know what OS your on. (well, but if you're going to kernel level, even flush cannot guarantee that data will "be physically placed". Maybe you're flushing to a file via NFS (and the client "thinks" that it was written, but maybe it was just buffered by the NFS server) or so... but of course such exceptions of the rules are constructable always.) Well, you tell that depending on the OS it can be that flush is needed or it can be that flush is not needed (beacuse the I/O is synchronized already), right? Also, applications should work on any OS, which includes the OSes that do need flush. Since the application cannot know whether flush is needed or not because it doesn't know what the OS is doing, it has to call flush, hasn't it? I mean, if it would not call flush then it would not work on such OSes (except the written data would not be needed at all, but in this would be an artificial example :)). Since applications are supposed to work this would be wrong, wouldn't it? So would it be correct to say: "Applications, that should work under all OSes (including the OSes where the I/O is not synchronised already), have to call flush on OutputStream to ensure the data is transfered to the kernel." or is this wrong? If so, then I'm afraid I missed the point again :( oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Tue Jun 12 04:46:52 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 12 Jun 2007 06:46:52 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070612081447.GU10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> <20070612081447.GU10821@elberon.bln.de.ingenico.com> Message-ID: <466E799C.7060700@gatworks.com> S > (well, but if you're going to kernel level, even flush cannot > guarantee that data will "be physically placed". Thats true now-a-days because ( from "man 2 sync" ) : > According to the standard specification (e.g., SVID), sync() schedules > the writes, but may return before the actual writing is done. However, > since version 1.3.20 Linux does actually wait. (This still does not > guarantee data integrity: modern disks have large caches.) My disk drive has 8mb cache. Maybe you're > flushing to a file via NFS (and the client "thinks" that it was > written, but maybe it was just buffered by the NFS server) or > so... but of course such exceptions of the rules are > constructable always.) > > Well, you tell that depending on the OS it can be that flush is > needed or it can be that flush is not needed (beacuse the I/O is > synchronized already), right? Also, applications should work on > any OS, which includes the OSes that do need flush. Its not OS's that need flush, its applications that want to have some assurance that data is written to the device that really needs to use flush. If your program ( or thread ) dies then it is in your best interest to write out the critical data as soon as possible, as economical as possible. These are trade-off's that the application programmer makes. A big buffer may mean big loss of data, a small buffer may mean spending too much time writing out data. > > > So would it be correct to say: > > "Applications, that should work under all OSes (including the > OSes where the I/O is not synchronised already), have to call > flush on OutputStream to ensure the data is transfered to the > kernel." > > or is this wrong? If so, then I'm afraid I missed the point again > :( > No that is not wrong. Ensuring that data is transfered to the OS is just about what any application can do. From tjarvi at qbang.org Thu Jun 14 08:16:47 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 14 Jun 2007 08:16:47 -0600 (MDT) Subject: [Rxtx] rxtx and usb-serial solution In-Reply-To: References: Message-ID: On Thu, 14 Jun 2007, Vladimir Kirtchev wrote: > Hi Trent, > > I develop a Java application which communicates with devices which have > USB-to-Serial bridge in them. The target OS is Linux. So for this purpose I > use RXTX. > > But I encountered a strange problem - when reading from the InputStream, I > receive series of zeros. I have this problem under Linux only. Under Windows > it is fine. > Actually this problem is the same as the one described here: > http://marc.info/?l=rxtx&m=109703190731748&w=2. > > > So I searched for the problem in the native code. And found that the root of > the problem is in SerialImp.c, > int configure_port( int fd ) > { > ... > ttyset.c_iflag = INPCK; > ... > } > > This line enables input parity checking, and the data sent from the device > is processed by the OS driver before being read with read(). > In this case the driver detects some problem and sets the received bytes to > zero. > > On the other hand in the Java part a set the serial port parameters with > SerialPort.PARITY_NONE. According to me, except all other things, this > should also disable INPCK in c_iflag. > > So I refactored the method translate_parity(...) to the following: > > int translate_parity( JNIEnv *env, struct termios *ttyset, jint parity ) > { > ENTER( "translate_parity" ); > #ifdef CMSPAR > ttyset->c_cflag &= ~(PARENB | PARODD | CMSPAR ); > #endif /* CMSPAR */ > switch( parity ) { > case JPARITY_NONE: > ttyset->c_iflag &= ~INPCK; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_EVEN: > ttyset->c_cflag |= PARENB; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_ODD: > ttyset->c_cflag |= PARENB | PARODD; > LEAVE( "translate_parity" ); > return 0; > #ifdef CMSPAR > case JPARITY_MARK: > ttyset->c_cflag |= PARENB | PARODD | CMSPAR; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_SPACE: > ttyset->c_cflag |= PARENB | CMSPAR; > LEAVE( "translate_parity" ); > return 0; > #endif /* CMSPAR */ > default: > printf("Parity missed %i\n", (int) parity ); > } > > LEAVE( "translate_parity" ); > /* > For some reason the native exceptions are not being caught. Moving this > to the Java side fixed the issue. taj. > throw_java_exception( env, UNSUPPORTED_COMM_OPERATION, > "", "parity value not supported" ); > */ > return 1; > } > > This modification solved the problem and now it works correctly under Linux. > > I think I will be a nice if this is idea is included in a future release of > RXTX. > > Thanks Vadim, I'll try that out. Forwarding to the rxtx mail-list too. This is probably not going to help USB drivers on windows which I'm sure some are looking for. As far as I can tell, windows USB bluetooth and serial dongles are limited by driver functionality. Some are good and others lack key features. -- Trent Jarvi tjarvi at qbang.org From dan.sandberg.lists at gmail.com Mon Jun 18 14:43:39 2007 From: dan.sandberg.lists at gmail.com (Dan Sandberg) Date: Mon, 18 Jun 2007 13:43:39 -0700 Subject: [Rxtx] Fix for JNI Get/Set Field Errors Message-ID: <4676EE7B.7060800@gmail.com> Hi, I've fixed the problems that cause the following JNI error when extra JNI checking ( -Xjni:check ) is turned on. FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) The problem was basically that GetLong was being used to get ints, and SetInt was used for longs. The patch below fixes this. Please let me know if there are any questions / problems. Cheers, -Dan diff -aur old/SerialImp.c src/SerialImp.c --- old/SerialImp.c 2007-06-18 13:24:33.000000000 -0700 +++ src/SerialImp.c 2007-06-18 06:26:26.000000000 -0700 @@ -1337,7 +1337,7 @@ report("init_threads: get eis\n"); jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); report("init_threads: set eis\n"); - (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); + (*eis->env)->SetLongField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); report("init_threads: stop\n"); report_time_end( ); return( 1 ); @@ -1530,7 +1530,7 @@ jobject jobj, jboolean interrupted ) { int fd = get_java_var( env, jobj,"fd","I" ); - struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var( env, jobj, "eis", "J" ); + struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var_long( env, jobj, "eis", "J" ); int result, count=0; char message[80]; @@ -2939,7 +2939,7 @@ /* TRENT */ int flag, count = 0; struct event_info_struct *eis = ( struct event_info_struct * ) - get_java_var( env, *jobj,"eis","J" ); + get_java_var_long( env, *jobj,"eis","J" ); report_time_start(); flag = eis->eventflags[SPE_DATA_AVAILABLE]; @@ -4873,9 +4873,9 @@ exceptions: none comments: ----------------------------------------------------------*/ -size_t get_java_var( JNIEnv *env, jobject jobj, char *id, char *type ) +long get_java_var_long( JNIEnv *env, jobject jobj, char *id, char *type ) { - int result = 0; + long result = 0; jclass jclazz = (*env)->GetObjectClass( env, jobj ); jfieldID jfd = (*env)->GetFieldID( env, jclazz, id, type ); @@ -4889,7 +4889,11 @@ LEAVE( "get_java_var" ); return result; } - result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); + if ( !strcmp( type, "J" ) ) { + result = (long)( (*env)->GetLongField( env, jobj, jfd ) ); + } else { + result = (int) ( (*env)->GetIntField( env, jobj, jfd ) ); + } /* ct7 & gel * Added DeleteLocalRef */ (*env)->DeleteLocalRef( env, jclazz ); if(!strncmp( "fd",id,2) && result == 0) @@ -4900,6 +4904,10 @@ return result; } +int get_java_var( JNIEnv *env, jobject jobj, char *id, char *type ) { + return (int) get_java_var_long( env, jobj, id, type ); +} + /*---------------------------------------------------------- throw_java_exception diff -aur old/SerialImp.h src/SerialImp.h --- old/SerialImp.h 2007-06-18 13:24:39.000000000 -0700 +++ src/SerialImp.h 2007-06-18 06:23:43.000000000 -0700 @@ -413,7 +413,8 @@ void system_wait(); void finalize_event_info_struct( struct event_info_struct * ); int read_byte_array( JNIEnv *, jobject *, int, unsigned char *, int, int ); -size_t get_java_var( JNIEnv *, jobject, char *, char * ); +int get_java_var( JNIEnv *, jobject, char *, char * ); +long get_java_var_long( JNIEnv *, jobject, char *, char * ); jboolean is_interrupted( struct event_info_struct * ); int send_event(struct event_info_struct *, jint, int ); void dump_termios(char *,struct termios *); From netbeans at gatworks.com Fri Jun 1 05:38:50 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 07:38:50 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <465F7ADD.1010501@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> Message-ID: <4660054A.2040202@gatworks.com> Manuel Naranjo wrote: In the case of my module, you can > unplug the device but it will not delete the symlink until those apps > that had opened the port has closed it. This is done this way to avoid > kernel panics. What does this mean to user code ? I have tried the alternate route ( other than closing ) which is sleep inbetween the I/O errors ( an unplugged USB device). When the device is plugged back in, The writes to the device still get an I/O error. This would seem to be a lost cause for the application. From netbeans at gatworks.com Fri Jun 1 06:35:48 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 08:35:48 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <465F7ADD.1010501@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> Message-ID: <466012A4.90608@gatworks.com> Manuel Naranjo wrote: In the case of my module, you can > unplug the device but it will not delete the symlink until those apps > that had opened the port has closed it. T Did u also mean for this to happen? USB0 was not closed by application. Apparently USB1 got created when USB device was plugged back in. There is only one USB device on a 4 port USB hub. This also seems to suggest that application recovery to be impossible. > Jun 1 07:10:08 mylaptop kernel: garmin_gps 1-1.4:1.0: Garmin GPS usb/tty converter detected > Jun 1 07:10:08 mylaptop kernel: usb 1-1.4: Garmin GPS usb/tty converter now attached to ttyUSB0 > Jun 1 07:15:17 mylaptop kernel: usb 1-1: USB disconnect, address 4 > Jun 1 07:15:17 mylaptop kernel: usb 1-1.4: USB disconnect, address 5 > Jun 1 07:15:17 mylaptop kernel: garmin_gps 1-1.4:1.0: device disconnected > Jun 1 07:15:26 mylaptop kernel: usb 1-1: new full speed USB device using uhci_hcd and address 6 > Jun 1 07:15:26 mylaptop kernel: hub 1-1:1.0: USB hub found > Jun 1 07:15:26 mylaptop kernel: hub 1-1:1.0: 4 ports detected > Jun 1 07:15:27 mylaptop kernel: usb 1-1.4: new full speed USB device using uhci_hcd and address 7 > Jun 1 07:15:27 mylaptop kernel: garmin_gps 1-1.4:1.0: Garmin GPS usb/tty converter detected > Jun 1 07:15:27 mylaptop kernel: usb 1-1.4: Garmin GPS usb/tty converter now attached to ttyUSB1 From naranjo.manuel at gmail.com Fri Jun 1 09:17:22 2007 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Fri, 01 Jun 2007 12:17:22 -0300 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <466012A4.90608@gatworks.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> <466012A4.90608@gatworks.com> Message-ID: <46603882.5050701@gmail.com> Uncle George escribi?: > Manuel Naranjo wrote: > In the case of my module, you can > >> unplug the device but it will not delete the symlink until those apps >> that had opened the port has closed it. T >> > > Did u also mean for this to happen? USB0 was not closed by application. > > Apparently USB1 got created when USB device was plugged back in. There > is only one USB device on a 4 port USB hub. > > This also seems to suggest that application recovery to be impossible. > Exactly there's a dead symlink (you can read and write to it and nothing will happen) and a new port will be created when a new device is connencted. From netbeans at gatworks.com Fri Jun 1 10:20:46 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 12:20:46 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <46603882.5050701@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> <466012A4.90608@gatworks.com> <46603882.5050701@gmail.com> Message-ID: <4660475E.5090202@gatworks.com> Not sure what u mean by "symlink". U cant read/write to it anymore. U get I/O error. In this scenario the device effectively went dead, and only solution is to close the channel. reconnecting the USB device, although dead, but not closed, will create a second device. This does not seem to be a desirable side-effect. The user will now have ttyUSB1, wondering where did ttyUSB0 go to. The application will also be in a confused state, as well as RXTX, because RXTX wont know about ttyUSB1. Manuel Naranjo wrote: > Uncle George escribi?: >> Manuel Naranjo wrote: >> In the case of my module, you can >> >>> unplug the device but it will not delete the symlink until those apps >>> that had opened the port has closed it. T >>> >> Did u also mean for this to happen? USB0 was not closed by application. >> >> Apparently USB1 got created when USB device was plugged back in. There >> is only one USB device on a 4 port USB hub. >> >> This also seems to suggest that application recovery to be impossible. >> > Exactly there's a dead symlink (you can read and write to it and nothing > will happen) and a new port will be created when a new device is connencted. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From arnab.bhaumik at gmail.com Mon Jun 4 01:40:16 2007 From: arnab.bhaumik at gmail.com (arnab bhaumik) Date: Mon, 4 Jun 2007 13:10:16 +0530 Subject: [Rxtx] full duplex com port with rxtx Message-ID: hi , till now i did half duplex communication with rxtx package on com package. my question is : is it possible to use com port with full duplex mode with rxtx package . ther is example of SimpleRead class and SimpleWrite class. it is clear that if i can use both the class simultaneously then full duplex is possible......... arnab/vu2bpw -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070604/6edb0453/attachment-0003.html From lists at iDIAcomputing.com Mon Jun 4 07:53:17 2007 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Mon, 04 Jun 2007 09:53:17 -0400 Subject: [Rxtx] full duplex com port with rxtx In-Reply-To: References: Message-ID: <4664194D.90301@iDIAcomputing.com> arnab bhaumik wrote: > hi , > > till now i did half duplex communication with rxtx package on com > package. > > my question is : is it possible to use com port with full duplex mode > with rxtx package . > > > ther is example of SimpleRead class and SimpleWrite class. it is > clear that if i can use both the class simultaneously then full duplex > is possible......... I haven't looked at the SimpleRead and SimpleWrite classes (I originally wrote my code for the javax.comm api), but full duplex is certainly possible. My CommReader class requires an object analogous to a OutputStream or Writer. When started, it spawns a thread that reads the comm port and writes to that output device. In this way the input is asynchronous and dependent on the actual input data. For full duplex, I extend that class with CommReaderWriter, which adds synchronous output methods. Hope that helps, George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From supsoop at hotmail.com Mon Jun 4 15:21:06 2007 From: supsoop at hotmail.com (soop soop) Date: Mon, 04 Jun 2007 21:21:06 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- Message-ID: Hi Guys, Looked through the archives but still cannot figure this out. I have a Motorola G24 GPRS/GSM modem that I am connecting to my server running Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not detecting the port, CommPortIdentifier.getPortIdentifiers(). I have added the line to RXTXCommDriver: "ttyACM" // for USB Modems Rxtx still does not seem to find the port. Is there something I am missing to make this port visable? [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control Model driver for USB modems and ISDN adapters I really need your help as I have moved my server from windows to Linux and have been down for a few days because of this .. Thanks so much! _________________________________________________________________ PC Magazine’s 2007 editors’ choice for best Web mail—award-winning Windows Live Hotmail. http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 From tjarvi at qbang.org Mon Jun 4 16:17:35 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Jun 2007 16:17:35 -0600 (MDT) Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: On Mon, 4 Jun 2007, soop soop wrote: > Hi Guys, > > Looked through the archives but still cannot figure this out. I have a > Motorola G24 GPRS/GSM modem that I am connecting to my server running Ubuntu. > I can see my modem as is shows up as ttyACM0, but RXTX is not detecting the > port, CommPortIdentifier.getPortIdentifiers(). > > I have added the line to RXTXCommDriver: > > "ttyACM" // for USB Modems > > Rxtx still does not seem to find the port. Is there something I am missing to > make this port visable? > > [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver > [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device > [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control Model > driver for USB modems and ISDN adapters > > I really need your help as I have moved my server from windows to Linux and > have been down for a few days because of this .. Thanks so much! > You could try the INSTALL documentation that comes with the source for possible solutions. Those usually involve lockfile creation, permissions on the device file or the device is in use by another application (even another session of your application). The usual commands: ls -l /dev/ttyACM0 fuser /dev/ttyACM0 touch /var/lock/LCK.testfile && rm -f /var/lock/LCK.testfile whoami To disable lockfiles: ../configure --disable-lockfiles && make install -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Jun 4 16:22:52 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 04 Jun 2007 18:22:52 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <466490BC.3090801@gatworks.com> soop soop wrote: > I really need your help as I have moved my server from windows to Linux > and have been down for a few days because of this .. Thanks so much! can u open the device ? ie is the file protection/permissions keeping you out? From supsoop at hotmail.com Mon Jun 4 16:44:40 2007 From: supsoop at hotmail.com (soop soop) Date: Mon, 04 Jun 2007 22:44:40 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <466490BC.3090801@gatworks.com> Message-ID: Thanks for the reply, I see no exceptions being thrown, just no detection of the port whats so ever. I will run rxtx in debug mode and log. If this were a permissions issue would I not see some exceptions being thrown? >From: Uncle George >Reply-To: RXTX Developers and Users >To: RXTX Developers and Users >Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >Date: Mon, 04 Jun 2007 18:22:52 -0400 > >soop soop wrote: > > > I really need your help as I have moved my server from windows to Linux > > and have been down for a few days because of this .. Thanks so much! > >can u open the device ? ie is the file protection/permissions keeping >you out? >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ Get a preview of Live Earth, the hottest event this summer - only on MSN http://liveearth.msn.com?source=msntaglineliveearthhm From netbeans at gatworks.com Mon Jun 4 17:06:15 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 04 Jun 2007 19:06:15 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <46649AE7.10405@gatworks.com> Exceptions on what? On startup it wants to lookup all devices in /dev that it is capable of opening ( within the list of specific 'comm' devices ). If it cannot open, then does not get onto list. Part of this process, if configured, will also test if the "LOCK" schema can also be opened for the device. then it gets on the list of avail comm port. soop soop wrote: > Thanks for the reply, > > I see no exceptions being thrown, just no detection of the port whats so > ever. I will run rxtx in debug mode and log. If this were a permissions > issue would I not see some exceptions being thrown? > > >> From: Uncle George >> Reply-To: RXTX Developers and Users >> To: RXTX Developers and Users >> Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >> Date: Mon, 04 Jun 2007 18:22:52 -0400 >> >> soop soop wrote: >> >>> I really need your help as I have moved my server from windows to Linux >>> and have been down for a few days because of this .. Thanks so much! >> can u open the device ? ie is the file protection/permissions keeping >> you out? >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _________________________________________________________________ > Get a preview of Live Earth, the hottest event this summer - only on MSN > http://liveearth.msn.com?source=msntaglineliveearthhm > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From alex.flint at gmail.com Mon Jun 4 21:31:49 2007 From: alex.flint at gmail.com (Alex Flint) Date: Tue, 5 Jun 2007 13:01:49 +0930 Subject: [Rxtx] random EXCEPTION_ACCESS_VIOLATION errors Message-ID: Hi All, I'm running winXP and RXTX 2.1-7r2 (the latest from the webpage as of June 2007). I'm sending sequences of 64 lines (each line has about 15 chars) at various intervals. The strings are sent fine, until I get the following error (from hs_err_pid3316.log, at the end of this email). What can I do to avoid the error? Obviously this is a low-level memory exception, but is there any way I can keep the JVM running after such an error? I noticed the exact same problem here: http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20070129/1180520.html Cheers, Alex # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x100034fb, pid=3316, tid=2400 # # Java VM: Java HotSpot(TM) Client VM (1.6.0_01-b06 mixed mode, sharing) # Problematic frame: # C [rxtxSerial.dll+0x34fb] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # --------------- T H R E A D --------------- Current thread (0x00386400): JavaThread "main" [_thread_in_native, id=2400] siginfo: ExceptionCode=0xc0000005, reading address 0x20726f78 Registers: EAX=0x20726f20, EBX=0x6d8922c0, ECX=0x00000005, EDX=0x20726f20 ESP=0x003efa30, EBP=0x003efb68, ESI=0x269728a0, EDI=0x00386400 EIP=0x100034fb, EFLAGS=0x00010212 Top of Stack: (sp=0x003efa30) 0x003efa30: 003efa3c 003efa64 0000000f ffffffff 0x003efa40: 003efa40 2a97f808 003efa6c 2b190ca8 0x003efa50: 00000000 2b190ec0 003efa90 008e2dd7 0x003efa60: 003efa90 008e2dd7 26977f88 6d815e72 0x003efa70: 00000004 2696eae0 0000008a 003efb0c 0x003efa80: 6d852b4a 2696eae0 00000003 26970930 0x003efa90: 000000cb 2696eae0 6d86b264 00385d40 0x003efaa0: 0000003f 003efb0c 26977f90 2ace65d8 Instructions: (pc=0x100034fb) 0x100034eb: ff ff 8d 76 00 eb 02 89 f6 90 8b 45 f8 8b 55 f8 0x100034fb: 8b 4a 58 83 c9 04 89 48 58 83 c4 f8 8b 45 f8 8b Stack: [0x003a0000,0x003f0000), sp=0x003efa30, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x34fb] Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j gnu.io.RXTXPort.writeArray([BIIZ)V+0 j gnu.io.RXTXPort$SerialOutputStream.write([B)V+76 j com.bjt.media.server.CommLink.send(Ljava/lang/String;)V+48 j com.bjt.media.server.DigitoolConnection.select(I)V+73 j com.bjt.media.server.DigitoolConnection.main([Ljava/lang/String;)V+74 v ~StubRoutines::call_stub --------------- P R O C E S S --------------- Java Threads: ( => current thread ) 0x02a69400 JavaThread "Thread-0" [_thread_in_native, id=3052] 0x02a4d000 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=3920] 0x02a48400 JavaThread "CompilerThread0" daemon [_thread_blocked, id=1968] 0x02a47400 JavaThread "Attach Listener" daemon [_thread_blocked, id=2984] 0x02a46400 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=2660] 0x02a41c00 JavaThread "Finalizer" daemon [_thread_blocked, id=3924] 0x02a3d800 JavaThread "Reference Handler" daemon [_thread_blocked, id=4008] =>0x00386400 JavaThread "main" [_thread_in_native, id=2400] Other Threads: 0x02a34400 VMThread [id=3708] 0x02a4e800 WatcherThread [id=3964] VM state:not at safepoint (normal execution) VM Mutex/Monitor currently owned by a thread: None Heap def new generation total 960K, used 131K [0x22960000, 0x22a60000, 0x22e40000) eden space 896K, 7% used [0x22960000, 0x22970ea8, 0x22a40000) from space 64K, 99% used [0x22a50000, 0x22a5fff8, 0x22a60000) to space 64K, 0% used [0x22a40000, 0x22a40000, 0x22a50000) tenured generation total 4096K, used 76K [0x22e40000, 0x23240000, 0x26960000) the space 4096K, 1% used [0x22e40000, 0x22e53060, 0x22e53200, 0x23240000) compacting perm gen total 12288K, used 137K [0x26960000, 0x27560000, 0x2a960000) the space 12288K, 1% used [0x26960000, 0x26982518, 0x26982600, 0x27560000) ro space 8192K, 62% used [0x2a960000, 0x2ae5e4e8, 0x2ae5e600, 0x2b160000) rw space 12288K, 52% used [0x2b160000, 0x2b7a0e78, 0x2b7a1000, 0x2bd60000) Dynamic libraries: 0x00400000 - 0x00423000 C:\Program Files\Java\jre1.6.0_01\bin\javaw.exe 0x7c900000 - 0x7c9b0000 C:\WINDOWS\system32\ntdll.dll 0x7c800000 - 0x7c8f4000 C:\WINDOWS\system32\kernel32.dll 0x77dd0000 - 0x77e6b000 C:\WINDOWS\system32\ADVAPI32.dll 0x77e70000 - 0x77f01000 C:\WINDOWS\system32\RPCRT4.dll 0x7e410000 - 0x7e4a0000 C:\WINDOWS\system32\USER32.dll 0x77f10000 - 0x77f57000 C:\WINDOWS\system32\GDI32.dll 0x76390000 - 0x763ad000 C:\WINDOWS\system32\IMM32.DLL 0x7c340000 - 0x7c396000 C:\Program Files\Java\jre1.6.0_01\bin\msvcr71.dll 0x6d7c0000 - 0x6da07000 C:\Program Files\Java\jre1.6.0_01\bin\client\jvm.dll 0x76b40000 - 0x76b6d000 C:\WINDOWS\system32\WINMM.dll 0x5cd70000 - 0x5cd77000 C:\WINDOWS\system32\serwvdrv.dll 0x5b0a0000 - 0x5b0a7000 C:\WINDOWS\system32\umdmxfrm.dll 0x6d310000 - 0x6d318000 C:\Program Files\Java\jre1.6.0_01\bin\hpi.dll 0x76bf0000 - 0x76bfb000 C:\WINDOWS\system32\PSAPI.DLL 0x6d770000 - 0x6d77c000 C:\Program Files\Java\jre1.6.0_01\bin\verify.dll 0x6d3b0000 - 0x6d3cf000 C:\Program Files\Java\jre1.6.0_01\bin\java.dll 0x6d7b0000 - 0x6d7bf000 C:\Program Files\Java\jre1.6.0_01\bin\zip.dll 0x10000000 - 0x10012000 C:\Documents and Settings\Alex\workspace\MediaServer\rxtxSerial.dll 0x73d90000 - 0x73db7000 C:\WINDOWS\system32\crtdll.dll VM Arguments: jvm_args: -Djava.library.path=C:\Documents and Settings\Alex\workspace\MediaServer java_command: com.bjt.media.server.DigitoolConnection Launcher Type: SUN_STANDARD Environment Variables: CLASSPATH=.;C:\Program Files\Java\j2re1.4.2_07\lib\ext\QTJava.zip PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\wbem;c:\applications\php;C:\Program Files\MATLAB\R2006a\bin\win32;C:\Roger\Projects\UAV\Bin\Debug;C:\Program Files\Microsoft SQL Server\80\Tools\Binn\;c:\Program Files\Microsoft SQL Server\90\Tools\binn\;C:\Program Files\QuickTime\QTSystem\;C:\Pfps\system;C:\Program Files\Java\jdk1.6.0_01\bin;C:\Program Files\Java\jdk1.6.0_01\jre\bin USERNAME=Alex OS=Windows_NT PROCESSOR_IDENTIFIER=x86 Family 15 Model 4 Stepping 1, GenuineIntel --------------- S Y S T E M --------------- OS: Windows XP Build 2600 Service Pack 2 CPU:total 1 family 15, cmov, cx8, fxsr, mmx, sse, sse2 Memory: 4k page, physical 1046508k(275288k free), swap 2522816k(1909176k free) vm_info: Java HotSpot(TM) Client VM (1.6.0_01-b06) for windows-x86, built on Mar 14 2007 00:24:02 by "java_re" with unknown MS VC++:1310 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070604/c87ae1f0/attachment-0003.html From alwyn.schoeman at gmail.com Tue Jun 5 00:10:19 2007 From: alwyn.schoeman at gmail.com (Alwyn Schoeman) Date: Tue, 5 Jun 2007 08:10:19 +0200 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Hi, I'm using a similar modem. By default rxtx doesn't look for devices that start with ACM, so you need to modify the source code and recompile. Look in RXTXCommDriver and add values for ACM in the registerScannedPorts method in the Linux specific parts. Look for osName.equals("Linux")... On 6/4/07, soop soop wrote: > > Hi Guys, > > Looked through the archives but still cannot figure this out. I have a > Motorola G24 GPRS/GSM modem that I am connecting to my server running > Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not > detecting the port, CommPortIdentifier.getPortIdentifiers(). > > I have added the line to RXTXCommDriver: > > "ttyACM" // for USB Modems > > Rxtx still does not seem to find the port. Is there something I am missing > to make this port visable? > > [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver > [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device > [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control > Model > driver for USB modems and ISDN adapters > > I really need your help as I have moved my server from windows to Linux > and > have been down for a few days because of this .. Thanks so much! > > _________________________________________________________________ > PC Magazine's 2007 editors' choice for best Web mail?award-winning Windows > Live Hotmail. > > http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -- Alwyn Schoeman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/b6cb3053/attachment-0003.html From naranjo.manuel at gmail.com Tue Jun 5 06:48:45 2007 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Tue, 05 Jun 2007 09:48:45 -0300 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> References: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Message-ID: <46655BAD.7010501@gmail.com> That's right, an easier solution is creating symlinks to acm. For example make ttyS70 to 79 point to ACM0 to 9 and that will help you a lot, and doesn't even require compile. > Hi, > > I'm using a similar modem. By default rxtx doesn't look for devices > that start with ACM, so you need to modify the > source code and recompile. > > Look in RXTXCommDriver and add values for ACM in the > registerScannedPorts method in the Linux specific parts. Look for > osName.equals("Linux")... > From juanemc2 at gmail.com Tue Jun 5 07:02:43 2007 From: juanemc2 at gmail.com (Juan) Date: Tue, 5 Jun 2007 10:02:43 -0300 Subject: [Rxtx] Problems with Epson TMU220B POSPrinter using XON/XOFF Flow Control and rxtx jar and dll's with the serial port. Message-ID: Hi!, I?m having trouble printing to the serial port using the latest version of rxtx jar and dll's with an Epson POSPrinter. I`ve switched the printer to work with XON/XOFF Flow Control and have watched the serial port to be sure the printer is sending the XON XOFF stop and go characters. I`ve setted the port like this: CommPortIdentifier commPortIdentifier = CommPortIdentifier.* getPortIdentifier*(_portName); SerialPort serialPort = (SerialPort)commPortIdentifier.open(*this*.getClass().getName(), 2000); serialPort.setSerialPortParams(_baudRate, _dataBits, _stopBits, _parity); serialPort.setFlowControlMode( SerialPort.*FLOWCONTROL_XONXOFF_IN* | SerialPort.*FLOWCONTROL_XONXOFF_OUT*); where the baudRate is 9600 the dataBits is 8 the stopBits is 1 and the parity is 0 It seems as the library isn`t taking into account the XON XOFF setting. I would like to know if I`m setting correctly the Flow Control and if you had had any experiences using XON XOFF flow control and could give me some help to solve my problem. I`m very thankful in advance, Yours, Juan Polero -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/b080995a/attachment-0003.html From ehdez.correo at gmail.com Tue Jun 5 07:12:53 2007 From: ehdez.correo at gmail.com (=?ISO-8859-1?Q?Enrique_Hern=E1ndez?=) Date: Tue, 5 Jun 2007 09:12:53 -0400 Subject: [Rxtx] problem with rxtx Message-ID: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Hello: I doing a simple test to show the serial ports. This is the code: import java.util.Enumeration; import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; public class Show { private Enumeration portList; private CommPortIdentifier portId; private SerialPort port; /** Creates a new instance of Show */ public Show() { } public static void main(String args[]){ Show show = new Show(); show.portList = CommPortIdentifier.getPortIdentifiers(); String tPort = ""; System.out.println("========================================="); while(show.portList.hasMoreElements()){ show.portId = (CommPortIdentifier)show.portList.nextElement(); if(show.portId.getPortType() == CommPortIdentifier.PORT_SERIAL) tPort = "Serial"; else tPort = "Parallel"; System.out.println(show.portId.getName() + " " + tPort); } } } whit The problem is that this code not show the serial ports, this show the no use serial ports. I want to connect whit the modem but when windows open and connect the modem my application don't see the port(COMM3) when it is connect. what I can do? Is that the correct way to know the ports? thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/eedd744b/attachment-0003.html From ehdez.correo at gmail.com Tue Jun 5 07:42:13 2007 From: ehdez.correo at gmail.com (=?ISO-8859-1?Q?Enrique_Hern=E1ndez?=) Date: Tue, 5 Jun 2007 09:42:13 -0400 Subject: [Rxtx] serial port Message-ID: <4a814e1f0706050642p4ce9ac7bka80f9479c524c5ea@mail.gmail.com> Hello: How I can ask to the port what device is connect and information about this device. thanks. bye. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/4d10d26a/attachment-0003.html From supsoop at hotmail.com Tue Jun 5 09:29:00 2007 From: supsoop at hotmail.com (soop soop) Date: Tue, 05 Jun 2007 15:29:00 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Message-ID: Hi Guys, Thanks for all your help. I found the problem. I created a user, Tomcat55, for my tomcat but it did not belong to any group. I then added this user to dialout group to have access to the device ttyACM0. Works perfectly! Again permissions was the issue. This also seems to be persistent as a server reboot does not effect the access. Cheers! >From: "Alwyn Schoeman" >Reply-To: RXTX Developers and Users >To: "RXTX Developers and Users" >Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >Date: Tue, 5 Jun 2007 08:10:19 +0200 > >Hi, > >I'm using a similar modem. By default rxtx doesn't look for devices that >start with ACM, so you need to modify the >source code and recompile. > >Look in RXTXCommDriver and add values for ACM in the registerScannedPorts >method in the Linux specific parts. Look for osName.equals("Linux")... > >On 6/4/07, soop soop wrote: >> >>Hi Guys, >> >>Looked through the archives but still cannot figure this out. I have a >>Motorola G24 GPRS/GSM modem that I am connecting to my server running >>Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not >>detecting the port, CommPortIdentifier.getPortIdentifiers(). >> >>I have added the line to RXTXCommDriver: >> >>"ttyACM" // for USB Modems >> >>Rxtx still does not seem to find the port. Is there something I am missing >>to make this port visable? >> >>[ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver >>[ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device >>[ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control >>Model >>driver for USB modems and ISDN adapters >> >>I really need your help as I have moved my server from windows to Linux >>and >>have been down for a few days because of this .. Thanks so much! >> >>_________________________________________________________________ >>PC Magazine's 2007 editors' choice for best Web mail—award-winning Windows >>Live Hotmail. >> >>http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 >> >> >>_______________________________________________ >>Rxtx mailing list >>Rxtx at qbang.org >>http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > >-- >Alwyn Schoeman >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ Need a break? Find your escape route with Live Search Maps. http://maps.live.com/default.aspx?ss=Restaurants~Hotels~Amusement%20Park&cp=33.832922~-117.915659&style=r&lvl=13&tilt=-90&dir=0&alt=-1000&scene=1118863&encType=1&FORM=MGAC01 From netbeans at gatworks.com Tue Jun 5 09:42:31 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 11:42:31 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <46658467.20101@gatworks.com> soop soop wrote: > > Hi Guys, > > Thanks for all your help. I found the problem. I created a user, > Tomcat55, for my tomcat but it did not belong to any group. I then added Look at man pages for the program udev. From tjarvi at qbang.org Tue Jun 5 18:18:17 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Jun 2007 18:18:17 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Message-ID: On Tue, 5 Jun 2007, Enrique Hern?ndez wrote: > The problem is that this code not show the serial ports, this show the no > use serial ports. I want to connect whit the modem but when windows open and > connect the modem my application don't see the port(COMM3) when it is > connect. > what I can do? > Is that the correct way to know the ports? > Hello, We may have problems understanding each other. On windows, the port will not be an available serial port if another application has the port open. That is just how the library behaves. If you can not see the port in the enumerated list, you could not open it. Also note that enumeration only happens once. If you add a port such as a new USB dongle, the port will not be visible until the next time your application runs. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Tue Jun 5 18:45:01 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 20:45:01 -0400 Subject: [Rxtx] problem with rxtx In-Reply-To: References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Message-ID: <4666038D.8090700@gatworks.com> Trent Jarvi wrote: > > > Also note that enumeration only happens once. If you add a port such as > a new USB dongle, the port will not be visible until the next time your > application runs. Is this written in stone ? somewhere? From tjarvi at qbang.org Tue Jun 5 18:54:36 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Jun 2007 18:54:36 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <4666038D.8090700@gatworks.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> Message-ID: On Tue, 5 Jun 2007, Uncle George wrote: > Trent Jarvi wrote: >> >> >> Also note that enumeration only happens once. If you add a port such as >> a new USB dongle, the port will not be visible until the next time your >> application runs. > > Is this written in stone ? somewhere? It is just the current behavior. There is nothing preventing a fix that allows reenumeration. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Tue Jun 5 19:55:19 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 21:55:19 -0400 Subject: [Rxtx] problem with rxtx In-Reply-To: References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> Message-ID: <46661407.4020308@gatworks.com> >> Is this written in stone ? somewhere? > > It is just the current behavior. There is nothing preventing a fix that > allows reenumeration. With usb, ..... , things come and go. Seems a shame that you have to kill application to get at the device u just plugged in. From joachim at buechse.ch Wed Jun 6 01:50:06 2007 From: joachim at buechse.ch (Joachim Buechse) Date: Wed, 6 Jun 2007 09:50:06 +0200 Subject: [Rxtx] problem with rxtx In-Reply-To: <46661407.4020308@gatworks.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> <46661407.4020308@gatworks.com> Message-ID: <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> On MacOS RXTX's enumeration handling is more flexible. It will find new ports that are added during the lifetime of the application. But this is inherently incompatible with suns javax.comm implementation... Regards, Joachim On 06.06.2007, at 03:55, Uncle George wrote: > >>> Is this written in stone ? somewhere? >> >> It is just the current behavior. There is nothing preventing a >> fix that >> allows reenumeration. > > With usb, ..... , things come and go. Seems a shame that you have to > kill application to get at the device u just plugged in. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Jun 6 06:06:48 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Jun 2007 06:06:48 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> <46661407.4020308@gatworks.com> <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> Message-ID: Sun's javax.comm is not a major concern going forward. As long as we do not break old applications using rxtx, I see no reason to limit rxtx to that convention. We have already rejected version 3 from Sun as a dead end and limited our compatability to version 2. That does not mean we will not try to work with Sun and others but the current javax.comm convention (v3) is not a well conceived path. There has been discussion about doing a JSR which is one valid option. On Wed, 6 Jun 2007, Joachim Buechse wrote: > On MacOS RXTX's enumeration handling is more flexible. It will find > new ports that are added during the lifetime of the application. But > this is inherently incompatible with suns javax.comm implementation... > > Regards, > Joachim > > On 06.06.2007, at 03:55, Uncle George wrote: > >> >>>> Is this written in stone ? somewhere? >>> >>> It is just the current behavior. There is nothing preventing a >>> fix that >>> allows reenumeration. >> >> With usb, ..... , things come and go. Seems a shame that you have to >> kill application to get at the device u just plugged in. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From yvespielusenet at free.fr Wed Jun 6 08:46:35 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 16:46:35 +0200 Subject: [Rxtx] [PARALLEL] resource in use Message-ID: <1181141195.3407.20.camel@localhost.localdomain> Hello, I want to use rxtx in my application. I haveto send data to a very old printer (which have a drum and hammers http://perso.orange.fr/tiie/page00010017.html) This is printer is connecter with centronics. It works well but, while it's writting and I putthe printer off-line, after about 45 seconds, I have this error : ------------------------------------- java.io.IOException: La ressource demand?e est en cours d'utilisation. in writeArray at gnu.io.LPRPort.writeArray(Native Method) at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:292) at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:161) at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:156) at mce.buffer.bufferManager.BufferManager$PrintBuffer.run(BufferManager.java:141) The IOexception means "The wanted resource is in use" ------------------------------------- Here is the line 141 of BufferManager : ------------------------------------- while(send){ try{ fos.write(bb); <=== line 141 send = false; } catch(Exception e){ javax.swing.JOptionPane.showMessageDialog(null, "Erreur d'envoie. Veuillez cliquer sur OK pour relancer l'impression de la vignette.\nV?rifiez votre impression !", "Erreur d'envoie", javax.swing.JOptionPane.WARNING_MESSAGE); e.printStackTrace(System.err); System.err.flush(); System.out.println(e); send = true; } } -------------------------------- 'fos' is an outputstream which contains the rxtx stream (this.os is the rxtx outputstream) : -------------------------------- public void write(byte[] bb) throws IOException{ this.write(bb, 0, bb.length); } public void write(byte[] bb, int off, int len) throws IOException{ while(!imp1.isPrinterSelected() || !imp2.isPrinterSelected()){ } this.os.write(bb, off, len); } -------------------------------- Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( can you help me ? thank you :) -- yves piel From yvespielusenet at free.fr Wed Jun 6 09:11:15 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 17:11:15 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181141195.3407.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> Message-ID: <1181142675.3407.23.camel@localhost.localdomain> I forgot to tell that It's under windows XP and java 1.5. Le mercredi 06 juin 2007 ? 16:46 +0200, yves pielusenet a ?crit : > Hello, > I want to use rxtx in my application. I haveto send data to a very old > printer (which have a drum and hammers > http://perso.orange.fr/tiie/page00010017.html) > This is printer is connecter with centronics. It works well but, while > it's writting and I putthe printer off-line, after about 45 seconds, I > have this error : > ------------------------------------- > java.io.IOException: La ressource demand?e est en cours d'utilisation. > in writeArray > at gnu.io.LPRPort.writeArray(Native Method) > at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:292) > at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:161) > at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:156) > at mce.buffer.bufferManager.BufferManager$PrintBuffer.run(BufferManager.java:141) > > The IOexception means "The wanted resource is in use" > ------------------------------------- > > Here is the line 141 of BufferManager : > > ------------------------------------- > while(send){ > try{ > fos.write(bb); <=== line 141 > send = false; > } > catch(Exception e){ > javax.swing.JOptionPane.showMessageDialog(null, "Erreur d'envoie. Veuillez cliquer sur OK pour relancer l'impression de la vignette.\nV?rifiez votre impression !", "Erreur d'envoie", javax.swing.JOptionPane.WARNING_MESSAGE); > e.printStackTrace(System.err); > System.err.flush(); > System.out.println(e); > send = true; > } > } > -------------------------------- > 'fos' is an outputstream which contains the rxtx stream (this.os is the rxtx outputstream) : > > -------------------------------- > public void write(byte[] bb) throws IOException{ > this.write(bb, 0, bb.length); > } > public void write(byte[] bb, int off, int len) throws IOException{ > while(!imp1.isPrinterSelected() || !imp2.isPrinterSelected()){ > } > this.os.write(bb, off, len); > } > -------------------------------- > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > can you help me ? > > thank you :) > From netbeans at gatworks.com Wed Jun 6 09:21:46 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 11:21:46 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181141195.3407.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> Message-ID: <4666D10A.8000507@gatworks.com> } > -------------------------------- > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > can you help me ? > > thank you :) > windoz or linux? ( I guess windoz ) for windoz, there appears to be a timeout ( as Comments suggest ) of about 40seconds. > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } for linux, there is no implied timeout. > if( write( fd, bytes, count ) < 0 ) > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); From netbeans at gatworks.com Wed Jun 6 09:39:41 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 11:39:41 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666D10A.8000507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> Message-ID: <4666D53D.90000@gatworks.com> Uncle George wrote: > } >> -------------------------------- >> >> Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( >> >> can you help me ? From reading the code, I can see your concern. And it appears you are correct, because some of the data will be sent to the OS printer buffers, and then it will refuse to accept anymore. Unfortunately, writeArray does not return the num of characters written :{ So application has no idea to how many characters were accepted by the OS. I dont do windoz, so I cant say with absolute certainty what windoz will do with an off-line condition. If you have the source, and can compile, then maybe u can increase the loop count to hit 4hours? From yvespielusenet at free.fr Wed Jun 6 09:53:25 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 17:53:25 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666D10A.8000507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> Message-ID: <1181145205.3407.35.camel@localhost.localdomain> Thank you for your explanation :) This timeout comes when no data has been send to the printer after 40seconds if I well understand. But why there is such a timeout ? If I setthe printer offline while it's printing I mustn't have an exception. I don't understand why the "printer should solv all problems like buffer full" in 40 seconds. If I pause the printer the buffer will not be emptied, isn't it ? I not very familiar with C/C++, but it seem that the exception is thrown only when countWritten == 0, that means no data at all has been sent. So Is my code is good since when I intercept this exception I send all my buffer again. There is no way that the printer receive two times same bytes ? thanks ps: yes the application is running on windows XP since I developpe under Debian Le mercredi 06 juin 2007 ? 11:21 -0400, Uncle George a ?crit : > } > > -------------------------------- > > > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > > > can you help me ? > > > > thank you :) > > > > windoz or linux? ( I guess windoz ) > > for windoz, there appears to be a timeout ( as Comments suggest ) of > about 40seconds. > > while( count > 0 ){ > > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > > /* > > this are 20 * 2 seconds, in this time a printer (or other parallel device) > > should solv all problems like buffer full, etc > > */ > > if(errorCount++ < 20){ > > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > > continue; > > } > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > for linux, there is no implied timeout. > > if( write( fd, bytes, count ) < 0 ) > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Wed Jun 6 10:34:24 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 12:34:24 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181145205.3407.35.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> Message-ID: <4666E210.30507@gatworks.com> yves pielusenet wrote: > Thank you for your explanation :) > This timeout comes when no data has been send to the printer after > 40seconds if I well understand. But why there is such a timeout ? If I > setthe printer offline while it's printing I mustn't have an exception. > I don't understand why the "printer should solv all problems like buffer > full" in 40 seconds. If I pause the printer the buffer will not be > emptied, isn't it ? > > I not very familiar with C/C++, but it seem that the exception is thrown > only when countWritten == 0, that means no data at all has been sent. So > Is my code is good since when I intercept this exception I send all my > buffer again. There is no way that the printer receive two times same > bytes ? More technically, the function call returns and reports that 0 characters was written in this call. when 0 characters are written, it will check how many times 0 characters was written. If it has tried LESS than 20 times(errorCount), it will sleep() and try to write again. After 20 times, it wont sleep, but throw you the exception. Now suppose you are writing a 120 character line. you off-lined/paused your printer. The OS has room for 80 more characters in it's printer buffer. The WriteFile() will have a char count of 120, but on return the countWritten = 80. You still have 40 more characters to print. Since countWritten != 0, the counters: bytes += countWritten; count -= countWritten; get updated, and the Writefile now has a count of 40 characters. Since the printer is off-line, the countwritten is 0. And so the loop continues, till 40 seconds is up. As to why it is this way, i dont know ( not a windoz maven ); Also the sleep(20) in the loop is not so intuitive to suggest 2 seconds of sleep. I would have guessed 20seconds, or 20milliseconds. But go figure. BTW: Since your computer sends you error messages in French, does it curse in English? :)))) From yvespielusenet at free.fr Thu Jun 7 02:27:44 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Thu, 07 Jun 2007 10:27:44 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666E210.30507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> Message-ID: <1181204864.3501.10.camel@localhost.localdomain> Maybe in my case I should re-compile rxtx and change the code. Instead of send an exception I should display a dialog box to ask if it's printer problem or if it should trie to send bytes. Something like : while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } if(displayDialogBox("Try again to send datas ??")){ errorCount = 0; } else{ throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } } Le mercredi 06 juin 2007 ? 12:34 -0400, Uncle George a ?crit : > yves pielusenet wrote: > > Thank you for your explanation :) > > This timeout comes when no data has been send to the printer after > > 40seconds if I well understand. But why there is such a timeout ? If I > > setthe printer offline while it's printing I mustn't have an exception. > > I don't understand why the "printer should solv all problems like buffer > > full" in 40 seconds. If I pause the printer the buffer will not be > > emptied, isn't it ? > > > > I not very familiar with C/C++, but it seem that the exception is thrown > > only when countWritten == 0, that means no data at all has been sent. So > > Is my code is good since when I intercept this exception I send all my > > buffer again. There is no way that the printer receive two times same > > bytes ? > More technically, the function call returns and reports that 0 > characters was written in this call. > when 0 characters are written, it will check how many times 0 characters > was written. If it has tried LESS than 20 times(errorCount), it will > sleep() and try to write again. > After 20 times, it wont sleep, but throw you the exception. > > Now suppose you are writing a 120 character line. you off-lined/paused > your printer. The OS has room for 80 more characters in it's printer > buffer. The WriteFile() will have a char count of 120, but on return the > countWritten = 80. You still have 40 more characters to print. > Since countWritten != 0, the counters: > bytes += countWritten; > count -= countWritten; > get updated, and the Writefile now has a count of 40 characters. Since > the printer is off-line, the countwritten is 0. And so the loop > continues, till 40 seconds is up. > > As to why it is this way, i dont know ( not a windoz maven ); > Also the sleep(20) in the loop is not so intuitive to suggest 2 seconds > of sleep. I would have guessed 20seconds, or 20milliseconds. But go figure. > > BTW: Since your computer sends you error messages in French, does it > curse in English? :)))) > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 06:11:43 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 08:11:43 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181204864.3501.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> Message-ID: <4667F5FF.8070903@gatworks.com> your suggestion appears good. I dont know what displayDialogBox exactly will do, so all I can say it that it looks good. But I'd like to wait 10min before first dialog box And a 5 min wait for every dialog box there after. And since these are custom solution/choices, maybe a more exact explanation of what the issue is. if(errorCount++ < 300){ // wait 10min ( 10min * 60sec / 2 ) Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } if(displayDialogBox("Printer has Paused. Retry sending data?")){ errorCount = 150; // Wait for 5 min thereafter continue; } > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } yves pielusenet wrote: > Maybe in my case I should re-compile rxtx and change the code. Instead > of send an exception I should display a dialog box to ask if it's > printer problem or if it should trie to send bytes. Something like : > > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > > if(displayDialogBox("Try again to send datas ??")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > } > From yvespielusenet at free.fr Thu Jun 7 07:17:21 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Thu, 07 Jun 2007 15:17:21 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4667F5FF.8070903@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <4667F5FF.8070903@gatworks.com> Message-ID: <1181222241.3501.20.camel@localhost.localdomain> thank you :) 'displayDialogBox()' I think doesn't exist. It was just for the example :) But I think It should not be so complicated to display a dialog box under windows with YES/NO buttons. When yes is clicked it return 0 other it returns 1. Le jeudi 07 juin 2007 ? 08:11 -0400, Uncle George a ?crit : > your suggestion appears good. I dont know what displayDialogBox exactly > will do, so all I can say it that it looks good. > > But I'd like to wait 10min before first dialog box And a 5 min wait for > every dialog box there after. And since these are custom > solution/choices, maybe a more exact explanation of what the issue is. > > if(errorCount++ < 300){ // wait 10min ( 10min * 60sec / 2 ) > Sleep( 20 ); /* make a small pause to execute all other requests > in all other threads */ > continue; > } > > if(displayDialogBox("Printer has Paused. Retry sending data?")){ > errorCount = 150; // Wait for 5 min thereafter > continue; > } > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > > yves pielusenet wrote: > > Maybe in my case I should re-compile rxtx and change the code. Instead > > of send an exception I should display a dialog box to ask if it's > > printer problem or if it should trie to send bytes. Something like : > > > > while( count > 0 ){ > > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > > /* > > this are 20 * 2 seconds, in this time a printer (or other parallel device) > > should solv all problems like buffer full, etc > > */ > > if(errorCount++ < 20){ > > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > > continue; > > } > > > > if(displayDialogBox("Try again to send datas ??")){ > > errorCount = 0; > > } > > else{ > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > } > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 07:41:43 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 09:41:43 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181222241.3501.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <4667F5FF.8070903@gatworks.com> <1181222241.3501.20.camel@localhost.localdomain> Message-ID: <46680B17.8050109@gatworks.com> yves pielusenet wrote: > thank you :) > 'displayDialogBox()' I think doesn't exist. It was just for the > example :) too bad. Good luck. From rtrout at webbresearch.com Thu Jun 7 11:23:04 2007 From: rtrout at webbresearch.com (Robert Trout) Date: Thu, 07 Jun 2007 13:23:04 -0400 Subject: [Rxtx] Disconnected PortServer TS causes Java to hang Message-ID: <1181236984.14186.33.camel@sisyphus.DinkumSoftware.com> I'm running Linux with sun's Java 1.4.2, Java comm API 2.0, RXTX 2.0-7pre1, and the RealPort digi driver. "/dev/ttyrp00" is a RealPort device. My Java application never returns from a ComPortIdentifier.getPortIdentifier("/dev/ttyrp00") call while the Digi PortServer TS 4 is disconnected from the network. If I later re-connect the PortServer, the call returns about 30 seconds later (it's like a serial port read or write is blocking until the PortServer is re- connected). With the PortServer disconnected, minicom immediately responds with "cannot open /dev/ttyrp00: No such file or directory". I would like my Java application to behave similarly. That is, respond with an error condition instead of hanging when the PortServer is not connected. Since minicom and Java behave differently, I think this "hanging" behavior may be due to RXTX or Java? Has anyone had a similar issue? Solutions? Suggestions? Thanks, Robert From vicnevicne at gmail.com Thu Jun 7 12:16:02 2007 From: vicnevicne at gmail.com (Vicne) Date: Thu, 07 Jun 2007 20:16:02 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181204864.3501.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> Message-ID: <46684B62.7080802@gmail.com> yves pielusenet wrote: > Maybe in my case I should re-compile rxtx and change the code. Instead > of send an exception I should display a dialog box to ask if it's > printer problem or if it should trie to send bytes. Something like : > > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > > if(displayDialogBox("Try again to send datas ??")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > } > Sorry to step in without a specific solution to your problem, but I wanted to share my feeling regarding this proposal. AFAIK, it's generally considered bad practice to pop-up a prompt from a library. The main reason is that in general use, you can't guarantee that someone is actually present behind the console. Imagine a print server in a machine room, connected to a park of printers. In that case, when one printer fails, the logical behaviour would be to use an other one. If you change RxTx the way you propose, the printer queue will simply be stuck with a useless "Try again to send data ?" prompt until an administrator opens a remote connection to the print server's console and clicks "no". Second, it would create a dependency upon the existence of a graphical console (if you go the graphical "dialogBox" way). On many applications (typically server or embedded ones), the JVM is "headless" and if you try to pop-up a dialog, your app would throw an exception (at best) or just wouldn't display the prompt anywhere... Going the "text console" way is not more reliable, because on graphical environments, the text console is hidden unless explicitly requested. My advice would be to think again and find another solution. Ideas are : - make the number of retries a parameter so that you can tune it to what you think is reasonable - throw a more specific exception when the number of retries has been reached, so that a specific prompt can be shown at a higher level Anyway, if you feel that the prompt is the way to go in your case, I would at least make that prompt conditional. The least intrusive way would probably be using a system property, like if("true".equals(System.getProperty("org.rxtx.usePrompt")) && displayDialogBox("Retry sending data ?")){ errorCount = 0; } else{ throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } By default, the behaviour would remain as it is now, but you could force the prompts by defining the property at VM launch if desired. (for example : java.exe -Dorg.rxtx.usePrompt=true myApp) Also, you seemed to say you wanted the printer to start again exactly where is stopped. It would indeed be the best way when the printer is put offline for a few seconds. On the other hand, if the printer is turned off (or the printer runs out of paper, or someone steps on the mains cable), then the only way to go back to a "stable" situation would be by printing the item (page, label, etc.) again from scratch... Just my two cents. Vicne PS : By the way, the dialog box thing is very platform dependant on the C-side, and I think the simplest way would probably be to bridge it to a Java call where you can implement it like you proposed : public boolean displayDialogBox(prompt) { return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); } From netbeans at gatworks.com Thu Jun 7 14:08:24 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 16:08:24 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46684B62.7080802@gmail.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> Message-ID: <466865B8.4060004@gatworks.com> My feeling is that the code that was suggested was for his environs ( his shop ). The issue here is that after a 40+ second wait, an exception will be thrown. But you really dont have a way of 'cancelling' all the WriteFiles() that have already occured before the exception so that your writeArray and the Commapi can backtrack to a position in which they are in sync. The main ( really mine ) concern is not to lose data, or replicate data. After 40seconds, 300 seconds, 55min, no matter how long, data should not be lost or duplicated. But as soon as the exception is thrown, that possibility exists. Maybe an event should be thrown instead? Vicne wrote: > yves pielusenet wrote: >> Maybe in my case I should re-compile rxtx and change the code. Instead >> of send an exception I should display a dialog box to ask if it's >> printer problem or if it should trie to send bytes. Something like : >> >> while( count > 0 ){ >> if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ >> /* >> this are 20 * 2 seconds, in this time a printer (or other parallel device) >> should solv all problems like buffer full, etc >> */ >> if(errorCount++ < 20){ >> Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ >> continue; >> } >> >> if(displayDialogBox("Try again to send datas ??")){ >> errorCount = 0; >> } >> else{ >> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >> break; >> } >> } >> > > Sorry to step in without a specific solution to your problem, but I > wanted to share my feeling regarding this proposal. AFAIK, it's > generally considered bad practice to pop-up a prompt from a library. > The main reason is that in general use, you can't guarantee that > someone is actually present behind the console. Imagine a print server > in a machine room, connected to a park of printers. In that case, when > one printer fails, the logical behaviour would be to use an other one. > If you change RxTx the way you propose, the printer queue will simply be > stuck with a useless "Try again to send data ?" prompt until an > administrator opens a remote connection to the print server's console > and clicks "no". > Second, it would create a dependency upon the existence of a > graphical console (if you go the graphical "dialogBox" way). On many > applications (typically server or embedded ones), the JVM is "headless" > and if you try to pop-up a dialog, your app would throw an exception (at > best) or just wouldn't display the prompt anywhere... Going the "text > console" way is not more reliable, because on graphical environments, > the text console is hidden unless explicitly requested. > > My advice would be to think again and find another solution. Ideas are : > - make the number of retries a parameter so that you can tune it to what > you think is reasonable > - throw a more specific exception when the number of retries has been > reached, so that a specific prompt can be shown at a higher level > > Anyway, if you feel that the prompt is the way to go in your case, I > would at least make that prompt conditional. The least intrusive way > would probably be using a system property, like > > if("true".equals(System.getProperty("org.rxtx.usePrompt")) > && displayDialogBox("Retry sending data ?")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > > > By default, the behaviour would remain as it is now, but you could > force the prompts by defining the property at VM launch if desired. (for > example : java.exe -Dorg.rxtx.usePrompt=true myApp) > > > Also, you seemed to say you wanted the printer to start again > exactly where is stopped. It would indeed be the best way when the > printer is put offline for a few seconds. On the other hand, if the > printer is turned off (or the printer runs out of paper, or someone > steps on the mains cable), then the only way to go back to a "stable" > situation would be by printing the item (page, label, etc.) again from > scratch... > > > Just my two cents. > > > Vicne > > PS : By the way, the dialog box thing is very platform dependant on the > C-side, and I think the simplest way would probably be to bridge it to a > Java call where you can implement it like you proposed : > > public boolean displayDialogBox(prompt) { > return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", > JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); > } > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Thu Jun 7 17:48:11 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 Jun 2007 17:48:11 -0600 (MDT) Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <466865B8.4060004@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> Message-ID: An event is possible. I'm amazed this is the largest problem encountered while using the parallel code. How would the write ever exit if we throw events? Isn't this going to lead to hung applications? On Thu, 7 Jun 2007, Uncle George wrote: > My feeling is that the code that was suggested was for his environs ( > his shop ). > > The issue here is that after a 40+ second wait, an exception will be > thrown. But you really dont have a way of 'cancelling' all the > WriteFiles() that have already occured before the exception so that your > writeArray and the Commapi can backtrack to a position in which they are > in sync. > > The main ( really mine ) concern is not to lose data, or replicate data. > After 40seconds, 300 seconds, 55min, no matter how long, data should > not be lost or duplicated. But as soon as the exception is thrown, that > possibility exists. > > Maybe an event should be thrown instead? > > Vicne wrote: >> yves pielusenet wrote: >>> Maybe in my case I should re-compile rxtx and change the code. Instead >>> of send an exception I should display a dialog box to ask if it's >>> printer problem or if it should trie to send bytes. Something like : >>> >>> while( count > 0 ){ >>> if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ >>> /* >>> this are 20 * 2 seconds, in this time a printer (or other parallel device) >>> should solv all problems like buffer full, etc >>> */ >>> if(errorCount++ < 20){ >>> Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ >>> continue; >>> } >>> >>> if(displayDialogBox("Try again to send datas ??")){ >>> errorCount = 0; >>> } >>> else{ >>> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >>> break; >>> } >>> } >>> >> >> Sorry to step in without a specific solution to your problem, but I >> wanted to share my feeling regarding this proposal. AFAIK, it's >> generally considered bad practice to pop-up a prompt from a library. >> The main reason is that in general use, you can't guarantee that >> someone is actually present behind the console. Imagine a print server >> in a machine room, connected to a park of printers. In that case, when >> one printer fails, the logical behaviour would be to use an other one. >> If you change RxTx the way you propose, the printer queue will simply be >> stuck with a useless "Try again to send data ?" prompt until an >> administrator opens a remote connection to the print server's console >> and clicks "no". >> Second, it would create a dependency upon the existence of a >> graphical console (if you go the graphical "dialogBox" way). On many >> applications (typically server or embedded ones), the JVM is "headless" >> and if you try to pop-up a dialog, your app would throw an exception (at >> best) or just wouldn't display the prompt anywhere... Going the "text >> console" way is not more reliable, because on graphical environments, >> the text console is hidden unless explicitly requested. >> >> My advice would be to think again and find another solution. Ideas are : >> - make the number of retries a parameter so that you can tune it to what >> you think is reasonable >> - throw a more specific exception when the number of retries has been >> reached, so that a specific prompt can be shown at a higher level >> >> Anyway, if you feel that the prompt is the way to go in your case, I >> would at least make that prompt conditional. The least intrusive way >> would probably be using a system property, like >> >> if("true".equals(System.getProperty("org.rxtx.usePrompt")) >> && displayDialogBox("Retry sending data ?")){ >> errorCount = 0; >> } >> else{ >> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >> break; >> } >> >> >> By default, the behaviour would remain as it is now, but you could >> force the prompts by defining the property at VM launch if desired. (for >> example : java.exe -Dorg.rxtx.usePrompt=true myApp) >> >> >> Also, you seemed to say you wanted the printer to start again >> exactly where is stopped. It would indeed be the best way when the >> printer is put offline for a few seconds. On the other hand, if the >> printer is turned off (or the printer runs out of paper, or someone >> steps on the mains cable), then the only way to go back to a "stable" >> situation would be by printing the item (page, label, etc.) again from >> scratch... >> >> >> Just my two cents. >> >> >> Vicne >> >> PS : By the way, the dialog box thing is very platform dependant on the >> C-side, and I think the simplest way would probably be to bridge it to a >> Java call where you can implement it like you proposed : >> >> public boolean displayDialogBox(prompt) { >> return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", >> JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); >> } >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 19:18:51 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 21:18:51 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> Message-ID: <4668AE7B.3060409@gatworks.com> The UNIX version of writeArray is not too great either. It is possible that the write will only process some of the bytes. #else if( write( fd, bytes, count ) < 0 ) throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); #endif -------------------------------- Maybe it might be better to have the native function inform the caller of the # of characters written, then the commapi/output-buffer can be modified to reflect the #of chars written. If an exception is to be thrown, for too many loops of chars written == 0, then exception wont affect the state of the output buffer. Then a ParallelPort.restart() can be called to resume printing whats in the buffer. Trent Jarvi wrote: > An event is possible. I'm amazed this is the largest problem encountered > while using the parallel code. > > How would the write ever exit if we throw events? Isn't this going to > lead to hung applications? Sure. If you dont time out, then there is nothing that will force an EXIT from the write(). Issue is what has the OS done with the write. > > On Thu, 7 Jun 2007, Uncle George wrote: > >> My feeling is that the code that was suggested was for his environs ( >> his shop ). From yvespielusenet at free.fr Fri Jun 8 01:09:01 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Fri, 08 Jun 2007 09:09:01 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4668AE7B.3060409@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> Message-ID: <1181286541.3674.10.camel@localhost.localdomain> It is not possible that the rxtx java method write(byte[], int offset, int length) return anint which contains the number of byte really send to the printer instead of an exception ? So this is the programm which will see if all bytes have been sent. If not it can retry to send the unsended bytes. -------------------------------------------------------- int sended = 0; while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ sended += countWritten; /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } return sended; /*throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break;*/ } ... ... return countWritten; ------------------------------------------------ Le jeudi 07 juin 2007 ? 21:18 -0400, Uncle George a ?crit : > The UNIX version of writeArray is not too great either. It is possible > that the write will only process some of the bytes. > > #else > if( write( fd, bytes, count ) < 0 ) > throw_java_exception_system_msg( env, IO_EXCEPTION, > "writeArray" ); > #endif > -------------------------------- > > Maybe it might be better to have the native function inform the caller > of the # of characters written, then the commapi/output-buffer can be > modified to reflect the #of chars written. If an exception is to be > thrown, for too many loops of chars written == 0, then exception wont > affect the state of the output buffer. Then a ParallelPort.restart() can > be called to resume printing whats in the buffer. > > > Trent Jarvi wrote: > > An event is possible. I'm amazed this is the largest problem encountered > > while using the parallel code. > > > > How would the write ever exit if we throw events? Isn't this going to > > lead to hung applications? > Sure. If you dont time out, then there is nothing that will force an > EXIT from the write(). Issue is what has the OS done with the write. > > > > On Thu, 7 Jun 2007, Uncle George wrote: > > > >> My feeling is that the code that was suggested was for his environs ( > >> his shop ). > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Fri Jun 8 03:45:00 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 11:45:00 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181286541.3674.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> Message-ID: <20070608094500.GC21069@elberon.bln.de.ingenico.com> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > It is not possible that the rxtx java method write(byte[], int offset, > int length) return anint which contains the number of byte really send > to the printer instead of an exception ? > So this is the programm which will see if all bytes have been sent. If > not it can retry to send the unsended bytes. I think write() is void because in Java people love to do this since OutputStream :-) Of course on such interfaces you cannot implement something nice. If you would have a int write, you would not implement the interface and no applications expecting this interface would link/work/compile. oki, Steffen P.S.: (OT) If you propose not to implement the Java interfaces (especially not on JNI level), maybe optionally offering a wrapper that removes e.g. the write return value and so on to downgrade the powerful classic old POSIX read/write style to the modern limited Java style, then I agree :-) Same for read. Instead of things like "int avialable()" it is more powerful to have an approach as select(2) offers (to guarante the caller that read/write will not block [nothing else make sense anyway IMHO] but may read/write less bytes then requested). The caller gets full control and the higher level protocols can care about timeouts, invoking read in some loops and/or implement retransmission. On top of such an implementation, where everything is controlled, defined, guaranteed and reliable, someone could use an InputStream or OutputStream style interface. Or even better: don't use them at all :) just BTW :-) St. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From yvespielusenet at free.fr Fri Jun 8 05:52:45 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Fri, 08 Jun 2007 13:52:45 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <20070608094500.GC21069@elberon.bln.de.ingenico.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> Message-ID: <1181303565.11203.3.camel@localhost.localdomain> So maybe a better way should be to create a new Exception class which has a method "int getWrittenByte()". So the Exception should be use to send again bytes which are not printed yet. yves Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : > * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > > It is not possible that the rxtx java method write(byte[], int offset, > > int length) return anint which contains the number of byte really send > > to the printer instead of an exception ? > > So this is the programm which will see if all bytes have been sent. If > > not it can retry to send the unsended bytes. > > I think write() is void because in Java people love to do this > since OutputStream :-) Of course on such interfaces you cannot > implement something nice. If you would have a int write, you > would not implement the interface and no applications expecting > this interface would link/work/compile. > > oki, > > Steffen > > P.S.: (OT) > If you propose not to implement the Java interfaces (especially > not on JNI level), maybe optionally offering a wrapper that > removes e.g. the write return value and so on to downgrade the > powerful classic old POSIX read/write style to the modern limited > Java style, then I agree :-) Same for read. Instead of things > like "int avialable()" it is more powerful to have an approach as > select(2) offers (to guarante the caller that read/write will not > block [nothing else make sense anyway IMHO] but may read/write > less bytes then requested). The caller gets full control and the > higher level protocols can care about timeouts, invoking read in > some loops and/or implement retransmission. On top of such an > implementation, where everything is controlled, defined, > guaranteed and reliable, someone could use an InputStream or > OutputStream style interface. Or even better: don't use them at > all :) just BTW :-) > St. > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > 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. > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > 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. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Fri Jun 8 06:46:21 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 08:46:21 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181303565.11203.3.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> Message-ID: <46694F9D.5080501@gatworks.com> It seems that with outputstream.write(b[]), you become terribly uncoordinated as soon as an exception is thrown. Docs do not say what happens to the data. Yet from a practicable point of view, one would like to know if the write was accepted in-full, or rejected before any writes. There are no in betweens, as partial writes are not reportable. So for an outputstream.write(), in order for it to return, the full write request has to be taken, and stored in an internal output buffer. If there is no room, the write() is suspended, till there is room. Or throw's an IOException( "no room in buffer") ; As the select() loop for write reports buffer room avail, then more of the internal buffer is sent to the printer. yves pielusenet wrote: > So maybe a better way should be to create a new Exception class which > has a method "int getWrittenByte()". So the Exception should be use to > send again bytes which are not printed yet. > > yves > > Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : >> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: >>> It is not possible that the rxtx java method write(byte[], int offset, >>> int length) return anint which contains the number of byte really send >>> to the printer instead of an exception ? >>> So this is the programm which will see if all bytes have been sent. If >>> not it can retry to send the unsended bytes. >> I think write() is void because in Java people love to do this >> since OutputStream :-) Of course on such interfaces you cannot >> implement something nice. If you would have a int write, you >> would not implement the interface and no applications expecting >> this interface would link/work/compile. >> >> oki, >> >> Steffen >> >> P.S.: (OT) >> If you propose not to implement the Java interfaces (especially >> not on JNI level), maybe optionally offering a wrapper that >> removes e.g. the write return value and so on to downgrade the >> powerful classic old POSIX read/write style to the modern limited >> Java style, then I agree :-) Same for read. Instead of things >> like "int avialable()" it is more powerful to have an approach as >> select(2) offers (to guarante the caller that read/write will not >> block [nothing else make sense anyway IMHO] but may read/write >> less bytes then requested). The caller gets full control and the >> higher level protocols can care about timeouts, invoking read in >> some loops and/or implement retransmission. On top of such an >> implementation, where everything is controlled, defined, >> guaranteed and reliable, someone could use an InputStream or >> OutputStream style interface. Or even better: don't use them at >> all :) just BTW :-) >> St. >> >> About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. >> 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. >> >> About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. >> 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. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From Steffen.DETTMER at ingenico.com Fri Jun 8 08:12:18 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 16:12:18 +0200 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <46694F9D.5080501@gatworks.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: <20070608141218.GE21069@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 08:46 -0400: > It seems that with outputstream.write(b[]), you become terribly > uncoordinated as soon as an exception is thrown. Docs do not say what > happens to the data. (yes, so avoiding it seems to be good :)) > Yet from a practicable point of view, one would like to know if the > write was accepted in-full, or rejected before any writes. There are no > in betweens, as partial writes are not reportable. (which is an artificial API limitation. I never understood how this happend when they invented JDK because the well-known BSD socket API and thus [probably] WinSock does this correct, but anyway) > So for an outputstream.write(), in order for it to return, the full > write request has to be taken, and stored in an internal output buffer. > If there is no room, the write() is suspended, till there is room. Or > throw's an IOException( "no room in buffer") ; As the select() loop for > write reports buffer room avail, then more of the internal buffer is > sent to the printer. yes, might be good in case of a printer. May be horrible in case of PPP/TCP or some other transmission control protocol which may e.g. repeat data or even omit parts of it (e.g. internet realtime radio station broadcasting)... So I think the idea of "int write" (e.g. BSD sockets, linux files and so on) still is the best. A clean API / implementation should guarantee and allow implementations (users) to rely on that; assumptions and automatic background-sending and so on may look pragmatic and may even work on the first look, but may fail in other situations. BTW, if e.g. BSD socket API is known, why not simply copy it (until something better is invented :)) instead of fiddling around with JDK APIs? anyway, have a nice weekend everyone :-) oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Fri Jun 8 08:55:56 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 10:55:56 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070608141218.GE21069@elberon.bln.de.ingenico.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> Message-ID: <46696DFC.7000801@gatworks.com> >> write reports buffer room avail, then more of the internal buffer is >> sent to the printer. > > yes, might be good in case of a printer. May be horrible in case > of PPP/TCP or some other transmission control protocol which > may e.g. repeat data or even omit parts of it (e.g. internet > realtime radio station broadcasting)... So I think the idea of > "int write" (e.g. BSD sockets, linux files and so on) still is > the best. A clean API / implementation should guarantee and allow > implementations (users) to rely on that; assumptions and > automatic background-sending and so on may look pragmatic and may > even work on the first look, but may fail in other situations. > BTW, if e.g. BSD socket API is known, why not simply copy it > (until something better is invented :)) instead of fiddling > around with JDK APIs? But we were talking about the Parallel Port, and the transmission of data over the commapi/parallel-port schema. There isn't much in bi-directional software communication. Its a simple write one byte at a time interface. I'm not looking to change the comm-api. I'm just looking to alter the interaction between the Native ParallelPort functions, and the java ParallelPort functions that call them. This might be more readily doable than to get a committee to re-specify java-API specs. BTW: Whats is off-topic? ( help: not looking for def of off-topic ) From j.kenneth.gentle at acm.org Fri Jun 8 08:58:59 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Fri, 08 Jun 2007 10:58:59 -0400 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <20070608141218.GE21069@elberon.bln.de.ingenico.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> Message-ID: <200706081459.l58Ex5rA019991@qbang.org> Perhaps it is a bit late to jump in on this one, but here goes anyway. If the solutions all seem to "break" the contract with "java.io.outputstream", then, as noted, that may not be the appropriate contract. At the risk of being heretical, JDK1.4 introduced the "nio" package to address some of the compatibility issues with C apis mentioned in previous posts. The interface "java.nio.channels.WriteableByteChannel" defines the following single method: int write(ByteBuffer source); int, strangely enough, is the actual number of bytes written. So, if RXTX as written, against the JavaCOMM api and OutputStream, doesn't do what we want, how about writing a different set of bindings using the java.nio classes and as much of the underlying native code as possible. Note that just because the java.nio.channels.WriteableByteChannel sends back a result, OutputStream.write doesn't have to - and they could both call the same underlying native code. My 2 cents - maybe not worth even that... Ken From netbeans at gatworks.com Fri Jun 8 10:37:28 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 12:37:28 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <200706081459.l58Ex5rA019991@qbang.org> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> Message-ID: <466985C8.8000505@gatworks.com> Ken Gentle wrote: > Perhaps it is a bit late to jump in on this one, but here goes anyway. Common in, the waters fine. > > If the solutions all seem to "break" the contract with > "java.io.outputstream", then, as noted, that may not be the > appropriate contract. > How would the contract be broken? The machinery underneath is handling the contract. From j.kenneth.gentle at acm.org Fri Jun 8 10:48:01 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Fri, 08 Jun 2007 12:48:01 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466985C8.8000505@gatworks.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> Message-ID: <200706081648.l58Gm7YA022904@qbang.org> At 12:37 2007-06-08, you wrote: >Ken Gentle wrote: > > > > If the solutions all seem to "break" the contract with > > "java.io.outputstream", then, as noted, that may not be the > > appropriate contract. > > >How would the contract be broken? The machinery underneath is handling >the contract. It seems that a lot of the discussion has been about not only the timeout and being able to adjust it in the "machinery layer", but also about knowing in the Java layer, in the event of a timeout or exception, how many characters have been written to the device. An OutputStream won't ever do this with out an extension and including a return value "breaks" the contract, right? So, go with a Java IO api that *does* return the number of bytes written, out of the NIO package. I know it doesn't allow for a strict implementation of the JavaCOMM API - however, using NIO classes in place of the IO classes isn't that big a break and would allow those applications that need such information a way to get it. Maybe I'm misunderstanding the problem... Ken From netbeans at gatworks.com Fri Jun 8 11:24:14 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 13:24:14 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <200706081648.l58Gm7YA022904@qbang.org> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> Message-ID: <466990BE.7040100@gatworks.com> Ken Gentle wrote: An > OutputStream won't ever do this with out an extension and including a > return value "breaks" the contract, right? > i was not thinking of change the API to OutputSream. Are there specs for how output stream should work internally? for instance: String data = "Hello this is a line of data"; Outputstream.write( data.getbytes() ); ParallelPort.suspend(); int free = ParallelPort.getoutputbufferfree(); There is a symbiotic relationship between outputstream and the functionality of ParallelPort. From Steffen.DETTMER at ingenico.com Fri Jun 8 11:15:39 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 19:15:39 +0200 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <200706081459.l58Ex5rA019991@qbang.org> References: <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> Message-ID: <20070608171539.GK21069@elberon.bln.de.ingenico.com> * Ken Gentle wrote on Fri, Jun 08, 2007 at 10:58 -0400: > If the solutions all seem to "break" the contract with > "java.io.outputstream", then, as noted, that may not be the > appropriate contract. > > At the risk of being heretical, JDK1.4 introduced the "nio" package > to address some of the compatibility issues with C apis mentioned in > previous posts. The interface > "java.nio.channels.WriteableByteChannel" defines the following single method: > > int write(ByteBuffer source); > > int, strangely enough, is the actual number of bytes written. Yes, AFAIK one of the motivations for the NIO interface was, that the JDK-1.3 APIs (InputStream, e.g.) were not powerfull enough, especially for multi-connection-TCP servers or so. I don't know much about it but I've heard of a project where NIO usage was removed because of stability issues in multi-threaded environments and performance limitations under some circumstances. IIRC the "nio.ByteBuffer" is something very special (namely something you cannot implement in Java, it is "magic" or part of the language itself). Not sure if this is such a great idea (but for performance in the end sometimes heavy prices must be paid) :) > So, if RXTX as written, against the JavaCOMM api and OutputStream, > doesn't do what we want, how about writing a different set of > bindings using the java.nio classes and as much of the underlying > native code as possible. Yes, this would be an idea: use a full-featured interface on JNI, and, if wanted, deliver some wrappers converting this to a less-featured Java-compliant interface. However, powerful things as e.g. "select" are difficult to "emulate" if you are e.g. on some (older?) windows. But if you expose the full-featured APIs, you need to emulate them full-featured, theoretically. In the end it depends what you do on the serial line. If you just want to talk to a modem, then you may not need precise timeouts. But if you need to implement complexer protocols which define response times and timeouts, you may quickly get into difficulties. For instance, AFAIK, rxtx 1.7.2 (?) for windows is very messy with timeouts (there is a maximum, higher values are truncated; resolution is 100ms only; the function may take up to twice the timeout because internally it may be called twice). Probably for most people this is OK, but probably not for all. But having precise timeouts should be OK for all :-) Well, in the end it is nice to wish but somewhat hard to implement (many platforms, connections, USB, BlueTooth, whatever). oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Steffen.DETTMER at ingenico.com Fri Jun 8 11:04:22 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 19:04:22 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <46696DFC.7000801@gatworks.com> References: <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <46696DFC.7000801@gatworks.com> Message-ID: <20070608170422.GJ21069@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 10:55 -0400: > > BTW, if e.g. BSD socket API is known, why not simply copy it > > (until something better is invented :)) instead of fiddling > > around with JDK APIs? > > But we were talking about the Parallel Port, and the > transmission of data over the commapi/parallel-port schema. > There isn't much in bi-directional software communication. Its > a simple write one byte at a time interface. First, there are things like PLIP (http://en.wikipedia.org/wiki/Plip) - well, probably not widely used, sure ;) Second, I think if there is a good simple API known to support all that (with known "best practices") or so and there is no forcing need to invent a new one, why not simply using it? > I'm not looking to change the comm-api. I'm just looking to > alter the interaction between the Native ParallelPort > functions, and the java ParallelPort functions that call them. Ahh, yes. I think this is what I tried to ask. Having an usable JNI interface and on top (in pure java) some wrapper to InputStream or whatever could be done (e.g. by ignoring the return value of write or throwing if != length). Developers could then use the full-featured (non-JAVA-standard) API or select among various wrappers (as InputStream). > This might be more readily doable than to get a committee to > re-specify java-API specs. Yes, of course. I'm afraid that the Java APIs change regularily, but still yet with limited success it seems, so maybe they get it in one of the next iterations; who knows, maybe Java-9 has a BSD-like socket API :) SCNR. > BTW: Whats is off-topic? ( help: not looking for def of > off-topic ) I think I started some "re-specify java-API specs" which was OT probably. oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From lists at iDIAcomputing.com Fri Jun 8 18:48:54 2007 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Fri, 08 Jun 2007 20:48:54 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46684B62.7080802@gmail.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> Message-ID: <4669F8F6.3040101@iDIAcomputing.com> Vicne wrote: > Sorry to step in without a specific solution to your problem, but I > wanted to share my feeling regarding this proposal. AFAIK, it's > generally considered bad practice to pop-up a prompt from a library. ... > > My advice would be to think again and find another solution. Ideas are : > - make the number of retries a parameter so that you can tune it to what > you think is reasonable > - throw a more specific exception when the number of retries has been > reached, so that a specific prompt can be shown at a higher level You could also allow the client code to register a callback class which returns a boolean indicating whether to retry or cancel. This callback class could pop up a dialog, if appropriate, or follow some preset policy, or.... - George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From joachim at buechse.ch Sat Jun 9 09:43:16 2007 From: joachim at buechse.ch (Joachim Buechse) Date: Sat, 9 Jun 2007 17:43:16 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46694F9D.5080501@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: You should not forget, that in the case of an exception it may not even be known what happened to the data. You have a kernel buffer, outgoing chip buffer, incoming chip buffer, etc. So of course, it would be nice to know up to which point data was correctly processed, but this feedback does not exist on the hardware or protocol level and hence can in general not be magicly created on the software level... Regards, Joachim On 08.06.2007, at 14:46, Uncle George wrote: > It seems that with outputstream.write(b[]), you become terribly > uncoordinated as soon as an exception is thrown. Docs do not say what > happens to the data. > > Yet from a practicable point of view, one would like to know if the > write was accepted in-full, or rejected before any writes. There > are no > in betweens, as partial writes are not reportable. > > So for an outputstream.write(), in order for it to return, the full > write request has to be taken, and stored in an internal output > buffer. > If there is no room, the write() is suspended, till there is room. Or > throw's an IOException( "no room in buffer") ; As the select() loop > for > write reports buffer room avail, then more of the internal buffer is > sent to the printer. > > > > yves pielusenet wrote: >> So maybe a better way should be to create a new Exception class which >> has a method "int getWrittenByte()". So the Exception should be >> use to >> send again bytes which are not printed yet. >> >> yves >> >> Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : >>> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: >>>> It is not possible that the rxtx java method write(byte[], int >>>> offset, >>>> int length) return anint which contains the number of byte >>>> really send >>>> to the printer instead of an exception ? >>>> So this is the programm which will see if all bytes have been >>>> sent. If >>>> not it can retry to send the unsended bytes. >>> I think write() is void because in Java people love to do this >>> since OutputStream :-) Of course on such interfaces you cannot >>> implement something nice. If you would have a int write, you >>> would not implement the interface and no applications expecting >>> this interface would link/work/compile. >>> >>> oki, >>> >>> Steffen >>> >>> P.S.: (OT) >>> If you propose not to implement the Java interfaces (especially >>> not on JNI level), maybe optionally offering a wrapper that >>> removes e.g. the write return value and so on to downgrade the >>> powerful classic old POSIX read/write style to the modern limited >>> Java style, then I agree :-) Same for read. Instead of things >>> like "int avialable()" it is more powerful to have an approach as >>> select(2) offers (to guarante the caller that read/write will not >>> block [nothing else make sense anyway IMHO] but may read/write >>> less bytes then requested). The caller gets full control and the >>> higher level protocols can care about timeouts, invoking read in >>> some loops and/or implement retransmission. On top of such an >>> implementation, where everything is controlled, defined, >>> guaranteed and reliable, someone could use an InputStream or >>> OutputStream style interface. Or even better: don't use them at >>> all :) just BTW :-) >>> St. >>> >>> About Ingenico Throughout the world businesses rely on Ingenico >>> for secure and expedient electronic transaction acceptance. >>> Ingenico products leverage proven technology, established >>> standards and unparalleled ergonomics to provide optimal >>> reliability, versatility and usability. This comprehensive range >>> of products is complemented by a global array of services and >>> partnerships, enabling businesses in a number of vertical sectors >>> to accept transactions anywhere their business takes them. >>> 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. >>> >>> About Ingenico Throughout the world businesses rely on Ingenico >>> for secure and expedient electronic transaction acceptance. >>> Ingenico products leverage proven technology, established >>> standards and unparalleled ergonomics to provide optimal >>> reliability, versatility and usability. This comprehensive range >>> of products is complemented by a global array of services and >>> partnerships, enabling businesses in a number of vertical sectors >>> to accept transactions anywhere their business takes them. >>> 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. >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx 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 yvespielusenet at free.fr Mon Jun 11 03:15:12 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Mon, 11 Jun 2007 11:15:12 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: <1181553312.8335.14.camel@localhost.localdomain> So can someone tell a solution for my problem :( Must I say to the user to not put the printer off-line ? I can't since he has to do some pauses, verify print, paper conditioning etc... How do other people ? Before I use the parport librarry to read port status : http://www.geocities.com/Juanga69/parport/ (which doesn't work on windows XP) And I send data into the file LPT1 I use to have no problem when printer was disabled. thanks -- yves piel Le samedi 09 juin 2007 ? 17:43 +0200, Joachim Buechse a ?crit : > You should not forget, that in the case of an exception it may not > even be known what happened to the data. > > You have a kernel buffer, outgoing chip buffer, incoming chip buffer, > etc. So of course, it would be nice to know up to which point data > was correctly processed, but this feedback does not exist on the > hardware or protocol level and hence can in general not be magicly > created on the software level... > > Regards, > Joachim > > On 08.06.2007, at 14:46, Uncle George wrote: > > > It seems that with outputstream.write(b[]), you become terribly > > uncoordinated as soon as an exception is thrown. Docs do not say what > > happens to the data. > > > > Yet from a practicable point of view, one would like to know if the > > write was accepted in-full, or rejected before any writes. There > > are no > > in betweens, as partial writes are not reportable. > > > > So for an outputstream.write(), in order for it to return, the full > > write request has to be taken, and stored in an internal output > > buffer. > > If there is no room, the write() is suspended, till there is room. Or > > throw's an IOException( "no room in buffer") ; As the select() loop > > for > > write reports buffer room avail, then more of the internal buffer is > > sent to the printer. > > > > > > > > yves pielusenet wrote: > >> So maybe a better way should be to create a new Exception class which > >> has a method "int getWrittenByte()". So the Exception should be > >> use to > >> send again bytes which are not printed yet. > >> > >> yves > >> > >> Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : > >>> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > >>>> It is not possible that the rxtx java method write(byte[], int > >>>> offset, > >>>> int length) return anint which contains the number of byte > >>>> really send > >>>> to the printer instead of an exception ? > >>>> So this is the programm which will see if all bytes have been > >>>> sent. If > >>>> not it can retry to send the unsended bytes. > >>> I think write() is void because in Java people love to do this > >>> since OutputStream :-) Of course on such interfaces you cannot > >>> implement something nice. If you would have a int write, you > >>> would not implement the interface and no applications expecting > >>> this interface would link/work/compile. > >>> > >>> oki, > >>> > >>> Steffen > >>> > >>> P.S.: (OT) > >>> If you propose not to implement the Java interfaces (especially > >>> not on JNI level), maybe optionally offering a wrapper that > >>> removes e.g. the write return value and so on to downgrade the > >>> powerful classic old POSIX read/write style to the modern limited > >>> Java style, then I agree :-) Same for read. Instead of things > >>> like "int avialable()" it is more powerful to have an approach as > >>> select(2) offers (to guarante the caller that read/write will not > >>> block [nothing else make sense anyway IMHO] but may read/write > >>> less bytes then requested). The caller gets full control and the > >>> higher level protocols can care about timeouts, invoking read in > >>> some loops and/or implement retransmission. On top of such an > >>> implementation, where everything is controlled, defined, > >>> guaranteed and reliable, someone could use an InputStream or > >>> OutputStream style interface. Or even better: don't use them at > >>> all :) just BTW :-) > >>> St. > >>> > >>> About Ingenico Throughout the world businesses rely on Ingenico > >>> for secure and expedient electronic transaction acceptance. > >>> Ingenico products leverage proven technology, established > >>> standards and unparalleled ergonomics to provide optimal > >>> reliability, versatility and usability. This comprehensive range > >>> of products is complemented by a global array of services and > >>> partnerships, enabling businesses in a number of vertical sectors > >>> to accept transactions anywhere their business takes them. > >>> 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. > >>> > >>> About Ingenico Throughout the world businesses rely on Ingenico > >>> for secure and expedient electronic transaction acceptance. > >>> Ingenico products leverage proven technology, established > >>> standards and unparalleled ergonomics to provide optimal > >>> reliability, versatility and usability. This comprehensive range > >>> of products is complemented by a global array of services and > >>> partnerships, enabling businesses in a number of vertical sectors > >>> to accept transactions anywhere their business takes them. > >>> 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. > >>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx 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 > From Steffen.DETTMER at ingenico.com Mon Jun 11 03:56:18 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 11:56:18 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466990BE.7040100@gatworks.com> References: <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> Message-ID: <20070611095618.GA10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 13:24 -0400: > i was not thinking of change the API to OutputSream. Then I think either someone uses OutputStream (and has no reliable information about incomplete writes) or someone uses somethink else. > Are there specs for how output stream should work internally? > > for instance: > String data = "Hello this is a line of data"; > Outputstream.write( data.getbytes() ); > ParallelPort.suspend(); > int free = ParallelPort.getoutputbufferfree(); > > There is a symbiotic relationship between outputstream and the > functionality of ParallelPort. If you need OutputStream "plus something else", in short you're needing "something else". Personally I dislike the code above a lot. The stream "looks" like if it would be an OutputStream, but in fact it isn't. You need to call getoutputbufferfree later to check if write succeeded (but OutputStream promises that write succeedes synchronous, blocking, or throws an exception). So it is not an OutputStream. No application written for OutputStreams would work without change (because it won't know getoutputbufferfree at all). It is not abstracted from ParallelPort. I think this would be wrong. Then I think an alternative interface instead is better. Let's assume we had some "connection" (to distinguish between OutputStreams and Channels). Then why not working as on a file handle in POSIX: do { // ... select maybe using timer ... readyForWrite = ... if (readyForWrite) { int writtenBytes = connection.write(toWrite); toWrite.remove(0, writtenBytes); } while(readyForWrite && toWrite.length > 0); I think, having such a write isn't the big problem. I think, the difficult thing is around "select" - however this would look like. It should be OO, typesafe, performant, supporting multiple connections/channels/streams in various modes and should be orthogonal to other functionalities. Of course, this heavily depends on what the application is doing; for a simple situation (like reading a small, mandatory file from a local disk) this would be to uncomfortable (and offering unneeded features only). just BTW :) oki, Steffen -- // Modeline for VIM. Please don't remove. // (Help: autoindent, expandtab, shiftwidth=4, tabstop=4, textwidth=75) // vi: set ai et sw=4 ts=4 tw=75 ft=java: About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Mon Jun 11 05:38:33 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 07:38:33 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611095618.GA10821@elberon.bln.de.ingenico.com> References: <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> Message-ID: <466D3439.4020805@gatworks.com> Steffen DETTMER wrote: > (but OutputStream promises that write > succeedes synchronous, blocking, or throws an exception). Where is it so written? From Steffen.DETTMER at ingenico.com Mon Jun 11 06:36:50 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 14:36:50 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466D3439.4020805@gatworks.com> References: <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> <466D3439.4020805@gatworks.com> Message-ID: <20070611123650.GI10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Mon, Jun 11, 2007 at 07:38 -0400: > Steffen DETTMER wrote: > > > (but OutputStream promises that write > > succeedes synchronous, blocking, or throws an exception). > > Where is it so written? Now, as you ask, I think it is not written that clearly but follows from specification. mmm... Am I wrong? I understand the API doc in this way: * http://java.sun.com/j2se/1.4.2/docs/api/java/io/OutputStream.html#write(byte[]) > public void write(byte[] b) > throws IOException > > Writes b.length bytes from the specified byte array to this > output stream. The general contract for write(b) is that > it should have exactly the same effect as the call write(b, > 0, b.length). > > Parameters: > b - the data. > Throws: > IOException - if an I/O error occurs. > See Also: > write(byte[], int, int) and there is: > public void write(byte[] b, > int off, > int len) > throws IOException > > Writes len bytes from the specified byte array starting at > offset off to this output stream. The general contract for > write(b, off, len) is that some of the bytes in the array b > are written to the output stream in order; element b[off] > is the first byte written and b[off+len-1] is the last byte > written by this operation. > > The write method of OutputStream calls the write method of > one argument on each of the bytes to be written out. > Subclasses are encouraged to override this method and > provide a more efficient implementation. > > If b is null, a NullPointerException is thrown. > > If off is negative, or len is negative, or off+len is > greater than the length of the array b, then an > IndexOutOfBoundsException is thrown. > > Parameters: > b - the data. > off - the start offset in the data. > len - the number of bytes to write. > Throws: > IOException - if an I/O error occurs. In particular, an > IOException is thrown if the output stream is closed. In general, any specialisation (derived child class) must comform to this. So write in the end is specified (!) as "The write method ... calls the write method ... on each of the bytes to be written out". This is what must be implemented by ANY OutputStream. Of course, there is: "Subclasses are encouraged to override this method and provide a more efficient implementation." which IMHO does not contradict - the more efficient must behave in exactly the same way of course (just wasting less resources than a simple byte-by-byte write). So it does not matter here I think. The write that finally defines the behavior tells basically: > "Writes the specified byte to this output stream. The general > contract for write is that one byte is written to the output > stream. " > > Throws: > IOException - if an I/O error occurs. which IMHO is another way of saying "write writes the byte immediately and returns on success (only), otherwise an exception is thrown". Especially it cannot happen that zero bytes are written (i.e. the specified byte is NOT written) without an exception. So by this write must be synchronous and blocking, because otherwise it could not reliably know if an asynchronous operation will succeede or not (some getAsyncResult or so would be needed). Since write(byte[]) does this for each byte (or with a behavior beeing exactly the same as if it would do), I think this means that the write(byte[]) succeedes synchronous/blocking or throws an exception. Did I an error in reasoning or confused something or so? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From j.kenneth.gentle at acm.org Mon Jun 11 06:51:25 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 11 Jun 2007 08:51:25 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611123650.GI10821@elberon.bln.de.ingenico.com> References: <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> <466D3439.4020805@gatworks.com> <20070611123650.GI10821@elberon.bln.de.ingenico.com> Message-ID: <200706111251.l5BCpS9T017831@qbang.org> It is as Steffen describes. "InputStream" and "OutputStream" are inherently synchronous (which is why so many java programs resort to threads to use them). Anything outside of this "contract" is *not* an InputStream or OutputStream. That is why there is a new package for things that don't behave like the old *Stream classes - the NIO package. If you look carefully at the IO package, you'll note that almost all the classes are _Decorator_ pattern implementations of the *Stream classes - and the interface presents the _same_ behavior to the calling code in all cases - a synchronous operation that completes successfully or throws an exception (with the one exception of "read" that returns a "-1" on end-of-stream. I know I've read this numerous times - I'd suggest checking the Language Spec or one of the books by Bloch or Gosling. Ken At 08:36 2007-06-11, you wrote: >* Uncle George wrote on Mon, Jun 11, 2007 at 07:38 -0400: > > Steffen DETTMER wrote: > > > > > (but OutputStream promises that write > > > succeedes synchronous, blocking, or throws an exception). > > > > Where is it so written? > >Now, as you ask, I think it is not written that clearly but >follows from specification. mmm... > >Am I wrong? > >I understand the API doc in this way: > >* >http://java.sun.com/j2se/1.4.2/docs/api/java/io/OutputStream.html#write(byte[]) > > public void write(byte[] b) > > throws IOException > > > > Writes b.length bytes from the specified byte array to this > > output stream. The general contract for write(b) is that > > it should have exactly the same effect as the call write(b, > > 0, b.length). > > > > Parameters: > > b - the data. > > Throws: > > IOException - if an I/O error occurs. > > See Also: > > write(byte[], int, int) > > >and there is: > > > > public void write(byte[] b, > > int off, > > int len) > > throws IOException > > > > Writes len bytes from the specified byte array starting at > > offset off to this output stream. The general contract for > > write(b, off, len) is that some of the bytes in the array b > > are written to the output stream in order; element b[off] > > is the first byte written and b[off+len-1] is the last byte > > written by this operation. > > > > The write method of OutputStream calls the write method of > > one argument on each of the bytes to be written out. > > Subclasses are encouraged to override this method and > > provide a more efficient implementation. > > > > If b is null, a NullPointerException is thrown. > > > > If off is negative, or len is negative, or off+len is > > greater than the length of the array b, then an > > IndexOutOfBoundsException is thrown. > > > > Parameters: > > b - the data. > > off - the start offset in the data. > > len - the number of bytes to write. > > Throws: > > IOException - if an I/O error occurs. In particular, an > > IOException is thrown if the output stream is closed. > > >In general, any specialisation (derived child class) must comform >to this. So write in the end is specified (!) as "The write >method ... calls the write method ... on each of the bytes to be >written out". This is what must be implemented by ANY >OutputStream. > >Of course, there is: "Subclasses are encouraged to override this >method and provide a more efficient implementation." which IMHO >does not contradict - the more efficient must behave in exactly >the same way of course (just wasting less resources than a simple >byte-by-byte write). So it does not matter here I think. > > > >The write that finally defines the behavior tells basically: > > > "Writes the specified byte to this output stream. The general > > contract for write is that one byte is written to the output > > stream. " > > > > Throws: > > IOException - if an I/O error occurs. > > >which IMHO is another way of saying "write writes the byte >immediately and returns on success (only), otherwise an exception >is thrown". Especially it cannot happen that zero bytes are >written (i.e. the specified byte is NOT written) without an >exception. So by this write must be synchronous and blocking, >because otherwise it could not reliably know if an asynchronous >operation will succeede or not (some getAsyncResult or so would >be needed). > >Since write(byte[]) does this for each byte (or with a behavior >beeing exactly the same as if it would do), I think this means >that the write(byte[]) succeedes synchronous/blocking or throws >an exception. > >Did I an error in reasoning or confused something or so? > >oki, > >Steffen > >About Ingenico Throughout the world businesses rely on Ingenico for >secure and expedient electronic transaction acceptance. Ingenico >products leverage proven technology, established standards and >unparalleled ergonomics to provide optimal reliability, versatility >and usability. This comprehensive range of products is complemented >by a global array of services and partnerships, enabling businesses >in a number of vertical sectors to accept transactions anywhere >their business takes them. >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. > >About Ingenico Throughout the world businesses rely on Ingenico for >secure and expedient electronic transaction acceptance. Ingenico >products leverage proven technology, established standards and >unparalleled ergonomics to provide optimal reliability, versatility >and usability. This comprehensive range of products is complemented >by a global array of services and partnerships, enabling businesses >in a number of vertical sectors to accept transactions anywhere >their business takes them. >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. > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From alesinskyy at googlemail.com Mon Jun 11 07:25:33 2007 From: alesinskyy at googlemail.com (Oleksandr Alesinskyy) Date: Mon, 11 Jun 2007 15:25:33 +0200 Subject: [Rxtx] [OT] select :-) Message-ID: Sorry, but I have to disagree with following statement: "So write in the end is specified (!) as "The write method ... calls the write method ... on each of the bytes to be written out". This is what must be implemented by ANY OutputStream.". This is not part of the specification or contract, it is just revealed implementation detail of the OutputStream. It is not stated anywhere that behavoiur of derived classes shall conform with this one. Statement concerning "synchronous" nature of the output stream is invalid as well. Really synchronous stream does not require flush() but OutputStream has it. From Steffen.DETTMER at ingenico.com Mon Jun 11 08:21:16 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 16:21:16 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: Message-ID: <20070611142116.GN10821@elberon.bln.de.ingenico.com> * Oleksandr Alesinskyy wrote on Mon, Jun 11, 2007 at 15:25 +0200: > Sorry, but I have to disagree with following statement: > "So write in the end is specified (!) as "The write > method ... calls the write method ... on each of the bytes to be > written out". This is what must be implemented by ANY > OutputStream.". > > This is not part of the specification or contract, it is just > revealed implementation detail of the OutputStream. It is not > stated anywhere that behavoiur of derived classes shall conform > with this one. (I didn't meant that the implementation must really write byte by byte, but that it must "look as if it would do" - because all implementations of OutputStream must "look" in the same way [which is another way of saying "do abstract" I think]) I think the API doc is not "revealing implementation details" but it is the *specification* of that interface and derivations must (should) conform to this specification. Isn't this the idea of interfaces? A function that expects an OutputStream should work on ANY OutputStream, shouldn't it? just kidding: I mean, what would be the point in implementing a checksum function as OutputStream.write which throws its result as IOException? Or which requires to call close() as very first operation to tell that the application is about to transmit confidential data? :-) > Statement concerning "synchronous" nature of the output stream > is invalid as well. Really synchronous stream does not require > flush() but OutputStream has it. ahh, interesting point! I think this is another bug in the API. flush() is wrong. Because write specifies "The general contract for write is that one byte is written to the output stream." but not "a byte may be written or buffered". Actually, an application would need to call flush() after each write (or bunch of write calls) to ensure that write really did something otherwise I think. I didn't found in the spec of OutputStream that it would be required to call flush(). This should mean that calling flush is not required which in turn leads to the conclusion that write must be synchrous (private threads are forbidden because not specified :)) which in turn leads to the conclusion that flush() is not needed at all... I mean, what if someone would only store in write and do the "real write" in flush() and never else? An application could write in one stream and read on another one (e.g. in bidirectional communication) and would never get anything back, because nothing was actually written because no flush was called? Then someone could even think that on error in some write the data could remain buffered AND throw an exception, retrying to send the data in the next write. Ohh, and if there would be some message number inside, and underlaying write (e.g. a protocol offering InputStream/OutputStream) would check this and throw "DuplicatedMessageNumber" the stream would only throw it again and again beeing unusable... In short: I have no clue how someone could be able to implement an asynchrounos write (which is realiable and correct) without beeing specific to anything which is not specified by OutputStream. Well, I think in the end OutputStream was not intended for such communication or protocol implementations - but to read a local disk file or so. In case of I/O errors usually you can abort your application and change the hard disk :-) oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Bob_Jacobsen at lbl.gov Mon Jun 11 09:32:23 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Mon, 11 Jun 2007 08:32:23 -0700 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611142116.GN10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> Message-ID: At 4:21 PM +0200 6/11/07, Steffen DETTMER wrote: > > Statement concerning "synchronous" nature of the output stream >> is invalid as well. Really synchronous stream does not require >> flush() but OutputStream has it. > >ahh, interesting point! > >I think this is another bug in the API. flush() is wrong. Because >write specifies "The general contract for write is that one byte >is written to the output stream." but not "a byte may be written >or buffered". > >Actually, an application would need to call flush() after each >write (or bunch of write calls) to ensure that write really did >something otherwise I think. OutputStreams don't _have_ to be synchronous or asynchronous, but the OutputStream API was be arranged so that subclasses _can_ be synchronous or asynchronous. Such generality is the hardest part of getting an API right. Hence, if at some point a program using an OutputStream wants to be sure that the data has been pushed all the way out, flush() is available. For some subclasses, e.g. the buffered ones, this has important behavior. Others write the data from each call, and flush() doesn't do anything. You _can_ omit it in programs that are known to use this second type, but there's no requirement that you do so; the interface is general in that way. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From Steffen.DETTMER at ingenico.com Mon Jun 11 12:32:39 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 20:32:39 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> Message-ID: <20070611183239.GT10821@elberon.bln.de.ingenico.com> * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: > >Actually, an application would need to call flush() after each > >write (or bunch of write calls) to ensure that write really did > >something otherwise I think. > OutputStreams don't _have_ to be synchronous or asynchronous, > but the OutputStream API was be arranged so that subclasses > _can_ be synchronous or asynchronous. Ahh, oki. Thanks for the clarificaion. So in short, flush() MUST be called on OutputStream, this is just not documented correctly or so clearly (right?). So the overall usage semantics would be: 1. call write (multiple times if desired) 2. call flush only if both succeeded, write was successful. If flush fails it remains unknown if a part of the data was written and/or will be repeated. So the spec (API doc) is wrong. Correct would be to tell that write behaves as told as long as it is followed by a call to flush, otherwise data may or may not get lost (depending wheter close() is called and calls flush(), which seems not to be guaranteed/required). BTW, I think it is a little bit... erm... interesting to find the specification (java API doc reference) wrong, having a need to conclude it from the presence of some methods with "it would make no sense if they behave exactly as specified, so specification must be wrong (incomplete)". > Such generality is the hardest part of getting an API right. Yes, seems to be proven ;) > Hence, if at some point a program using an OutputStream wants > to be sure that the data has been pushed all the way out, > flush() is available. For some subclasses, e.g. the buffered > ones, this has important behavior. Others write the data from > each call, and flush() doesn't do anything. > You _can_ omit it in programs that are known to use this second > type, but there's no requirement that you do so; the interface > is general in that way. I think, it still it must be called always, otherwise the application could break if passing a different runtime type as OutputStream. I think, if the application/method needs a special "type of OutputStream" then the parameter type must be a subclass but not OutputStream, maybe a PrintStream or so - otherwise the compiler could not detect this error (passing wrong type). Is this correct? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Bob_Jacobsen at lbl.gov Mon Jun 11 13:00:52 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Mon, 11 Jun 2007 12:00:52 -0700 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611183239.GT10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> Message-ID: At 8:32 PM +0200 6/11/07, Steffen DETTMER wrote: >So the spec (API doc) is wrong. Correct would be to tell that >write behaves as told as long as it is followed by a call to >flush, otherwise data may or may not get lost (depending wheter >close() is called and calls flush(), which seems not to be >guaranteed/required). I'm not entirely sure that the spec is wrong, but reasonable people can differ on this. In the 1.5 JavaDocs, all that the docs say for the write methods is that they write to the _output_ _stream_; there is no guarantee of anything beyond that. Only the flush method has any guarantee about the data, which is >Flushes this output stream and forces any buffered output bytes to >be written out. The general contract of flush is that calling it is >an indication that, if any bytes previously written have been >buffered by the implementation of the output stream, such bytes >should immediately be written to their intended destination. People commonly use various OutputStreams without using flush(), and it often works, but it's a bad practice and will eventually bite them. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From netbeans at gatworks.com Mon Jun 11 13:31:57 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 15:31:57 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611183239.GT10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> Message-ID: <466DA32D.1010602@gatworks.com> Steffen DETTMER wrote: > * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: >>> Actually, an application would need to call flush() after each >>> write (or bunch of write calls) to ensure that write really did >>> something otherwise I think. > >> OutputStreams don't _have_ to be synchronous or asynchronous, >> but the OutputStream API was be arranged so that subclasses >> _can_ be synchronous or asynchronous. > > Ahh, oki. Thanks for the clarificaion. > > So in short, flush() MUST be called on OutputStream, this is just > not documented correctly or so clearly (right?). No. Flush can be called to force all current data in java buffer's to be written to the kernel - NOW. A flush() can also *imply* that, besides writing out the buffer's that java employs, may also imply/ask the kernel to write all data thusfar written to the kernel, to be physically placed on the destination device - NOW. For some OS's there is no need to do a kernel flush(), as the I/O is synchronized already. Since this is java, you never know what OS your on. From tjarvi at qbang.org Mon Jun 11 19:28:27 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Jun 2007 19:28:27 -0600 (MDT) Subject: [Rxtx] [OT] select :-) In-Reply-To: <466DA32D.1010602@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: On Mon, 11 Jun 2007, Uncle George wrote: > Steffen DETTMER wrote: >> * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: >>>> Actually, an application would need to call flush() after each >>>> write (or bunch of write calls) to ensure that write really did >>>> something otherwise I think. >> >>> OutputStreams don't _have_ to be synchronous or asynchronous, >>> but the OutputStream API was be arranged so that subclasses >>> _can_ be synchronous or asynchronous. >> >> Ahh, oki. Thanks for the clarificaion. >> >> So in short, flush() MUST be called on OutputStream, this is just >> not documented correctly or so clearly (right?). > No. > Flush can be called to force all current data in java buffer's to be > written to the kernel - NOW. > > A flush() can also *imply* that, besides writing out the buffer's that > java employs, may also imply/ask the kernel to write all data thusfar > written to the kernel, to be physically placed on the destination device > - NOW. > For some OS's there is no need to do a kernel flush(), as the I/O is > synchronized already. Since this is java, you never know what OS your on. To add to the confusion, flush on the C side throws away data. drain makes sure it is written. Looking at the ParallelImp.c we can probably do better. /* we set a timeout because all calls are sequentiell (also with asynchron) this means that the default timeout of unlimited blocks all calls (also close and status request) if the device is down */ GetCommTimeouts( (HANDLE)fd, &timeouts ); timeouts.WriteTotalTimeoutMultiplier = 0; timeouts.WriteTotalTimeoutConstant = 2000; /* 2000 is the min value for the default Windows NT and Windows 2000 driver */ SetCommTimeouts( (HANDLE)fd, &timeouts ); while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } errorCount = 0; bytes += countWritten; count -= countWritten; } LPRPort has some timeout code that appears to be doing nothing but flipping bits back and forth right now. The commapi rxtx follows allows for timeout control from javax.comm.CommPort. The above is a solution that worked in one specific use case. With timeouts in place, the original 'old printer going offline' problem could be solved. That printer code isn't written in stone. In fact it was ajusted from being able to print 'asdf' to a daisy wheel printer to working for one person. BTW, I've finished teaching after hours tonight and will be moving forward with a new rxtx release in my free time. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Jun 11 21:28:04 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 23:28:04 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: <466E12C4.1010305@gatworks.com> > Looking at the ParallelImp.c we can probably do better. > The problem stemmed from the possibility that the writev routine could have written some of the buffer, in chunks, printer pauses, refuses any more chunks, and a timeout occurs. Do you or do you not cause an exception to be thrown? Is there a way to set timeout for a ParallelPort data output stream? I cant find it. From tjarvi at qbang.org Mon Jun 11 22:17:23 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Jun 2007 22:17:23 -0600 (MDT) Subject: [Rxtx] [OT] select :-) In-Reply-To: <466E12C4.1010305@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> <466E12C4.1010305@gatworks.com> Message-ID: On Mon, 11 Jun 2007, Uncle George wrote: >> Looking at the ParallelImp.c we can probably do better. >> > The problem stemmed from the possibility that the writev routine could > have written some of the buffer, in chunks, printer pauses, refuses any > more chunks, and a timeout occurs. Do you or do you not cause an > exception to be thrown? > > Is there a way to set timeout for a ParallelPort data output stream? I > cant find it. hmm I looked again after you asked. The timeouts are only controllable on the receive side. This comes from CommPort; the parent. So what we are talking about is some bytes in memory that rxtx has and is supposed to write. A buffer perhaps? The approach with rxtx in the past has been to ignore output buffer sizes. The assumption is that the library does not know how to best handle buffers. There are buffered output streams that can do buffering on top of rxtx for instance. There is also a question regarding what was actually ment when the API was put together. My suspicion is that it was put together while looking at one OS API and was never ment to be anything more than a hook into that API. The comments are fairly telling combined with reading the w32 API. So looking at the problem again.. The current timeout behavior appears fairly arbitrary. Presumably this is to prevent a program from hanging instead of using a helper thread to write - heavy handed for new programmers. Even so, I don't think the write should timeout at all if it is not configurable. >From the API perspective, "What Timeout?" -- Trent Jarvi tjarvi at qbang.org From Steffen.DETTMER at ingenico.com Tue Jun 12 02:14:48 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 12 Jun 2007 10:14:48 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466DA32D.1010602@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: <20070612081447.GU10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Mon, Jun 11, 2007 at 15:31 -0400: > Steffen DETTMER wrote: > > Ahh, oki. Thanks for the clarificaion. > > > > So in short, flush() MUST be called on OutputStream, this is just > > not documented correctly or so clearly (right?). > No. hum (though now I got it, but...). > Flush can be called to force all current data in java buffer's to be > written to the kernel - NOW. > > A flush() can also *imply* that, besides writing out the > buffer's that java employs, may also imply/ask the kernel to > write all data thusfar written to the kernel, to be physically > placed on the destination device - NOW. > > For some OS's there is no need to do a kernel flush(), as the I/O is > synchronized already. Since this is java, you never know what OS your on. (well, but if you're going to kernel level, even flush cannot guarantee that data will "be physically placed". Maybe you're flushing to a file via NFS (and the client "thinks" that it was written, but maybe it was just buffered by the NFS server) or so... but of course such exceptions of the rules are constructable always.) Well, you tell that depending on the OS it can be that flush is needed or it can be that flush is not needed (beacuse the I/O is synchronized already), right? Also, applications should work on any OS, which includes the OSes that do need flush. Since the application cannot know whether flush is needed or not because it doesn't know what the OS is doing, it has to call flush, hasn't it? I mean, if it would not call flush then it would not work on such OSes (except the written data would not be needed at all, but in this would be an artificial example :)). Since applications are supposed to work this would be wrong, wouldn't it? So would it be correct to say: "Applications, that should work under all OSes (including the OSes where the I/O is not synchronised already), have to call flush on OutputStream to ensure the data is transfered to the kernel." or is this wrong? If so, then I'm afraid I missed the point again :( oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Tue Jun 12 04:46:52 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 12 Jun 2007 06:46:52 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070612081447.GU10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> <20070612081447.GU10821@elberon.bln.de.ingenico.com> Message-ID: <466E799C.7060700@gatworks.com> S > (well, but if you're going to kernel level, even flush cannot > guarantee that data will "be physically placed". Thats true now-a-days because ( from "man 2 sync" ) : > According to the standard specification (e.g., SVID), sync() schedules > the writes, but may return before the actual writing is done. However, > since version 1.3.20 Linux does actually wait. (This still does not > guarantee data integrity: modern disks have large caches.) My disk drive has 8mb cache. Maybe you're > flushing to a file via NFS (and the client "thinks" that it was > written, but maybe it was just buffered by the NFS server) or > so... but of course such exceptions of the rules are > constructable always.) > > Well, you tell that depending on the OS it can be that flush is > needed or it can be that flush is not needed (beacuse the I/O is > synchronized already), right? Also, applications should work on > any OS, which includes the OSes that do need flush. Its not OS's that need flush, its applications that want to have some assurance that data is written to the device that really needs to use flush. If your program ( or thread ) dies then it is in your best interest to write out the critical data as soon as possible, as economical as possible. These are trade-off's that the application programmer makes. A big buffer may mean big loss of data, a small buffer may mean spending too much time writing out data. > > > So would it be correct to say: > > "Applications, that should work under all OSes (including the > OSes where the I/O is not synchronised already), have to call > flush on OutputStream to ensure the data is transfered to the > kernel." > > or is this wrong? If so, then I'm afraid I missed the point again > :( > No that is not wrong. Ensuring that data is transfered to the OS is just about what any application can do. From tjarvi at qbang.org Thu Jun 14 08:16:47 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 14 Jun 2007 08:16:47 -0600 (MDT) Subject: [Rxtx] rxtx and usb-serial solution In-Reply-To: References: Message-ID: On Thu, 14 Jun 2007, Vladimir Kirtchev wrote: > Hi Trent, > > I develop a Java application which communicates with devices which have > USB-to-Serial bridge in them. The target OS is Linux. So for this purpose I > use RXTX. > > But I encountered a strange problem - when reading from the InputStream, I > receive series of zeros. I have this problem under Linux only. Under Windows > it is fine. > Actually this problem is the same as the one described here: > http://marc.info/?l=rxtx&m=109703190731748&w=2. > > > So I searched for the problem in the native code. And found that the root of > the problem is in SerialImp.c, > int configure_port( int fd ) > { > ... > ttyset.c_iflag = INPCK; > ... > } > > This line enables input parity checking, and the data sent from the device > is processed by the OS driver before being read with read(). > In this case the driver detects some problem and sets the received bytes to > zero. > > On the other hand in the Java part a set the serial port parameters with > SerialPort.PARITY_NONE. According to me, except all other things, this > should also disable INPCK in c_iflag. > > So I refactored the method translate_parity(...) to the following: > > int translate_parity( JNIEnv *env, struct termios *ttyset, jint parity ) > { > ENTER( "translate_parity" ); > #ifdef CMSPAR > ttyset->c_cflag &= ~(PARENB | PARODD | CMSPAR ); > #endif /* CMSPAR */ > switch( parity ) { > case JPARITY_NONE: > ttyset->c_iflag &= ~INPCK; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_EVEN: > ttyset->c_cflag |= PARENB; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_ODD: > ttyset->c_cflag |= PARENB | PARODD; > LEAVE( "translate_parity" ); > return 0; > #ifdef CMSPAR > case JPARITY_MARK: > ttyset->c_cflag |= PARENB | PARODD | CMSPAR; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_SPACE: > ttyset->c_cflag |= PARENB | CMSPAR; > LEAVE( "translate_parity" ); > return 0; > #endif /* CMSPAR */ > default: > printf("Parity missed %i\n", (int) parity ); > } > > LEAVE( "translate_parity" ); > /* > For some reason the native exceptions are not being caught. Moving this > to the Java side fixed the issue. taj. > throw_java_exception( env, UNSUPPORTED_COMM_OPERATION, > "", "parity value not supported" ); > */ > return 1; > } > > This modification solved the problem and now it works correctly under Linux. > > I think I will be a nice if this is idea is included in a future release of > RXTX. > > Thanks Vadim, I'll try that out. Forwarding to the rxtx mail-list too. This is probably not going to help USB drivers on windows which I'm sure some are looking for. As far as I can tell, windows USB bluetooth and serial dongles are limited by driver functionality. Some are good and others lack key features. -- Trent Jarvi tjarvi at qbang.org From dan.sandberg.lists at gmail.com Mon Jun 18 14:43:39 2007 From: dan.sandberg.lists at gmail.com (Dan Sandberg) Date: Mon, 18 Jun 2007 13:43:39 -0700 Subject: [Rxtx] Fix for JNI Get/Set Field Errors Message-ID: <4676EE7B.7060800@gmail.com> Hi, I've fixed the problems that cause the following JNI error when extra JNI checking ( -Xjni:check ) is turned on. FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) The problem was basically that GetLong was being used to get ints, and SetInt was used for longs. The patch below fixes this. Please let me know if there are any questions / problems. Cheers, -Dan diff -aur old/SerialImp.c src/SerialImp.c --- old/SerialImp.c 2007-06-18 13:24:33.000000000 -0700 +++ src/SerialImp.c 2007-06-18 06:26:26.000000000 -0700 @@ -1337,7 +1337,7 @@ report("init_threads: get eis\n"); jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); report("init_threads: set eis\n"); - (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); + (*eis->env)->SetLongField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); report("init_threads: stop\n"); report_time_end( ); return( 1 ); @@ -1530,7 +1530,7 @@ jobject jobj, jboolean interrupted ) { int fd = get_java_var( env, jobj,"fd","I" ); - struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var( env, jobj, "eis", "J" ); + struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var_long( env, jobj, "eis", "J" ); int result, count=0; char message[80]; @@ -2939,7 +2939,7 @@ /* TRENT */ int flag, count = 0; struct event_info_struct *eis = ( struct event_info_struct * ) - get_java_var( env, *jobj,"eis","J" ); + get_java_var_long( env, *jobj,"eis","J" ); report_time_start(); flag = eis->eventflags[SPE_DATA_AVAILABLE]; @@ -4873,9 +4873,9 @@ exceptions: none comments: ----------------------------------------------------------*/ -size_t get_java_var( JNIEnv *env, jobject jobj, char *id, char *type ) +long get_java_var_long( JNIEnv *env, jobject jobj, char *id, char *type ) { - int result = 0; + long result = 0; jclass jclazz = (*env)->GetObjectClass( env, jobj ); jfieldID jfd = (*env)->GetFieldID( env, jclazz, id, type ); @@ -4889,7 +4889,11 @@ LEAVE( "get_java_var" ); return result; } - result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); + if ( !strcmp( type, "J" ) ) { + result = (long)( (*env)->GetLongField( env, jobj, jfd ) ); + } else { + result = (int) ( (*env)->GetIntField( env, jobj, jfd ) ); + } /* ct7 & gel * Added DeleteLocalRef */ (*env)->DeleteLocalRef( env, jclazz ); if(!strncmp( "fd",id,2) && result == 0) @@ -4900,6 +4904,10 @@ return result; } +int get_java_var( JNIEnv *env, jobject jobj, char *id, char *type ) { + return (int) get_java_var_long( env, jobj, id, type ); +} + /*---------------------------------------------------------- throw_java_exception diff -aur old/SerialImp.h src/SerialImp.h --- old/SerialImp.h 2007-06-18 13:24:39.000000000 -0700 +++ src/SerialImp.h 2007-06-18 06:23:43.000000000 -0700 @@ -413,7 +413,8 @@ void system_wait(); void finalize_event_info_struct( struct event_info_struct * ); int read_byte_array( JNIEnv *, jobject *, int, unsigned char *, int, int ); -size_t get_java_var( JNIEnv *, jobject, char *, char * ); +int get_java_var( JNIEnv *, jobject, char *, char * ); +long get_java_var_long( JNIEnv *, jobject, char *, char * ); jboolean is_interrupted( struct event_info_struct * ); int send_event(struct event_info_struct *, jint, int ); void dump_termios(char *,struct termios *); From netbeans at gatworks.com Fri Jun 1 05:38:50 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 07:38:50 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <465F7ADD.1010501@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> Message-ID: <4660054A.2040202@gatworks.com> Manuel Naranjo wrote: In the case of my module, you can > unplug the device but it will not delete the symlink until those apps > that had opened the port has closed it. This is done this way to avoid > kernel panics. What does this mean to user code ? I have tried the alternate route ( other than closing ) which is sleep inbetween the I/O errors ( an unplugged USB device). When the device is plugged back in, The writes to the device still get an I/O error. This would seem to be a lost cause for the application. From netbeans at gatworks.com Fri Jun 1 06:35:48 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 08:35:48 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <465F7ADD.1010501@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> Message-ID: <466012A4.90608@gatworks.com> Manuel Naranjo wrote: In the case of my module, you can > unplug the device but it will not delete the symlink until those apps > that had opened the port has closed it. T Did u also mean for this to happen? USB0 was not closed by application. Apparently USB1 got created when USB device was plugged back in. There is only one USB device on a 4 port USB hub. This also seems to suggest that application recovery to be impossible. > Jun 1 07:10:08 mylaptop kernel: garmin_gps 1-1.4:1.0: Garmin GPS usb/tty converter detected > Jun 1 07:10:08 mylaptop kernel: usb 1-1.4: Garmin GPS usb/tty converter now attached to ttyUSB0 > Jun 1 07:15:17 mylaptop kernel: usb 1-1: USB disconnect, address 4 > Jun 1 07:15:17 mylaptop kernel: usb 1-1.4: USB disconnect, address 5 > Jun 1 07:15:17 mylaptop kernel: garmin_gps 1-1.4:1.0: device disconnected > Jun 1 07:15:26 mylaptop kernel: usb 1-1: new full speed USB device using uhci_hcd and address 6 > Jun 1 07:15:26 mylaptop kernel: hub 1-1:1.0: USB hub found > Jun 1 07:15:26 mylaptop kernel: hub 1-1:1.0: 4 ports detected > Jun 1 07:15:27 mylaptop kernel: usb 1-1.4: new full speed USB device using uhci_hcd and address 7 > Jun 1 07:15:27 mylaptop kernel: garmin_gps 1-1.4:1.0: Garmin GPS usb/tty converter detected > Jun 1 07:15:27 mylaptop kernel: usb 1-1.4: Garmin GPS usb/tty converter now attached to ttyUSB1 From naranjo.manuel at gmail.com Fri Jun 1 09:17:22 2007 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Fri, 01 Jun 2007 12:17:22 -0300 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <466012A4.90608@gatworks.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> <466012A4.90608@gatworks.com> Message-ID: <46603882.5050701@gmail.com> Uncle George escribi?: > Manuel Naranjo wrote: > In the case of my module, you can > >> unplug the device but it will not delete the symlink until those apps >> that had opened the port has closed it. T >> > > Did u also mean for this to happen? USB0 was not closed by application. > > Apparently USB1 got created when USB device was plugged back in. There > is only one USB device on a 4 port USB hub. > > This also seems to suggest that application recovery to be impossible. > Exactly there's a dead symlink (you can read and write to it and nothing will happen) and a new port will be created when a new device is connencted. From netbeans at gatworks.com Fri Jun 1 10:20:46 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 12:20:46 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <46603882.5050701@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> <466012A4.90608@gatworks.com> <46603882.5050701@gmail.com> Message-ID: <4660475E.5090202@gatworks.com> Not sure what u mean by "symlink". U cant read/write to it anymore. U get I/O error. In this scenario the device effectively went dead, and only solution is to close the channel. reconnecting the USB device, although dead, but not closed, will create a second device. This does not seem to be a desirable side-effect. The user will now have ttyUSB1, wondering where did ttyUSB0 go to. The application will also be in a confused state, as well as RXTX, because RXTX wont know about ttyUSB1. Manuel Naranjo wrote: > Uncle George escribi?: >> Manuel Naranjo wrote: >> In the case of my module, you can >> >>> unplug the device but it will not delete the symlink until those apps >>> that had opened the port has closed it. T >>> >> Did u also mean for this to happen? USB0 was not closed by application. >> >> Apparently USB1 got created when USB device was plugged back in. There >> is only one USB device on a 4 port USB hub. >> >> This also seems to suggest that application recovery to be impossible. >> > Exactly there's a dead symlink (you can read and write to it and nothing > will happen) and a new port will be created when a new device is connencted. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From arnab.bhaumik at gmail.com Mon Jun 4 01:40:16 2007 From: arnab.bhaumik at gmail.com (arnab bhaumik) Date: Mon, 4 Jun 2007 13:10:16 +0530 Subject: [Rxtx] full duplex com port with rxtx Message-ID: hi , till now i did half duplex communication with rxtx package on com package. my question is : is it possible to use com port with full duplex mode with rxtx package . ther is example of SimpleRead class and SimpleWrite class. it is clear that if i can use both the class simultaneously then full duplex is possible......... arnab/vu2bpw -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070604/6edb0453/attachment-0004.html From lists at iDIAcomputing.com Mon Jun 4 07:53:17 2007 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Mon, 04 Jun 2007 09:53:17 -0400 Subject: [Rxtx] full duplex com port with rxtx In-Reply-To: References: Message-ID: <4664194D.90301@iDIAcomputing.com> arnab bhaumik wrote: > hi , > > till now i did half duplex communication with rxtx package on com > package. > > my question is : is it possible to use com port with full duplex mode > with rxtx package . > > > ther is example of SimpleRead class and SimpleWrite class. it is > clear that if i can use both the class simultaneously then full duplex > is possible......... I haven't looked at the SimpleRead and SimpleWrite classes (I originally wrote my code for the javax.comm api), but full duplex is certainly possible. My CommReader class requires an object analogous to a OutputStream or Writer. When started, it spawns a thread that reads the comm port and writes to that output device. In this way the input is asynchronous and dependent on the actual input data. For full duplex, I extend that class with CommReaderWriter, which adds synchronous output methods. Hope that helps, George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From supsoop at hotmail.com Mon Jun 4 15:21:06 2007 From: supsoop at hotmail.com (soop soop) Date: Mon, 04 Jun 2007 21:21:06 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- Message-ID: Hi Guys, Looked through the archives but still cannot figure this out. I have a Motorola G24 GPRS/GSM modem that I am connecting to my server running Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not detecting the port, CommPortIdentifier.getPortIdentifiers(). I have added the line to RXTXCommDriver: "ttyACM" // for USB Modems Rxtx still does not seem to find the port. Is there something I am missing to make this port visable? [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control Model driver for USB modems and ISDN adapters I really need your help as I have moved my server from windows to Linux and have been down for a few days because of this .. Thanks so much! _________________________________________________________________ PC Magazine’s 2007 editors’ choice for best Web mail—award-winning Windows Live Hotmail. http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 From tjarvi at qbang.org Mon Jun 4 16:17:35 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Jun 2007 16:17:35 -0600 (MDT) Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: On Mon, 4 Jun 2007, soop soop wrote: > Hi Guys, > > Looked through the archives but still cannot figure this out. I have a > Motorola G24 GPRS/GSM modem that I am connecting to my server running Ubuntu. > I can see my modem as is shows up as ttyACM0, but RXTX is not detecting the > port, CommPortIdentifier.getPortIdentifiers(). > > I have added the line to RXTXCommDriver: > > "ttyACM" // for USB Modems > > Rxtx still does not seem to find the port. Is there something I am missing to > make this port visable? > > [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver > [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device > [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control Model > driver for USB modems and ISDN adapters > > I really need your help as I have moved my server from windows to Linux and > have been down for a few days because of this .. Thanks so much! > You could try the INSTALL documentation that comes with the source for possible solutions. Those usually involve lockfile creation, permissions on the device file or the device is in use by another application (even another session of your application). The usual commands: ls -l /dev/ttyACM0 fuser /dev/ttyACM0 touch /var/lock/LCK.testfile && rm -f /var/lock/LCK.testfile whoami To disable lockfiles: ../configure --disable-lockfiles && make install -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Jun 4 16:22:52 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 04 Jun 2007 18:22:52 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <466490BC.3090801@gatworks.com> soop soop wrote: > I really need your help as I have moved my server from windows to Linux > and have been down for a few days because of this .. Thanks so much! can u open the device ? ie is the file protection/permissions keeping you out? From supsoop at hotmail.com Mon Jun 4 16:44:40 2007 From: supsoop at hotmail.com (soop soop) Date: Mon, 04 Jun 2007 22:44:40 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <466490BC.3090801@gatworks.com> Message-ID: Thanks for the reply, I see no exceptions being thrown, just no detection of the port whats so ever. I will run rxtx in debug mode and log. If this were a permissions issue would I not see some exceptions being thrown? >From: Uncle George >Reply-To: RXTX Developers and Users >To: RXTX Developers and Users >Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >Date: Mon, 04 Jun 2007 18:22:52 -0400 > >soop soop wrote: > > > I really need your help as I have moved my server from windows to Linux > > and have been down for a few days because of this .. Thanks so much! > >can u open the device ? ie is the file protection/permissions keeping >you out? >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ Get a preview of Live Earth, the hottest event this summer - only on MSN http://liveearth.msn.com?source=msntaglineliveearthhm From netbeans at gatworks.com Mon Jun 4 17:06:15 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 04 Jun 2007 19:06:15 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <46649AE7.10405@gatworks.com> Exceptions on what? On startup it wants to lookup all devices in /dev that it is capable of opening ( within the list of specific 'comm' devices ). If it cannot open, then does not get onto list. Part of this process, if configured, will also test if the "LOCK" schema can also be opened for the device. then it gets on the list of avail comm port. soop soop wrote: > Thanks for the reply, > > I see no exceptions being thrown, just no detection of the port whats so > ever. I will run rxtx in debug mode and log. If this were a permissions > issue would I not see some exceptions being thrown? > > >> From: Uncle George >> Reply-To: RXTX Developers and Users >> To: RXTX Developers and Users >> Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >> Date: Mon, 04 Jun 2007 18:22:52 -0400 >> >> soop soop wrote: >> >>> I really need your help as I have moved my server from windows to Linux >>> and have been down for a few days because of this .. Thanks so much! >> can u open the device ? ie is the file protection/permissions keeping >> you out? >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _________________________________________________________________ > Get a preview of Live Earth, the hottest event this summer - only on MSN > http://liveearth.msn.com?source=msntaglineliveearthhm > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From alex.flint at gmail.com Mon Jun 4 21:31:49 2007 From: alex.flint at gmail.com (Alex Flint) Date: Tue, 5 Jun 2007 13:01:49 +0930 Subject: [Rxtx] random EXCEPTION_ACCESS_VIOLATION errors Message-ID: Hi All, I'm running winXP and RXTX 2.1-7r2 (the latest from the webpage as of June 2007). I'm sending sequences of 64 lines (each line has about 15 chars) at various intervals. The strings are sent fine, until I get the following error (from hs_err_pid3316.log, at the end of this email). What can I do to avoid the error? Obviously this is a low-level memory exception, but is there any way I can keep the JVM running after such an error? I noticed the exact same problem here: http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20070129/1180520.html Cheers, Alex # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x100034fb, pid=3316, tid=2400 # # Java VM: Java HotSpot(TM) Client VM (1.6.0_01-b06 mixed mode, sharing) # Problematic frame: # C [rxtxSerial.dll+0x34fb] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # --------------- T H R E A D --------------- Current thread (0x00386400): JavaThread "main" [_thread_in_native, id=2400] siginfo: ExceptionCode=0xc0000005, reading address 0x20726f78 Registers: EAX=0x20726f20, EBX=0x6d8922c0, ECX=0x00000005, EDX=0x20726f20 ESP=0x003efa30, EBP=0x003efb68, ESI=0x269728a0, EDI=0x00386400 EIP=0x100034fb, EFLAGS=0x00010212 Top of Stack: (sp=0x003efa30) 0x003efa30: 003efa3c 003efa64 0000000f ffffffff 0x003efa40: 003efa40 2a97f808 003efa6c 2b190ca8 0x003efa50: 00000000 2b190ec0 003efa90 008e2dd7 0x003efa60: 003efa90 008e2dd7 26977f88 6d815e72 0x003efa70: 00000004 2696eae0 0000008a 003efb0c 0x003efa80: 6d852b4a 2696eae0 00000003 26970930 0x003efa90: 000000cb 2696eae0 6d86b264 00385d40 0x003efaa0: 0000003f 003efb0c 26977f90 2ace65d8 Instructions: (pc=0x100034fb) 0x100034eb: ff ff 8d 76 00 eb 02 89 f6 90 8b 45 f8 8b 55 f8 0x100034fb: 8b 4a 58 83 c9 04 89 48 58 83 c4 f8 8b 45 f8 8b Stack: [0x003a0000,0x003f0000), sp=0x003efa30, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x34fb] Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j gnu.io.RXTXPort.writeArray([BIIZ)V+0 j gnu.io.RXTXPort$SerialOutputStream.write([B)V+76 j com.bjt.media.server.CommLink.send(Ljava/lang/String;)V+48 j com.bjt.media.server.DigitoolConnection.select(I)V+73 j com.bjt.media.server.DigitoolConnection.main([Ljava/lang/String;)V+74 v ~StubRoutines::call_stub --------------- P R O C E S S --------------- Java Threads: ( => current thread ) 0x02a69400 JavaThread "Thread-0" [_thread_in_native, id=3052] 0x02a4d000 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=3920] 0x02a48400 JavaThread "CompilerThread0" daemon [_thread_blocked, id=1968] 0x02a47400 JavaThread "Attach Listener" daemon [_thread_blocked, id=2984] 0x02a46400 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=2660] 0x02a41c00 JavaThread "Finalizer" daemon [_thread_blocked, id=3924] 0x02a3d800 JavaThread "Reference Handler" daemon [_thread_blocked, id=4008] =>0x00386400 JavaThread "main" [_thread_in_native, id=2400] Other Threads: 0x02a34400 VMThread [id=3708] 0x02a4e800 WatcherThread [id=3964] VM state:not at safepoint (normal execution) VM Mutex/Monitor currently owned by a thread: None Heap def new generation total 960K, used 131K [0x22960000, 0x22a60000, 0x22e40000) eden space 896K, 7% used [0x22960000, 0x22970ea8, 0x22a40000) from space 64K, 99% used [0x22a50000, 0x22a5fff8, 0x22a60000) to space 64K, 0% used [0x22a40000, 0x22a40000, 0x22a50000) tenured generation total 4096K, used 76K [0x22e40000, 0x23240000, 0x26960000) the space 4096K, 1% used [0x22e40000, 0x22e53060, 0x22e53200, 0x23240000) compacting perm gen total 12288K, used 137K [0x26960000, 0x27560000, 0x2a960000) the space 12288K, 1% used [0x26960000, 0x26982518, 0x26982600, 0x27560000) ro space 8192K, 62% used [0x2a960000, 0x2ae5e4e8, 0x2ae5e600, 0x2b160000) rw space 12288K, 52% used [0x2b160000, 0x2b7a0e78, 0x2b7a1000, 0x2bd60000) Dynamic libraries: 0x00400000 - 0x00423000 C:\Program Files\Java\jre1.6.0_01\bin\javaw.exe 0x7c900000 - 0x7c9b0000 C:\WINDOWS\system32\ntdll.dll 0x7c800000 - 0x7c8f4000 C:\WINDOWS\system32\kernel32.dll 0x77dd0000 - 0x77e6b000 C:\WINDOWS\system32\ADVAPI32.dll 0x77e70000 - 0x77f01000 C:\WINDOWS\system32\RPCRT4.dll 0x7e410000 - 0x7e4a0000 C:\WINDOWS\system32\USER32.dll 0x77f10000 - 0x77f57000 C:\WINDOWS\system32\GDI32.dll 0x76390000 - 0x763ad000 C:\WINDOWS\system32\IMM32.DLL 0x7c340000 - 0x7c396000 C:\Program Files\Java\jre1.6.0_01\bin\msvcr71.dll 0x6d7c0000 - 0x6da07000 C:\Program Files\Java\jre1.6.0_01\bin\client\jvm.dll 0x76b40000 - 0x76b6d000 C:\WINDOWS\system32\WINMM.dll 0x5cd70000 - 0x5cd77000 C:\WINDOWS\system32\serwvdrv.dll 0x5b0a0000 - 0x5b0a7000 C:\WINDOWS\system32\umdmxfrm.dll 0x6d310000 - 0x6d318000 C:\Program Files\Java\jre1.6.0_01\bin\hpi.dll 0x76bf0000 - 0x76bfb000 C:\WINDOWS\system32\PSAPI.DLL 0x6d770000 - 0x6d77c000 C:\Program Files\Java\jre1.6.0_01\bin\verify.dll 0x6d3b0000 - 0x6d3cf000 C:\Program Files\Java\jre1.6.0_01\bin\java.dll 0x6d7b0000 - 0x6d7bf000 C:\Program Files\Java\jre1.6.0_01\bin\zip.dll 0x10000000 - 0x10012000 C:\Documents and Settings\Alex\workspace\MediaServer\rxtxSerial.dll 0x73d90000 - 0x73db7000 C:\WINDOWS\system32\crtdll.dll VM Arguments: jvm_args: -Djava.library.path=C:\Documents and Settings\Alex\workspace\MediaServer java_command: com.bjt.media.server.DigitoolConnection Launcher Type: SUN_STANDARD Environment Variables: CLASSPATH=.;C:\Program Files\Java\j2re1.4.2_07\lib\ext\QTJava.zip PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\wbem;c:\applications\php;C:\Program Files\MATLAB\R2006a\bin\win32;C:\Roger\Projects\UAV\Bin\Debug;C:\Program Files\Microsoft SQL Server\80\Tools\Binn\;c:\Program Files\Microsoft SQL Server\90\Tools\binn\;C:\Program Files\QuickTime\QTSystem\;C:\Pfps\system;C:\Program Files\Java\jdk1.6.0_01\bin;C:\Program Files\Java\jdk1.6.0_01\jre\bin USERNAME=Alex OS=Windows_NT PROCESSOR_IDENTIFIER=x86 Family 15 Model 4 Stepping 1, GenuineIntel --------------- S Y S T E M --------------- OS: Windows XP Build 2600 Service Pack 2 CPU:total 1 family 15, cmov, cx8, fxsr, mmx, sse, sse2 Memory: 4k page, physical 1046508k(275288k free), swap 2522816k(1909176k free) vm_info: Java HotSpot(TM) Client VM (1.6.0_01-b06) for windows-x86, built on Mar 14 2007 00:24:02 by "java_re" with unknown MS VC++:1310 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070604/c87ae1f0/attachment-0004.html From alwyn.schoeman at gmail.com Tue Jun 5 00:10:19 2007 From: alwyn.schoeman at gmail.com (Alwyn Schoeman) Date: Tue, 5 Jun 2007 08:10:19 +0200 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Hi, I'm using a similar modem. By default rxtx doesn't look for devices that start with ACM, so you need to modify the source code and recompile. Look in RXTXCommDriver and add values for ACM in the registerScannedPorts method in the Linux specific parts. Look for osName.equals("Linux")... On 6/4/07, soop soop wrote: > > Hi Guys, > > Looked through the archives but still cannot figure this out. I have a > Motorola G24 GPRS/GSM modem that I am connecting to my server running > Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not > detecting the port, CommPortIdentifier.getPortIdentifiers(). > > I have added the line to RXTXCommDriver: > > "ttyACM" // for USB Modems > > Rxtx still does not seem to find the port. Is there something I am missing > to make this port visable? > > [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver > [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device > [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control > Model > driver for USB modems and ISDN adapters > > I really need your help as I have moved my server from windows to Linux > and > have been down for a few days because of this .. Thanks so much! > > _________________________________________________________________ > PC Magazine's 2007 editors' choice for best Web mail?award-winning Windows > Live Hotmail. > > http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -- Alwyn Schoeman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/b6cb3053/attachment-0004.html From naranjo.manuel at gmail.com Tue Jun 5 06:48:45 2007 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Tue, 05 Jun 2007 09:48:45 -0300 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> References: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Message-ID: <46655BAD.7010501@gmail.com> That's right, an easier solution is creating symlinks to acm. For example make ttyS70 to 79 point to ACM0 to 9 and that will help you a lot, and doesn't even require compile. > Hi, > > I'm using a similar modem. By default rxtx doesn't look for devices > that start with ACM, so you need to modify the > source code and recompile. > > Look in RXTXCommDriver and add values for ACM in the > registerScannedPorts method in the Linux specific parts. Look for > osName.equals("Linux")... > From juanemc2 at gmail.com Tue Jun 5 07:02:43 2007 From: juanemc2 at gmail.com (Juan) Date: Tue, 5 Jun 2007 10:02:43 -0300 Subject: [Rxtx] Problems with Epson TMU220B POSPrinter using XON/XOFF Flow Control and rxtx jar and dll's with the serial port. Message-ID: Hi!, I?m having trouble printing to the serial port using the latest version of rxtx jar and dll's with an Epson POSPrinter. I`ve switched the printer to work with XON/XOFF Flow Control and have watched the serial port to be sure the printer is sending the XON XOFF stop and go characters. I`ve setted the port like this: CommPortIdentifier commPortIdentifier = CommPortIdentifier.* getPortIdentifier*(_portName); SerialPort serialPort = (SerialPort)commPortIdentifier.open(*this*.getClass().getName(), 2000); serialPort.setSerialPortParams(_baudRate, _dataBits, _stopBits, _parity); serialPort.setFlowControlMode( SerialPort.*FLOWCONTROL_XONXOFF_IN* | SerialPort.*FLOWCONTROL_XONXOFF_OUT*); where the baudRate is 9600 the dataBits is 8 the stopBits is 1 and the parity is 0 It seems as the library isn`t taking into account the XON XOFF setting. I would like to know if I`m setting correctly the Flow Control and if you had had any experiences using XON XOFF flow control and could give me some help to solve my problem. I`m very thankful in advance, Yours, Juan Polero -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/b080995a/attachment-0004.html From ehdez.correo at gmail.com Tue Jun 5 07:12:53 2007 From: ehdez.correo at gmail.com (=?ISO-8859-1?Q?Enrique_Hern=E1ndez?=) Date: Tue, 5 Jun 2007 09:12:53 -0400 Subject: [Rxtx] problem with rxtx Message-ID: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Hello: I doing a simple test to show the serial ports. This is the code: import java.util.Enumeration; import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; public class Show { private Enumeration portList; private CommPortIdentifier portId; private SerialPort port; /** Creates a new instance of Show */ public Show() { } public static void main(String args[]){ Show show = new Show(); show.portList = CommPortIdentifier.getPortIdentifiers(); String tPort = ""; System.out.println("========================================="); while(show.portList.hasMoreElements()){ show.portId = (CommPortIdentifier)show.portList.nextElement(); if(show.portId.getPortType() == CommPortIdentifier.PORT_SERIAL) tPort = "Serial"; else tPort = "Parallel"; System.out.println(show.portId.getName() + " " + tPort); } } } whit The problem is that this code not show the serial ports, this show the no use serial ports. I want to connect whit the modem but when windows open and connect the modem my application don't see the port(COMM3) when it is connect. what I can do? Is that the correct way to know the ports? thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/eedd744b/attachment-0004.html From ehdez.correo at gmail.com Tue Jun 5 07:42:13 2007 From: ehdez.correo at gmail.com (=?ISO-8859-1?Q?Enrique_Hern=E1ndez?=) Date: Tue, 5 Jun 2007 09:42:13 -0400 Subject: [Rxtx] serial port Message-ID: <4a814e1f0706050642p4ce9ac7bka80f9479c524c5ea@mail.gmail.com> Hello: How I can ask to the port what device is connect and information about this device. thanks. bye. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/4d10d26a/attachment-0004.html From supsoop at hotmail.com Tue Jun 5 09:29:00 2007 From: supsoop at hotmail.com (soop soop) Date: Tue, 05 Jun 2007 15:29:00 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Message-ID: Hi Guys, Thanks for all your help. I found the problem. I created a user, Tomcat55, for my tomcat but it did not belong to any group. I then added this user to dialout group to have access to the device ttyACM0. Works perfectly! Again permissions was the issue. This also seems to be persistent as a server reboot does not effect the access. Cheers! >From: "Alwyn Schoeman" >Reply-To: RXTX Developers and Users >To: "RXTX Developers and Users" >Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >Date: Tue, 5 Jun 2007 08:10:19 +0200 > >Hi, > >I'm using a similar modem. By default rxtx doesn't look for devices that >start with ACM, so you need to modify the >source code and recompile. > >Look in RXTXCommDriver and add values for ACM in the registerScannedPorts >method in the Linux specific parts. Look for osName.equals("Linux")... > >On 6/4/07, soop soop wrote: >> >>Hi Guys, >> >>Looked through the archives but still cannot figure this out. I have a >>Motorola G24 GPRS/GSM modem that I am connecting to my server running >>Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not >>detecting the port, CommPortIdentifier.getPortIdentifiers(). >> >>I have added the line to RXTXCommDriver: >> >>"ttyACM" // for USB Modems >> >>Rxtx still does not seem to find the port. Is there something I am missing >>to make this port visable? >> >>[ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver >>[ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device >>[ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control >>Model >>driver for USB modems and ISDN adapters >> >>I really need your help as I have moved my server from windows to Linux >>and >>have been down for a few days because of this .. Thanks so much! >> >>_________________________________________________________________ >>PC Magazine's 2007 editors' choice for best Web mail—award-winning Windows >>Live Hotmail. >> >>http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 >> >> >>_______________________________________________ >>Rxtx mailing list >>Rxtx at qbang.org >>http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > >-- >Alwyn Schoeman >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ Need a break? Find your escape route with Live Search Maps. http://maps.live.com/default.aspx?ss=Restaurants~Hotels~Amusement%20Park&cp=33.832922~-117.915659&style=r&lvl=13&tilt=-90&dir=0&alt=-1000&scene=1118863&encType=1&FORM=MGAC01 From netbeans at gatworks.com Tue Jun 5 09:42:31 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 11:42:31 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <46658467.20101@gatworks.com> soop soop wrote: > > Hi Guys, > > Thanks for all your help. I found the problem. I created a user, > Tomcat55, for my tomcat but it did not belong to any group. I then added Look at man pages for the program udev. From tjarvi at qbang.org Tue Jun 5 18:18:17 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Jun 2007 18:18:17 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Message-ID: On Tue, 5 Jun 2007, Enrique Hern?ndez wrote: > The problem is that this code not show the serial ports, this show the no > use serial ports. I want to connect whit the modem but when windows open and > connect the modem my application don't see the port(COMM3) when it is > connect. > what I can do? > Is that the correct way to know the ports? > Hello, We may have problems understanding each other. On windows, the port will not be an available serial port if another application has the port open. That is just how the library behaves. If you can not see the port in the enumerated list, you could not open it. Also note that enumeration only happens once. If you add a port such as a new USB dongle, the port will not be visible until the next time your application runs. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Tue Jun 5 18:45:01 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 20:45:01 -0400 Subject: [Rxtx] problem with rxtx In-Reply-To: References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Message-ID: <4666038D.8090700@gatworks.com> Trent Jarvi wrote: > > > Also note that enumeration only happens once. If you add a port such as > a new USB dongle, the port will not be visible until the next time your > application runs. Is this written in stone ? somewhere? From tjarvi at qbang.org Tue Jun 5 18:54:36 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Jun 2007 18:54:36 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <4666038D.8090700@gatworks.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> Message-ID: On Tue, 5 Jun 2007, Uncle George wrote: > Trent Jarvi wrote: >> >> >> Also note that enumeration only happens once. If you add a port such as >> a new USB dongle, the port will not be visible until the next time your >> application runs. > > Is this written in stone ? somewhere? It is just the current behavior. There is nothing preventing a fix that allows reenumeration. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Tue Jun 5 19:55:19 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 21:55:19 -0400 Subject: [Rxtx] problem with rxtx In-Reply-To: References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> Message-ID: <46661407.4020308@gatworks.com> >> Is this written in stone ? somewhere? > > It is just the current behavior. There is nothing preventing a fix that > allows reenumeration. With usb, ..... , things come and go. Seems a shame that you have to kill application to get at the device u just plugged in. From joachim at buechse.ch Wed Jun 6 01:50:06 2007 From: joachim at buechse.ch (Joachim Buechse) Date: Wed, 6 Jun 2007 09:50:06 +0200 Subject: [Rxtx] problem with rxtx In-Reply-To: <46661407.4020308@gatworks.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> <46661407.4020308@gatworks.com> Message-ID: <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> On MacOS RXTX's enumeration handling is more flexible. It will find new ports that are added during the lifetime of the application. But this is inherently incompatible with suns javax.comm implementation... Regards, Joachim On 06.06.2007, at 03:55, Uncle George wrote: > >>> Is this written in stone ? somewhere? >> >> It is just the current behavior. There is nothing preventing a >> fix that >> allows reenumeration. > > With usb, ..... , things come and go. Seems a shame that you have to > kill application to get at the device u just plugged in. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Jun 6 06:06:48 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Jun 2007 06:06:48 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> <46661407.4020308@gatworks.com> <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> Message-ID: Sun's javax.comm is not a major concern going forward. As long as we do not break old applications using rxtx, I see no reason to limit rxtx to that convention. We have already rejected version 3 from Sun as a dead end and limited our compatability to version 2. That does not mean we will not try to work with Sun and others but the current javax.comm convention (v3) is not a well conceived path. There has been discussion about doing a JSR which is one valid option. On Wed, 6 Jun 2007, Joachim Buechse wrote: > On MacOS RXTX's enumeration handling is more flexible. It will find > new ports that are added during the lifetime of the application. But > this is inherently incompatible with suns javax.comm implementation... > > Regards, > Joachim > > On 06.06.2007, at 03:55, Uncle George wrote: > >> >>>> Is this written in stone ? somewhere? >>> >>> It is just the current behavior. There is nothing preventing a >>> fix that >>> allows reenumeration. >> >> With usb, ..... , things come and go. Seems a shame that you have to >> kill application to get at the device u just plugged in. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From yvespielusenet at free.fr Wed Jun 6 08:46:35 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 16:46:35 +0200 Subject: [Rxtx] [PARALLEL] resource in use Message-ID: <1181141195.3407.20.camel@localhost.localdomain> Hello, I want to use rxtx in my application. I haveto send data to a very old printer (which have a drum and hammers http://perso.orange.fr/tiie/page00010017.html) This is printer is connecter with centronics. It works well but, while it's writting and I putthe printer off-line, after about 45 seconds, I have this error : ------------------------------------- java.io.IOException: La ressource demand?e est en cours d'utilisation. in writeArray at gnu.io.LPRPort.writeArray(Native Method) at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:292) at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:161) at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:156) at mce.buffer.bufferManager.BufferManager$PrintBuffer.run(BufferManager.java:141) The IOexception means "The wanted resource is in use" ------------------------------------- Here is the line 141 of BufferManager : ------------------------------------- while(send){ try{ fos.write(bb); <=== line 141 send = false; } catch(Exception e){ javax.swing.JOptionPane.showMessageDialog(null, "Erreur d'envoie. Veuillez cliquer sur OK pour relancer l'impression de la vignette.\nV?rifiez votre impression !", "Erreur d'envoie", javax.swing.JOptionPane.WARNING_MESSAGE); e.printStackTrace(System.err); System.err.flush(); System.out.println(e); send = true; } } -------------------------------- 'fos' is an outputstream which contains the rxtx stream (this.os is the rxtx outputstream) : -------------------------------- public void write(byte[] bb) throws IOException{ this.write(bb, 0, bb.length); } public void write(byte[] bb, int off, int len) throws IOException{ while(!imp1.isPrinterSelected() || !imp2.isPrinterSelected()){ } this.os.write(bb, off, len); } -------------------------------- Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( can you help me ? thank you :) -- yves piel From yvespielusenet at free.fr Wed Jun 6 09:11:15 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 17:11:15 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181141195.3407.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> Message-ID: <1181142675.3407.23.camel@localhost.localdomain> I forgot to tell that It's under windows XP and java 1.5. Le mercredi 06 juin 2007 ? 16:46 +0200, yves pielusenet a ?crit : > Hello, > I want to use rxtx in my application. I haveto send data to a very old > printer (which have a drum and hammers > http://perso.orange.fr/tiie/page00010017.html) > This is printer is connecter with centronics. It works well but, while > it's writting and I putthe printer off-line, after about 45 seconds, I > have this error : > ------------------------------------- > java.io.IOException: La ressource demand?e est en cours d'utilisation. > in writeArray > at gnu.io.LPRPort.writeArray(Native Method) > at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:292) > at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:161) > at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:156) > at mce.buffer.bufferManager.BufferManager$PrintBuffer.run(BufferManager.java:141) > > The IOexception means "The wanted resource is in use" > ------------------------------------- > > Here is the line 141 of BufferManager : > > ------------------------------------- > while(send){ > try{ > fos.write(bb); <=== line 141 > send = false; > } > catch(Exception e){ > javax.swing.JOptionPane.showMessageDialog(null, "Erreur d'envoie. Veuillez cliquer sur OK pour relancer l'impression de la vignette.\nV?rifiez votre impression !", "Erreur d'envoie", javax.swing.JOptionPane.WARNING_MESSAGE); > e.printStackTrace(System.err); > System.err.flush(); > System.out.println(e); > send = true; > } > } > -------------------------------- > 'fos' is an outputstream which contains the rxtx stream (this.os is the rxtx outputstream) : > > -------------------------------- > public void write(byte[] bb) throws IOException{ > this.write(bb, 0, bb.length); > } > public void write(byte[] bb, int off, int len) throws IOException{ > while(!imp1.isPrinterSelected() || !imp2.isPrinterSelected()){ > } > this.os.write(bb, off, len); > } > -------------------------------- > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > can you help me ? > > thank you :) > From netbeans at gatworks.com Wed Jun 6 09:21:46 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 11:21:46 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181141195.3407.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> Message-ID: <4666D10A.8000507@gatworks.com> } > -------------------------------- > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > can you help me ? > > thank you :) > windoz or linux? ( I guess windoz ) for windoz, there appears to be a timeout ( as Comments suggest ) of about 40seconds. > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } for linux, there is no implied timeout. > if( write( fd, bytes, count ) < 0 ) > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); From netbeans at gatworks.com Wed Jun 6 09:39:41 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 11:39:41 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666D10A.8000507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> Message-ID: <4666D53D.90000@gatworks.com> Uncle George wrote: > } >> -------------------------------- >> >> Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( >> >> can you help me ? From reading the code, I can see your concern. And it appears you are correct, because some of the data will be sent to the OS printer buffers, and then it will refuse to accept anymore. Unfortunately, writeArray does not return the num of characters written :{ So application has no idea to how many characters were accepted by the OS. I dont do windoz, so I cant say with absolute certainty what windoz will do with an off-line condition. If you have the source, and can compile, then maybe u can increase the loop count to hit 4hours? From yvespielusenet at free.fr Wed Jun 6 09:53:25 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 17:53:25 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666D10A.8000507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> Message-ID: <1181145205.3407.35.camel@localhost.localdomain> Thank you for your explanation :) This timeout comes when no data has been send to the printer after 40seconds if I well understand. But why there is such a timeout ? If I setthe printer offline while it's printing I mustn't have an exception. I don't understand why the "printer should solv all problems like buffer full" in 40 seconds. If I pause the printer the buffer will not be emptied, isn't it ? I not very familiar with C/C++, but it seem that the exception is thrown only when countWritten == 0, that means no data at all has been sent. So Is my code is good since when I intercept this exception I send all my buffer again. There is no way that the printer receive two times same bytes ? thanks ps: yes the application is running on windows XP since I developpe under Debian Le mercredi 06 juin 2007 ? 11:21 -0400, Uncle George a ?crit : > } > > -------------------------------- > > > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > > > can you help me ? > > > > thank you :) > > > > windoz or linux? ( I guess windoz ) > > for windoz, there appears to be a timeout ( as Comments suggest ) of > about 40seconds. > > while( count > 0 ){ > > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > > /* > > this are 20 * 2 seconds, in this time a printer (or other parallel device) > > should solv all problems like buffer full, etc > > */ > > if(errorCount++ < 20){ > > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > > continue; > > } > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > for linux, there is no implied timeout. > > if( write( fd, bytes, count ) < 0 ) > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Wed Jun 6 10:34:24 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 12:34:24 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181145205.3407.35.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> Message-ID: <4666E210.30507@gatworks.com> yves pielusenet wrote: > Thank you for your explanation :) > This timeout comes when no data has been send to the printer after > 40seconds if I well understand. But why there is such a timeout ? If I > setthe printer offline while it's printing I mustn't have an exception. > I don't understand why the "printer should solv all problems like buffer > full" in 40 seconds. If I pause the printer the buffer will not be > emptied, isn't it ? > > I not very familiar with C/C++, but it seem that the exception is thrown > only when countWritten == 0, that means no data at all has been sent. So > Is my code is good since when I intercept this exception I send all my > buffer again. There is no way that the printer receive two times same > bytes ? More technically, the function call returns and reports that 0 characters was written in this call. when 0 characters are written, it will check how many times 0 characters was written. If it has tried LESS than 20 times(errorCount), it will sleep() and try to write again. After 20 times, it wont sleep, but throw you the exception. Now suppose you are writing a 120 character line. you off-lined/paused your printer. The OS has room for 80 more characters in it's printer buffer. The WriteFile() will have a char count of 120, but on return the countWritten = 80. You still have 40 more characters to print. Since countWritten != 0, the counters: bytes += countWritten; count -= countWritten; get updated, and the Writefile now has a count of 40 characters. Since the printer is off-line, the countwritten is 0. And so the loop continues, till 40 seconds is up. As to why it is this way, i dont know ( not a windoz maven ); Also the sleep(20) in the loop is not so intuitive to suggest 2 seconds of sleep. I would have guessed 20seconds, or 20milliseconds. But go figure. BTW: Since your computer sends you error messages in French, does it curse in English? :)))) From yvespielusenet at free.fr Thu Jun 7 02:27:44 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Thu, 07 Jun 2007 10:27:44 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666E210.30507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> Message-ID: <1181204864.3501.10.camel@localhost.localdomain> Maybe in my case I should re-compile rxtx and change the code. Instead of send an exception I should display a dialog box to ask if it's printer problem or if it should trie to send bytes. Something like : while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } if(displayDialogBox("Try again to send datas ??")){ errorCount = 0; } else{ throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } } Le mercredi 06 juin 2007 ? 12:34 -0400, Uncle George a ?crit : > yves pielusenet wrote: > > Thank you for your explanation :) > > This timeout comes when no data has been send to the printer after > > 40seconds if I well understand. But why there is such a timeout ? If I > > setthe printer offline while it's printing I mustn't have an exception. > > I don't understand why the "printer should solv all problems like buffer > > full" in 40 seconds. If I pause the printer the buffer will not be > > emptied, isn't it ? > > > > I not very familiar with C/C++, but it seem that the exception is thrown > > only when countWritten == 0, that means no data at all has been sent. So > > Is my code is good since when I intercept this exception I send all my > > buffer again. There is no way that the printer receive two times same > > bytes ? > More technically, the function call returns and reports that 0 > characters was written in this call. > when 0 characters are written, it will check how many times 0 characters > was written. If it has tried LESS than 20 times(errorCount), it will > sleep() and try to write again. > After 20 times, it wont sleep, but throw you the exception. > > Now suppose you are writing a 120 character line. you off-lined/paused > your printer. The OS has room for 80 more characters in it's printer > buffer. The WriteFile() will have a char count of 120, but on return the > countWritten = 80. You still have 40 more characters to print. > Since countWritten != 0, the counters: > bytes += countWritten; > count -= countWritten; > get updated, and the Writefile now has a count of 40 characters. Since > the printer is off-line, the countwritten is 0. And so the loop > continues, till 40 seconds is up. > > As to why it is this way, i dont know ( not a windoz maven ); > Also the sleep(20) in the loop is not so intuitive to suggest 2 seconds > of sleep. I would have guessed 20seconds, or 20milliseconds. But go figure. > > BTW: Since your computer sends you error messages in French, does it > curse in English? :)))) > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 06:11:43 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 08:11:43 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181204864.3501.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> Message-ID: <4667F5FF.8070903@gatworks.com> your suggestion appears good. I dont know what displayDialogBox exactly will do, so all I can say it that it looks good. But I'd like to wait 10min before first dialog box And a 5 min wait for every dialog box there after. And since these are custom solution/choices, maybe a more exact explanation of what the issue is. if(errorCount++ < 300){ // wait 10min ( 10min * 60sec / 2 ) Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } if(displayDialogBox("Printer has Paused. Retry sending data?")){ errorCount = 150; // Wait for 5 min thereafter continue; } > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } yves pielusenet wrote: > Maybe in my case I should re-compile rxtx and change the code. Instead > of send an exception I should display a dialog box to ask if it's > printer problem or if it should trie to send bytes. Something like : > > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > > if(displayDialogBox("Try again to send datas ??")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > } > From yvespielusenet at free.fr Thu Jun 7 07:17:21 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Thu, 07 Jun 2007 15:17:21 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4667F5FF.8070903@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <4667F5FF.8070903@gatworks.com> Message-ID: <1181222241.3501.20.camel@localhost.localdomain> thank you :) 'displayDialogBox()' I think doesn't exist. It was just for the example :) But I think It should not be so complicated to display a dialog box under windows with YES/NO buttons. When yes is clicked it return 0 other it returns 1. Le jeudi 07 juin 2007 ? 08:11 -0400, Uncle George a ?crit : > your suggestion appears good. I dont know what displayDialogBox exactly > will do, so all I can say it that it looks good. > > But I'd like to wait 10min before first dialog box And a 5 min wait for > every dialog box there after. And since these are custom > solution/choices, maybe a more exact explanation of what the issue is. > > if(errorCount++ < 300){ // wait 10min ( 10min * 60sec / 2 ) > Sleep( 20 ); /* make a small pause to execute all other requests > in all other threads */ > continue; > } > > if(displayDialogBox("Printer has Paused. Retry sending data?")){ > errorCount = 150; // Wait for 5 min thereafter > continue; > } > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > > yves pielusenet wrote: > > Maybe in my case I should re-compile rxtx and change the code. Instead > > of send an exception I should display a dialog box to ask if it's > > printer problem or if it should trie to send bytes. Something like : > > > > while( count > 0 ){ > > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > > /* > > this are 20 * 2 seconds, in this time a printer (or other parallel device) > > should solv all problems like buffer full, etc > > */ > > if(errorCount++ < 20){ > > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > > continue; > > } > > > > if(displayDialogBox("Try again to send datas ??")){ > > errorCount = 0; > > } > > else{ > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > } > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 07:41:43 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 09:41:43 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181222241.3501.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <4667F5FF.8070903@gatworks.com> <1181222241.3501.20.camel@localhost.localdomain> Message-ID: <46680B17.8050109@gatworks.com> yves pielusenet wrote: > thank you :) > 'displayDialogBox()' I think doesn't exist. It was just for the > example :) too bad. Good luck. From rtrout at webbresearch.com Thu Jun 7 11:23:04 2007 From: rtrout at webbresearch.com (Robert Trout) Date: Thu, 07 Jun 2007 13:23:04 -0400 Subject: [Rxtx] Disconnected PortServer TS causes Java to hang Message-ID: <1181236984.14186.33.camel@sisyphus.DinkumSoftware.com> I'm running Linux with sun's Java 1.4.2, Java comm API 2.0, RXTX 2.0-7pre1, and the RealPort digi driver. "/dev/ttyrp00" is a RealPort device. My Java application never returns from a ComPortIdentifier.getPortIdentifier("/dev/ttyrp00") call while the Digi PortServer TS 4 is disconnected from the network. If I later re-connect the PortServer, the call returns about 30 seconds later (it's like a serial port read or write is blocking until the PortServer is re- connected). With the PortServer disconnected, minicom immediately responds with "cannot open /dev/ttyrp00: No such file or directory". I would like my Java application to behave similarly. That is, respond with an error condition instead of hanging when the PortServer is not connected. Since minicom and Java behave differently, I think this "hanging" behavior may be due to RXTX or Java? Has anyone had a similar issue? Solutions? Suggestions? Thanks, Robert From vicnevicne at gmail.com Thu Jun 7 12:16:02 2007 From: vicnevicne at gmail.com (Vicne) Date: Thu, 07 Jun 2007 20:16:02 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181204864.3501.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> Message-ID: <46684B62.7080802@gmail.com> yves pielusenet wrote: > Maybe in my case I should re-compile rxtx and change the code. Instead > of send an exception I should display a dialog box to ask if it's > printer problem or if it should trie to send bytes. Something like : > > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > > if(displayDialogBox("Try again to send datas ??")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > } > Sorry to step in without a specific solution to your problem, but I wanted to share my feeling regarding this proposal. AFAIK, it's generally considered bad practice to pop-up a prompt from a library. The main reason is that in general use, you can't guarantee that someone is actually present behind the console. Imagine a print server in a machine room, connected to a park of printers. In that case, when one printer fails, the logical behaviour would be to use an other one. If you change RxTx the way you propose, the printer queue will simply be stuck with a useless "Try again to send data ?" prompt until an administrator opens a remote connection to the print server's console and clicks "no". Second, it would create a dependency upon the existence of a graphical console (if you go the graphical "dialogBox" way). On many applications (typically server or embedded ones), the JVM is "headless" and if you try to pop-up a dialog, your app would throw an exception (at best) or just wouldn't display the prompt anywhere... Going the "text console" way is not more reliable, because on graphical environments, the text console is hidden unless explicitly requested. My advice would be to think again and find another solution. Ideas are : - make the number of retries a parameter so that you can tune it to what you think is reasonable - throw a more specific exception when the number of retries has been reached, so that a specific prompt can be shown at a higher level Anyway, if you feel that the prompt is the way to go in your case, I would at least make that prompt conditional. The least intrusive way would probably be using a system property, like if("true".equals(System.getProperty("org.rxtx.usePrompt")) && displayDialogBox("Retry sending data ?")){ errorCount = 0; } else{ throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } By default, the behaviour would remain as it is now, but you could force the prompts by defining the property at VM launch if desired. (for example : java.exe -Dorg.rxtx.usePrompt=true myApp) Also, you seemed to say you wanted the printer to start again exactly where is stopped. It would indeed be the best way when the printer is put offline for a few seconds. On the other hand, if the printer is turned off (or the printer runs out of paper, or someone steps on the mains cable), then the only way to go back to a "stable" situation would be by printing the item (page, label, etc.) again from scratch... Just my two cents. Vicne PS : By the way, the dialog box thing is very platform dependant on the C-side, and I think the simplest way would probably be to bridge it to a Java call where you can implement it like you proposed : public boolean displayDialogBox(prompt) { return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); } From netbeans at gatworks.com Thu Jun 7 14:08:24 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 16:08:24 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46684B62.7080802@gmail.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> Message-ID: <466865B8.4060004@gatworks.com> My feeling is that the code that was suggested was for his environs ( his shop ). The issue here is that after a 40+ second wait, an exception will be thrown. But you really dont have a way of 'cancelling' all the WriteFiles() that have already occured before the exception so that your writeArray and the Commapi can backtrack to a position in which they are in sync. The main ( really mine ) concern is not to lose data, or replicate data. After 40seconds, 300 seconds, 55min, no matter how long, data should not be lost or duplicated. But as soon as the exception is thrown, that possibility exists. Maybe an event should be thrown instead? Vicne wrote: > yves pielusenet wrote: >> Maybe in my case I should re-compile rxtx and change the code. Instead >> of send an exception I should display a dialog box to ask if it's >> printer problem or if it should trie to send bytes. Something like : >> >> while( count > 0 ){ >> if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ >> /* >> this are 20 * 2 seconds, in this time a printer (or other parallel device) >> should solv all problems like buffer full, etc >> */ >> if(errorCount++ < 20){ >> Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ >> continue; >> } >> >> if(displayDialogBox("Try again to send datas ??")){ >> errorCount = 0; >> } >> else{ >> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >> break; >> } >> } >> > > Sorry to step in without a specific solution to your problem, but I > wanted to share my feeling regarding this proposal. AFAIK, it's > generally considered bad practice to pop-up a prompt from a library. > The main reason is that in general use, you can't guarantee that > someone is actually present behind the console. Imagine a print server > in a machine room, connected to a park of printers. In that case, when > one printer fails, the logical behaviour would be to use an other one. > If you change RxTx the way you propose, the printer queue will simply be > stuck with a useless "Try again to send data ?" prompt until an > administrator opens a remote connection to the print server's console > and clicks "no". > Second, it would create a dependency upon the existence of a > graphical console (if you go the graphical "dialogBox" way). On many > applications (typically server or embedded ones), the JVM is "headless" > and if you try to pop-up a dialog, your app would throw an exception (at > best) or just wouldn't display the prompt anywhere... Going the "text > console" way is not more reliable, because on graphical environments, > the text console is hidden unless explicitly requested. > > My advice would be to think again and find another solution. Ideas are : > - make the number of retries a parameter so that you can tune it to what > you think is reasonable > - throw a more specific exception when the number of retries has been > reached, so that a specific prompt can be shown at a higher level > > Anyway, if you feel that the prompt is the way to go in your case, I > would at least make that prompt conditional. The least intrusive way > would probably be using a system property, like > > if("true".equals(System.getProperty("org.rxtx.usePrompt")) > && displayDialogBox("Retry sending data ?")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > > > By default, the behaviour would remain as it is now, but you could > force the prompts by defining the property at VM launch if desired. (for > example : java.exe -Dorg.rxtx.usePrompt=true myApp) > > > Also, you seemed to say you wanted the printer to start again > exactly where is stopped. It would indeed be the best way when the > printer is put offline for a few seconds. On the other hand, if the > printer is turned off (or the printer runs out of paper, or someone > steps on the mains cable), then the only way to go back to a "stable" > situation would be by printing the item (page, label, etc.) again from > scratch... > > > Just my two cents. > > > Vicne > > PS : By the way, the dialog box thing is very platform dependant on the > C-side, and I think the simplest way would probably be to bridge it to a > Java call where you can implement it like you proposed : > > public boolean displayDialogBox(prompt) { > return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", > JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); > } > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Thu Jun 7 17:48:11 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 Jun 2007 17:48:11 -0600 (MDT) Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <466865B8.4060004@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> Message-ID: An event is possible. I'm amazed this is the largest problem encountered while using the parallel code. How would the write ever exit if we throw events? Isn't this going to lead to hung applications? On Thu, 7 Jun 2007, Uncle George wrote: > My feeling is that the code that was suggested was for his environs ( > his shop ). > > The issue here is that after a 40+ second wait, an exception will be > thrown. But you really dont have a way of 'cancelling' all the > WriteFiles() that have already occured before the exception so that your > writeArray and the Commapi can backtrack to a position in which they are > in sync. > > The main ( really mine ) concern is not to lose data, or replicate data. > After 40seconds, 300 seconds, 55min, no matter how long, data should > not be lost or duplicated. But as soon as the exception is thrown, that > possibility exists. > > Maybe an event should be thrown instead? > > Vicne wrote: >> yves pielusenet wrote: >>> Maybe in my case I should re-compile rxtx and change the code. Instead >>> of send an exception I should display a dialog box to ask if it's >>> printer problem or if it should trie to send bytes. Something like : >>> >>> while( count > 0 ){ >>> if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ >>> /* >>> this are 20 * 2 seconds, in this time a printer (or other parallel device) >>> should solv all problems like buffer full, etc >>> */ >>> if(errorCount++ < 20){ >>> Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ >>> continue; >>> } >>> >>> if(displayDialogBox("Try again to send datas ??")){ >>> errorCount = 0; >>> } >>> else{ >>> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >>> break; >>> } >>> } >>> >> >> Sorry to step in without a specific solution to your problem, but I >> wanted to share my feeling regarding this proposal. AFAIK, it's >> generally considered bad practice to pop-up a prompt from a library. >> The main reason is that in general use, you can't guarantee that >> someone is actually present behind the console. Imagine a print server >> in a machine room, connected to a park of printers. In that case, when >> one printer fails, the logical behaviour would be to use an other one. >> If you change RxTx the way you propose, the printer queue will simply be >> stuck with a useless "Try again to send data ?" prompt until an >> administrator opens a remote connection to the print server's console >> and clicks "no". >> Second, it would create a dependency upon the existence of a >> graphical console (if you go the graphical "dialogBox" way). On many >> applications (typically server or embedded ones), the JVM is "headless" >> and if you try to pop-up a dialog, your app would throw an exception (at >> best) or just wouldn't display the prompt anywhere... Going the "text >> console" way is not more reliable, because on graphical environments, >> the text console is hidden unless explicitly requested. >> >> My advice would be to think again and find another solution. Ideas are : >> - make the number of retries a parameter so that you can tune it to what >> you think is reasonable >> - throw a more specific exception when the number of retries has been >> reached, so that a specific prompt can be shown at a higher level >> >> Anyway, if you feel that the prompt is the way to go in your case, I >> would at least make that prompt conditional. The least intrusive way >> would probably be using a system property, like >> >> if("true".equals(System.getProperty("org.rxtx.usePrompt")) >> && displayDialogBox("Retry sending data ?")){ >> errorCount = 0; >> } >> else{ >> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >> break; >> } >> >> >> By default, the behaviour would remain as it is now, but you could >> force the prompts by defining the property at VM launch if desired. (for >> example : java.exe -Dorg.rxtx.usePrompt=true myApp) >> >> >> Also, you seemed to say you wanted the printer to start again >> exactly where is stopped. It would indeed be the best way when the >> printer is put offline for a few seconds. On the other hand, if the >> printer is turned off (or the printer runs out of paper, or someone >> steps on the mains cable), then the only way to go back to a "stable" >> situation would be by printing the item (page, label, etc.) again from >> scratch... >> >> >> Just my two cents. >> >> >> Vicne >> >> PS : By the way, the dialog box thing is very platform dependant on the >> C-side, and I think the simplest way would probably be to bridge it to a >> Java call where you can implement it like you proposed : >> >> public boolean displayDialogBox(prompt) { >> return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", >> JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); >> } >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 19:18:51 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 21:18:51 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> Message-ID: <4668AE7B.3060409@gatworks.com> The UNIX version of writeArray is not too great either. It is possible that the write will only process some of the bytes. #else if( write( fd, bytes, count ) < 0 ) throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); #endif -------------------------------- Maybe it might be better to have the native function inform the caller of the # of characters written, then the commapi/output-buffer can be modified to reflect the #of chars written. If an exception is to be thrown, for too many loops of chars written == 0, then exception wont affect the state of the output buffer. Then a ParallelPort.restart() can be called to resume printing whats in the buffer. Trent Jarvi wrote: > An event is possible. I'm amazed this is the largest problem encountered > while using the parallel code. > > How would the write ever exit if we throw events? Isn't this going to > lead to hung applications? Sure. If you dont time out, then there is nothing that will force an EXIT from the write(). Issue is what has the OS done with the write. > > On Thu, 7 Jun 2007, Uncle George wrote: > >> My feeling is that the code that was suggested was for his environs ( >> his shop ). From yvespielusenet at free.fr Fri Jun 8 01:09:01 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Fri, 08 Jun 2007 09:09:01 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4668AE7B.3060409@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> Message-ID: <1181286541.3674.10.camel@localhost.localdomain> It is not possible that the rxtx java method write(byte[], int offset, int length) return anint which contains the number of byte really send to the printer instead of an exception ? So this is the programm which will see if all bytes have been sent. If not it can retry to send the unsended bytes. -------------------------------------------------------- int sended = 0; while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ sended += countWritten; /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } return sended; /*throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break;*/ } ... ... return countWritten; ------------------------------------------------ Le jeudi 07 juin 2007 ? 21:18 -0400, Uncle George a ?crit : > The UNIX version of writeArray is not too great either. It is possible > that the write will only process some of the bytes. > > #else > if( write( fd, bytes, count ) < 0 ) > throw_java_exception_system_msg( env, IO_EXCEPTION, > "writeArray" ); > #endif > -------------------------------- > > Maybe it might be better to have the native function inform the caller > of the # of characters written, then the commapi/output-buffer can be > modified to reflect the #of chars written. If an exception is to be > thrown, for too many loops of chars written == 0, then exception wont > affect the state of the output buffer. Then a ParallelPort.restart() can > be called to resume printing whats in the buffer. > > > Trent Jarvi wrote: > > An event is possible. I'm amazed this is the largest problem encountered > > while using the parallel code. > > > > How would the write ever exit if we throw events? Isn't this going to > > lead to hung applications? > Sure. If you dont time out, then there is nothing that will force an > EXIT from the write(). Issue is what has the OS done with the write. > > > > On Thu, 7 Jun 2007, Uncle George wrote: > > > >> My feeling is that the code that was suggested was for his environs ( > >> his shop ). > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Fri Jun 8 03:45:00 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 11:45:00 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181286541.3674.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> Message-ID: <20070608094500.GC21069@elberon.bln.de.ingenico.com> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > It is not possible that the rxtx java method write(byte[], int offset, > int length) return anint which contains the number of byte really send > to the printer instead of an exception ? > So this is the programm which will see if all bytes have been sent. If > not it can retry to send the unsended bytes. I think write() is void because in Java people love to do this since OutputStream :-) Of course on such interfaces you cannot implement something nice. If you would have a int write, you would not implement the interface and no applications expecting this interface would link/work/compile. oki, Steffen P.S.: (OT) If you propose not to implement the Java interfaces (especially not on JNI level), maybe optionally offering a wrapper that removes e.g. the write return value and so on to downgrade the powerful classic old POSIX read/write style to the modern limited Java style, then I agree :-) Same for read. Instead of things like "int avialable()" it is more powerful to have an approach as select(2) offers (to guarante the caller that read/write will not block [nothing else make sense anyway IMHO] but may read/write less bytes then requested). The caller gets full control and the higher level protocols can care about timeouts, invoking read in some loops and/or implement retransmission. On top of such an implementation, where everything is controlled, defined, guaranteed and reliable, someone could use an InputStream or OutputStream style interface. Or even better: don't use them at all :) just BTW :-) St. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From yvespielusenet at free.fr Fri Jun 8 05:52:45 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Fri, 08 Jun 2007 13:52:45 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <20070608094500.GC21069@elberon.bln.de.ingenico.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> Message-ID: <1181303565.11203.3.camel@localhost.localdomain> So maybe a better way should be to create a new Exception class which has a method "int getWrittenByte()". So the Exception should be use to send again bytes which are not printed yet. yves Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : > * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > > It is not possible that the rxtx java method write(byte[], int offset, > > int length) return anint which contains the number of byte really send > > to the printer instead of an exception ? > > So this is the programm which will see if all bytes have been sent. If > > not it can retry to send the unsended bytes. > > I think write() is void because in Java people love to do this > since OutputStream :-) Of course on such interfaces you cannot > implement something nice. If you would have a int write, you > would not implement the interface and no applications expecting > this interface would link/work/compile. > > oki, > > Steffen > > P.S.: (OT) > If you propose not to implement the Java interfaces (especially > not on JNI level), maybe optionally offering a wrapper that > removes e.g. the write return value and so on to downgrade the > powerful classic old POSIX read/write style to the modern limited > Java style, then I agree :-) Same for read. Instead of things > like "int avialable()" it is more powerful to have an approach as > select(2) offers (to guarante the caller that read/write will not > block [nothing else make sense anyway IMHO] but may read/write > less bytes then requested). The caller gets full control and the > higher level protocols can care about timeouts, invoking read in > some loops and/or implement retransmission. On top of such an > implementation, where everything is controlled, defined, > guaranteed and reliable, someone could use an InputStream or > OutputStream style interface. Or even better: don't use them at > all :) just BTW :-) > St. > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > 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. > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > 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. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Fri Jun 8 06:46:21 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 08:46:21 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181303565.11203.3.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> Message-ID: <46694F9D.5080501@gatworks.com> It seems that with outputstream.write(b[]), you become terribly uncoordinated as soon as an exception is thrown. Docs do not say what happens to the data. Yet from a practicable point of view, one would like to know if the write was accepted in-full, or rejected before any writes. There are no in betweens, as partial writes are not reportable. So for an outputstream.write(), in order for it to return, the full write request has to be taken, and stored in an internal output buffer. If there is no room, the write() is suspended, till there is room. Or throw's an IOException( "no room in buffer") ; As the select() loop for write reports buffer room avail, then more of the internal buffer is sent to the printer. yves pielusenet wrote: > So maybe a better way should be to create a new Exception class which > has a method "int getWrittenByte()". So the Exception should be use to > send again bytes which are not printed yet. > > yves > > Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : >> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: >>> It is not possible that the rxtx java method write(byte[], int offset, >>> int length) return anint which contains the number of byte really send >>> to the printer instead of an exception ? >>> So this is the programm which will see if all bytes have been sent. If >>> not it can retry to send the unsended bytes. >> I think write() is void because in Java people love to do this >> since OutputStream :-) Of course on such interfaces you cannot >> implement something nice. If you would have a int write, you >> would not implement the interface and no applications expecting >> this interface would link/work/compile. >> >> oki, >> >> Steffen >> >> P.S.: (OT) >> If you propose not to implement the Java interfaces (especially >> not on JNI level), maybe optionally offering a wrapper that >> removes e.g. the write return value and so on to downgrade the >> powerful classic old POSIX read/write style to the modern limited >> Java style, then I agree :-) Same for read. Instead of things >> like "int avialable()" it is more powerful to have an approach as >> select(2) offers (to guarante the caller that read/write will not >> block [nothing else make sense anyway IMHO] but may read/write >> less bytes then requested). The caller gets full control and the >> higher level protocols can care about timeouts, invoking read in >> some loops and/or implement retransmission. On top of such an >> implementation, where everything is controlled, defined, >> guaranteed and reliable, someone could use an InputStream or >> OutputStream style interface. Or even better: don't use them at >> all :) just BTW :-) >> St. >> >> About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. >> 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. >> >> About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. >> 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. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From Steffen.DETTMER at ingenico.com Fri Jun 8 08:12:18 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 16:12:18 +0200 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <46694F9D.5080501@gatworks.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: <20070608141218.GE21069@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 08:46 -0400: > It seems that with outputstream.write(b[]), you become terribly > uncoordinated as soon as an exception is thrown. Docs do not say what > happens to the data. (yes, so avoiding it seems to be good :)) > Yet from a practicable point of view, one would like to know if the > write was accepted in-full, or rejected before any writes. There are no > in betweens, as partial writes are not reportable. (which is an artificial API limitation. I never understood how this happend when they invented JDK because the well-known BSD socket API and thus [probably] WinSock does this correct, but anyway) > So for an outputstream.write(), in order for it to return, the full > write request has to be taken, and stored in an internal output buffer. > If there is no room, the write() is suspended, till there is room. Or > throw's an IOException( "no room in buffer") ; As the select() loop for > write reports buffer room avail, then more of the internal buffer is > sent to the printer. yes, might be good in case of a printer. May be horrible in case of PPP/TCP or some other transmission control protocol which may e.g. repeat data or even omit parts of it (e.g. internet realtime radio station broadcasting)... So I think the idea of "int write" (e.g. BSD sockets, linux files and so on) still is the best. A clean API / implementation should guarantee and allow implementations (users) to rely on that; assumptions and automatic background-sending and so on may look pragmatic and may even work on the first look, but may fail in other situations. BTW, if e.g. BSD socket API is known, why not simply copy it (until something better is invented :)) instead of fiddling around with JDK APIs? anyway, have a nice weekend everyone :-) oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Fri Jun 8 08:55:56 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 10:55:56 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070608141218.GE21069@elberon.bln.de.ingenico.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> Message-ID: <46696DFC.7000801@gatworks.com> >> write reports buffer room avail, then more of the internal buffer is >> sent to the printer. > > yes, might be good in case of a printer. May be horrible in case > of PPP/TCP or some other transmission control protocol which > may e.g. repeat data or even omit parts of it (e.g. internet > realtime radio station broadcasting)... So I think the idea of > "int write" (e.g. BSD sockets, linux files and so on) still is > the best. A clean API / implementation should guarantee and allow > implementations (users) to rely on that; assumptions and > automatic background-sending and so on may look pragmatic and may > even work on the first look, but may fail in other situations. > BTW, if e.g. BSD socket API is known, why not simply copy it > (until something better is invented :)) instead of fiddling > around with JDK APIs? But we were talking about the Parallel Port, and the transmission of data over the commapi/parallel-port schema. There isn't much in bi-directional software communication. Its a simple write one byte at a time interface. I'm not looking to change the comm-api. I'm just looking to alter the interaction between the Native ParallelPort functions, and the java ParallelPort functions that call them. This might be more readily doable than to get a committee to re-specify java-API specs. BTW: Whats is off-topic? ( help: not looking for def of off-topic ) From j.kenneth.gentle at acm.org Fri Jun 8 08:58:59 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Fri, 08 Jun 2007 10:58:59 -0400 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <20070608141218.GE21069@elberon.bln.de.ingenico.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> Message-ID: <200706081459.l58Ex5rA019991@qbang.org> Perhaps it is a bit late to jump in on this one, but here goes anyway. If the solutions all seem to "break" the contract with "java.io.outputstream", then, as noted, that may not be the appropriate contract. At the risk of being heretical, JDK1.4 introduced the "nio" package to address some of the compatibility issues with C apis mentioned in previous posts. The interface "java.nio.channels.WriteableByteChannel" defines the following single method: int write(ByteBuffer source); int, strangely enough, is the actual number of bytes written. So, if RXTX as written, against the JavaCOMM api and OutputStream, doesn't do what we want, how about writing a different set of bindings using the java.nio classes and as much of the underlying native code as possible. Note that just because the java.nio.channels.WriteableByteChannel sends back a result, OutputStream.write doesn't have to - and they could both call the same underlying native code. My 2 cents - maybe not worth even that... Ken From netbeans at gatworks.com Fri Jun 8 10:37:28 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 12:37:28 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <200706081459.l58Ex5rA019991@qbang.org> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> Message-ID: <466985C8.8000505@gatworks.com> Ken Gentle wrote: > Perhaps it is a bit late to jump in on this one, but here goes anyway. Common in, the waters fine. > > If the solutions all seem to "break" the contract with > "java.io.outputstream", then, as noted, that may not be the > appropriate contract. > How would the contract be broken? The machinery underneath is handling the contract. From j.kenneth.gentle at acm.org Fri Jun 8 10:48:01 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Fri, 08 Jun 2007 12:48:01 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466985C8.8000505@gatworks.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> Message-ID: <200706081648.l58Gm7YA022904@qbang.org> At 12:37 2007-06-08, you wrote: >Ken Gentle wrote: > > > > If the solutions all seem to "break" the contract with > > "java.io.outputstream", then, as noted, that may not be the > > appropriate contract. > > >How would the contract be broken? The machinery underneath is handling >the contract. It seems that a lot of the discussion has been about not only the timeout and being able to adjust it in the "machinery layer", but also about knowing in the Java layer, in the event of a timeout or exception, how many characters have been written to the device. An OutputStream won't ever do this with out an extension and including a return value "breaks" the contract, right? So, go with a Java IO api that *does* return the number of bytes written, out of the NIO package. I know it doesn't allow for a strict implementation of the JavaCOMM API - however, using NIO classes in place of the IO classes isn't that big a break and would allow those applications that need such information a way to get it. Maybe I'm misunderstanding the problem... Ken From netbeans at gatworks.com Fri Jun 8 11:24:14 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 13:24:14 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <200706081648.l58Gm7YA022904@qbang.org> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> Message-ID: <466990BE.7040100@gatworks.com> Ken Gentle wrote: An > OutputStream won't ever do this with out an extension and including a > return value "breaks" the contract, right? > i was not thinking of change the API to OutputSream. Are there specs for how output stream should work internally? for instance: String data = "Hello this is a line of data"; Outputstream.write( data.getbytes() ); ParallelPort.suspend(); int free = ParallelPort.getoutputbufferfree(); There is a symbiotic relationship between outputstream and the functionality of ParallelPort. From Steffen.DETTMER at ingenico.com Fri Jun 8 11:15:39 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 19:15:39 +0200 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <200706081459.l58Ex5rA019991@qbang.org> References: <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> Message-ID: <20070608171539.GK21069@elberon.bln.de.ingenico.com> * Ken Gentle wrote on Fri, Jun 08, 2007 at 10:58 -0400: > If the solutions all seem to "break" the contract with > "java.io.outputstream", then, as noted, that may not be the > appropriate contract. > > At the risk of being heretical, JDK1.4 introduced the "nio" package > to address some of the compatibility issues with C apis mentioned in > previous posts. The interface > "java.nio.channels.WriteableByteChannel" defines the following single method: > > int write(ByteBuffer source); > > int, strangely enough, is the actual number of bytes written. Yes, AFAIK one of the motivations for the NIO interface was, that the JDK-1.3 APIs (InputStream, e.g.) were not powerfull enough, especially for multi-connection-TCP servers or so. I don't know much about it but I've heard of a project where NIO usage was removed because of stability issues in multi-threaded environments and performance limitations under some circumstances. IIRC the "nio.ByteBuffer" is something very special (namely something you cannot implement in Java, it is "magic" or part of the language itself). Not sure if this is such a great idea (but for performance in the end sometimes heavy prices must be paid) :) > So, if RXTX as written, against the JavaCOMM api and OutputStream, > doesn't do what we want, how about writing a different set of > bindings using the java.nio classes and as much of the underlying > native code as possible. Yes, this would be an idea: use a full-featured interface on JNI, and, if wanted, deliver some wrappers converting this to a less-featured Java-compliant interface. However, powerful things as e.g. "select" are difficult to "emulate" if you are e.g. on some (older?) windows. But if you expose the full-featured APIs, you need to emulate them full-featured, theoretically. In the end it depends what you do on the serial line. If you just want to talk to a modem, then you may not need precise timeouts. But if you need to implement complexer protocols which define response times and timeouts, you may quickly get into difficulties. For instance, AFAIK, rxtx 1.7.2 (?) for windows is very messy with timeouts (there is a maximum, higher values are truncated; resolution is 100ms only; the function may take up to twice the timeout because internally it may be called twice). Probably for most people this is OK, but probably not for all. But having precise timeouts should be OK for all :-) Well, in the end it is nice to wish but somewhat hard to implement (many platforms, connections, USB, BlueTooth, whatever). oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Steffen.DETTMER at ingenico.com Fri Jun 8 11:04:22 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 19:04:22 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <46696DFC.7000801@gatworks.com> References: <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <46696DFC.7000801@gatworks.com> Message-ID: <20070608170422.GJ21069@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 10:55 -0400: > > BTW, if e.g. BSD socket API is known, why not simply copy it > > (until something better is invented :)) instead of fiddling > > around with JDK APIs? > > But we were talking about the Parallel Port, and the > transmission of data over the commapi/parallel-port schema. > There isn't much in bi-directional software communication. Its > a simple write one byte at a time interface. First, there are things like PLIP (http://en.wikipedia.org/wiki/Plip) - well, probably not widely used, sure ;) Second, I think if there is a good simple API known to support all that (with known "best practices") or so and there is no forcing need to invent a new one, why not simply using it? > I'm not looking to change the comm-api. I'm just looking to > alter the interaction between the Native ParallelPort > functions, and the java ParallelPort functions that call them. Ahh, yes. I think this is what I tried to ask. Having an usable JNI interface and on top (in pure java) some wrapper to InputStream or whatever could be done (e.g. by ignoring the return value of write or throwing if != length). Developers could then use the full-featured (non-JAVA-standard) API or select among various wrappers (as InputStream). > This might be more readily doable than to get a committee to > re-specify java-API specs. Yes, of course. I'm afraid that the Java APIs change regularily, but still yet with limited success it seems, so maybe they get it in one of the next iterations; who knows, maybe Java-9 has a BSD-like socket API :) SCNR. > BTW: Whats is off-topic? ( help: not looking for def of > off-topic ) I think I started some "re-specify java-API specs" which was OT probably. oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From lists at iDIAcomputing.com Fri Jun 8 18:48:54 2007 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Fri, 08 Jun 2007 20:48:54 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46684B62.7080802@gmail.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> Message-ID: <4669F8F6.3040101@iDIAcomputing.com> Vicne wrote: > Sorry to step in without a specific solution to your problem, but I > wanted to share my feeling regarding this proposal. AFAIK, it's > generally considered bad practice to pop-up a prompt from a library. ... > > My advice would be to think again and find another solution. Ideas are : > - make the number of retries a parameter so that you can tune it to what > you think is reasonable > - throw a more specific exception when the number of retries has been > reached, so that a specific prompt can be shown at a higher level You could also allow the client code to register a callback class which returns a boolean indicating whether to retry or cancel. This callback class could pop up a dialog, if appropriate, or follow some preset policy, or.... - George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From joachim at buechse.ch Sat Jun 9 09:43:16 2007 From: joachim at buechse.ch (Joachim Buechse) Date: Sat, 9 Jun 2007 17:43:16 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46694F9D.5080501@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: You should not forget, that in the case of an exception it may not even be known what happened to the data. You have a kernel buffer, outgoing chip buffer, incoming chip buffer, etc. So of course, it would be nice to know up to which point data was correctly processed, but this feedback does not exist on the hardware or protocol level and hence can in general not be magicly created on the software level... Regards, Joachim On 08.06.2007, at 14:46, Uncle George wrote: > It seems that with outputstream.write(b[]), you become terribly > uncoordinated as soon as an exception is thrown. Docs do not say what > happens to the data. > > Yet from a practicable point of view, one would like to know if the > write was accepted in-full, or rejected before any writes. There > are no > in betweens, as partial writes are not reportable. > > So for an outputstream.write(), in order for it to return, the full > write request has to be taken, and stored in an internal output > buffer. > If there is no room, the write() is suspended, till there is room. Or > throw's an IOException( "no room in buffer") ; As the select() loop > for > write reports buffer room avail, then more of the internal buffer is > sent to the printer. > > > > yves pielusenet wrote: >> So maybe a better way should be to create a new Exception class which >> has a method "int getWrittenByte()". So the Exception should be >> use to >> send again bytes which are not printed yet. >> >> yves >> >> Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : >>> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: >>>> It is not possible that the rxtx java method write(byte[], int >>>> offset, >>>> int length) return anint which contains the number of byte >>>> really send >>>> to the printer instead of an exception ? >>>> So this is the programm which will see if all bytes have been >>>> sent. If >>>> not it can retry to send the unsended bytes. >>> I think write() is void because in Java people love to do this >>> since OutputStream :-) Of course on such interfaces you cannot >>> implement something nice. If you would have a int write, you >>> would not implement the interface and no applications expecting >>> this interface would link/work/compile. >>> >>> oki, >>> >>> Steffen >>> >>> P.S.: (OT) >>> If you propose not to implement the Java interfaces (especially >>> not on JNI level), maybe optionally offering a wrapper that >>> removes e.g. the write return value and so on to downgrade the >>> powerful classic old POSIX read/write style to the modern limited >>> Java style, then I agree :-) Same for read. Instead of things >>> like "int avialable()" it is more powerful to have an approach as >>> select(2) offers (to guarante the caller that read/write will not >>> block [nothing else make sense anyway IMHO] but may read/write >>> less bytes then requested). The caller gets full control and the >>> higher level protocols can care about timeouts, invoking read in >>> some loops and/or implement retransmission. On top of such an >>> implementation, where everything is controlled, defined, >>> guaranteed and reliable, someone could use an InputStream or >>> OutputStream style interface. Or even better: don't use them at >>> all :) just BTW :-) >>> St. >>> >>> About Ingenico Throughout the world businesses rely on Ingenico >>> for secure and expedient electronic transaction acceptance. >>> Ingenico products leverage proven technology, established >>> standards and unparalleled ergonomics to provide optimal >>> reliability, versatility and usability. This comprehensive range >>> of products is complemented by a global array of services and >>> partnerships, enabling businesses in a number of vertical sectors >>> to accept transactions anywhere their business takes them. >>> 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. >>> >>> About Ingenico Throughout the world businesses rely on Ingenico >>> for secure and expedient electronic transaction acceptance. >>> Ingenico products leverage proven technology, established >>> standards and unparalleled ergonomics to provide optimal >>> reliability, versatility and usability. This comprehensive range >>> of products is complemented by a global array of services and >>> partnerships, enabling businesses in a number of vertical sectors >>> to accept transactions anywhere their business takes them. >>> 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. >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx 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 yvespielusenet at free.fr Mon Jun 11 03:15:12 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Mon, 11 Jun 2007 11:15:12 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: <1181553312.8335.14.camel@localhost.localdomain> So can someone tell a solution for my problem :( Must I say to the user to not put the printer off-line ? I can't since he has to do some pauses, verify print, paper conditioning etc... How do other people ? Before I use the parport librarry to read port status : http://www.geocities.com/Juanga69/parport/ (which doesn't work on windows XP) And I send data into the file LPT1 I use to have no problem when printer was disabled. thanks -- yves piel Le samedi 09 juin 2007 ? 17:43 +0200, Joachim Buechse a ?crit : > You should not forget, that in the case of an exception it may not > even be known what happened to the data. > > You have a kernel buffer, outgoing chip buffer, incoming chip buffer, > etc. So of course, it would be nice to know up to which point data > was correctly processed, but this feedback does not exist on the > hardware or protocol level and hence can in general not be magicly > created on the software level... > > Regards, > Joachim > > On 08.06.2007, at 14:46, Uncle George wrote: > > > It seems that with outputstream.write(b[]), you become terribly > > uncoordinated as soon as an exception is thrown. Docs do not say what > > happens to the data. > > > > Yet from a practicable point of view, one would like to know if the > > write was accepted in-full, or rejected before any writes. There > > are no > > in betweens, as partial writes are not reportable. > > > > So for an outputstream.write(), in order for it to return, the full > > write request has to be taken, and stored in an internal output > > buffer. > > If there is no room, the write() is suspended, till there is room. Or > > throw's an IOException( "no room in buffer") ; As the select() loop > > for > > write reports buffer room avail, then more of the internal buffer is > > sent to the printer. > > > > > > > > yves pielusenet wrote: > >> So maybe a better way should be to create a new Exception class which > >> has a method "int getWrittenByte()". So the Exception should be > >> use to > >> send again bytes which are not printed yet. > >> > >> yves > >> > >> Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : > >>> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > >>>> It is not possible that the rxtx java method write(byte[], int > >>>> offset, > >>>> int length) return anint which contains the number of byte > >>>> really send > >>>> to the printer instead of an exception ? > >>>> So this is the programm which will see if all bytes have been > >>>> sent. If > >>>> not it can retry to send the unsended bytes. > >>> I think write() is void because in Java people love to do this > >>> since OutputStream :-) Of course on such interfaces you cannot > >>> implement something nice. If you would have a int write, you > >>> would not implement the interface and no applications expecting > >>> this interface would link/work/compile. > >>> > >>> oki, > >>> > >>> Steffen > >>> > >>> P.S.: (OT) > >>> If you propose not to implement the Java interfaces (especially > >>> not on JNI level), maybe optionally offering a wrapper that > >>> removes e.g. the write return value and so on to downgrade the > >>> powerful classic old POSIX read/write style to the modern limited > >>> Java style, then I agree :-) Same for read. Instead of things > >>> like "int avialable()" it is more powerful to have an approach as > >>> select(2) offers (to guarante the caller that read/write will not > >>> block [nothing else make sense anyway IMHO] but may read/write > >>> less bytes then requested). The caller gets full control and the > >>> higher level protocols can care about timeouts, invoking read in > >>> some loops and/or implement retransmission. On top of such an > >>> implementation, where everything is controlled, defined, > >>> guaranteed and reliable, someone could use an InputStream or > >>> OutputStream style interface. Or even better: don't use them at > >>> all :) just BTW :-) > >>> St. > >>> > >>> About Ingenico Throughout the world businesses rely on Ingenico > >>> for secure and expedient electronic transaction acceptance. > >>> Ingenico products leverage proven technology, established > >>> standards and unparalleled ergonomics to provide optimal > >>> reliability, versatility and usability. This comprehensive range > >>> of products is complemented by a global array of services and > >>> partnerships, enabling businesses in a number of vertical sectors > >>> to accept transactions anywhere their business takes them. > >>> 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. > >>> > >>> About Ingenico Throughout the world businesses rely on Ingenico > >>> for secure and expedient electronic transaction acceptance. > >>> Ingenico products leverage proven technology, established > >>> standards and unparalleled ergonomics to provide optimal > >>> reliability, versatility and usability. This comprehensive range > >>> of products is complemented by a global array of services and > >>> partnerships, enabling businesses in a number of vertical sectors > >>> to accept transactions anywhere their business takes them. > >>> 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. > >>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx 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 > From Steffen.DETTMER at ingenico.com Mon Jun 11 03:56:18 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 11:56:18 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466990BE.7040100@gatworks.com> References: <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> Message-ID: <20070611095618.GA10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 13:24 -0400: > i was not thinking of change the API to OutputSream. Then I think either someone uses OutputStream (and has no reliable information about incomplete writes) or someone uses somethink else. > Are there specs for how output stream should work internally? > > for instance: > String data = "Hello this is a line of data"; > Outputstream.write( data.getbytes() ); > ParallelPort.suspend(); > int free = ParallelPort.getoutputbufferfree(); > > There is a symbiotic relationship between outputstream and the > functionality of ParallelPort. If you need OutputStream "plus something else", in short you're needing "something else". Personally I dislike the code above a lot. The stream "looks" like if it would be an OutputStream, but in fact it isn't. You need to call getoutputbufferfree later to check if write succeeded (but OutputStream promises that write succeedes synchronous, blocking, or throws an exception). So it is not an OutputStream. No application written for OutputStreams would work without change (because it won't know getoutputbufferfree at all). It is not abstracted from ParallelPort. I think this would be wrong. Then I think an alternative interface instead is better. Let's assume we had some "connection" (to distinguish between OutputStreams and Channels). Then why not working as on a file handle in POSIX: do { // ... select maybe using timer ... readyForWrite = ... if (readyForWrite) { int writtenBytes = connection.write(toWrite); toWrite.remove(0, writtenBytes); } while(readyForWrite && toWrite.length > 0); I think, having such a write isn't the big problem. I think, the difficult thing is around "select" - however this would look like. It should be OO, typesafe, performant, supporting multiple connections/channels/streams in various modes and should be orthogonal to other functionalities. Of course, this heavily depends on what the application is doing; for a simple situation (like reading a small, mandatory file from a local disk) this would be to uncomfortable (and offering unneeded features only). just BTW :) oki, Steffen -- // Modeline for VIM. Please don't remove. // (Help: autoindent, expandtab, shiftwidth=4, tabstop=4, textwidth=75) // vi: set ai et sw=4 ts=4 tw=75 ft=java: About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Mon Jun 11 05:38:33 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 07:38:33 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611095618.GA10821@elberon.bln.de.ingenico.com> References: <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> Message-ID: <466D3439.4020805@gatworks.com> Steffen DETTMER wrote: > (but OutputStream promises that write > succeedes synchronous, blocking, or throws an exception). Where is it so written? From Steffen.DETTMER at ingenico.com Mon Jun 11 06:36:50 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 14:36:50 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466D3439.4020805@gatworks.com> References: <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> <466D3439.4020805@gatworks.com> Message-ID: <20070611123650.GI10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Mon, Jun 11, 2007 at 07:38 -0400: > Steffen DETTMER wrote: > > > (but OutputStream promises that write > > succeedes synchronous, blocking, or throws an exception). > > Where is it so written? Now, as you ask, I think it is not written that clearly but follows from specification. mmm... Am I wrong? I understand the API doc in this way: * http://java.sun.com/j2se/1.4.2/docs/api/java/io/OutputStream.html#write(byte[]) > public void write(byte[] b) > throws IOException > > Writes b.length bytes from the specified byte array to this > output stream. The general contract for write(b) is that > it should have exactly the same effect as the call write(b, > 0, b.length). > > Parameters: > b - the data. > Throws: > IOException - if an I/O error occurs. > See Also: > write(byte[], int, int) and there is: > public void write(byte[] b, > int off, > int len) > throws IOException > > Writes len bytes from the specified byte array starting at > offset off to this output stream. The general contract for > write(b, off, len) is that some of the bytes in the array b > are written to the output stream in order; element b[off] > is the first byte written and b[off+len-1] is the last byte > written by this operation. > > The write method of OutputStream calls the write method of > one argument on each of the bytes to be written out. > Subclasses are encouraged to override this method and > provide a more efficient implementation. > > If b is null, a NullPointerException is thrown. > > If off is negative, or len is negative, or off+len is > greater than the length of the array b, then an > IndexOutOfBoundsException is thrown. > > Parameters: > b - the data. > off - the start offset in the data. > len - the number of bytes to write. > Throws: > IOException - if an I/O error occurs. In particular, an > IOException is thrown if the output stream is closed. In general, any specialisation (derived child class) must comform to this. So write in the end is specified (!) as "The write method ... calls the write method ... on each of the bytes to be written out". This is what must be implemented by ANY OutputStream. Of course, there is: "Subclasses are encouraged to override this method and provide a more efficient implementation." which IMHO does not contradict - the more efficient must behave in exactly the same way of course (just wasting less resources than a simple byte-by-byte write). So it does not matter here I think. The write that finally defines the behavior tells basically: > "Writes the specified byte to this output stream. The general > contract for write is that one byte is written to the output > stream. " > > Throws: > IOException - if an I/O error occurs. which IMHO is another way of saying "write writes the byte immediately and returns on success (only), otherwise an exception is thrown". Especially it cannot happen that zero bytes are written (i.e. the specified byte is NOT written) without an exception. So by this write must be synchronous and blocking, because otherwise it could not reliably know if an asynchronous operation will succeede or not (some getAsyncResult or so would be needed). Since write(byte[]) does this for each byte (or with a behavior beeing exactly the same as if it would do), I think this means that the write(byte[]) succeedes synchronous/blocking or throws an exception. Did I an error in reasoning or confused something or so? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From j.kenneth.gentle at acm.org Mon Jun 11 06:51:25 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 11 Jun 2007 08:51:25 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611123650.GI10821@elberon.bln.de.ingenico.com> References: <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> <466D3439.4020805@gatworks.com> <20070611123650.GI10821@elberon.bln.de.ingenico.com> Message-ID: <200706111251.l5BCpS9T017831@qbang.org> It is as Steffen describes. "InputStream" and "OutputStream" are inherently synchronous (which is why so many java programs resort to threads to use them). Anything outside of this "contract" is *not* an InputStream or OutputStream. That is why there is a new package for things that don't behave like the old *Stream classes - the NIO package. If you look carefully at the IO package, you'll note that almost all the classes are _Decorator_ pattern implementations of the *Stream classes - and the interface presents the _same_ behavior to the calling code in all cases - a synchronous operation that completes successfully or throws an exception (with the one exception of "read" that returns a "-1" on end-of-stream. I know I've read this numerous times - I'd suggest checking the Language Spec or one of the books by Bloch or Gosling. Ken At 08:36 2007-06-11, you wrote: >* Uncle George wrote on Mon, Jun 11, 2007 at 07:38 -0400: > > Steffen DETTMER wrote: > > > > > (but OutputStream promises that write > > > succeedes synchronous, blocking, or throws an exception). > > > > Where is it so written? > >Now, as you ask, I think it is not written that clearly but >follows from specification. mmm... > >Am I wrong? > >I understand the API doc in this way: > >* >http://java.sun.com/j2se/1.4.2/docs/api/java/io/OutputStream.html#write(byte[]) > > public void write(byte[] b) > > throws IOException > > > > Writes b.length bytes from the specified byte array to this > > output stream. The general contract for write(b) is that > > it should have exactly the same effect as the call write(b, > > 0, b.length). > > > > Parameters: > > b - the data. > > Throws: > > IOException - if an I/O error occurs. > > See Also: > > write(byte[], int, int) > > >and there is: > > > > public void write(byte[] b, > > int off, > > int len) > > throws IOException > > > > Writes len bytes from the specified byte array starting at > > offset off to this output stream. The general contract for > > write(b, off, len) is that some of the bytes in the array b > > are written to the output stream in order; element b[off] > > is the first byte written and b[off+len-1] is the last byte > > written by this operation. > > > > The write method of OutputStream calls the write method of > > one argument on each of the bytes to be written out. > > Subclasses are encouraged to override this method and > > provide a more efficient implementation. > > > > If b is null, a NullPointerException is thrown. > > > > If off is negative, or len is negative, or off+len is > > greater than the length of the array b, then an > > IndexOutOfBoundsException is thrown. > > > > Parameters: > > b - the data. > > off - the start offset in the data. > > len - the number of bytes to write. > > Throws: > > IOException - if an I/O error occurs. In particular, an > > IOException is thrown if the output stream is closed. > > >In general, any specialisation (derived child class) must comform >to this. So write in the end is specified (!) as "The write >method ... calls the write method ... on each of the bytes to be >written out". This is what must be implemented by ANY >OutputStream. > >Of course, there is: "Subclasses are encouraged to override this >method and provide a more efficient implementation." which IMHO >does not contradict - the more efficient must behave in exactly >the same way of course (just wasting less resources than a simple >byte-by-byte write). So it does not matter here I think. > > > >The write that finally defines the behavior tells basically: > > > "Writes the specified byte to this output stream. The general > > contract for write is that one byte is written to the output > > stream. " > > > > Throws: > > IOException - if an I/O error occurs. > > >which IMHO is another way of saying "write writes the byte >immediately and returns on success (only), otherwise an exception >is thrown". Especially it cannot happen that zero bytes are >written (i.e. the specified byte is NOT written) without an >exception. So by this write must be synchronous and blocking, >because otherwise it could not reliably know if an asynchronous >operation will succeede or not (some getAsyncResult or so would >be needed). > >Since write(byte[]) does this for each byte (or with a behavior >beeing exactly the same as if it would do), I think this means >that the write(byte[]) succeedes synchronous/blocking or throws >an exception. > >Did I an error in reasoning or confused something or so? > >oki, > >Steffen > >About Ingenico Throughout the world businesses rely on Ingenico for >secure and expedient electronic transaction acceptance. Ingenico >products leverage proven technology, established standards and >unparalleled ergonomics to provide optimal reliability, versatility >and usability. This comprehensive range of products is complemented >by a global array of services and partnerships, enabling businesses >in a number of vertical sectors to accept transactions anywhere >their business takes them. >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. > >About Ingenico Throughout the world businesses rely on Ingenico for >secure and expedient electronic transaction acceptance. Ingenico >products leverage proven technology, established standards and >unparalleled ergonomics to provide optimal reliability, versatility >and usability. This comprehensive range of products is complemented >by a global array of services and partnerships, enabling businesses >in a number of vertical sectors to accept transactions anywhere >their business takes them. >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. > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From alesinskyy at googlemail.com Mon Jun 11 07:25:33 2007 From: alesinskyy at googlemail.com (Oleksandr Alesinskyy) Date: Mon, 11 Jun 2007 15:25:33 +0200 Subject: [Rxtx] [OT] select :-) Message-ID: Sorry, but I have to disagree with following statement: "So write in the end is specified (!) as "The write method ... calls the write method ... on each of the bytes to be written out". This is what must be implemented by ANY OutputStream.". This is not part of the specification or contract, it is just revealed implementation detail of the OutputStream. It is not stated anywhere that behavoiur of derived classes shall conform with this one. Statement concerning "synchronous" nature of the output stream is invalid as well. Really synchronous stream does not require flush() but OutputStream has it. From Steffen.DETTMER at ingenico.com Mon Jun 11 08:21:16 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 16:21:16 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: Message-ID: <20070611142116.GN10821@elberon.bln.de.ingenico.com> * Oleksandr Alesinskyy wrote on Mon, Jun 11, 2007 at 15:25 +0200: > Sorry, but I have to disagree with following statement: > "So write in the end is specified (!) as "The write > method ... calls the write method ... on each of the bytes to be > written out". This is what must be implemented by ANY > OutputStream.". > > This is not part of the specification or contract, it is just > revealed implementation detail of the OutputStream. It is not > stated anywhere that behavoiur of derived classes shall conform > with this one. (I didn't meant that the implementation must really write byte by byte, but that it must "look as if it would do" - because all implementations of OutputStream must "look" in the same way [which is another way of saying "do abstract" I think]) I think the API doc is not "revealing implementation details" but it is the *specification* of that interface and derivations must (should) conform to this specification. Isn't this the idea of interfaces? A function that expects an OutputStream should work on ANY OutputStream, shouldn't it? just kidding: I mean, what would be the point in implementing a checksum function as OutputStream.write which throws its result as IOException? Or which requires to call close() as very first operation to tell that the application is about to transmit confidential data? :-) > Statement concerning "synchronous" nature of the output stream > is invalid as well. Really synchronous stream does not require > flush() but OutputStream has it. ahh, interesting point! I think this is another bug in the API. flush() is wrong. Because write specifies "The general contract for write is that one byte is written to the output stream." but not "a byte may be written or buffered". Actually, an application would need to call flush() after each write (or bunch of write calls) to ensure that write really did something otherwise I think. I didn't found in the spec of OutputStream that it would be required to call flush(). This should mean that calling flush is not required which in turn leads to the conclusion that write must be synchrous (private threads are forbidden because not specified :)) which in turn leads to the conclusion that flush() is not needed at all... I mean, what if someone would only store in write and do the "real write" in flush() and never else? An application could write in one stream and read on another one (e.g. in bidirectional communication) and would never get anything back, because nothing was actually written because no flush was called? Then someone could even think that on error in some write the data could remain buffered AND throw an exception, retrying to send the data in the next write. Ohh, and if there would be some message number inside, and underlaying write (e.g. a protocol offering InputStream/OutputStream) would check this and throw "DuplicatedMessageNumber" the stream would only throw it again and again beeing unusable... In short: I have no clue how someone could be able to implement an asynchrounos write (which is realiable and correct) without beeing specific to anything which is not specified by OutputStream. Well, I think in the end OutputStream was not intended for such communication or protocol implementations - but to read a local disk file or so. In case of I/O errors usually you can abort your application and change the hard disk :-) oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Bob_Jacobsen at lbl.gov Mon Jun 11 09:32:23 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Mon, 11 Jun 2007 08:32:23 -0700 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611142116.GN10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> Message-ID: At 4:21 PM +0200 6/11/07, Steffen DETTMER wrote: > > Statement concerning "synchronous" nature of the output stream >> is invalid as well. Really synchronous stream does not require >> flush() but OutputStream has it. > >ahh, interesting point! > >I think this is another bug in the API. flush() is wrong. Because >write specifies "The general contract for write is that one byte >is written to the output stream." but not "a byte may be written >or buffered". > >Actually, an application would need to call flush() after each >write (or bunch of write calls) to ensure that write really did >something otherwise I think. OutputStreams don't _have_ to be synchronous or asynchronous, but the OutputStream API was be arranged so that subclasses _can_ be synchronous or asynchronous. Such generality is the hardest part of getting an API right. Hence, if at some point a program using an OutputStream wants to be sure that the data has been pushed all the way out, flush() is available. For some subclasses, e.g. the buffered ones, this has important behavior. Others write the data from each call, and flush() doesn't do anything. You _can_ omit it in programs that are known to use this second type, but there's no requirement that you do so; the interface is general in that way. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From Steffen.DETTMER at ingenico.com Mon Jun 11 12:32:39 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 20:32:39 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> Message-ID: <20070611183239.GT10821@elberon.bln.de.ingenico.com> * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: > >Actually, an application would need to call flush() after each > >write (or bunch of write calls) to ensure that write really did > >something otherwise I think. > OutputStreams don't _have_ to be synchronous or asynchronous, > but the OutputStream API was be arranged so that subclasses > _can_ be synchronous or asynchronous. Ahh, oki. Thanks for the clarificaion. So in short, flush() MUST be called on OutputStream, this is just not documented correctly or so clearly (right?). So the overall usage semantics would be: 1. call write (multiple times if desired) 2. call flush only if both succeeded, write was successful. If flush fails it remains unknown if a part of the data was written and/or will be repeated. So the spec (API doc) is wrong. Correct would be to tell that write behaves as told as long as it is followed by a call to flush, otherwise data may or may not get lost (depending wheter close() is called and calls flush(), which seems not to be guaranteed/required). BTW, I think it is a little bit... erm... interesting to find the specification (java API doc reference) wrong, having a need to conclude it from the presence of some methods with "it would make no sense if they behave exactly as specified, so specification must be wrong (incomplete)". > Such generality is the hardest part of getting an API right. Yes, seems to be proven ;) > Hence, if at some point a program using an OutputStream wants > to be sure that the data has been pushed all the way out, > flush() is available. For some subclasses, e.g. the buffered > ones, this has important behavior. Others write the data from > each call, and flush() doesn't do anything. > You _can_ omit it in programs that are known to use this second > type, but there's no requirement that you do so; the interface > is general in that way. I think, it still it must be called always, otherwise the application could break if passing a different runtime type as OutputStream. I think, if the application/method needs a special "type of OutputStream" then the parameter type must be a subclass but not OutputStream, maybe a PrintStream or so - otherwise the compiler could not detect this error (passing wrong type). Is this correct? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Bob_Jacobsen at lbl.gov Mon Jun 11 13:00:52 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Mon, 11 Jun 2007 12:00:52 -0700 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611183239.GT10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> Message-ID: At 8:32 PM +0200 6/11/07, Steffen DETTMER wrote: >So the spec (API doc) is wrong. Correct would be to tell that >write behaves as told as long as it is followed by a call to >flush, otherwise data may or may not get lost (depending wheter >close() is called and calls flush(), which seems not to be >guaranteed/required). I'm not entirely sure that the spec is wrong, but reasonable people can differ on this. In the 1.5 JavaDocs, all that the docs say for the write methods is that they write to the _output_ _stream_; there is no guarantee of anything beyond that. Only the flush method has any guarantee about the data, which is >Flushes this output stream and forces any buffered output bytes to >be written out. The general contract of flush is that calling it is >an indication that, if any bytes previously written have been >buffered by the implementation of the output stream, such bytes >should immediately be written to their intended destination. People commonly use various OutputStreams without using flush(), and it often works, but it's a bad practice and will eventually bite them. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From netbeans at gatworks.com Mon Jun 11 13:31:57 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 15:31:57 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611183239.GT10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> Message-ID: <466DA32D.1010602@gatworks.com> Steffen DETTMER wrote: > * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: >>> Actually, an application would need to call flush() after each >>> write (or bunch of write calls) to ensure that write really did >>> something otherwise I think. > >> OutputStreams don't _have_ to be synchronous or asynchronous, >> but the OutputStream API was be arranged so that subclasses >> _can_ be synchronous or asynchronous. > > Ahh, oki. Thanks for the clarificaion. > > So in short, flush() MUST be called on OutputStream, this is just > not documented correctly or so clearly (right?). No. Flush can be called to force all current data in java buffer's to be written to the kernel - NOW. A flush() can also *imply* that, besides writing out the buffer's that java employs, may also imply/ask the kernel to write all data thusfar written to the kernel, to be physically placed on the destination device - NOW. For some OS's there is no need to do a kernel flush(), as the I/O is synchronized already. Since this is java, you never know what OS your on. From tjarvi at qbang.org Mon Jun 11 19:28:27 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Jun 2007 19:28:27 -0600 (MDT) Subject: [Rxtx] [OT] select :-) In-Reply-To: <466DA32D.1010602@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: On Mon, 11 Jun 2007, Uncle George wrote: > Steffen DETTMER wrote: >> * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: >>>> Actually, an application would need to call flush() after each >>>> write (or bunch of write calls) to ensure that write really did >>>> something otherwise I think. >> >>> OutputStreams don't _have_ to be synchronous or asynchronous, >>> but the OutputStream API was be arranged so that subclasses >>> _can_ be synchronous or asynchronous. >> >> Ahh, oki. Thanks for the clarificaion. >> >> So in short, flush() MUST be called on OutputStream, this is just >> not documented correctly or so clearly (right?). > No. > Flush can be called to force all current data in java buffer's to be > written to the kernel - NOW. > > A flush() can also *imply* that, besides writing out the buffer's that > java employs, may also imply/ask the kernel to write all data thusfar > written to the kernel, to be physically placed on the destination device > - NOW. > For some OS's there is no need to do a kernel flush(), as the I/O is > synchronized already. Since this is java, you never know what OS your on. To add to the confusion, flush on the C side throws away data. drain makes sure it is written. Looking at the ParallelImp.c we can probably do better. /* we set a timeout because all calls are sequentiell (also with asynchron) this means that the default timeout of unlimited blocks all calls (also close and status request) if the device is down */ GetCommTimeouts( (HANDLE)fd, &timeouts ); timeouts.WriteTotalTimeoutMultiplier = 0; timeouts.WriteTotalTimeoutConstant = 2000; /* 2000 is the min value for the default Windows NT and Windows 2000 driver */ SetCommTimeouts( (HANDLE)fd, &timeouts ); while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } errorCount = 0; bytes += countWritten; count -= countWritten; } LPRPort has some timeout code that appears to be doing nothing but flipping bits back and forth right now. The commapi rxtx follows allows for timeout control from javax.comm.CommPort. The above is a solution that worked in one specific use case. With timeouts in place, the original 'old printer going offline' problem could be solved. That printer code isn't written in stone. In fact it was ajusted from being able to print 'asdf' to a daisy wheel printer to working for one person. BTW, I've finished teaching after hours tonight and will be moving forward with a new rxtx release in my free time. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Jun 11 21:28:04 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 23:28:04 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: <466E12C4.1010305@gatworks.com> > Looking at the ParallelImp.c we can probably do better. > The problem stemmed from the possibility that the writev routine could have written some of the buffer, in chunks, printer pauses, refuses any more chunks, and a timeout occurs. Do you or do you not cause an exception to be thrown? Is there a way to set timeout for a ParallelPort data output stream? I cant find it. From tjarvi at qbang.org Mon Jun 11 22:17:23 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Jun 2007 22:17:23 -0600 (MDT) Subject: [Rxtx] [OT] select :-) In-Reply-To: <466E12C4.1010305@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> <466E12C4.1010305@gatworks.com> Message-ID: On Mon, 11 Jun 2007, Uncle George wrote: >> Looking at the ParallelImp.c we can probably do better. >> > The problem stemmed from the possibility that the writev routine could > have written some of the buffer, in chunks, printer pauses, refuses any > more chunks, and a timeout occurs. Do you or do you not cause an > exception to be thrown? > > Is there a way to set timeout for a ParallelPort data output stream? I > cant find it. hmm I looked again after you asked. The timeouts are only controllable on the receive side. This comes from CommPort; the parent. So what we are talking about is some bytes in memory that rxtx has and is supposed to write. A buffer perhaps? The approach with rxtx in the past has been to ignore output buffer sizes. The assumption is that the library does not know how to best handle buffers. There are buffered output streams that can do buffering on top of rxtx for instance. There is also a question regarding what was actually ment when the API was put together. My suspicion is that it was put together while looking at one OS API and was never ment to be anything more than a hook into that API. The comments are fairly telling combined with reading the w32 API. So looking at the problem again.. The current timeout behavior appears fairly arbitrary. Presumably this is to prevent a program from hanging instead of using a helper thread to write - heavy handed for new programmers. Even so, I don't think the write should timeout at all if it is not configurable. >From the API perspective, "What Timeout?" -- Trent Jarvi tjarvi at qbang.org From Steffen.DETTMER at ingenico.com Tue Jun 12 02:14:48 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 12 Jun 2007 10:14:48 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466DA32D.1010602@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: <20070612081447.GU10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Mon, Jun 11, 2007 at 15:31 -0400: > Steffen DETTMER wrote: > > Ahh, oki. Thanks for the clarificaion. > > > > So in short, flush() MUST be called on OutputStream, this is just > > not documented correctly or so clearly (right?). > No. hum (though now I got it, but...). > Flush can be called to force all current data in java buffer's to be > written to the kernel - NOW. > > A flush() can also *imply* that, besides writing out the > buffer's that java employs, may also imply/ask the kernel to > write all data thusfar written to the kernel, to be physically > placed on the destination device - NOW. > > For some OS's there is no need to do a kernel flush(), as the I/O is > synchronized already. Since this is java, you never know what OS your on. (well, but if you're going to kernel level, even flush cannot guarantee that data will "be physically placed". Maybe you're flushing to a file via NFS (and the client "thinks" that it was written, but maybe it was just buffered by the NFS server) or so... but of course such exceptions of the rules are constructable always.) Well, you tell that depending on the OS it can be that flush is needed or it can be that flush is not needed (beacuse the I/O is synchronized already), right? Also, applications should work on any OS, which includes the OSes that do need flush. Since the application cannot know whether flush is needed or not because it doesn't know what the OS is doing, it has to call flush, hasn't it? I mean, if it would not call flush then it would not work on such OSes (except the written data would not be needed at all, but in this would be an artificial example :)). Since applications are supposed to work this would be wrong, wouldn't it? So would it be correct to say: "Applications, that should work under all OSes (including the OSes where the I/O is not synchronised already), have to call flush on OutputStream to ensure the data is transfered to the kernel." or is this wrong? If so, then I'm afraid I missed the point again :( oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Tue Jun 12 04:46:52 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 12 Jun 2007 06:46:52 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070612081447.GU10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> <20070612081447.GU10821@elberon.bln.de.ingenico.com> Message-ID: <466E799C.7060700@gatworks.com> S > (well, but if you're going to kernel level, even flush cannot > guarantee that data will "be physically placed". Thats true now-a-days because ( from "man 2 sync" ) : > According to the standard specification (e.g., SVID), sync() schedules > the writes, but may return before the actual writing is done. However, > since version 1.3.20 Linux does actually wait. (This still does not > guarantee data integrity: modern disks have large caches.) My disk drive has 8mb cache. Maybe you're > flushing to a file via NFS (and the client "thinks" that it was > written, but maybe it was just buffered by the NFS server) or > so... but of course such exceptions of the rules are > constructable always.) > > Well, you tell that depending on the OS it can be that flush is > needed or it can be that flush is not needed (beacuse the I/O is > synchronized already), right? Also, applications should work on > any OS, which includes the OSes that do need flush. Its not OS's that need flush, its applications that want to have some assurance that data is written to the device that really needs to use flush. If your program ( or thread ) dies then it is in your best interest to write out the critical data as soon as possible, as economical as possible. These are trade-off's that the application programmer makes. A big buffer may mean big loss of data, a small buffer may mean spending too much time writing out data. > > > So would it be correct to say: > > "Applications, that should work under all OSes (including the > OSes where the I/O is not synchronised already), have to call > flush on OutputStream to ensure the data is transfered to the > kernel." > > or is this wrong? If so, then I'm afraid I missed the point again > :( > No that is not wrong. Ensuring that data is transfered to the OS is just about what any application can do. From tjarvi at qbang.org Thu Jun 14 08:16:47 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 14 Jun 2007 08:16:47 -0600 (MDT) Subject: [Rxtx] rxtx and usb-serial solution In-Reply-To: References: Message-ID: On Thu, 14 Jun 2007, Vladimir Kirtchev wrote: > Hi Trent, > > I develop a Java application which communicates with devices which have > USB-to-Serial bridge in them. The target OS is Linux. So for this purpose I > use RXTX. > > But I encountered a strange problem - when reading from the InputStream, I > receive series of zeros. I have this problem under Linux only. Under Windows > it is fine. > Actually this problem is the same as the one described here: > http://marc.info/?l=rxtx&m=109703190731748&w=2. > > > So I searched for the problem in the native code. And found that the root of > the problem is in SerialImp.c, > int configure_port( int fd ) > { > ... > ttyset.c_iflag = INPCK; > ... > } > > This line enables input parity checking, and the data sent from the device > is processed by the OS driver before being read with read(). > In this case the driver detects some problem and sets the received bytes to > zero. > > On the other hand in the Java part a set the serial port parameters with > SerialPort.PARITY_NONE. According to me, except all other things, this > should also disable INPCK in c_iflag. > > So I refactored the method translate_parity(...) to the following: > > int translate_parity( JNIEnv *env, struct termios *ttyset, jint parity ) > { > ENTER( "translate_parity" ); > #ifdef CMSPAR > ttyset->c_cflag &= ~(PARENB | PARODD | CMSPAR ); > #endif /* CMSPAR */ > switch( parity ) { > case JPARITY_NONE: > ttyset->c_iflag &= ~INPCK; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_EVEN: > ttyset->c_cflag |= PARENB; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_ODD: > ttyset->c_cflag |= PARENB | PARODD; > LEAVE( "translate_parity" ); > return 0; > #ifdef CMSPAR > case JPARITY_MARK: > ttyset->c_cflag |= PARENB | PARODD | CMSPAR; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_SPACE: > ttyset->c_cflag |= PARENB | CMSPAR; > LEAVE( "translate_parity" ); > return 0; > #endif /* CMSPAR */ > default: > printf("Parity missed %i\n", (int) parity ); > } > > LEAVE( "translate_parity" ); > /* > For some reason the native exceptions are not being caught. Moving this > to the Java side fixed the issue. taj. > throw_java_exception( env, UNSUPPORTED_COMM_OPERATION, > "", "parity value not supported" ); > */ > return 1; > } > > This modification solved the problem and now it works correctly under Linux. > > I think I will be a nice if this is idea is included in a future release of > RXTX. > > Thanks Vadim, I'll try that out. Forwarding to the rxtx mail-list too. This is probably not going to help USB drivers on windows which I'm sure some are looking for. As far as I can tell, windows USB bluetooth and serial dongles are limited by driver functionality. Some are good and others lack key features. -- Trent Jarvi tjarvi at qbang.org From dan.sandberg.lists at gmail.com Mon Jun 18 14:43:39 2007 From: dan.sandberg.lists at gmail.com (Dan Sandberg) Date: Mon, 18 Jun 2007 13:43:39 -0700 Subject: [Rxtx] Fix for JNI Get/Set Field Errors Message-ID: <4676EE7B.7060800@gmail.com> Hi, I've fixed the problems that cause the following JNI error when extra JNI checking ( -Xjni:check ) is turned on. FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) The problem was basically that GetLong was being used to get ints, and SetInt was used for longs. The patch below fixes this. Please let me know if there are any questions / problems. Cheers, -Dan diff -aur old/SerialImp.c src/SerialImp.c --- old/SerialImp.c 2007-06-18 13:24:33.000000000 -0700 +++ src/SerialImp.c 2007-06-18 06:26:26.000000000 -0700 @@ -1337,7 +1337,7 @@ report("init_threads: get eis\n"); jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); report("init_threads: set eis\n"); - (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); + (*eis->env)->SetLongField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); report("init_threads: stop\n"); report_time_end( ); return( 1 ); @@ -1530,7 +1530,7 @@ jobject jobj, jboolean interrupted ) { int fd = get_java_var( env, jobj,"fd","I" ); - struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var( env, jobj, "eis", "J" ); + struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var_long( env, jobj, "eis", "J" ); int result, count=0; char message[80]; @@ -2939,7 +2939,7 @@ /* TRENT */ int flag, count = 0; struct event_info_struct *eis = ( struct event_info_struct * ) - get_java_var( env, *jobj,"eis","J" ); + get_java_var_long( env, *jobj,"eis","J" ); report_time_start(); flag = eis->eventflags[SPE_DATA_AVAILABLE]; @@ -4873,9 +4873,9 @@ exceptions: none comments: ----------------------------------------------------------*/ -size_t get_java_var( JNIEnv *env, jobject jobj, char *id, char *type ) +long get_java_var_long( JNIEnv *env, jobject jobj, char *id, char *type ) { - int result = 0; + long result = 0; jclass jclazz = (*env)->GetObjectClass( env, jobj ); jfieldID jfd = (*env)->GetFieldID( env, jclazz, id, type ); @@ -4889,7 +4889,11 @@ LEAVE( "get_java_var" ); return result; } - result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); + if ( !strcmp( type, "J" ) ) { + result = (long)( (*env)->GetLongField( env, jobj, jfd ) ); + } else { + result = (int) ( (*env)->GetIntField( env, jobj, jfd ) ); + } /* ct7 & gel * Added DeleteLocalRef */ (*env)->DeleteLocalRef( env, jclazz ); if(!strncmp( "fd",id,2) && result == 0) @@ -4900,6 +4904,10 @@ return result; } +int get_java_var( JNIEnv *env, jobject jobj, char *id, char *type ) { + return (int) get_java_var_long( env, jobj, id, type ); +} + /*---------------------------------------------------------- throw_java_exception diff -aur old/SerialImp.h src/SerialImp.h --- old/SerialImp.h 2007-06-18 13:24:39.000000000 -0700 +++ src/SerialImp.h 2007-06-18 06:23:43.000000000 -0700 @@ -413,7 +413,8 @@ void system_wait(); void finalize_event_info_struct( struct event_info_struct * ); int read_byte_array( JNIEnv *, jobject *, int, unsigned char *, int, int ); -size_t get_java_var( JNIEnv *, jobject, char *, char * ); +int get_java_var( JNIEnv *, jobject, char *, char * ); +long get_java_var_long( JNIEnv *, jobject, char *, char * ); jboolean is_interrupted( struct event_info_struct * ); int send_event(struct event_info_struct *, jint, int ); void dump_termios(char *,struct termios *); From netbeans at gatworks.com Fri Jun 1 05:38:50 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 07:38:50 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <465F7ADD.1010501@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> Message-ID: <4660054A.2040202@gatworks.com> Manuel Naranjo wrote: In the case of my module, you can > unplug the device but it will not delete the symlink until those apps > that had opened the port has closed it. This is done this way to avoid > kernel panics. What does this mean to user code ? I have tried the alternate route ( other than closing ) which is sleep inbetween the I/O errors ( an unplugged USB device). When the device is plugged back in, The writes to the device still get an I/O error. This would seem to be a lost cause for the application. From netbeans at gatworks.com Fri Jun 1 06:35:48 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 08:35:48 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <465F7ADD.1010501@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> Message-ID: <466012A4.90608@gatworks.com> Manuel Naranjo wrote: In the case of my module, you can > unplug the device but it will not delete the symlink until those apps > that had opened the port has closed it. T Did u also mean for this to happen? USB0 was not closed by application. Apparently USB1 got created when USB device was plugged back in. There is only one USB device on a 4 port USB hub. This also seems to suggest that application recovery to be impossible. > Jun 1 07:10:08 mylaptop kernel: garmin_gps 1-1.4:1.0: Garmin GPS usb/tty converter detected > Jun 1 07:10:08 mylaptop kernel: usb 1-1.4: Garmin GPS usb/tty converter now attached to ttyUSB0 > Jun 1 07:15:17 mylaptop kernel: usb 1-1: USB disconnect, address 4 > Jun 1 07:15:17 mylaptop kernel: usb 1-1.4: USB disconnect, address 5 > Jun 1 07:15:17 mylaptop kernel: garmin_gps 1-1.4:1.0: device disconnected > Jun 1 07:15:26 mylaptop kernel: usb 1-1: new full speed USB device using uhci_hcd and address 6 > Jun 1 07:15:26 mylaptop kernel: hub 1-1:1.0: USB hub found > Jun 1 07:15:26 mylaptop kernel: hub 1-1:1.0: 4 ports detected > Jun 1 07:15:27 mylaptop kernel: usb 1-1.4: new full speed USB device using uhci_hcd and address 7 > Jun 1 07:15:27 mylaptop kernel: garmin_gps 1-1.4:1.0: Garmin GPS usb/tty converter detected > Jun 1 07:15:27 mylaptop kernel: usb 1-1.4: Garmin GPS usb/tty converter now attached to ttyUSB1 From naranjo.manuel at gmail.com Fri Jun 1 09:17:22 2007 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Fri, 01 Jun 2007 12:17:22 -0300 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <466012A4.90608@gatworks.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> <466012A4.90608@gatworks.com> Message-ID: <46603882.5050701@gmail.com> Uncle George escribi?: > Manuel Naranjo wrote: > In the case of my module, you can > >> unplug the device but it will not delete the symlink until those apps >> that had opened the port has closed it. T >> > > Did u also mean for this to happen? USB0 was not closed by application. > > Apparently USB1 got created when USB device was plugged back in. There > is only one USB device on a 4 port USB hub. > > This also seems to suggest that application recovery to be impossible. > Exactly there's a dead symlink (you can read and write to it and nothing will happen) and a new port will be created when a new device is connencted. From netbeans at gatworks.com Fri Jun 1 10:20:46 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 12:20:46 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <46603882.5050701@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> <466012A4.90608@gatworks.com> <46603882.5050701@gmail.com> Message-ID: <4660475E.5090202@gatworks.com> Not sure what u mean by "symlink". U cant read/write to it anymore. U get I/O error. In this scenario the device effectively went dead, and only solution is to close the channel. reconnecting the USB device, although dead, but not closed, will create a second device. This does not seem to be a desirable side-effect. The user will now have ttyUSB1, wondering where did ttyUSB0 go to. The application will also be in a confused state, as well as RXTX, because RXTX wont know about ttyUSB1. Manuel Naranjo wrote: > Uncle George escribi?: >> Manuel Naranjo wrote: >> In the case of my module, you can >> >>> unplug the device but it will not delete the symlink until those apps >>> that had opened the port has closed it. T >>> >> Did u also mean for this to happen? USB0 was not closed by application. >> >> Apparently USB1 got created when USB device was plugged back in. There >> is only one USB device on a 4 port USB hub. >> >> This also seems to suggest that application recovery to be impossible. >> > Exactly there's a dead symlink (you can read and write to it and nothing > will happen) and a new port will be created when a new device is connencted. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From arnab.bhaumik at gmail.com Mon Jun 4 01:40:16 2007 From: arnab.bhaumik at gmail.com (arnab bhaumik) Date: Mon, 4 Jun 2007 13:10:16 +0530 Subject: [Rxtx] full duplex com port with rxtx Message-ID: hi , till now i did half duplex communication with rxtx package on com package. my question is : is it possible to use com port with full duplex mode with rxtx package . ther is example of SimpleRead class and SimpleWrite class. it is clear that if i can use both the class simultaneously then full duplex is possible......... arnab/vu2bpw -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070604/6edb0453/attachment-0005.html From lists at iDIAcomputing.com Mon Jun 4 07:53:17 2007 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Mon, 04 Jun 2007 09:53:17 -0400 Subject: [Rxtx] full duplex com port with rxtx In-Reply-To: References: Message-ID: <4664194D.90301@iDIAcomputing.com> arnab bhaumik wrote: > hi , > > till now i did half duplex communication with rxtx package on com > package. > > my question is : is it possible to use com port with full duplex mode > with rxtx package . > > > ther is example of SimpleRead class and SimpleWrite class. it is > clear that if i can use both the class simultaneously then full duplex > is possible......... I haven't looked at the SimpleRead and SimpleWrite classes (I originally wrote my code for the javax.comm api), but full duplex is certainly possible. My CommReader class requires an object analogous to a OutputStream or Writer. When started, it spawns a thread that reads the comm port and writes to that output device. In this way the input is asynchronous and dependent on the actual input data. For full duplex, I extend that class with CommReaderWriter, which adds synchronous output methods. Hope that helps, George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From supsoop at hotmail.com Mon Jun 4 15:21:06 2007 From: supsoop at hotmail.com (soop soop) Date: Mon, 04 Jun 2007 21:21:06 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- Message-ID: Hi Guys, Looked through the archives but still cannot figure this out. I have a Motorola G24 GPRS/GSM modem that I am connecting to my server running Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not detecting the port, CommPortIdentifier.getPortIdentifiers(). I have added the line to RXTXCommDriver: "ttyACM" // for USB Modems Rxtx still does not seem to find the port. Is there something I am missing to make this port visable? [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control Model driver for USB modems and ISDN adapters I really need your help as I have moved my server from windows to Linux and have been down for a few days because of this .. Thanks so much! _________________________________________________________________ PC Magazine’s 2007 editors’ choice for best Web mail—award-winning Windows Live Hotmail. http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 From tjarvi at qbang.org Mon Jun 4 16:17:35 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Jun 2007 16:17:35 -0600 (MDT) Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: On Mon, 4 Jun 2007, soop soop wrote: > Hi Guys, > > Looked through the archives but still cannot figure this out. I have a > Motorola G24 GPRS/GSM modem that I am connecting to my server running Ubuntu. > I can see my modem as is shows up as ttyACM0, but RXTX is not detecting the > port, CommPortIdentifier.getPortIdentifiers(). > > I have added the line to RXTXCommDriver: > > "ttyACM" // for USB Modems > > Rxtx still does not seem to find the port. Is there something I am missing to > make this port visable? > > [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver > [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device > [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control Model > driver for USB modems and ISDN adapters > > I really need your help as I have moved my server from windows to Linux and > have been down for a few days because of this .. Thanks so much! > You could try the INSTALL documentation that comes with the source for possible solutions. Those usually involve lockfile creation, permissions on the device file or the device is in use by another application (even another session of your application). The usual commands: ls -l /dev/ttyACM0 fuser /dev/ttyACM0 touch /var/lock/LCK.testfile && rm -f /var/lock/LCK.testfile whoami To disable lockfiles: ../configure --disable-lockfiles && make install -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Jun 4 16:22:52 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 04 Jun 2007 18:22:52 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <466490BC.3090801@gatworks.com> soop soop wrote: > I really need your help as I have moved my server from windows to Linux > and have been down for a few days because of this .. Thanks so much! can u open the device ? ie is the file protection/permissions keeping you out? From supsoop at hotmail.com Mon Jun 4 16:44:40 2007 From: supsoop at hotmail.com (soop soop) Date: Mon, 04 Jun 2007 22:44:40 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <466490BC.3090801@gatworks.com> Message-ID: Thanks for the reply, I see no exceptions being thrown, just no detection of the port whats so ever. I will run rxtx in debug mode and log. If this were a permissions issue would I not see some exceptions being thrown? >From: Uncle George >Reply-To: RXTX Developers and Users >To: RXTX Developers and Users >Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >Date: Mon, 04 Jun 2007 18:22:52 -0400 > >soop soop wrote: > > > I really need your help as I have moved my server from windows to Linux > > and have been down for a few days because of this .. Thanks so much! > >can u open the device ? ie is the file protection/permissions keeping >you out? >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ Get a preview of Live Earth, the hottest event this summer - only on MSN http://liveearth.msn.com?source=msntaglineliveearthhm From netbeans at gatworks.com Mon Jun 4 17:06:15 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 04 Jun 2007 19:06:15 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <46649AE7.10405@gatworks.com> Exceptions on what? On startup it wants to lookup all devices in /dev that it is capable of opening ( within the list of specific 'comm' devices ). If it cannot open, then does not get onto list. Part of this process, if configured, will also test if the "LOCK" schema can also be opened for the device. then it gets on the list of avail comm port. soop soop wrote: > Thanks for the reply, > > I see no exceptions being thrown, just no detection of the port whats so > ever. I will run rxtx in debug mode and log. If this were a permissions > issue would I not see some exceptions being thrown? > > >> From: Uncle George >> Reply-To: RXTX Developers and Users >> To: RXTX Developers and Users >> Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >> Date: Mon, 04 Jun 2007 18:22:52 -0400 >> >> soop soop wrote: >> >>> I really need your help as I have moved my server from windows to Linux >>> and have been down for a few days because of this .. Thanks so much! >> can u open the device ? ie is the file protection/permissions keeping >> you out? >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _________________________________________________________________ > Get a preview of Live Earth, the hottest event this summer - only on MSN > http://liveearth.msn.com?source=msntaglineliveearthhm > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From alex.flint at gmail.com Mon Jun 4 21:31:49 2007 From: alex.flint at gmail.com (Alex Flint) Date: Tue, 5 Jun 2007 13:01:49 +0930 Subject: [Rxtx] random EXCEPTION_ACCESS_VIOLATION errors Message-ID: Hi All, I'm running winXP and RXTX 2.1-7r2 (the latest from the webpage as of June 2007). I'm sending sequences of 64 lines (each line has about 15 chars) at various intervals. The strings are sent fine, until I get the following error (from hs_err_pid3316.log, at the end of this email). What can I do to avoid the error? Obviously this is a low-level memory exception, but is there any way I can keep the JVM running after such an error? I noticed the exact same problem here: http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20070129/1180520.html Cheers, Alex # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x100034fb, pid=3316, tid=2400 # # Java VM: Java HotSpot(TM) Client VM (1.6.0_01-b06 mixed mode, sharing) # Problematic frame: # C [rxtxSerial.dll+0x34fb] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # --------------- T H R E A D --------------- Current thread (0x00386400): JavaThread "main" [_thread_in_native, id=2400] siginfo: ExceptionCode=0xc0000005, reading address 0x20726f78 Registers: EAX=0x20726f20, EBX=0x6d8922c0, ECX=0x00000005, EDX=0x20726f20 ESP=0x003efa30, EBP=0x003efb68, ESI=0x269728a0, EDI=0x00386400 EIP=0x100034fb, EFLAGS=0x00010212 Top of Stack: (sp=0x003efa30) 0x003efa30: 003efa3c 003efa64 0000000f ffffffff 0x003efa40: 003efa40 2a97f808 003efa6c 2b190ca8 0x003efa50: 00000000 2b190ec0 003efa90 008e2dd7 0x003efa60: 003efa90 008e2dd7 26977f88 6d815e72 0x003efa70: 00000004 2696eae0 0000008a 003efb0c 0x003efa80: 6d852b4a 2696eae0 00000003 26970930 0x003efa90: 000000cb 2696eae0 6d86b264 00385d40 0x003efaa0: 0000003f 003efb0c 26977f90 2ace65d8 Instructions: (pc=0x100034fb) 0x100034eb: ff ff 8d 76 00 eb 02 89 f6 90 8b 45 f8 8b 55 f8 0x100034fb: 8b 4a 58 83 c9 04 89 48 58 83 c4 f8 8b 45 f8 8b Stack: [0x003a0000,0x003f0000), sp=0x003efa30, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x34fb] Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j gnu.io.RXTXPort.writeArray([BIIZ)V+0 j gnu.io.RXTXPort$SerialOutputStream.write([B)V+76 j com.bjt.media.server.CommLink.send(Ljava/lang/String;)V+48 j com.bjt.media.server.DigitoolConnection.select(I)V+73 j com.bjt.media.server.DigitoolConnection.main([Ljava/lang/String;)V+74 v ~StubRoutines::call_stub --------------- P R O C E S S --------------- Java Threads: ( => current thread ) 0x02a69400 JavaThread "Thread-0" [_thread_in_native, id=3052] 0x02a4d000 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=3920] 0x02a48400 JavaThread "CompilerThread0" daemon [_thread_blocked, id=1968] 0x02a47400 JavaThread "Attach Listener" daemon [_thread_blocked, id=2984] 0x02a46400 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=2660] 0x02a41c00 JavaThread "Finalizer" daemon [_thread_blocked, id=3924] 0x02a3d800 JavaThread "Reference Handler" daemon [_thread_blocked, id=4008] =>0x00386400 JavaThread "main" [_thread_in_native, id=2400] Other Threads: 0x02a34400 VMThread [id=3708] 0x02a4e800 WatcherThread [id=3964] VM state:not at safepoint (normal execution) VM Mutex/Monitor currently owned by a thread: None Heap def new generation total 960K, used 131K [0x22960000, 0x22a60000, 0x22e40000) eden space 896K, 7% used [0x22960000, 0x22970ea8, 0x22a40000) from space 64K, 99% used [0x22a50000, 0x22a5fff8, 0x22a60000) to space 64K, 0% used [0x22a40000, 0x22a40000, 0x22a50000) tenured generation total 4096K, used 76K [0x22e40000, 0x23240000, 0x26960000) the space 4096K, 1% used [0x22e40000, 0x22e53060, 0x22e53200, 0x23240000) compacting perm gen total 12288K, used 137K [0x26960000, 0x27560000, 0x2a960000) the space 12288K, 1% used [0x26960000, 0x26982518, 0x26982600, 0x27560000) ro space 8192K, 62% used [0x2a960000, 0x2ae5e4e8, 0x2ae5e600, 0x2b160000) rw space 12288K, 52% used [0x2b160000, 0x2b7a0e78, 0x2b7a1000, 0x2bd60000) Dynamic libraries: 0x00400000 - 0x00423000 C:\Program Files\Java\jre1.6.0_01\bin\javaw.exe 0x7c900000 - 0x7c9b0000 C:\WINDOWS\system32\ntdll.dll 0x7c800000 - 0x7c8f4000 C:\WINDOWS\system32\kernel32.dll 0x77dd0000 - 0x77e6b000 C:\WINDOWS\system32\ADVAPI32.dll 0x77e70000 - 0x77f01000 C:\WINDOWS\system32\RPCRT4.dll 0x7e410000 - 0x7e4a0000 C:\WINDOWS\system32\USER32.dll 0x77f10000 - 0x77f57000 C:\WINDOWS\system32\GDI32.dll 0x76390000 - 0x763ad000 C:\WINDOWS\system32\IMM32.DLL 0x7c340000 - 0x7c396000 C:\Program Files\Java\jre1.6.0_01\bin\msvcr71.dll 0x6d7c0000 - 0x6da07000 C:\Program Files\Java\jre1.6.0_01\bin\client\jvm.dll 0x76b40000 - 0x76b6d000 C:\WINDOWS\system32\WINMM.dll 0x5cd70000 - 0x5cd77000 C:\WINDOWS\system32\serwvdrv.dll 0x5b0a0000 - 0x5b0a7000 C:\WINDOWS\system32\umdmxfrm.dll 0x6d310000 - 0x6d318000 C:\Program Files\Java\jre1.6.0_01\bin\hpi.dll 0x76bf0000 - 0x76bfb000 C:\WINDOWS\system32\PSAPI.DLL 0x6d770000 - 0x6d77c000 C:\Program Files\Java\jre1.6.0_01\bin\verify.dll 0x6d3b0000 - 0x6d3cf000 C:\Program Files\Java\jre1.6.0_01\bin\java.dll 0x6d7b0000 - 0x6d7bf000 C:\Program Files\Java\jre1.6.0_01\bin\zip.dll 0x10000000 - 0x10012000 C:\Documents and Settings\Alex\workspace\MediaServer\rxtxSerial.dll 0x73d90000 - 0x73db7000 C:\WINDOWS\system32\crtdll.dll VM Arguments: jvm_args: -Djava.library.path=C:\Documents and Settings\Alex\workspace\MediaServer java_command: com.bjt.media.server.DigitoolConnection Launcher Type: SUN_STANDARD Environment Variables: CLASSPATH=.;C:\Program Files\Java\j2re1.4.2_07\lib\ext\QTJava.zip PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\wbem;c:\applications\php;C:\Program Files\MATLAB\R2006a\bin\win32;C:\Roger\Projects\UAV\Bin\Debug;C:\Program Files\Microsoft SQL Server\80\Tools\Binn\;c:\Program Files\Microsoft SQL Server\90\Tools\binn\;C:\Program Files\QuickTime\QTSystem\;C:\Pfps\system;C:\Program Files\Java\jdk1.6.0_01\bin;C:\Program Files\Java\jdk1.6.0_01\jre\bin USERNAME=Alex OS=Windows_NT PROCESSOR_IDENTIFIER=x86 Family 15 Model 4 Stepping 1, GenuineIntel --------------- S Y S T E M --------------- OS: Windows XP Build 2600 Service Pack 2 CPU:total 1 family 15, cmov, cx8, fxsr, mmx, sse, sse2 Memory: 4k page, physical 1046508k(275288k free), swap 2522816k(1909176k free) vm_info: Java HotSpot(TM) Client VM (1.6.0_01-b06) for windows-x86, built on Mar 14 2007 00:24:02 by "java_re" with unknown MS VC++:1310 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070604/c87ae1f0/attachment-0005.html From alwyn.schoeman at gmail.com Tue Jun 5 00:10:19 2007 From: alwyn.schoeman at gmail.com (Alwyn Schoeman) Date: Tue, 5 Jun 2007 08:10:19 +0200 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Hi, I'm using a similar modem. By default rxtx doesn't look for devices that start with ACM, so you need to modify the source code and recompile. Look in RXTXCommDriver and add values for ACM in the registerScannedPorts method in the Linux specific parts. Look for osName.equals("Linux")... On 6/4/07, soop soop wrote: > > Hi Guys, > > Looked through the archives but still cannot figure this out. I have a > Motorola G24 GPRS/GSM modem that I am connecting to my server running > Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not > detecting the port, CommPortIdentifier.getPortIdentifiers(). > > I have added the line to RXTXCommDriver: > > "ttyACM" // for USB Modems > > Rxtx still does not seem to find the port. Is there something I am missing > to make this port visable? > > [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver > [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device > [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control > Model > driver for USB modems and ISDN adapters > > I really need your help as I have moved my server from windows to Linux > and > have been down for a few days because of this .. Thanks so much! > > _________________________________________________________________ > PC Magazine's 2007 editors' choice for best Web mail?award-winning Windows > Live Hotmail. > > http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -- Alwyn Schoeman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/b6cb3053/attachment-0005.html From naranjo.manuel at gmail.com Tue Jun 5 06:48:45 2007 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Tue, 05 Jun 2007 09:48:45 -0300 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> References: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Message-ID: <46655BAD.7010501@gmail.com> That's right, an easier solution is creating symlinks to acm. For example make ttyS70 to 79 point to ACM0 to 9 and that will help you a lot, and doesn't even require compile. > Hi, > > I'm using a similar modem. By default rxtx doesn't look for devices > that start with ACM, so you need to modify the > source code and recompile. > > Look in RXTXCommDriver and add values for ACM in the > registerScannedPorts method in the Linux specific parts. Look for > osName.equals("Linux")... > From juanemc2 at gmail.com Tue Jun 5 07:02:43 2007 From: juanemc2 at gmail.com (Juan) Date: Tue, 5 Jun 2007 10:02:43 -0300 Subject: [Rxtx] Problems with Epson TMU220B POSPrinter using XON/XOFF Flow Control and rxtx jar and dll's with the serial port. Message-ID: Hi!, I?m having trouble printing to the serial port using the latest version of rxtx jar and dll's with an Epson POSPrinter. I`ve switched the printer to work with XON/XOFF Flow Control and have watched the serial port to be sure the printer is sending the XON XOFF stop and go characters. I`ve setted the port like this: CommPortIdentifier commPortIdentifier = CommPortIdentifier.* getPortIdentifier*(_portName); SerialPort serialPort = (SerialPort)commPortIdentifier.open(*this*.getClass().getName(), 2000); serialPort.setSerialPortParams(_baudRate, _dataBits, _stopBits, _parity); serialPort.setFlowControlMode( SerialPort.*FLOWCONTROL_XONXOFF_IN* | SerialPort.*FLOWCONTROL_XONXOFF_OUT*); where the baudRate is 9600 the dataBits is 8 the stopBits is 1 and the parity is 0 It seems as the library isn`t taking into account the XON XOFF setting. I would like to know if I`m setting correctly the Flow Control and if you had had any experiences using XON XOFF flow control and could give me some help to solve my problem. I`m very thankful in advance, Yours, Juan Polero -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/b080995a/attachment-0005.html From ehdez.correo at gmail.com Tue Jun 5 07:12:53 2007 From: ehdez.correo at gmail.com (=?ISO-8859-1?Q?Enrique_Hern=E1ndez?=) Date: Tue, 5 Jun 2007 09:12:53 -0400 Subject: [Rxtx] problem with rxtx Message-ID: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Hello: I doing a simple test to show the serial ports. This is the code: import java.util.Enumeration; import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; public class Show { private Enumeration portList; private CommPortIdentifier portId; private SerialPort port; /** Creates a new instance of Show */ public Show() { } public static void main(String args[]){ Show show = new Show(); show.portList = CommPortIdentifier.getPortIdentifiers(); String tPort = ""; System.out.println("========================================="); while(show.portList.hasMoreElements()){ show.portId = (CommPortIdentifier)show.portList.nextElement(); if(show.portId.getPortType() == CommPortIdentifier.PORT_SERIAL) tPort = "Serial"; else tPort = "Parallel"; System.out.println(show.portId.getName() + " " + tPort); } } } whit The problem is that this code not show the serial ports, this show the no use serial ports. I want to connect whit the modem but when windows open and connect the modem my application don't see the port(COMM3) when it is connect. what I can do? Is that the correct way to know the ports? thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/eedd744b/attachment-0005.html From ehdez.correo at gmail.com Tue Jun 5 07:42:13 2007 From: ehdez.correo at gmail.com (=?ISO-8859-1?Q?Enrique_Hern=E1ndez?=) Date: Tue, 5 Jun 2007 09:42:13 -0400 Subject: [Rxtx] serial port Message-ID: <4a814e1f0706050642p4ce9ac7bka80f9479c524c5ea@mail.gmail.com> Hello: How I can ask to the port what device is connect and information about this device. thanks. bye. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/4d10d26a/attachment-0005.html From supsoop at hotmail.com Tue Jun 5 09:29:00 2007 From: supsoop at hotmail.com (soop soop) Date: Tue, 05 Jun 2007 15:29:00 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Message-ID: Hi Guys, Thanks for all your help. I found the problem. I created a user, Tomcat55, for my tomcat but it did not belong to any group. I then added this user to dialout group to have access to the device ttyACM0. Works perfectly! Again permissions was the issue. This also seems to be persistent as a server reboot does not effect the access. Cheers! >From: "Alwyn Schoeman" >Reply-To: RXTX Developers and Users >To: "RXTX Developers and Users" >Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >Date: Tue, 5 Jun 2007 08:10:19 +0200 > >Hi, > >I'm using a similar modem. By default rxtx doesn't look for devices that >start with ACM, so you need to modify the >source code and recompile. > >Look in RXTXCommDriver and add values for ACM in the registerScannedPorts >method in the Linux specific parts. Look for osName.equals("Linux")... > >On 6/4/07, soop soop wrote: >> >>Hi Guys, >> >>Looked through the archives but still cannot figure this out. I have a >>Motorola G24 GPRS/GSM modem that I am connecting to my server running >>Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not >>detecting the port, CommPortIdentifier.getPortIdentifiers(). >> >>I have added the line to RXTXCommDriver: >> >>"ttyACM" // for USB Modems >> >>Rxtx still does not seem to find the port. Is there something I am missing >>to make this port visable? >> >>[ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver >>[ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device >>[ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control >>Model >>driver for USB modems and ISDN adapters >> >>I really need your help as I have moved my server from windows to Linux >>and >>have been down for a few days because of this .. Thanks so much! >> >>_________________________________________________________________ >>PC Magazine's 2007 editors' choice for best Web mail—award-winning Windows >>Live Hotmail. >> >>http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 >> >> >>_______________________________________________ >>Rxtx mailing list >>Rxtx at qbang.org >>http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > >-- >Alwyn Schoeman >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ Need a break? Find your escape route with Live Search Maps. http://maps.live.com/default.aspx?ss=Restaurants~Hotels~Amusement%20Park&cp=33.832922~-117.915659&style=r&lvl=13&tilt=-90&dir=0&alt=-1000&scene=1118863&encType=1&FORM=MGAC01 From netbeans at gatworks.com Tue Jun 5 09:42:31 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 11:42:31 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <46658467.20101@gatworks.com> soop soop wrote: > > Hi Guys, > > Thanks for all your help. I found the problem. I created a user, > Tomcat55, for my tomcat but it did not belong to any group. I then added Look at man pages for the program udev. From tjarvi at qbang.org Tue Jun 5 18:18:17 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Jun 2007 18:18:17 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Message-ID: On Tue, 5 Jun 2007, Enrique Hern?ndez wrote: > The problem is that this code not show the serial ports, this show the no > use serial ports. I want to connect whit the modem but when windows open and > connect the modem my application don't see the port(COMM3) when it is > connect. > what I can do? > Is that the correct way to know the ports? > Hello, We may have problems understanding each other. On windows, the port will not be an available serial port if another application has the port open. That is just how the library behaves. If you can not see the port in the enumerated list, you could not open it. Also note that enumeration only happens once. If you add a port such as a new USB dongle, the port will not be visible until the next time your application runs. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Tue Jun 5 18:45:01 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 20:45:01 -0400 Subject: [Rxtx] problem with rxtx In-Reply-To: References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Message-ID: <4666038D.8090700@gatworks.com> Trent Jarvi wrote: > > > Also note that enumeration only happens once. If you add a port such as > a new USB dongle, the port will not be visible until the next time your > application runs. Is this written in stone ? somewhere? From tjarvi at qbang.org Tue Jun 5 18:54:36 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Jun 2007 18:54:36 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <4666038D.8090700@gatworks.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> Message-ID: On Tue, 5 Jun 2007, Uncle George wrote: > Trent Jarvi wrote: >> >> >> Also note that enumeration only happens once. If you add a port such as >> a new USB dongle, the port will not be visible until the next time your >> application runs. > > Is this written in stone ? somewhere? It is just the current behavior. There is nothing preventing a fix that allows reenumeration. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Tue Jun 5 19:55:19 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 21:55:19 -0400 Subject: [Rxtx] problem with rxtx In-Reply-To: References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> Message-ID: <46661407.4020308@gatworks.com> >> Is this written in stone ? somewhere? > > It is just the current behavior. There is nothing preventing a fix that > allows reenumeration. With usb, ..... , things come and go. Seems a shame that you have to kill application to get at the device u just plugged in. From joachim at buechse.ch Wed Jun 6 01:50:06 2007 From: joachim at buechse.ch (Joachim Buechse) Date: Wed, 6 Jun 2007 09:50:06 +0200 Subject: [Rxtx] problem with rxtx In-Reply-To: <46661407.4020308@gatworks.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> <46661407.4020308@gatworks.com> Message-ID: <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> On MacOS RXTX's enumeration handling is more flexible. It will find new ports that are added during the lifetime of the application. But this is inherently incompatible with suns javax.comm implementation... Regards, Joachim On 06.06.2007, at 03:55, Uncle George wrote: > >>> Is this written in stone ? somewhere? >> >> It is just the current behavior. There is nothing preventing a >> fix that >> allows reenumeration. > > With usb, ..... , things come and go. Seems a shame that you have to > kill application to get at the device u just plugged in. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Jun 6 06:06:48 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Jun 2007 06:06:48 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> <46661407.4020308@gatworks.com> <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> Message-ID: Sun's javax.comm is not a major concern going forward. As long as we do not break old applications using rxtx, I see no reason to limit rxtx to that convention. We have already rejected version 3 from Sun as a dead end and limited our compatability to version 2. That does not mean we will not try to work with Sun and others but the current javax.comm convention (v3) is not a well conceived path. There has been discussion about doing a JSR which is one valid option. On Wed, 6 Jun 2007, Joachim Buechse wrote: > On MacOS RXTX's enumeration handling is more flexible. It will find > new ports that are added during the lifetime of the application. But > this is inherently incompatible with suns javax.comm implementation... > > Regards, > Joachim > > On 06.06.2007, at 03:55, Uncle George wrote: > >> >>>> Is this written in stone ? somewhere? >>> >>> It is just the current behavior. There is nothing preventing a >>> fix that >>> allows reenumeration. >> >> With usb, ..... , things come and go. Seems a shame that you have to >> kill application to get at the device u just plugged in. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From yvespielusenet at free.fr Wed Jun 6 08:46:35 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 16:46:35 +0200 Subject: [Rxtx] [PARALLEL] resource in use Message-ID: <1181141195.3407.20.camel@localhost.localdomain> Hello, I want to use rxtx in my application. I haveto send data to a very old printer (which have a drum and hammers http://perso.orange.fr/tiie/page00010017.html) This is printer is connecter with centronics. It works well but, while it's writting and I putthe printer off-line, after about 45 seconds, I have this error : ------------------------------------- java.io.IOException: La ressource demand?e est en cours d'utilisation. in writeArray at gnu.io.LPRPort.writeArray(Native Method) at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:292) at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:161) at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:156) at mce.buffer.bufferManager.BufferManager$PrintBuffer.run(BufferManager.java:141) The IOexception means "The wanted resource is in use" ------------------------------------- Here is the line 141 of BufferManager : ------------------------------------- while(send){ try{ fos.write(bb); <=== line 141 send = false; } catch(Exception e){ javax.swing.JOptionPane.showMessageDialog(null, "Erreur d'envoie. Veuillez cliquer sur OK pour relancer l'impression de la vignette.\nV?rifiez votre impression !", "Erreur d'envoie", javax.swing.JOptionPane.WARNING_MESSAGE); e.printStackTrace(System.err); System.err.flush(); System.out.println(e); send = true; } } -------------------------------- 'fos' is an outputstream which contains the rxtx stream (this.os is the rxtx outputstream) : -------------------------------- public void write(byte[] bb) throws IOException{ this.write(bb, 0, bb.length); } public void write(byte[] bb, int off, int len) throws IOException{ while(!imp1.isPrinterSelected() || !imp2.isPrinterSelected()){ } this.os.write(bb, off, len); } -------------------------------- Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( can you help me ? thank you :) -- yves piel From yvespielusenet at free.fr Wed Jun 6 09:11:15 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 17:11:15 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181141195.3407.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> Message-ID: <1181142675.3407.23.camel@localhost.localdomain> I forgot to tell that It's under windows XP and java 1.5. Le mercredi 06 juin 2007 ? 16:46 +0200, yves pielusenet a ?crit : > Hello, > I want to use rxtx in my application. I haveto send data to a very old > printer (which have a drum and hammers > http://perso.orange.fr/tiie/page00010017.html) > This is printer is connecter with centronics. It works well but, while > it's writting and I putthe printer off-line, after about 45 seconds, I > have this error : > ------------------------------------- > java.io.IOException: La ressource demand?e est en cours d'utilisation. > in writeArray > at gnu.io.LPRPort.writeArray(Native Method) > at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:292) > at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:161) > at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:156) > at mce.buffer.bufferManager.BufferManager$PrintBuffer.run(BufferManager.java:141) > > The IOexception means "The wanted resource is in use" > ------------------------------------- > > Here is the line 141 of BufferManager : > > ------------------------------------- > while(send){ > try{ > fos.write(bb); <=== line 141 > send = false; > } > catch(Exception e){ > javax.swing.JOptionPane.showMessageDialog(null, "Erreur d'envoie. Veuillez cliquer sur OK pour relancer l'impression de la vignette.\nV?rifiez votre impression !", "Erreur d'envoie", javax.swing.JOptionPane.WARNING_MESSAGE); > e.printStackTrace(System.err); > System.err.flush(); > System.out.println(e); > send = true; > } > } > -------------------------------- > 'fos' is an outputstream which contains the rxtx stream (this.os is the rxtx outputstream) : > > -------------------------------- > public void write(byte[] bb) throws IOException{ > this.write(bb, 0, bb.length); > } > public void write(byte[] bb, int off, int len) throws IOException{ > while(!imp1.isPrinterSelected() || !imp2.isPrinterSelected()){ > } > this.os.write(bb, off, len); > } > -------------------------------- > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > can you help me ? > > thank you :) > From netbeans at gatworks.com Wed Jun 6 09:21:46 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 11:21:46 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181141195.3407.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> Message-ID: <4666D10A.8000507@gatworks.com> } > -------------------------------- > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > can you help me ? > > thank you :) > windoz or linux? ( I guess windoz ) for windoz, there appears to be a timeout ( as Comments suggest ) of about 40seconds. > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } for linux, there is no implied timeout. > if( write( fd, bytes, count ) < 0 ) > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); From netbeans at gatworks.com Wed Jun 6 09:39:41 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 11:39:41 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666D10A.8000507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> Message-ID: <4666D53D.90000@gatworks.com> Uncle George wrote: > } >> -------------------------------- >> >> Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( >> >> can you help me ? From reading the code, I can see your concern. And it appears you are correct, because some of the data will be sent to the OS printer buffers, and then it will refuse to accept anymore. Unfortunately, writeArray does not return the num of characters written :{ So application has no idea to how many characters were accepted by the OS. I dont do windoz, so I cant say with absolute certainty what windoz will do with an off-line condition. If you have the source, and can compile, then maybe u can increase the loop count to hit 4hours? From yvespielusenet at free.fr Wed Jun 6 09:53:25 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 17:53:25 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666D10A.8000507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> Message-ID: <1181145205.3407.35.camel@localhost.localdomain> Thank you for your explanation :) This timeout comes when no data has been send to the printer after 40seconds if I well understand. But why there is such a timeout ? If I setthe printer offline while it's printing I mustn't have an exception. I don't understand why the "printer should solv all problems like buffer full" in 40 seconds. If I pause the printer the buffer will not be emptied, isn't it ? I not very familiar with C/C++, but it seem that the exception is thrown only when countWritten == 0, that means no data at all has been sent. So Is my code is good since when I intercept this exception I send all my buffer again. There is no way that the printer receive two times same bytes ? thanks ps: yes the application is running on windows XP since I developpe under Debian Le mercredi 06 juin 2007 ? 11:21 -0400, Uncle George a ?crit : > } > > -------------------------------- > > > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > > > can you help me ? > > > > thank you :) > > > > windoz or linux? ( I guess windoz ) > > for windoz, there appears to be a timeout ( as Comments suggest ) of > about 40seconds. > > while( count > 0 ){ > > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > > /* > > this are 20 * 2 seconds, in this time a printer (or other parallel device) > > should solv all problems like buffer full, etc > > */ > > if(errorCount++ < 20){ > > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > > continue; > > } > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > for linux, there is no implied timeout. > > if( write( fd, bytes, count ) < 0 ) > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Wed Jun 6 10:34:24 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 12:34:24 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181145205.3407.35.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> Message-ID: <4666E210.30507@gatworks.com> yves pielusenet wrote: > Thank you for your explanation :) > This timeout comes when no data has been send to the printer after > 40seconds if I well understand. But why there is such a timeout ? If I > setthe printer offline while it's printing I mustn't have an exception. > I don't understand why the "printer should solv all problems like buffer > full" in 40 seconds. If I pause the printer the buffer will not be > emptied, isn't it ? > > I not very familiar with C/C++, but it seem that the exception is thrown > only when countWritten == 0, that means no data at all has been sent. So > Is my code is good since when I intercept this exception I send all my > buffer again. There is no way that the printer receive two times same > bytes ? More technically, the function call returns and reports that 0 characters was written in this call. when 0 characters are written, it will check how many times 0 characters was written. If it has tried LESS than 20 times(errorCount), it will sleep() and try to write again. After 20 times, it wont sleep, but throw you the exception. Now suppose you are writing a 120 character line. you off-lined/paused your printer. The OS has room for 80 more characters in it's printer buffer. The WriteFile() will have a char count of 120, but on return the countWritten = 80. You still have 40 more characters to print. Since countWritten != 0, the counters: bytes += countWritten; count -= countWritten; get updated, and the Writefile now has a count of 40 characters. Since the printer is off-line, the countwritten is 0. And so the loop continues, till 40 seconds is up. As to why it is this way, i dont know ( not a windoz maven ); Also the sleep(20) in the loop is not so intuitive to suggest 2 seconds of sleep. I would have guessed 20seconds, or 20milliseconds. But go figure. BTW: Since your computer sends you error messages in French, does it curse in English? :)))) From yvespielusenet at free.fr Thu Jun 7 02:27:44 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Thu, 07 Jun 2007 10:27:44 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666E210.30507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> Message-ID: <1181204864.3501.10.camel@localhost.localdomain> Maybe in my case I should re-compile rxtx and change the code. Instead of send an exception I should display a dialog box to ask if it's printer problem or if it should trie to send bytes. Something like : while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } if(displayDialogBox("Try again to send datas ??")){ errorCount = 0; } else{ throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } } Le mercredi 06 juin 2007 ? 12:34 -0400, Uncle George a ?crit : > yves pielusenet wrote: > > Thank you for your explanation :) > > This timeout comes when no data has been send to the printer after > > 40seconds if I well understand. But why there is such a timeout ? If I > > setthe printer offline while it's printing I mustn't have an exception. > > I don't understand why the "printer should solv all problems like buffer > > full" in 40 seconds. If I pause the printer the buffer will not be > > emptied, isn't it ? > > > > I not very familiar with C/C++, but it seem that the exception is thrown > > only when countWritten == 0, that means no data at all has been sent. So > > Is my code is good since when I intercept this exception I send all my > > buffer again. There is no way that the printer receive two times same > > bytes ? > More technically, the function call returns and reports that 0 > characters was written in this call. > when 0 characters are written, it will check how many times 0 characters > was written. If it has tried LESS than 20 times(errorCount), it will > sleep() and try to write again. > After 20 times, it wont sleep, but throw you the exception. > > Now suppose you are writing a 120 character line. you off-lined/paused > your printer. The OS has room for 80 more characters in it's printer > buffer. The WriteFile() will have a char count of 120, but on return the > countWritten = 80. You still have 40 more characters to print. > Since countWritten != 0, the counters: > bytes += countWritten; > count -= countWritten; > get updated, and the Writefile now has a count of 40 characters. Since > the printer is off-line, the countwritten is 0. And so the loop > continues, till 40 seconds is up. > > As to why it is this way, i dont know ( not a windoz maven ); > Also the sleep(20) in the loop is not so intuitive to suggest 2 seconds > of sleep. I would have guessed 20seconds, or 20milliseconds. But go figure. > > BTW: Since your computer sends you error messages in French, does it > curse in English? :)))) > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 06:11:43 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 08:11:43 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181204864.3501.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> Message-ID: <4667F5FF.8070903@gatworks.com> your suggestion appears good. I dont know what displayDialogBox exactly will do, so all I can say it that it looks good. But I'd like to wait 10min before first dialog box And a 5 min wait for every dialog box there after. And since these are custom solution/choices, maybe a more exact explanation of what the issue is. if(errorCount++ < 300){ // wait 10min ( 10min * 60sec / 2 ) Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } if(displayDialogBox("Printer has Paused. Retry sending data?")){ errorCount = 150; // Wait for 5 min thereafter continue; } > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } yves pielusenet wrote: > Maybe in my case I should re-compile rxtx and change the code. Instead > of send an exception I should display a dialog box to ask if it's > printer problem or if it should trie to send bytes. Something like : > > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > > if(displayDialogBox("Try again to send datas ??")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > } > From yvespielusenet at free.fr Thu Jun 7 07:17:21 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Thu, 07 Jun 2007 15:17:21 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4667F5FF.8070903@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <4667F5FF.8070903@gatworks.com> Message-ID: <1181222241.3501.20.camel@localhost.localdomain> thank you :) 'displayDialogBox()' I think doesn't exist. It was just for the example :) But I think It should not be so complicated to display a dialog box under windows with YES/NO buttons. When yes is clicked it return 0 other it returns 1. Le jeudi 07 juin 2007 ? 08:11 -0400, Uncle George a ?crit : > your suggestion appears good. I dont know what displayDialogBox exactly > will do, so all I can say it that it looks good. > > But I'd like to wait 10min before first dialog box And a 5 min wait for > every dialog box there after. And since these are custom > solution/choices, maybe a more exact explanation of what the issue is. > > if(errorCount++ < 300){ // wait 10min ( 10min * 60sec / 2 ) > Sleep( 20 ); /* make a small pause to execute all other requests > in all other threads */ > continue; > } > > if(displayDialogBox("Printer has Paused. Retry sending data?")){ > errorCount = 150; // Wait for 5 min thereafter > continue; > } > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > > yves pielusenet wrote: > > Maybe in my case I should re-compile rxtx and change the code. Instead > > of send an exception I should display a dialog box to ask if it's > > printer problem or if it should trie to send bytes. Something like : > > > > while( count > 0 ){ > > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > > /* > > this are 20 * 2 seconds, in this time a printer (or other parallel device) > > should solv all problems like buffer full, etc > > */ > > if(errorCount++ < 20){ > > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > > continue; > > } > > > > if(displayDialogBox("Try again to send datas ??")){ > > errorCount = 0; > > } > > else{ > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > } > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 07:41:43 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 09:41:43 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181222241.3501.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <4667F5FF.8070903@gatworks.com> <1181222241.3501.20.camel@localhost.localdomain> Message-ID: <46680B17.8050109@gatworks.com> yves pielusenet wrote: > thank you :) > 'displayDialogBox()' I think doesn't exist. It was just for the > example :) too bad. Good luck. From rtrout at webbresearch.com Thu Jun 7 11:23:04 2007 From: rtrout at webbresearch.com (Robert Trout) Date: Thu, 07 Jun 2007 13:23:04 -0400 Subject: [Rxtx] Disconnected PortServer TS causes Java to hang Message-ID: <1181236984.14186.33.camel@sisyphus.DinkumSoftware.com> I'm running Linux with sun's Java 1.4.2, Java comm API 2.0, RXTX 2.0-7pre1, and the RealPort digi driver. "/dev/ttyrp00" is a RealPort device. My Java application never returns from a ComPortIdentifier.getPortIdentifier("/dev/ttyrp00") call while the Digi PortServer TS 4 is disconnected from the network. If I later re-connect the PortServer, the call returns about 30 seconds later (it's like a serial port read or write is blocking until the PortServer is re- connected). With the PortServer disconnected, minicom immediately responds with "cannot open /dev/ttyrp00: No such file or directory". I would like my Java application to behave similarly. That is, respond with an error condition instead of hanging when the PortServer is not connected. Since minicom and Java behave differently, I think this "hanging" behavior may be due to RXTX or Java? Has anyone had a similar issue? Solutions? Suggestions? Thanks, Robert From vicnevicne at gmail.com Thu Jun 7 12:16:02 2007 From: vicnevicne at gmail.com (Vicne) Date: Thu, 07 Jun 2007 20:16:02 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181204864.3501.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> Message-ID: <46684B62.7080802@gmail.com> yves pielusenet wrote: > Maybe in my case I should re-compile rxtx and change the code. Instead > of send an exception I should display a dialog box to ask if it's > printer problem or if it should trie to send bytes. Something like : > > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > > if(displayDialogBox("Try again to send datas ??")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > } > Sorry to step in without a specific solution to your problem, but I wanted to share my feeling regarding this proposal. AFAIK, it's generally considered bad practice to pop-up a prompt from a library. The main reason is that in general use, you can't guarantee that someone is actually present behind the console. Imagine a print server in a machine room, connected to a park of printers. In that case, when one printer fails, the logical behaviour would be to use an other one. If you change RxTx the way you propose, the printer queue will simply be stuck with a useless "Try again to send data ?" prompt until an administrator opens a remote connection to the print server's console and clicks "no". Second, it would create a dependency upon the existence of a graphical console (if you go the graphical "dialogBox" way). On many applications (typically server or embedded ones), the JVM is "headless" and if you try to pop-up a dialog, your app would throw an exception (at best) or just wouldn't display the prompt anywhere... Going the "text console" way is not more reliable, because on graphical environments, the text console is hidden unless explicitly requested. My advice would be to think again and find another solution. Ideas are : - make the number of retries a parameter so that you can tune it to what you think is reasonable - throw a more specific exception when the number of retries has been reached, so that a specific prompt can be shown at a higher level Anyway, if you feel that the prompt is the way to go in your case, I would at least make that prompt conditional. The least intrusive way would probably be using a system property, like if("true".equals(System.getProperty("org.rxtx.usePrompt")) && displayDialogBox("Retry sending data ?")){ errorCount = 0; } else{ throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } By default, the behaviour would remain as it is now, but you could force the prompts by defining the property at VM launch if desired. (for example : java.exe -Dorg.rxtx.usePrompt=true myApp) Also, you seemed to say you wanted the printer to start again exactly where is stopped. It would indeed be the best way when the printer is put offline for a few seconds. On the other hand, if the printer is turned off (or the printer runs out of paper, or someone steps on the mains cable), then the only way to go back to a "stable" situation would be by printing the item (page, label, etc.) again from scratch... Just my two cents. Vicne PS : By the way, the dialog box thing is very platform dependant on the C-side, and I think the simplest way would probably be to bridge it to a Java call where you can implement it like you proposed : public boolean displayDialogBox(prompt) { return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); } From netbeans at gatworks.com Thu Jun 7 14:08:24 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 16:08:24 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46684B62.7080802@gmail.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> Message-ID: <466865B8.4060004@gatworks.com> My feeling is that the code that was suggested was for his environs ( his shop ). The issue here is that after a 40+ second wait, an exception will be thrown. But you really dont have a way of 'cancelling' all the WriteFiles() that have already occured before the exception so that your writeArray and the Commapi can backtrack to a position in which they are in sync. The main ( really mine ) concern is not to lose data, or replicate data. After 40seconds, 300 seconds, 55min, no matter how long, data should not be lost or duplicated. But as soon as the exception is thrown, that possibility exists. Maybe an event should be thrown instead? Vicne wrote: > yves pielusenet wrote: >> Maybe in my case I should re-compile rxtx and change the code. Instead >> of send an exception I should display a dialog box to ask if it's >> printer problem or if it should trie to send bytes. Something like : >> >> while( count > 0 ){ >> if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ >> /* >> this are 20 * 2 seconds, in this time a printer (or other parallel device) >> should solv all problems like buffer full, etc >> */ >> if(errorCount++ < 20){ >> Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ >> continue; >> } >> >> if(displayDialogBox("Try again to send datas ??")){ >> errorCount = 0; >> } >> else{ >> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >> break; >> } >> } >> > > Sorry to step in without a specific solution to your problem, but I > wanted to share my feeling regarding this proposal. AFAIK, it's > generally considered bad practice to pop-up a prompt from a library. > The main reason is that in general use, you can't guarantee that > someone is actually present behind the console. Imagine a print server > in a machine room, connected to a park of printers. In that case, when > one printer fails, the logical behaviour would be to use an other one. > If you change RxTx the way you propose, the printer queue will simply be > stuck with a useless "Try again to send data ?" prompt until an > administrator opens a remote connection to the print server's console > and clicks "no". > Second, it would create a dependency upon the existence of a > graphical console (if you go the graphical "dialogBox" way). On many > applications (typically server or embedded ones), the JVM is "headless" > and if you try to pop-up a dialog, your app would throw an exception (at > best) or just wouldn't display the prompt anywhere... Going the "text > console" way is not more reliable, because on graphical environments, > the text console is hidden unless explicitly requested. > > My advice would be to think again and find another solution. Ideas are : > - make the number of retries a parameter so that you can tune it to what > you think is reasonable > - throw a more specific exception when the number of retries has been > reached, so that a specific prompt can be shown at a higher level > > Anyway, if you feel that the prompt is the way to go in your case, I > would at least make that prompt conditional. The least intrusive way > would probably be using a system property, like > > if("true".equals(System.getProperty("org.rxtx.usePrompt")) > && displayDialogBox("Retry sending data ?")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > > > By default, the behaviour would remain as it is now, but you could > force the prompts by defining the property at VM launch if desired. (for > example : java.exe -Dorg.rxtx.usePrompt=true myApp) > > > Also, you seemed to say you wanted the printer to start again > exactly where is stopped. It would indeed be the best way when the > printer is put offline for a few seconds. On the other hand, if the > printer is turned off (or the printer runs out of paper, or someone > steps on the mains cable), then the only way to go back to a "stable" > situation would be by printing the item (page, label, etc.) again from > scratch... > > > Just my two cents. > > > Vicne > > PS : By the way, the dialog box thing is very platform dependant on the > C-side, and I think the simplest way would probably be to bridge it to a > Java call where you can implement it like you proposed : > > public boolean displayDialogBox(prompt) { > return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", > JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); > } > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Thu Jun 7 17:48:11 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 Jun 2007 17:48:11 -0600 (MDT) Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <466865B8.4060004@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> Message-ID: An event is possible. I'm amazed this is the largest problem encountered while using the parallel code. How would the write ever exit if we throw events? Isn't this going to lead to hung applications? On Thu, 7 Jun 2007, Uncle George wrote: > My feeling is that the code that was suggested was for his environs ( > his shop ). > > The issue here is that after a 40+ second wait, an exception will be > thrown. But you really dont have a way of 'cancelling' all the > WriteFiles() that have already occured before the exception so that your > writeArray and the Commapi can backtrack to a position in which they are > in sync. > > The main ( really mine ) concern is not to lose data, or replicate data. > After 40seconds, 300 seconds, 55min, no matter how long, data should > not be lost or duplicated. But as soon as the exception is thrown, that > possibility exists. > > Maybe an event should be thrown instead? > > Vicne wrote: >> yves pielusenet wrote: >>> Maybe in my case I should re-compile rxtx and change the code. Instead >>> of send an exception I should display a dialog box to ask if it's >>> printer problem or if it should trie to send bytes. Something like : >>> >>> while( count > 0 ){ >>> if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ >>> /* >>> this are 20 * 2 seconds, in this time a printer (or other parallel device) >>> should solv all problems like buffer full, etc >>> */ >>> if(errorCount++ < 20){ >>> Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ >>> continue; >>> } >>> >>> if(displayDialogBox("Try again to send datas ??")){ >>> errorCount = 0; >>> } >>> else{ >>> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >>> break; >>> } >>> } >>> >> >> Sorry to step in without a specific solution to your problem, but I >> wanted to share my feeling regarding this proposal. AFAIK, it's >> generally considered bad practice to pop-up a prompt from a library. >> The main reason is that in general use, you can't guarantee that >> someone is actually present behind the console. Imagine a print server >> in a machine room, connected to a park of printers. In that case, when >> one printer fails, the logical behaviour would be to use an other one. >> If you change RxTx the way you propose, the printer queue will simply be >> stuck with a useless "Try again to send data ?" prompt until an >> administrator opens a remote connection to the print server's console >> and clicks "no". >> Second, it would create a dependency upon the existence of a >> graphical console (if you go the graphical "dialogBox" way). On many >> applications (typically server or embedded ones), the JVM is "headless" >> and if you try to pop-up a dialog, your app would throw an exception (at >> best) or just wouldn't display the prompt anywhere... Going the "text >> console" way is not more reliable, because on graphical environments, >> the text console is hidden unless explicitly requested. >> >> My advice would be to think again and find another solution. Ideas are : >> - make the number of retries a parameter so that you can tune it to what >> you think is reasonable >> - throw a more specific exception when the number of retries has been >> reached, so that a specific prompt can be shown at a higher level >> >> Anyway, if you feel that the prompt is the way to go in your case, I >> would at least make that prompt conditional. The least intrusive way >> would probably be using a system property, like >> >> if("true".equals(System.getProperty("org.rxtx.usePrompt")) >> && displayDialogBox("Retry sending data ?")){ >> errorCount = 0; >> } >> else{ >> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >> break; >> } >> >> >> By default, the behaviour would remain as it is now, but you could >> force the prompts by defining the property at VM launch if desired. (for >> example : java.exe -Dorg.rxtx.usePrompt=true myApp) >> >> >> Also, you seemed to say you wanted the printer to start again >> exactly where is stopped. It would indeed be the best way when the >> printer is put offline for a few seconds. On the other hand, if the >> printer is turned off (or the printer runs out of paper, or someone >> steps on the mains cable), then the only way to go back to a "stable" >> situation would be by printing the item (page, label, etc.) again from >> scratch... >> >> >> Just my two cents. >> >> >> Vicne >> >> PS : By the way, the dialog box thing is very platform dependant on the >> C-side, and I think the simplest way would probably be to bridge it to a >> Java call where you can implement it like you proposed : >> >> public boolean displayDialogBox(prompt) { >> return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", >> JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); >> } >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 19:18:51 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 21:18:51 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> Message-ID: <4668AE7B.3060409@gatworks.com> The UNIX version of writeArray is not too great either. It is possible that the write will only process some of the bytes. #else if( write( fd, bytes, count ) < 0 ) throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); #endif -------------------------------- Maybe it might be better to have the native function inform the caller of the # of characters written, then the commapi/output-buffer can be modified to reflect the #of chars written. If an exception is to be thrown, for too many loops of chars written == 0, then exception wont affect the state of the output buffer. Then a ParallelPort.restart() can be called to resume printing whats in the buffer. Trent Jarvi wrote: > An event is possible. I'm amazed this is the largest problem encountered > while using the parallel code. > > How would the write ever exit if we throw events? Isn't this going to > lead to hung applications? Sure. If you dont time out, then there is nothing that will force an EXIT from the write(). Issue is what has the OS done with the write. > > On Thu, 7 Jun 2007, Uncle George wrote: > >> My feeling is that the code that was suggested was for his environs ( >> his shop ). From yvespielusenet at free.fr Fri Jun 8 01:09:01 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Fri, 08 Jun 2007 09:09:01 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4668AE7B.3060409@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> Message-ID: <1181286541.3674.10.camel@localhost.localdomain> It is not possible that the rxtx java method write(byte[], int offset, int length) return anint which contains the number of byte really send to the printer instead of an exception ? So this is the programm which will see if all bytes have been sent. If not it can retry to send the unsended bytes. -------------------------------------------------------- int sended = 0; while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ sended += countWritten; /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } return sended; /*throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break;*/ } ... ... return countWritten; ------------------------------------------------ Le jeudi 07 juin 2007 ? 21:18 -0400, Uncle George a ?crit : > The UNIX version of writeArray is not too great either. It is possible > that the write will only process some of the bytes. > > #else > if( write( fd, bytes, count ) < 0 ) > throw_java_exception_system_msg( env, IO_EXCEPTION, > "writeArray" ); > #endif > -------------------------------- > > Maybe it might be better to have the native function inform the caller > of the # of characters written, then the commapi/output-buffer can be > modified to reflect the #of chars written. If an exception is to be > thrown, for too many loops of chars written == 0, then exception wont > affect the state of the output buffer. Then a ParallelPort.restart() can > be called to resume printing whats in the buffer. > > > Trent Jarvi wrote: > > An event is possible. I'm amazed this is the largest problem encountered > > while using the parallel code. > > > > How would the write ever exit if we throw events? Isn't this going to > > lead to hung applications? > Sure. If you dont time out, then there is nothing that will force an > EXIT from the write(). Issue is what has the OS done with the write. > > > > On Thu, 7 Jun 2007, Uncle George wrote: > > > >> My feeling is that the code that was suggested was for his environs ( > >> his shop ). > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Fri Jun 8 03:45:00 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 11:45:00 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181286541.3674.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> Message-ID: <20070608094500.GC21069@elberon.bln.de.ingenico.com> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > It is not possible that the rxtx java method write(byte[], int offset, > int length) return anint which contains the number of byte really send > to the printer instead of an exception ? > So this is the programm which will see if all bytes have been sent. If > not it can retry to send the unsended bytes. I think write() is void because in Java people love to do this since OutputStream :-) Of course on such interfaces you cannot implement something nice. If you would have a int write, you would not implement the interface and no applications expecting this interface would link/work/compile. oki, Steffen P.S.: (OT) If you propose not to implement the Java interfaces (especially not on JNI level), maybe optionally offering a wrapper that removes e.g. the write return value and so on to downgrade the powerful classic old POSIX read/write style to the modern limited Java style, then I agree :-) Same for read. Instead of things like "int avialable()" it is more powerful to have an approach as select(2) offers (to guarante the caller that read/write will not block [nothing else make sense anyway IMHO] but may read/write less bytes then requested). The caller gets full control and the higher level protocols can care about timeouts, invoking read in some loops and/or implement retransmission. On top of such an implementation, where everything is controlled, defined, guaranteed and reliable, someone could use an InputStream or OutputStream style interface. Or even better: don't use them at all :) just BTW :-) St. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From yvespielusenet at free.fr Fri Jun 8 05:52:45 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Fri, 08 Jun 2007 13:52:45 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <20070608094500.GC21069@elberon.bln.de.ingenico.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> Message-ID: <1181303565.11203.3.camel@localhost.localdomain> So maybe a better way should be to create a new Exception class which has a method "int getWrittenByte()". So the Exception should be use to send again bytes which are not printed yet. yves Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : > * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > > It is not possible that the rxtx java method write(byte[], int offset, > > int length) return anint which contains the number of byte really send > > to the printer instead of an exception ? > > So this is the programm which will see if all bytes have been sent. If > > not it can retry to send the unsended bytes. > > I think write() is void because in Java people love to do this > since OutputStream :-) Of course on such interfaces you cannot > implement something nice. If you would have a int write, you > would not implement the interface and no applications expecting > this interface would link/work/compile. > > oki, > > Steffen > > P.S.: (OT) > If you propose not to implement the Java interfaces (especially > not on JNI level), maybe optionally offering a wrapper that > removes e.g. the write return value and so on to downgrade the > powerful classic old POSIX read/write style to the modern limited > Java style, then I agree :-) Same for read. Instead of things > like "int avialable()" it is more powerful to have an approach as > select(2) offers (to guarante the caller that read/write will not > block [nothing else make sense anyway IMHO] but may read/write > less bytes then requested). The caller gets full control and the > higher level protocols can care about timeouts, invoking read in > some loops and/or implement retransmission. On top of such an > implementation, where everything is controlled, defined, > guaranteed and reliable, someone could use an InputStream or > OutputStream style interface. Or even better: don't use them at > all :) just BTW :-) > St. > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > 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. > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > 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. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Fri Jun 8 06:46:21 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 08:46:21 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181303565.11203.3.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> Message-ID: <46694F9D.5080501@gatworks.com> It seems that with outputstream.write(b[]), you become terribly uncoordinated as soon as an exception is thrown. Docs do not say what happens to the data. Yet from a practicable point of view, one would like to know if the write was accepted in-full, or rejected before any writes. There are no in betweens, as partial writes are not reportable. So for an outputstream.write(), in order for it to return, the full write request has to be taken, and stored in an internal output buffer. If there is no room, the write() is suspended, till there is room. Or throw's an IOException( "no room in buffer") ; As the select() loop for write reports buffer room avail, then more of the internal buffer is sent to the printer. yves pielusenet wrote: > So maybe a better way should be to create a new Exception class which > has a method "int getWrittenByte()". So the Exception should be use to > send again bytes which are not printed yet. > > yves > > Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : >> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: >>> It is not possible that the rxtx java method write(byte[], int offset, >>> int length) return anint which contains the number of byte really send >>> to the printer instead of an exception ? >>> So this is the programm which will see if all bytes have been sent. If >>> not it can retry to send the unsended bytes. >> I think write() is void because in Java people love to do this >> since OutputStream :-) Of course on such interfaces you cannot >> implement something nice. If you would have a int write, you >> would not implement the interface and no applications expecting >> this interface would link/work/compile. >> >> oki, >> >> Steffen >> >> P.S.: (OT) >> If you propose not to implement the Java interfaces (especially >> not on JNI level), maybe optionally offering a wrapper that >> removes e.g. the write return value and so on to downgrade the >> powerful classic old POSIX read/write style to the modern limited >> Java style, then I agree :-) Same for read. Instead of things >> like "int avialable()" it is more powerful to have an approach as >> select(2) offers (to guarante the caller that read/write will not >> block [nothing else make sense anyway IMHO] but may read/write >> less bytes then requested). The caller gets full control and the >> higher level protocols can care about timeouts, invoking read in >> some loops and/or implement retransmission. On top of such an >> implementation, where everything is controlled, defined, >> guaranteed and reliable, someone could use an InputStream or >> OutputStream style interface. Or even better: don't use them at >> all :) just BTW :-) >> St. >> >> About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. >> 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. >> >> About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. >> 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. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From Steffen.DETTMER at ingenico.com Fri Jun 8 08:12:18 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 16:12:18 +0200 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <46694F9D.5080501@gatworks.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: <20070608141218.GE21069@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 08:46 -0400: > It seems that with outputstream.write(b[]), you become terribly > uncoordinated as soon as an exception is thrown. Docs do not say what > happens to the data. (yes, so avoiding it seems to be good :)) > Yet from a practicable point of view, one would like to know if the > write was accepted in-full, or rejected before any writes. There are no > in betweens, as partial writes are not reportable. (which is an artificial API limitation. I never understood how this happend when they invented JDK because the well-known BSD socket API and thus [probably] WinSock does this correct, but anyway) > So for an outputstream.write(), in order for it to return, the full > write request has to be taken, and stored in an internal output buffer. > If there is no room, the write() is suspended, till there is room. Or > throw's an IOException( "no room in buffer") ; As the select() loop for > write reports buffer room avail, then more of the internal buffer is > sent to the printer. yes, might be good in case of a printer. May be horrible in case of PPP/TCP or some other transmission control protocol which may e.g. repeat data or even omit parts of it (e.g. internet realtime radio station broadcasting)... So I think the idea of "int write" (e.g. BSD sockets, linux files and so on) still is the best. A clean API / implementation should guarantee and allow implementations (users) to rely on that; assumptions and automatic background-sending and so on may look pragmatic and may even work on the first look, but may fail in other situations. BTW, if e.g. BSD socket API is known, why not simply copy it (until something better is invented :)) instead of fiddling around with JDK APIs? anyway, have a nice weekend everyone :-) oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Fri Jun 8 08:55:56 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 10:55:56 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070608141218.GE21069@elberon.bln.de.ingenico.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> Message-ID: <46696DFC.7000801@gatworks.com> >> write reports buffer room avail, then more of the internal buffer is >> sent to the printer. > > yes, might be good in case of a printer. May be horrible in case > of PPP/TCP or some other transmission control protocol which > may e.g. repeat data or even omit parts of it (e.g. internet > realtime radio station broadcasting)... So I think the idea of > "int write" (e.g. BSD sockets, linux files and so on) still is > the best. A clean API / implementation should guarantee and allow > implementations (users) to rely on that; assumptions and > automatic background-sending and so on may look pragmatic and may > even work on the first look, but may fail in other situations. > BTW, if e.g. BSD socket API is known, why not simply copy it > (until something better is invented :)) instead of fiddling > around with JDK APIs? But we were talking about the Parallel Port, and the transmission of data over the commapi/parallel-port schema. There isn't much in bi-directional software communication. Its a simple write one byte at a time interface. I'm not looking to change the comm-api. I'm just looking to alter the interaction between the Native ParallelPort functions, and the java ParallelPort functions that call them. This might be more readily doable than to get a committee to re-specify java-API specs. BTW: Whats is off-topic? ( help: not looking for def of off-topic ) From j.kenneth.gentle at acm.org Fri Jun 8 08:58:59 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Fri, 08 Jun 2007 10:58:59 -0400 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <20070608141218.GE21069@elberon.bln.de.ingenico.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> Message-ID: <200706081459.l58Ex5rA019991@qbang.org> Perhaps it is a bit late to jump in on this one, but here goes anyway. If the solutions all seem to "break" the contract with "java.io.outputstream", then, as noted, that may not be the appropriate contract. At the risk of being heretical, JDK1.4 introduced the "nio" package to address some of the compatibility issues with C apis mentioned in previous posts. The interface "java.nio.channels.WriteableByteChannel" defines the following single method: int write(ByteBuffer source); int, strangely enough, is the actual number of bytes written. So, if RXTX as written, against the JavaCOMM api and OutputStream, doesn't do what we want, how about writing a different set of bindings using the java.nio classes and as much of the underlying native code as possible. Note that just because the java.nio.channels.WriteableByteChannel sends back a result, OutputStream.write doesn't have to - and they could both call the same underlying native code. My 2 cents - maybe not worth even that... Ken From netbeans at gatworks.com Fri Jun 8 10:37:28 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 12:37:28 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <200706081459.l58Ex5rA019991@qbang.org> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> Message-ID: <466985C8.8000505@gatworks.com> Ken Gentle wrote: > Perhaps it is a bit late to jump in on this one, but here goes anyway. Common in, the waters fine. > > If the solutions all seem to "break" the contract with > "java.io.outputstream", then, as noted, that may not be the > appropriate contract. > How would the contract be broken? The machinery underneath is handling the contract. From j.kenneth.gentle at acm.org Fri Jun 8 10:48:01 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Fri, 08 Jun 2007 12:48:01 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466985C8.8000505@gatworks.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> Message-ID: <200706081648.l58Gm7YA022904@qbang.org> At 12:37 2007-06-08, you wrote: >Ken Gentle wrote: > > > > If the solutions all seem to "break" the contract with > > "java.io.outputstream", then, as noted, that may not be the > > appropriate contract. > > >How would the contract be broken? The machinery underneath is handling >the contract. It seems that a lot of the discussion has been about not only the timeout and being able to adjust it in the "machinery layer", but also about knowing in the Java layer, in the event of a timeout or exception, how many characters have been written to the device. An OutputStream won't ever do this with out an extension and including a return value "breaks" the contract, right? So, go with a Java IO api that *does* return the number of bytes written, out of the NIO package. I know it doesn't allow for a strict implementation of the JavaCOMM API - however, using NIO classes in place of the IO classes isn't that big a break and would allow those applications that need such information a way to get it. Maybe I'm misunderstanding the problem... Ken From netbeans at gatworks.com Fri Jun 8 11:24:14 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 13:24:14 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <200706081648.l58Gm7YA022904@qbang.org> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> Message-ID: <466990BE.7040100@gatworks.com> Ken Gentle wrote: An > OutputStream won't ever do this with out an extension and including a > return value "breaks" the contract, right? > i was not thinking of change the API to OutputSream. Are there specs for how output stream should work internally? for instance: String data = "Hello this is a line of data"; Outputstream.write( data.getbytes() ); ParallelPort.suspend(); int free = ParallelPort.getoutputbufferfree(); There is a symbiotic relationship between outputstream and the functionality of ParallelPort. From Steffen.DETTMER at ingenico.com Fri Jun 8 11:15:39 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 19:15:39 +0200 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <200706081459.l58Ex5rA019991@qbang.org> References: <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> Message-ID: <20070608171539.GK21069@elberon.bln.de.ingenico.com> * Ken Gentle wrote on Fri, Jun 08, 2007 at 10:58 -0400: > If the solutions all seem to "break" the contract with > "java.io.outputstream", then, as noted, that may not be the > appropriate contract. > > At the risk of being heretical, JDK1.4 introduced the "nio" package > to address some of the compatibility issues with C apis mentioned in > previous posts. The interface > "java.nio.channels.WriteableByteChannel" defines the following single method: > > int write(ByteBuffer source); > > int, strangely enough, is the actual number of bytes written. Yes, AFAIK one of the motivations for the NIO interface was, that the JDK-1.3 APIs (InputStream, e.g.) were not powerfull enough, especially for multi-connection-TCP servers or so. I don't know much about it but I've heard of a project where NIO usage was removed because of stability issues in multi-threaded environments and performance limitations under some circumstances. IIRC the "nio.ByteBuffer" is something very special (namely something you cannot implement in Java, it is "magic" or part of the language itself). Not sure if this is such a great idea (but for performance in the end sometimes heavy prices must be paid) :) > So, if RXTX as written, against the JavaCOMM api and OutputStream, > doesn't do what we want, how about writing a different set of > bindings using the java.nio classes and as much of the underlying > native code as possible. Yes, this would be an idea: use a full-featured interface on JNI, and, if wanted, deliver some wrappers converting this to a less-featured Java-compliant interface. However, powerful things as e.g. "select" are difficult to "emulate" if you are e.g. on some (older?) windows. But if you expose the full-featured APIs, you need to emulate them full-featured, theoretically. In the end it depends what you do on the serial line. If you just want to talk to a modem, then you may not need precise timeouts. But if you need to implement complexer protocols which define response times and timeouts, you may quickly get into difficulties. For instance, AFAIK, rxtx 1.7.2 (?) for windows is very messy with timeouts (there is a maximum, higher values are truncated; resolution is 100ms only; the function may take up to twice the timeout because internally it may be called twice). Probably for most people this is OK, but probably not for all. But having precise timeouts should be OK for all :-) Well, in the end it is nice to wish but somewhat hard to implement (many platforms, connections, USB, BlueTooth, whatever). oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Steffen.DETTMER at ingenico.com Fri Jun 8 11:04:22 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 19:04:22 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <46696DFC.7000801@gatworks.com> References: <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <46696DFC.7000801@gatworks.com> Message-ID: <20070608170422.GJ21069@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 10:55 -0400: > > BTW, if e.g. BSD socket API is known, why not simply copy it > > (until something better is invented :)) instead of fiddling > > around with JDK APIs? > > But we were talking about the Parallel Port, and the > transmission of data over the commapi/parallel-port schema. > There isn't much in bi-directional software communication. Its > a simple write one byte at a time interface. First, there are things like PLIP (http://en.wikipedia.org/wiki/Plip) - well, probably not widely used, sure ;) Second, I think if there is a good simple API known to support all that (with known "best practices") or so and there is no forcing need to invent a new one, why not simply using it? > I'm not looking to change the comm-api. I'm just looking to > alter the interaction between the Native ParallelPort > functions, and the java ParallelPort functions that call them. Ahh, yes. I think this is what I tried to ask. Having an usable JNI interface and on top (in pure java) some wrapper to InputStream or whatever could be done (e.g. by ignoring the return value of write or throwing if != length). Developers could then use the full-featured (non-JAVA-standard) API or select among various wrappers (as InputStream). > This might be more readily doable than to get a committee to > re-specify java-API specs. Yes, of course. I'm afraid that the Java APIs change regularily, but still yet with limited success it seems, so maybe they get it in one of the next iterations; who knows, maybe Java-9 has a BSD-like socket API :) SCNR. > BTW: Whats is off-topic? ( help: not looking for def of > off-topic ) I think I started some "re-specify java-API specs" which was OT probably. oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From lists at iDIAcomputing.com Fri Jun 8 18:48:54 2007 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Fri, 08 Jun 2007 20:48:54 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46684B62.7080802@gmail.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> Message-ID: <4669F8F6.3040101@iDIAcomputing.com> Vicne wrote: > Sorry to step in without a specific solution to your problem, but I > wanted to share my feeling regarding this proposal. AFAIK, it's > generally considered bad practice to pop-up a prompt from a library. ... > > My advice would be to think again and find another solution. Ideas are : > - make the number of retries a parameter so that you can tune it to what > you think is reasonable > - throw a more specific exception when the number of retries has been > reached, so that a specific prompt can be shown at a higher level You could also allow the client code to register a callback class which returns a boolean indicating whether to retry or cancel. This callback class could pop up a dialog, if appropriate, or follow some preset policy, or.... - George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From joachim at buechse.ch Sat Jun 9 09:43:16 2007 From: joachim at buechse.ch (Joachim Buechse) Date: Sat, 9 Jun 2007 17:43:16 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46694F9D.5080501@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: You should not forget, that in the case of an exception it may not even be known what happened to the data. You have a kernel buffer, outgoing chip buffer, incoming chip buffer, etc. So of course, it would be nice to know up to which point data was correctly processed, but this feedback does not exist on the hardware or protocol level and hence can in general not be magicly created on the software level... Regards, Joachim On 08.06.2007, at 14:46, Uncle George wrote: > It seems that with outputstream.write(b[]), you become terribly > uncoordinated as soon as an exception is thrown. Docs do not say what > happens to the data. > > Yet from a practicable point of view, one would like to know if the > write was accepted in-full, or rejected before any writes. There > are no > in betweens, as partial writes are not reportable. > > So for an outputstream.write(), in order for it to return, the full > write request has to be taken, and stored in an internal output > buffer. > If there is no room, the write() is suspended, till there is room. Or > throw's an IOException( "no room in buffer") ; As the select() loop > for > write reports buffer room avail, then more of the internal buffer is > sent to the printer. > > > > yves pielusenet wrote: >> So maybe a better way should be to create a new Exception class which >> has a method "int getWrittenByte()". So the Exception should be >> use to >> send again bytes which are not printed yet. >> >> yves >> >> Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : >>> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: >>>> It is not possible that the rxtx java method write(byte[], int >>>> offset, >>>> int length) return anint which contains the number of byte >>>> really send >>>> to the printer instead of an exception ? >>>> So this is the programm which will see if all bytes have been >>>> sent. If >>>> not it can retry to send the unsended bytes. >>> I think write() is void because in Java people love to do this >>> since OutputStream :-) Of course on such interfaces you cannot >>> implement something nice. If you would have a int write, you >>> would not implement the interface and no applications expecting >>> this interface would link/work/compile. >>> >>> oki, >>> >>> Steffen >>> >>> P.S.: (OT) >>> If you propose not to implement the Java interfaces (especially >>> not on JNI level), maybe optionally offering a wrapper that >>> removes e.g. the write return value and so on to downgrade the >>> powerful classic old POSIX read/write style to the modern limited >>> Java style, then I agree :-) Same for read. Instead of things >>> like "int avialable()" it is more powerful to have an approach as >>> select(2) offers (to guarante the caller that read/write will not >>> block [nothing else make sense anyway IMHO] but may read/write >>> less bytes then requested). The caller gets full control and the >>> higher level protocols can care about timeouts, invoking read in >>> some loops and/or implement retransmission. On top of such an >>> implementation, where everything is controlled, defined, >>> guaranteed and reliable, someone could use an InputStream or >>> OutputStream style interface. Or even better: don't use them at >>> all :) just BTW :-) >>> St. >>> >>> About Ingenico Throughout the world businesses rely on Ingenico >>> for secure and expedient electronic transaction acceptance. >>> Ingenico products leverage proven technology, established >>> standards and unparalleled ergonomics to provide optimal >>> reliability, versatility and usability. This comprehensive range >>> of products is complemented by a global array of services and >>> partnerships, enabling businesses in a number of vertical sectors >>> to accept transactions anywhere their business takes them. >>> 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. >>> >>> About Ingenico Throughout the world businesses rely on Ingenico >>> for secure and expedient electronic transaction acceptance. >>> Ingenico products leverage proven technology, established >>> standards and unparalleled ergonomics to provide optimal >>> reliability, versatility and usability. This comprehensive range >>> of products is complemented by a global array of services and >>> partnerships, enabling businesses in a number of vertical sectors >>> to accept transactions anywhere their business takes them. >>> 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. >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx 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 yvespielusenet at free.fr Mon Jun 11 03:15:12 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Mon, 11 Jun 2007 11:15:12 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: <1181553312.8335.14.camel@localhost.localdomain> So can someone tell a solution for my problem :( Must I say to the user to not put the printer off-line ? I can't since he has to do some pauses, verify print, paper conditioning etc... How do other people ? Before I use the parport librarry to read port status : http://www.geocities.com/Juanga69/parport/ (which doesn't work on windows XP) And I send data into the file LPT1 I use to have no problem when printer was disabled. thanks -- yves piel Le samedi 09 juin 2007 ? 17:43 +0200, Joachim Buechse a ?crit : > You should not forget, that in the case of an exception it may not > even be known what happened to the data. > > You have a kernel buffer, outgoing chip buffer, incoming chip buffer, > etc. So of course, it would be nice to know up to which point data > was correctly processed, but this feedback does not exist on the > hardware or protocol level and hence can in general not be magicly > created on the software level... > > Regards, > Joachim > > On 08.06.2007, at 14:46, Uncle George wrote: > > > It seems that with outputstream.write(b[]), you become terribly > > uncoordinated as soon as an exception is thrown. Docs do not say what > > happens to the data. > > > > Yet from a practicable point of view, one would like to know if the > > write was accepted in-full, or rejected before any writes. There > > are no > > in betweens, as partial writes are not reportable. > > > > So for an outputstream.write(), in order for it to return, the full > > write request has to be taken, and stored in an internal output > > buffer. > > If there is no room, the write() is suspended, till there is room. Or > > throw's an IOException( "no room in buffer") ; As the select() loop > > for > > write reports buffer room avail, then more of the internal buffer is > > sent to the printer. > > > > > > > > yves pielusenet wrote: > >> So maybe a better way should be to create a new Exception class which > >> has a method "int getWrittenByte()". So the Exception should be > >> use to > >> send again bytes which are not printed yet. > >> > >> yves > >> > >> Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : > >>> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > >>>> It is not possible that the rxtx java method write(byte[], int > >>>> offset, > >>>> int length) return anint which contains the number of byte > >>>> really send > >>>> to the printer instead of an exception ? > >>>> So this is the programm which will see if all bytes have been > >>>> sent. If > >>>> not it can retry to send the unsended bytes. > >>> I think write() is void because in Java people love to do this > >>> since OutputStream :-) Of course on such interfaces you cannot > >>> implement something nice. If you would have a int write, you > >>> would not implement the interface and no applications expecting > >>> this interface would link/work/compile. > >>> > >>> oki, > >>> > >>> Steffen > >>> > >>> P.S.: (OT) > >>> If you propose not to implement the Java interfaces (especially > >>> not on JNI level), maybe optionally offering a wrapper that > >>> removes e.g. the write return value and so on to downgrade the > >>> powerful classic old POSIX read/write style to the modern limited > >>> Java style, then I agree :-) Same for read. Instead of things > >>> like "int avialable()" it is more powerful to have an approach as > >>> select(2) offers (to guarante the caller that read/write will not > >>> block [nothing else make sense anyway IMHO] but may read/write > >>> less bytes then requested). The caller gets full control and the > >>> higher level protocols can care about timeouts, invoking read in > >>> some loops and/or implement retransmission. On top of such an > >>> implementation, where everything is controlled, defined, > >>> guaranteed and reliable, someone could use an InputStream or > >>> OutputStream style interface. Or even better: don't use them at > >>> all :) just BTW :-) > >>> St. > >>> > >>> About Ingenico Throughout the world businesses rely on Ingenico > >>> for secure and expedient electronic transaction acceptance. > >>> Ingenico products leverage proven technology, established > >>> standards and unparalleled ergonomics to provide optimal > >>> reliability, versatility and usability. This comprehensive range > >>> of products is complemented by a global array of services and > >>> partnerships, enabling businesses in a number of vertical sectors > >>> to accept transactions anywhere their business takes them. > >>> 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. > >>> > >>> About Ingenico Throughout the world businesses rely on Ingenico > >>> for secure and expedient electronic transaction acceptance. > >>> Ingenico products leverage proven technology, established > >>> standards and unparalleled ergonomics to provide optimal > >>> reliability, versatility and usability. This comprehensive range > >>> of products is complemented by a global array of services and > >>> partnerships, enabling businesses in a number of vertical sectors > >>> to accept transactions anywhere their business takes them. > >>> 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. > >>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx 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 > From Steffen.DETTMER at ingenico.com Mon Jun 11 03:56:18 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 11:56:18 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466990BE.7040100@gatworks.com> References: <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> Message-ID: <20070611095618.GA10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 13:24 -0400: > i was not thinking of change the API to OutputSream. Then I think either someone uses OutputStream (and has no reliable information about incomplete writes) or someone uses somethink else. > Are there specs for how output stream should work internally? > > for instance: > String data = "Hello this is a line of data"; > Outputstream.write( data.getbytes() ); > ParallelPort.suspend(); > int free = ParallelPort.getoutputbufferfree(); > > There is a symbiotic relationship between outputstream and the > functionality of ParallelPort. If you need OutputStream "plus something else", in short you're needing "something else". Personally I dislike the code above a lot. The stream "looks" like if it would be an OutputStream, but in fact it isn't. You need to call getoutputbufferfree later to check if write succeeded (but OutputStream promises that write succeedes synchronous, blocking, or throws an exception). So it is not an OutputStream. No application written for OutputStreams would work without change (because it won't know getoutputbufferfree at all). It is not abstracted from ParallelPort. I think this would be wrong. Then I think an alternative interface instead is better. Let's assume we had some "connection" (to distinguish between OutputStreams and Channels). Then why not working as on a file handle in POSIX: do { // ... select maybe using timer ... readyForWrite = ... if (readyForWrite) { int writtenBytes = connection.write(toWrite); toWrite.remove(0, writtenBytes); } while(readyForWrite && toWrite.length > 0); I think, having such a write isn't the big problem. I think, the difficult thing is around "select" - however this would look like. It should be OO, typesafe, performant, supporting multiple connections/channels/streams in various modes and should be orthogonal to other functionalities. Of course, this heavily depends on what the application is doing; for a simple situation (like reading a small, mandatory file from a local disk) this would be to uncomfortable (and offering unneeded features only). just BTW :) oki, Steffen -- // Modeline for VIM. Please don't remove. // (Help: autoindent, expandtab, shiftwidth=4, tabstop=4, textwidth=75) // vi: set ai et sw=4 ts=4 tw=75 ft=java: About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Mon Jun 11 05:38:33 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 07:38:33 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611095618.GA10821@elberon.bln.de.ingenico.com> References: <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> Message-ID: <466D3439.4020805@gatworks.com> Steffen DETTMER wrote: > (but OutputStream promises that write > succeedes synchronous, blocking, or throws an exception). Where is it so written? From Steffen.DETTMER at ingenico.com Mon Jun 11 06:36:50 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 14:36:50 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466D3439.4020805@gatworks.com> References: <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> <466D3439.4020805@gatworks.com> Message-ID: <20070611123650.GI10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Mon, Jun 11, 2007 at 07:38 -0400: > Steffen DETTMER wrote: > > > (but OutputStream promises that write > > succeedes synchronous, blocking, or throws an exception). > > Where is it so written? Now, as you ask, I think it is not written that clearly but follows from specification. mmm... Am I wrong? I understand the API doc in this way: * http://java.sun.com/j2se/1.4.2/docs/api/java/io/OutputStream.html#write(byte[]) > public void write(byte[] b) > throws IOException > > Writes b.length bytes from the specified byte array to this > output stream. The general contract for write(b) is that > it should have exactly the same effect as the call write(b, > 0, b.length). > > Parameters: > b - the data. > Throws: > IOException - if an I/O error occurs. > See Also: > write(byte[], int, int) and there is: > public void write(byte[] b, > int off, > int len) > throws IOException > > Writes len bytes from the specified byte array starting at > offset off to this output stream. The general contract for > write(b, off, len) is that some of the bytes in the array b > are written to the output stream in order; element b[off] > is the first byte written and b[off+len-1] is the last byte > written by this operation. > > The write method of OutputStream calls the write method of > one argument on each of the bytes to be written out. > Subclasses are encouraged to override this method and > provide a more efficient implementation. > > If b is null, a NullPointerException is thrown. > > If off is negative, or len is negative, or off+len is > greater than the length of the array b, then an > IndexOutOfBoundsException is thrown. > > Parameters: > b - the data. > off - the start offset in the data. > len - the number of bytes to write. > Throws: > IOException - if an I/O error occurs. In particular, an > IOException is thrown if the output stream is closed. In general, any specialisation (derived child class) must comform to this. So write in the end is specified (!) as "The write method ... calls the write method ... on each of the bytes to be written out". This is what must be implemented by ANY OutputStream. Of course, there is: "Subclasses are encouraged to override this method and provide a more efficient implementation." which IMHO does not contradict - the more efficient must behave in exactly the same way of course (just wasting less resources than a simple byte-by-byte write). So it does not matter here I think. The write that finally defines the behavior tells basically: > "Writes the specified byte to this output stream. The general > contract for write is that one byte is written to the output > stream. " > > Throws: > IOException - if an I/O error occurs. which IMHO is another way of saying "write writes the byte immediately and returns on success (only), otherwise an exception is thrown". Especially it cannot happen that zero bytes are written (i.e. the specified byte is NOT written) without an exception. So by this write must be synchronous and blocking, because otherwise it could not reliably know if an asynchronous operation will succeede or not (some getAsyncResult or so would be needed). Since write(byte[]) does this for each byte (or with a behavior beeing exactly the same as if it would do), I think this means that the write(byte[]) succeedes synchronous/blocking or throws an exception. Did I an error in reasoning or confused something or so? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From j.kenneth.gentle at acm.org Mon Jun 11 06:51:25 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 11 Jun 2007 08:51:25 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611123650.GI10821@elberon.bln.de.ingenico.com> References: <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> <466D3439.4020805@gatworks.com> <20070611123650.GI10821@elberon.bln.de.ingenico.com> Message-ID: <200706111251.l5BCpS9T017831@qbang.org> It is as Steffen describes. "InputStream" and "OutputStream" are inherently synchronous (which is why so many java programs resort to threads to use them). Anything outside of this "contract" is *not* an InputStream or OutputStream. That is why there is a new package for things that don't behave like the old *Stream classes - the NIO package. If you look carefully at the IO package, you'll note that almost all the classes are _Decorator_ pattern implementations of the *Stream classes - and the interface presents the _same_ behavior to the calling code in all cases - a synchronous operation that completes successfully or throws an exception (with the one exception of "read" that returns a "-1" on end-of-stream. I know I've read this numerous times - I'd suggest checking the Language Spec or one of the books by Bloch or Gosling. Ken At 08:36 2007-06-11, you wrote: >* Uncle George wrote on Mon, Jun 11, 2007 at 07:38 -0400: > > Steffen DETTMER wrote: > > > > > (but OutputStream promises that write > > > succeedes synchronous, blocking, or throws an exception). > > > > Where is it so written? > >Now, as you ask, I think it is not written that clearly but >follows from specification. mmm... > >Am I wrong? > >I understand the API doc in this way: > >* >http://java.sun.com/j2se/1.4.2/docs/api/java/io/OutputStream.html#write(byte[]) > > public void write(byte[] b) > > throws IOException > > > > Writes b.length bytes from the specified byte array to this > > output stream. The general contract for write(b) is that > > it should have exactly the same effect as the call write(b, > > 0, b.length). > > > > Parameters: > > b - the data. > > Throws: > > IOException - if an I/O error occurs. > > See Also: > > write(byte[], int, int) > > >and there is: > > > > public void write(byte[] b, > > int off, > > int len) > > throws IOException > > > > Writes len bytes from the specified byte array starting at > > offset off to this output stream. The general contract for > > write(b, off, len) is that some of the bytes in the array b > > are written to the output stream in order; element b[off] > > is the first byte written and b[off+len-1] is the last byte > > written by this operation. > > > > The write method of OutputStream calls the write method of > > one argument on each of the bytes to be written out. > > Subclasses are encouraged to override this method and > > provide a more efficient implementation. > > > > If b is null, a NullPointerException is thrown. > > > > If off is negative, or len is negative, or off+len is > > greater than the length of the array b, then an > > IndexOutOfBoundsException is thrown. > > > > Parameters: > > b - the data. > > off - the start offset in the data. > > len - the number of bytes to write. > > Throws: > > IOException - if an I/O error occurs. In particular, an > > IOException is thrown if the output stream is closed. > > >In general, any specialisation (derived child class) must comform >to this. So write in the end is specified (!) as "The write >method ... calls the write method ... on each of the bytes to be >written out". This is what must be implemented by ANY >OutputStream. > >Of course, there is: "Subclasses are encouraged to override this >method and provide a more efficient implementation." which IMHO >does not contradict - the more efficient must behave in exactly >the same way of course (just wasting less resources than a simple >byte-by-byte write). So it does not matter here I think. > > > >The write that finally defines the behavior tells basically: > > > "Writes the specified byte to this output stream. The general > > contract for write is that one byte is written to the output > > stream. " > > > > Throws: > > IOException - if an I/O error occurs. > > >which IMHO is another way of saying "write writes the byte >immediately and returns on success (only), otherwise an exception >is thrown". Especially it cannot happen that zero bytes are >written (i.e. the specified byte is NOT written) without an >exception. So by this write must be synchronous and blocking, >because otherwise it could not reliably know if an asynchronous >operation will succeede or not (some getAsyncResult or so would >be needed). > >Since write(byte[]) does this for each byte (or with a behavior >beeing exactly the same as if it would do), I think this means >that the write(byte[]) succeedes synchronous/blocking or throws >an exception. > >Did I an error in reasoning or confused something or so? > >oki, > >Steffen > >About Ingenico Throughout the world businesses rely on Ingenico for >secure and expedient electronic transaction acceptance. Ingenico >products leverage proven technology, established standards and >unparalleled ergonomics to provide optimal reliability, versatility >and usability. This comprehensive range of products is complemented >by a global array of services and partnerships, enabling businesses >in a number of vertical sectors to accept transactions anywhere >their business takes them. >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. > >About Ingenico Throughout the world businesses rely on Ingenico for >secure and expedient electronic transaction acceptance. Ingenico >products leverage proven technology, established standards and >unparalleled ergonomics to provide optimal reliability, versatility >and usability. This comprehensive range of products is complemented >by a global array of services and partnerships, enabling businesses >in a number of vertical sectors to accept transactions anywhere >their business takes them. >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. > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From alesinskyy at googlemail.com Mon Jun 11 07:25:33 2007 From: alesinskyy at googlemail.com (Oleksandr Alesinskyy) Date: Mon, 11 Jun 2007 15:25:33 +0200 Subject: [Rxtx] [OT] select :-) Message-ID: Sorry, but I have to disagree with following statement: "So write in the end is specified (!) as "The write method ... calls the write method ... on each of the bytes to be written out". This is what must be implemented by ANY OutputStream.". This is not part of the specification or contract, it is just revealed implementation detail of the OutputStream. It is not stated anywhere that behavoiur of derived classes shall conform with this one. Statement concerning "synchronous" nature of the output stream is invalid as well. Really synchronous stream does not require flush() but OutputStream has it. From Steffen.DETTMER at ingenico.com Mon Jun 11 08:21:16 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 16:21:16 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: Message-ID: <20070611142116.GN10821@elberon.bln.de.ingenico.com> * Oleksandr Alesinskyy wrote on Mon, Jun 11, 2007 at 15:25 +0200: > Sorry, but I have to disagree with following statement: > "So write in the end is specified (!) as "The write > method ... calls the write method ... on each of the bytes to be > written out". This is what must be implemented by ANY > OutputStream.". > > This is not part of the specification or contract, it is just > revealed implementation detail of the OutputStream. It is not > stated anywhere that behavoiur of derived classes shall conform > with this one. (I didn't meant that the implementation must really write byte by byte, but that it must "look as if it would do" - because all implementations of OutputStream must "look" in the same way [which is another way of saying "do abstract" I think]) I think the API doc is not "revealing implementation details" but it is the *specification* of that interface and derivations must (should) conform to this specification. Isn't this the idea of interfaces? A function that expects an OutputStream should work on ANY OutputStream, shouldn't it? just kidding: I mean, what would be the point in implementing a checksum function as OutputStream.write which throws its result as IOException? Or which requires to call close() as very first operation to tell that the application is about to transmit confidential data? :-) > Statement concerning "synchronous" nature of the output stream > is invalid as well. Really synchronous stream does not require > flush() but OutputStream has it. ahh, interesting point! I think this is another bug in the API. flush() is wrong. Because write specifies "The general contract for write is that one byte is written to the output stream." but not "a byte may be written or buffered". Actually, an application would need to call flush() after each write (or bunch of write calls) to ensure that write really did something otherwise I think. I didn't found in the spec of OutputStream that it would be required to call flush(). This should mean that calling flush is not required which in turn leads to the conclusion that write must be synchrous (private threads are forbidden because not specified :)) which in turn leads to the conclusion that flush() is not needed at all... I mean, what if someone would only store in write and do the "real write" in flush() and never else? An application could write in one stream and read on another one (e.g. in bidirectional communication) and would never get anything back, because nothing was actually written because no flush was called? Then someone could even think that on error in some write the data could remain buffered AND throw an exception, retrying to send the data in the next write. Ohh, and if there would be some message number inside, and underlaying write (e.g. a protocol offering InputStream/OutputStream) would check this and throw "DuplicatedMessageNumber" the stream would only throw it again and again beeing unusable... In short: I have no clue how someone could be able to implement an asynchrounos write (which is realiable and correct) without beeing specific to anything which is not specified by OutputStream. Well, I think in the end OutputStream was not intended for such communication or protocol implementations - but to read a local disk file or so. In case of I/O errors usually you can abort your application and change the hard disk :-) oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Bob_Jacobsen at lbl.gov Mon Jun 11 09:32:23 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Mon, 11 Jun 2007 08:32:23 -0700 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611142116.GN10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> Message-ID: At 4:21 PM +0200 6/11/07, Steffen DETTMER wrote: > > Statement concerning "synchronous" nature of the output stream >> is invalid as well. Really synchronous stream does not require >> flush() but OutputStream has it. > >ahh, interesting point! > >I think this is another bug in the API. flush() is wrong. Because >write specifies "The general contract for write is that one byte >is written to the output stream." but not "a byte may be written >or buffered". > >Actually, an application would need to call flush() after each >write (or bunch of write calls) to ensure that write really did >something otherwise I think. OutputStreams don't _have_ to be synchronous or asynchronous, but the OutputStream API was be arranged so that subclasses _can_ be synchronous or asynchronous. Such generality is the hardest part of getting an API right. Hence, if at some point a program using an OutputStream wants to be sure that the data has been pushed all the way out, flush() is available. For some subclasses, e.g. the buffered ones, this has important behavior. Others write the data from each call, and flush() doesn't do anything. You _can_ omit it in programs that are known to use this second type, but there's no requirement that you do so; the interface is general in that way. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From Steffen.DETTMER at ingenico.com Mon Jun 11 12:32:39 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 20:32:39 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> Message-ID: <20070611183239.GT10821@elberon.bln.de.ingenico.com> * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: > >Actually, an application would need to call flush() after each > >write (or bunch of write calls) to ensure that write really did > >something otherwise I think. > OutputStreams don't _have_ to be synchronous or asynchronous, > but the OutputStream API was be arranged so that subclasses > _can_ be synchronous or asynchronous. Ahh, oki. Thanks for the clarificaion. So in short, flush() MUST be called on OutputStream, this is just not documented correctly or so clearly (right?). So the overall usage semantics would be: 1. call write (multiple times if desired) 2. call flush only if both succeeded, write was successful. If flush fails it remains unknown if a part of the data was written and/or will be repeated. So the spec (API doc) is wrong. Correct would be to tell that write behaves as told as long as it is followed by a call to flush, otherwise data may or may not get lost (depending wheter close() is called and calls flush(), which seems not to be guaranteed/required). BTW, I think it is a little bit... erm... interesting to find the specification (java API doc reference) wrong, having a need to conclude it from the presence of some methods with "it would make no sense if they behave exactly as specified, so specification must be wrong (incomplete)". > Such generality is the hardest part of getting an API right. Yes, seems to be proven ;) > Hence, if at some point a program using an OutputStream wants > to be sure that the data has been pushed all the way out, > flush() is available. For some subclasses, e.g. the buffered > ones, this has important behavior. Others write the data from > each call, and flush() doesn't do anything. > You _can_ omit it in programs that are known to use this second > type, but there's no requirement that you do so; the interface > is general in that way. I think, it still it must be called always, otherwise the application could break if passing a different runtime type as OutputStream. I think, if the application/method needs a special "type of OutputStream" then the parameter type must be a subclass but not OutputStream, maybe a PrintStream or so - otherwise the compiler could not detect this error (passing wrong type). Is this correct? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Bob_Jacobsen at lbl.gov Mon Jun 11 13:00:52 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Mon, 11 Jun 2007 12:00:52 -0700 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611183239.GT10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> Message-ID: At 8:32 PM +0200 6/11/07, Steffen DETTMER wrote: >So the spec (API doc) is wrong. Correct would be to tell that >write behaves as told as long as it is followed by a call to >flush, otherwise data may or may not get lost (depending wheter >close() is called and calls flush(), which seems not to be >guaranteed/required). I'm not entirely sure that the spec is wrong, but reasonable people can differ on this. In the 1.5 JavaDocs, all that the docs say for the write methods is that they write to the _output_ _stream_; there is no guarantee of anything beyond that. Only the flush method has any guarantee about the data, which is >Flushes this output stream and forces any buffered output bytes to >be written out. The general contract of flush is that calling it is >an indication that, if any bytes previously written have been >buffered by the implementation of the output stream, such bytes >should immediately be written to their intended destination. People commonly use various OutputStreams without using flush(), and it often works, but it's a bad practice and will eventually bite them. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From netbeans at gatworks.com Mon Jun 11 13:31:57 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 15:31:57 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611183239.GT10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> Message-ID: <466DA32D.1010602@gatworks.com> Steffen DETTMER wrote: > * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: >>> Actually, an application would need to call flush() after each >>> write (or bunch of write calls) to ensure that write really did >>> something otherwise I think. > >> OutputStreams don't _have_ to be synchronous or asynchronous, >> but the OutputStream API was be arranged so that subclasses >> _can_ be synchronous or asynchronous. > > Ahh, oki. Thanks for the clarificaion. > > So in short, flush() MUST be called on OutputStream, this is just > not documented correctly or so clearly (right?). No. Flush can be called to force all current data in java buffer's to be written to the kernel - NOW. A flush() can also *imply* that, besides writing out the buffer's that java employs, may also imply/ask the kernel to write all data thusfar written to the kernel, to be physically placed on the destination device - NOW. For some OS's there is no need to do a kernel flush(), as the I/O is synchronized already. Since this is java, you never know what OS your on. From tjarvi at qbang.org Mon Jun 11 19:28:27 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Jun 2007 19:28:27 -0600 (MDT) Subject: [Rxtx] [OT] select :-) In-Reply-To: <466DA32D.1010602@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: On Mon, 11 Jun 2007, Uncle George wrote: > Steffen DETTMER wrote: >> * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: >>>> Actually, an application would need to call flush() after each >>>> write (or bunch of write calls) to ensure that write really did >>>> something otherwise I think. >> >>> OutputStreams don't _have_ to be synchronous or asynchronous, >>> but the OutputStream API was be arranged so that subclasses >>> _can_ be synchronous or asynchronous. >> >> Ahh, oki. Thanks for the clarificaion. >> >> So in short, flush() MUST be called on OutputStream, this is just >> not documented correctly or so clearly (right?). > No. > Flush can be called to force all current data in java buffer's to be > written to the kernel - NOW. > > A flush() can also *imply* that, besides writing out the buffer's that > java employs, may also imply/ask the kernel to write all data thusfar > written to the kernel, to be physically placed on the destination device > - NOW. > For some OS's there is no need to do a kernel flush(), as the I/O is > synchronized already. Since this is java, you never know what OS your on. To add to the confusion, flush on the C side throws away data. drain makes sure it is written. Looking at the ParallelImp.c we can probably do better. /* we set a timeout because all calls are sequentiell (also with asynchron) this means that the default timeout of unlimited blocks all calls (also close and status request) if the device is down */ GetCommTimeouts( (HANDLE)fd, &timeouts ); timeouts.WriteTotalTimeoutMultiplier = 0; timeouts.WriteTotalTimeoutConstant = 2000; /* 2000 is the min value for the default Windows NT and Windows 2000 driver */ SetCommTimeouts( (HANDLE)fd, &timeouts ); while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } errorCount = 0; bytes += countWritten; count -= countWritten; } LPRPort has some timeout code that appears to be doing nothing but flipping bits back and forth right now. The commapi rxtx follows allows for timeout control from javax.comm.CommPort. The above is a solution that worked in one specific use case. With timeouts in place, the original 'old printer going offline' problem could be solved. That printer code isn't written in stone. In fact it was ajusted from being able to print 'asdf' to a daisy wheel printer to working for one person. BTW, I've finished teaching after hours tonight and will be moving forward with a new rxtx release in my free time. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Jun 11 21:28:04 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 23:28:04 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: <466E12C4.1010305@gatworks.com> > Looking at the ParallelImp.c we can probably do better. > The problem stemmed from the possibility that the writev routine could have written some of the buffer, in chunks, printer pauses, refuses any more chunks, and a timeout occurs. Do you or do you not cause an exception to be thrown? Is there a way to set timeout for a ParallelPort data output stream? I cant find it. From tjarvi at qbang.org Mon Jun 11 22:17:23 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Jun 2007 22:17:23 -0600 (MDT) Subject: [Rxtx] [OT] select :-) In-Reply-To: <466E12C4.1010305@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> <466E12C4.1010305@gatworks.com> Message-ID: On Mon, 11 Jun 2007, Uncle George wrote: >> Looking at the ParallelImp.c we can probably do better. >> > The problem stemmed from the possibility that the writev routine could > have written some of the buffer, in chunks, printer pauses, refuses any > more chunks, and a timeout occurs. Do you or do you not cause an > exception to be thrown? > > Is there a way to set timeout for a ParallelPort data output stream? I > cant find it. hmm I looked again after you asked. The timeouts are only controllable on the receive side. This comes from CommPort; the parent. So what we are talking about is some bytes in memory that rxtx has and is supposed to write. A buffer perhaps? The approach with rxtx in the past has been to ignore output buffer sizes. The assumption is that the library does not know how to best handle buffers. There are buffered output streams that can do buffering on top of rxtx for instance. There is also a question regarding what was actually ment when the API was put together. My suspicion is that it was put together while looking at one OS API and was never ment to be anything more than a hook into that API. The comments are fairly telling combined with reading the w32 API. So looking at the problem again.. The current timeout behavior appears fairly arbitrary. Presumably this is to prevent a program from hanging instead of using a helper thread to write - heavy handed for new programmers. Even so, I don't think the write should timeout at all if it is not configurable. >From the API perspective, "What Timeout?" -- Trent Jarvi tjarvi at qbang.org From Steffen.DETTMER at ingenico.com Tue Jun 12 02:14:48 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 12 Jun 2007 10:14:48 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466DA32D.1010602@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: <20070612081447.GU10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Mon, Jun 11, 2007 at 15:31 -0400: > Steffen DETTMER wrote: > > Ahh, oki. Thanks for the clarificaion. > > > > So in short, flush() MUST be called on OutputStream, this is just > > not documented correctly or so clearly (right?). > No. hum (though now I got it, but...). > Flush can be called to force all current data in java buffer's to be > written to the kernel - NOW. > > A flush() can also *imply* that, besides writing out the > buffer's that java employs, may also imply/ask the kernel to > write all data thusfar written to the kernel, to be physically > placed on the destination device - NOW. > > For some OS's there is no need to do a kernel flush(), as the I/O is > synchronized already. Since this is java, you never know what OS your on. (well, but if you're going to kernel level, even flush cannot guarantee that data will "be physically placed". Maybe you're flushing to a file via NFS (and the client "thinks" that it was written, but maybe it was just buffered by the NFS server) or so... but of course such exceptions of the rules are constructable always.) Well, you tell that depending on the OS it can be that flush is needed or it can be that flush is not needed (beacuse the I/O is synchronized already), right? Also, applications should work on any OS, which includes the OSes that do need flush. Since the application cannot know whether flush is needed or not because it doesn't know what the OS is doing, it has to call flush, hasn't it? I mean, if it would not call flush then it would not work on such OSes (except the written data would not be needed at all, but in this would be an artificial example :)). Since applications are supposed to work this would be wrong, wouldn't it? So would it be correct to say: "Applications, that should work under all OSes (including the OSes where the I/O is not synchronised already), have to call flush on OutputStream to ensure the data is transfered to the kernel." or is this wrong? If so, then I'm afraid I missed the point again :( oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Tue Jun 12 04:46:52 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 12 Jun 2007 06:46:52 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070612081447.GU10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> <20070612081447.GU10821@elberon.bln.de.ingenico.com> Message-ID: <466E799C.7060700@gatworks.com> S > (well, but if you're going to kernel level, even flush cannot > guarantee that data will "be physically placed". Thats true now-a-days because ( from "man 2 sync" ) : > According to the standard specification (e.g., SVID), sync() schedules > the writes, but may return before the actual writing is done. However, > since version 1.3.20 Linux does actually wait. (This still does not > guarantee data integrity: modern disks have large caches.) My disk drive has 8mb cache. Maybe you're > flushing to a file via NFS (and the client "thinks" that it was > written, but maybe it was just buffered by the NFS server) or > so... but of course such exceptions of the rules are > constructable always.) > > Well, you tell that depending on the OS it can be that flush is > needed or it can be that flush is not needed (beacuse the I/O is > synchronized already), right? Also, applications should work on > any OS, which includes the OSes that do need flush. Its not OS's that need flush, its applications that want to have some assurance that data is written to the device that really needs to use flush. If your program ( or thread ) dies then it is in your best interest to write out the critical data as soon as possible, as economical as possible. These are trade-off's that the application programmer makes. A big buffer may mean big loss of data, a small buffer may mean spending too much time writing out data. > > > So would it be correct to say: > > "Applications, that should work under all OSes (including the > OSes where the I/O is not synchronised already), have to call > flush on OutputStream to ensure the data is transfered to the > kernel." > > or is this wrong? If so, then I'm afraid I missed the point again > :( > No that is not wrong. Ensuring that data is transfered to the OS is just about what any application can do. From tjarvi at qbang.org Thu Jun 14 08:16:47 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 14 Jun 2007 08:16:47 -0600 (MDT) Subject: [Rxtx] rxtx and usb-serial solution In-Reply-To: References: Message-ID: On Thu, 14 Jun 2007, Vladimir Kirtchev wrote: > Hi Trent, > > I develop a Java application which communicates with devices which have > USB-to-Serial bridge in them. The target OS is Linux. So for this purpose I > use RXTX. > > But I encountered a strange problem - when reading from the InputStream, I > receive series of zeros. I have this problem under Linux only. Under Windows > it is fine. > Actually this problem is the same as the one described here: > http://marc.info/?l=rxtx&m=109703190731748&w=2. > > > So I searched for the problem in the native code. And found that the root of > the problem is in SerialImp.c, > int configure_port( int fd ) > { > ... > ttyset.c_iflag = INPCK; > ... > } > > This line enables input parity checking, and the data sent from the device > is processed by the OS driver before being read with read(). > In this case the driver detects some problem and sets the received bytes to > zero. > > On the other hand in the Java part a set the serial port parameters with > SerialPort.PARITY_NONE. According to me, except all other things, this > should also disable INPCK in c_iflag. > > So I refactored the method translate_parity(...) to the following: > > int translate_parity( JNIEnv *env, struct termios *ttyset, jint parity ) > { > ENTER( "translate_parity" ); > #ifdef CMSPAR > ttyset->c_cflag &= ~(PARENB | PARODD | CMSPAR ); > #endif /* CMSPAR */ > switch( parity ) { > case JPARITY_NONE: > ttyset->c_iflag &= ~INPCK; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_EVEN: > ttyset->c_cflag |= PARENB; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_ODD: > ttyset->c_cflag |= PARENB | PARODD; > LEAVE( "translate_parity" ); > return 0; > #ifdef CMSPAR > case JPARITY_MARK: > ttyset->c_cflag |= PARENB | PARODD | CMSPAR; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_SPACE: > ttyset->c_cflag |= PARENB | CMSPAR; > LEAVE( "translate_parity" ); > return 0; > #endif /* CMSPAR */ > default: > printf("Parity missed %i\n", (int) parity ); > } > > LEAVE( "translate_parity" ); > /* > For some reason the native exceptions are not being caught. Moving this > to the Java side fixed the issue. taj. > throw_java_exception( env, UNSUPPORTED_COMM_OPERATION, > "", "parity value not supported" ); > */ > return 1; > } > > This modification solved the problem and now it works correctly under Linux. > > I think I will be a nice if this is idea is included in a future release of > RXTX. > > Thanks Vadim, I'll try that out. Forwarding to the rxtx mail-list too. This is probably not going to help USB drivers on windows which I'm sure some are looking for. As far as I can tell, windows USB bluetooth and serial dongles are limited by driver functionality. Some are good and others lack key features. -- Trent Jarvi tjarvi at qbang.org From dan.sandberg.lists at gmail.com Mon Jun 18 14:43:39 2007 From: dan.sandberg.lists at gmail.com (Dan Sandberg) Date: Mon, 18 Jun 2007 13:43:39 -0700 Subject: [Rxtx] Fix for JNI Get/Set Field Errors Message-ID: <4676EE7B.7060800@gmail.com> Hi, I've fixed the problems that cause the following JNI error when extra JNI checking ( -Xjni:check ) is turned on. FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) The problem was basically that GetLong was being used to get ints, and SetInt was used for longs. The patch below fixes this. Please let me know if there are any questions / problems. Cheers, -Dan diff -aur old/SerialImp.c src/SerialImp.c --- old/SerialImp.c 2007-06-18 13:24:33.000000000 -0700 +++ src/SerialImp.c 2007-06-18 06:26:26.000000000 -0700 @@ -1337,7 +1337,7 @@ report("init_threads: get eis\n"); jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); report("init_threads: set eis\n"); - (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); + (*eis->env)->SetLongField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); report("init_threads: stop\n"); report_time_end( ); return( 1 ); @@ -1530,7 +1530,7 @@ jobject jobj, jboolean interrupted ) { int fd = get_java_var( env, jobj,"fd","I" ); - struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var( env, jobj, "eis", "J" ); + struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var_long( env, jobj, "eis", "J" ); int result, count=0; char message[80]; @@ -2939,7 +2939,7 @@ /* TRENT */ int flag, count = 0; struct event_info_struct *eis = ( struct event_info_struct * ) - get_java_var( env, *jobj,"eis","J" ); + get_java_var_long( env, *jobj,"eis","J" ); report_time_start(); flag = eis->eventflags[SPE_DATA_AVAILABLE]; @@ -4873,9 +4873,9 @@ exceptions: none comments: ----------------------------------------------------------*/ -size_t get_java_var( JNIEnv *env, jobject jobj, char *id, char *type ) +long get_java_var_long( JNIEnv *env, jobject jobj, char *id, char *type ) { - int result = 0; + long result = 0; jclass jclazz = (*env)->GetObjectClass( env, jobj ); jfieldID jfd = (*env)->GetFieldID( env, jclazz, id, type ); @@ -4889,7 +4889,11 @@ LEAVE( "get_java_var" ); return result; } - result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); + if ( !strcmp( type, "J" ) ) { + result = (long)( (*env)->GetLongField( env, jobj, jfd ) ); + } else { + result = (int) ( (*env)->GetIntField( env, jobj, jfd ) ); + } /* ct7 & gel * Added DeleteLocalRef */ (*env)->DeleteLocalRef( env, jclazz ); if(!strncmp( "fd",id,2) && result == 0) @@ -4900,6 +4904,10 @@ return result; } +int get_java_var( JNIEnv *env, jobject jobj, char *id, char *type ) { + return (int) get_java_var_long( env, jobj, id, type ); +} + /*---------------------------------------------------------- throw_java_exception diff -aur old/SerialImp.h src/SerialImp.h --- old/SerialImp.h 2007-06-18 13:24:39.000000000 -0700 +++ src/SerialImp.h 2007-06-18 06:23:43.000000000 -0700 @@ -413,7 +413,8 @@ void system_wait(); void finalize_event_info_struct( struct event_info_struct * ); int read_byte_array( JNIEnv *, jobject *, int, unsigned char *, int, int ); -size_t get_java_var( JNIEnv *, jobject, char *, char * ); +int get_java_var( JNIEnv *, jobject, char *, char * ); +long get_java_var_long( JNIEnv *, jobject, char *, char * ); jboolean is_interrupted( struct event_info_struct * ); int send_event(struct event_info_struct *, jint, int ); void dump_termios(char *,struct termios *); From netbeans at gatworks.com Fri Jun 1 05:38:50 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 07:38:50 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <465F7ADD.1010501@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> Message-ID: <4660054A.2040202@gatworks.com> Manuel Naranjo wrote: In the case of my module, you can > unplug the device but it will not delete the symlink until those apps > that had opened the port has closed it. This is done this way to avoid > kernel panics. What does this mean to user code ? I have tried the alternate route ( other than closing ) which is sleep inbetween the I/O errors ( an unplugged USB device). When the device is plugged back in, The writes to the device still get an I/O error. This would seem to be a lost cause for the application. From netbeans at gatworks.com Fri Jun 1 06:35:48 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 08:35:48 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <465F7ADD.1010501@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> Message-ID: <466012A4.90608@gatworks.com> Manuel Naranjo wrote: In the case of my module, you can > unplug the device but it will not delete the symlink until those apps > that had opened the port has closed it. T Did u also mean for this to happen? USB0 was not closed by application. Apparently USB1 got created when USB device was plugged back in. There is only one USB device on a 4 port USB hub. This also seems to suggest that application recovery to be impossible. > Jun 1 07:10:08 mylaptop kernel: garmin_gps 1-1.4:1.0: Garmin GPS usb/tty converter detected > Jun 1 07:10:08 mylaptop kernel: usb 1-1.4: Garmin GPS usb/tty converter now attached to ttyUSB0 > Jun 1 07:15:17 mylaptop kernel: usb 1-1: USB disconnect, address 4 > Jun 1 07:15:17 mylaptop kernel: usb 1-1.4: USB disconnect, address 5 > Jun 1 07:15:17 mylaptop kernel: garmin_gps 1-1.4:1.0: device disconnected > Jun 1 07:15:26 mylaptop kernel: usb 1-1: new full speed USB device using uhci_hcd and address 6 > Jun 1 07:15:26 mylaptop kernel: hub 1-1:1.0: USB hub found > Jun 1 07:15:26 mylaptop kernel: hub 1-1:1.0: 4 ports detected > Jun 1 07:15:27 mylaptop kernel: usb 1-1.4: new full speed USB device using uhci_hcd and address 7 > Jun 1 07:15:27 mylaptop kernel: garmin_gps 1-1.4:1.0: Garmin GPS usb/tty converter detected > Jun 1 07:15:27 mylaptop kernel: usb 1-1.4: Garmin GPS usb/tty converter now attached to ttyUSB1 From naranjo.manuel at gmail.com Fri Jun 1 09:17:22 2007 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Fri, 01 Jun 2007 12:17:22 -0300 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <466012A4.90608@gatworks.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> <466012A4.90608@gatworks.com> Message-ID: <46603882.5050701@gmail.com> Uncle George escribi?: > Manuel Naranjo wrote: > In the case of my module, you can > >> unplug the device but it will not delete the symlink until those apps >> that had opened the port has closed it. T >> > > Did u also mean for this to happen? USB0 was not closed by application. > > Apparently USB1 got created when USB device was plugged back in. There > is only one USB device on a 4 port USB hub. > > This also seems to suggest that application recovery to be impossible. > Exactly there's a dead symlink (you can read and write to it and nothing will happen) and a new port will be created when a new device is connencted. From netbeans at gatworks.com Fri Jun 1 10:20:46 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 12:20:46 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <46603882.5050701@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> <466012A4.90608@gatworks.com> <46603882.5050701@gmail.com> Message-ID: <4660475E.5090202@gatworks.com> Not sure what u mean by "symlink". U cant read/write to it anymore. U get I/O error. In this scenario the device effectively went dead, and only solution is to close the channel. reconnecting the USB device, although dead, but not closed, will create a second device. This does not seem to be a desirable side-effect. The user will now have ttyUSB1, wondering where did ttyUSB0 go to. The application will also be in a confused state, as well as RXTX, because RXTX wont know about ttyUSB1. Manuel Naranjo wrote: > Uncle George escribi?: >> Manuel Naranjo wrote: >> In the case of my module, you can >> >>> unplug the device but it will not delete the symlink until those apps >>> that had opened the port has closed it. T >>> >> Did u also mean for this to happen? USB0 was not closed by application. >> >> Apparently USB1 got created when USB device was plugged back in. There >> is only one USB device on a 4 port USB hub. >> >> This also seems to suggest that application recovery to be impossible. >> > Exactly there's a dead symlink (you can read and write to it and nothing > will happen) and a new port will be created when a new device is connencted. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From arnab.bhaumik at gmail.com Mon Jun 4 01:40:16 2007 From: arnab.bhaumik at gmail.com (arnab bhaumik) Date: Mon, 4 Jun 2007 13:10:16 +0530 Subject: [Rxtx] full duplex com port with rxtx Message-ID: hi , till now i did half duplex communication with rxtx package on com package. my question is : is it possible to use com port with full duplex mode with rxtx package . ther is example of SimpleRead class and SimpleWrite class. it is clear that if i can use both the class simultaneously then full duplex is possible......... arnab/vu2bpw -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070604/6edb0453/attachment-0006.html From lists at iDIAcomputing.com Mon Jun 4 07:53:17 2007 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Mon, 04 Jun 2007 09:53:17 -0400 Subject: [Rxtx] full duplex com port with rxtx In-Reply-To: References: Message-ID: <4664194D.90301@iDIAcomputing.com> arnab bhaumik wrote: > hi , > > till now i did half duplex communication with rxtx package on com > package. > > my question is : is it possible to use com port with full duplex mode > with rxtx package . > > > ther is example of SimpleRead class and SimpleWrite class. it is > clear that if i can use both the class simultaneously then full duplex > is possible......... I haven't looked at the SimpleRead and SimpleWrite classes (I originally wrote my code for the javax.comm api), but full duplex is certainly possible. My CommReader class requires an object analogous to a OutputStream or Writer. When started, it spawns a thread that reads the comm port and writes to that output device. In this way the input is asynchronous and dependent on the actual input data. For full duplex, I extend that class with CommReaderWriter, which adds synchronous output methods. Hope that helps, George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From supsoop at hotmail.com Mon Jun 4 15:21:06 2007 From: supsoop at hotmail.com (soop soop) Date: Mon, 04 Jun 2007 21:21:06 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- Message-ID: Hi Guys, Looked through the archives but still cannot figure this out. I have a Motorola G24 GPRS/GSM modem that I am connecting to my server running Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not detecting the port, CommPortIdentifier.getPortIdentifiers(). I have added the line to RXTXCommDriver: "ttyACM" // for USB Modems Rxtx still does not seem to find the port. Is there something I am missing to make this port visable? [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control Model driver for USB modems and ISDN adapters I really need your help as I have moved my server from windows to Linux and have been down for a few days because of this .. Thanks so much! _________________________________________________________________ PC Magazine’s 2007 editors’ choice for best Web mail—award-winning Windows Live Hotmail. http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 From tjarvi at qbang.org Mon Jun 4 16:17:35 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Jun 2007 16:17:35 -0600 (MDT) Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: On Mon, 4 Jun 2007, soop soop wrote: > Hi Guys, > > Looked through the archives but still cannot figure this out. I have a > Motorola G24 GPRS/GSM modem that I am connecting to my server running Ubuntu. > I can see my modem as is shows up as ttyACM0, but RXTX is not detecting the > port, CommPortIdentifier.getPortIdentifiers(). > > I have added the line to RXTXCommDriver: > > "ttyACM" // for USB Modems > > Rxtx still does not seem to find the port. Is there something I am missing to > make this port visable? > > [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver > [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device > [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control Model > driver for USB modems and ISDN adapters > > I really need your help as I have moved my server from windows to Linux and > have been down for a few days because of this .. Thanks so much! > You could try the INSTALL documentation that comes with the source for possible solutions. Those usually involve lockfile creation, permissions on the device file or the device is in use by another application (even another session of your application). The usual commands: ls -l /dev/ttyACM0 fuser /dev/ttyACM0 touch /var/lock/LCK.testfile && rm -f /var/lock/LCK.testfile whoami To disable lockfiles: ../configure --disable-lockfiles && make install -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Jun 4 16:22:52 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 04 Jun 2007 18:22:52 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <466490BC.3090801@gatworks.com> soop soop wrote: > I really need your help as I have moved my server from windows to Linux > and have been down for a few days because of this .. Thanks so much! can u open the device ? ie is the file protection/permissions keeping you out? From supsoop at hotmail.com Mon Jun 4 16:44:40 2007 From: supsoop at hotmail.com (soop soop) Date: Mon, 04 Jun 2007 22:44:40 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <466490BC.3090801@gatworks.com> Message-ID: Thanks for the reply, I see no exceptions being thrown, just no detection of the port whats so ever. I will run rxtx in debug mode and log. If this were a permissions issue would I not see some exceptions being thrown? >From: Uncle George >Reply-To: RXTX Developers and Users >To: RXTX Developers and Users >Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >Date: Mon, 04 Jun 2007 18:22:52 -0400 > >soop soop wrote: > > > I really need your help as I have moved my server from windows to Linux > > and have been down for a few days because of this .. Thanks so much! > >can u open the device ? ie is the file protection/permissions keeping >you out? >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ Get a preview of Live Earth, the hottest event this summer - only on MSN http://liveearth.msn.com?source=msntaglineliveearthhm From netbeans at gatworks.com Mon Jun 4 17:06:15 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 04 Jun 2007 19:06:15 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <46649AE7.10405@gatworks.com> Exceptions on what? On startup it wants to lookup all devices in /dev that it is capable of opening ( within the list of specific 'comm' devices ). If it cannot open, then does not get onto list. Part of this process, if configured, will also test if the "LOCK" schema can also be opened for the device. then it gets on the list of avail comm port. soop soop wrote: > Thanks for the reply, > > I see no exceptions being thrown, just no detection of the port whats so > ever. I will run rxtx in debug mode and log. If this were a permissions > issue would I not see some exceptions being thrown? > > >> From: Uncle George >> Reply-To: RXTX Developers and Users >> To: RXTX Developers and Users >> Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >> Date: Mon, 04 Jun 2007 18:22:52 -0400 >> >> soop soop wrote: >> >>> I really need your help as I have moved my server from windows to Linux >>> and have been down for a few days because of this .. Thanks so much! >> can u open the device ? ie is the file protection/permissions keeping >> you out? >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _________________________________________________________________ > Get a preview of Live Earth, the hottest event this summer - only on MSN > http://liveearth.msn.com?source=msntaglineliveearthhm > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From alex.flint at gmail.com Mon Jun 4 21:31:49 2007 From: alex.flint at gmail.com (Alex Flint) Date: Tue, 5 Jun 2007 13:01:49 +0930 Subject: [Rxtx] random EXCEPTION_ACCESS_VIOLATION errors Message-ID: Hi All, I'm running winXP and RXTX 2.1-7r2 (the latest from the webpage as of June 2007). I'm sending sequences of 64 lines (each line has about 15 chars) at various intervals. The strings are sent fine, until I get the following error (from hs_err_pid3316.log, at the end of this email). What can I do to avoid the error? Obviously this is a low-level memory exception, but is there any way I can keep the JVM running after such an error? I noticed the exact same problem here: http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20070129/1180520.html Cheers, Alex # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x100034fb, pid=3316, tid=2400 # # Java VM: Java HotSpot(TM) Client VM (1.6.0_01-b06 mixed mode, sharing) # Problematic frame: # C [rxtxSerial.dll+0x34fb] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # --------------- T H R E A D --------------- Current thread (0x00386400): JavaThread "main" [_thread_in_native, id=2400] siginfo: ExceptionCode=0xc0000005, reading address 0x20726f78 Registers: EAX=0x20726f20, EBX=0x6d8922c0, ECX=0x00000005, EDX=0x20726f20 ESP=0x003efa30, EBP=0x003efb68, ESI=0x269728a0, EDI=0x00386400 EIP=0x100034fb, EFLAGS=0x00010212 Top of Stack: (sp=0x003efa30) 0x003efa30: 003efa3c 003efa64 0000000f ffffffff 0x003efa40: 003efa40 2a97f808 003efa6c 2b190ca8 0x003efa50: 00000000 2b190ec0 003efa90 008e2dd7 0x003efa60: 003efa90 008e2dd7 26977f88 6d815e72 0x003efa70: 00000004 2696eae0 0000008a 003efb0c 0x003efa80: 6d852b4a 2696eae0 00000003 26970930 0x003efa90: 000000cb 2696eae0 6d86b264 00385d40 0x003efaa0: 0000003f 003efb0c 26977f90 2ace65d8 Instructions: (pc=0x100034fb) 0x100034eb: ff ff 8d 76 00 eb 02 89 f6 90 8b 45 f8 8b 55 f8 0x100034fb: 8b 4a 58 83 c9 04 89 48 58 83 c4 f8 8b 45 f8 8b Stack: [0x003a0000,0x003f0000), sp=0x003efa30, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x34fb] Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j gnu.io.RXTXPort.writeArray([BIIZ)V+0 j gnu.io.RXTXPort$SerialOutputStream.write([B)V+76 j com.bjt.media.server.CommLink.send(Ljava/lang/String;)V+48 j com.bjt.media.server.DigitoolConnection.select(I)V+73 j com.bjt.media.server.DigitoolConnection.main([Ljava/lang/String;)V+74 v ~StubRoutines::call_stub --------------- P R O C E S S --------------- Java Threads: ( => current thread ) 0x02a69400 JavaThread "Thread-0" [_thread_in_native, id=3052] 0x02a4d000 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=3920] 0x02a48400 JavaThread "CompilerThread0" daemon [_thread_blocked, id=1968] 0x02a47400 JavaThread "Attach Listener" daemon [_thread_blocked, id=2984] 0x02a46400 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=2660] 0x02a41c00 JavaThread "Finalizer" daemon [_thread_blocked, id=3924] 0x02a3d800 JavaThread "Reference Handler" daemon [_thread_blocked, id=4008] =>0x00386400 JavaThread "main" [_thread_in_native, id=2400] Other Threads: 0x02a34400 VMThread [id=3708] 0x02a4e800 WatcherThread [id=3964] VM state:not at safepoint (normal execution) VM Mutex/Monitor currently owned by a thread: None Heap def new generation total 960K, used 131K [0x22960000, 0x22a60000, 0x22e40000) eden space 896K, 7% used [0x22960000, 0x22970ea8, 0x22a40000) from space 64K, 99% used [0x22a50000, 0x22a5fff8, 0x22a60000) to space 64K, 0% used [0x22a40000, 0x22a40000, 0x22a50000) tenured generation total 4096K, used 76K [0x22e40000, 0x23240000, 0x26960000) the space 4096K, 1% used [0x22e40000, 0x22e53060, 0x22e53200, 0x23240000) compacting perm gen total 12288K, used 137K [0x26960000, 0x27560000, 0x2a960000) the space 12288K, 1% used [0x26960000, 0x26982518, 0x26982600, 0x27560000) ro space 8192K, 62% used [0x2a960000, 0x2ae5e4e8, 0x2ae5e600, 0x2b160000) rw space 12288K, 52% used [0x2b160000, 0x2b7a0e78, 0x2b7a1000, 0x2bd60000) Dynamic libraries: 0x00400000 - 0x00423000 C:\Program Files\Java\jre1.6.0_01\bin\javaw.exe 0x7c900000 - 0x7c9b0000 C:\WINDOWS\system32\ntdll.dll 0x7c800000 - 0x7c8f4000 C:\WINDOWS\system32\kernel32.dll 0x77dd0000 - 0x77e6b000 C:\WINDOWS\system32\ADVAPI32.dll 0x77e70000 - 0x77f01000 C:\WINDOWS\system32\RPCRT4.dll 0x7e410000 - 0x7e4a0000 C:\WINDOWS\system32\USER32.dll 0x77f10000 - 0x77f57000 C:\WINDOWS\system32\GDI32.dll 0x76390000 - 0x763ad000 C:\WINDOWS\system32\IMM32.DLL 0x7c340000 - 0x7c396000 C:\Program Files\Java\jre1.6.0_01\bin\msvcr71.dll 0x6d7c0000 - 0x6da07000 C:\Program Files\Java\jre1.6.0_01\bin\client\jvm.dll 0x76b40000 - 0x76b6d000 C:\WINDOWS\system32\WINMM.dll 0x5cd70000 - 0x5cd77000 C:\WINDOWS\system32\serwvdrv.dll 0x5b0a0000 - 0x5b0a7000 C:\WINDOWS\system32\umdmxfrm.dll 0x6d310000 - 0x6d318000 C:\Program Files\Java\jre1.6.0_01\bin\hpi.dll 0x76bf0000 - 0x76bfb000 C:\WINDOWS\system32\PSAPI.DLL 0x6d770000 - 0x6d77c000 C:\Program Files\Java\jre1.6.0_01\bin\verify.dll 0x6d3b0000 - 0x6d3cf000 C:\Program Files\Java\jre1.6.0_01\bin\java.dll 0x6d7b0000 - 0x6d7bf000 C:\Program Files\Java\jre1.6.0_01\bin\zip.dll 0x10000000 - 0x10012000 C:\Documents and Settings\Alex\workspace\MediaServer\rxtxSerial.dll 0x73d90000 - 0x73db7000 C:\WINDOWS\system32\crtdll.dll VM Arguments: jvm_args: -Djava.library.path=C:\Documents and Settings\Alex\workspace\MediaServer java_command: com.bjt.media.server.DigitoolConnection Launcher Type: SUN_STANDARD Environment Variables: CLASSPATH=.;C:\Program Files\Java\j2re1.4.2_07\lib\ext\QTJava.zip PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\wbem;c:\applications\php;C:\Program Files\MATLAB\R2006a\bin\win32;C:\Roger\Projects\UAV\Bin\Debug;C:\Program Files\Microsoft SQL Server\80\Tools\Binn\;c:\Program Files\Microsoft SQL Server\90\Tools\binn\;C:\Program Files\QuickTime\QTSystem\;C:\Pfps\system;C:\Program Files\Java\jdk1.6.0_01\bin;C:\Program Files\Java\jdk1.6.0_01\jre\bin USERNAME=Alex OS=Windows_NT PROCESSOR_IDENTIFIER=x86 Family 15 Model 4 Stepping 1, GenuineIntel --------------- S Y S T E M --------------- OS: Windows XP Build 2600 Service Pack 2 CPU:total 1 family 15, cmov, cx8, fxsr, mmx, sse, sse2 Memory: 4k page, physical 1046508k(275288k free), swap 2522816k(1909176k free) vm_info: Java HotSpot(TM) Client VM (1.6.0_01-b06) for windows-x86, built on Mar 14 2007 00:24:02 by "java_re" with unknown MS VC++:1310 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070604/c87ae1f0/attachment-0006.html From alwyn.schoeman at gmail.com Tue Jun 5 00:10:19 2007 From: alwyn.schoeman at gmail.com (Alwyn Schoeman) Date: Tue, 5 Jun 2007 08:10:19 +0200 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Hi, I'm using a similar modem. By default rxtx doesn't look for devices that start with ACM, so you need to modify the source code and recompile. Look in RXTXCommDriver and add values for ACM in the registerScannedPorts method in the Linux specific parts. Look for osName.equals("Linux")... On 6/4/07, soop soop wrote: > > Hi Guys, > > Looked through the archives but still cannot figure this out. I have a > Motorola G24 GPRS/GSM modem that I am connecting to my server running > Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not > detecting the port, CommPortIdentifier.getPortIdentifiers(). > > I have added the line to RXTXCommDriver: > > "ttyACM" // for USB Modems > > Rxtx still does not seem to find the port. Is there something I am missing > to make this port visable? > > [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver > [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device > [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control > Model > driver for USB modems and ISDN adapters > > I really need your help as I have moved my server from windows to Linux > and > have been down for a few days because of this .. Thanks so much! > > _________________________________________________________________ > PC Magazine's 2007 editors' choice for best Web mail?award-winning Windows > Live Hotmail. > > http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -- Alwyn Schoeman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/b6cb3053/attachment-0006.html From naranjo.manuel at gmail.com Tue Jun 5 06:48:45 2007 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Tue, 05 Jun 2007 09:48:45 -0300 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> References: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Message-ID: <46655BAD.7010501@gmail.com> That's right, an easier solution is creating symlinks to acm. For example make ttyS70 to 79 point to ACM0 to 9 and that will help you a lot, and doesn't even require compile. > Hi, > > I'm using a similar modem. By default rxtx doesn't look for devices > that start with ACM, so you need to modify the > source code and recompile. > > Look in RXTXCommDriver and add values for ACM in the > registerScannedPorts method in the Linux specific parts. Look for > osName.equals("Linux")... > From juanemc2 at gmail.com Tue Jun 5 07:02:43 2007 From: juanemc2 at gmail.com (Juan) Date: Tue, 5 Jun 2007 10:02:43 -0300 Subject: [Rxtx] Problems with Epson TMU220B POSPrinter using XON/XOFF Flow Control and rxtx jar and dll's with the serial port. Message-ID: Hi!, I?m having trouble printing to the serial port using the latest version of rxtx jar and dll's with an Epson POSPrinter. I`ve switched the printer to work with XON/XOFF Flow Control and have watched the serial port to be sure the printer is sending the XON XOFF stop and go characters. I`ve setted the port like this: CommPortIdentifier commPortIdentifier = CommPortIdentifier.* getPortIdentifier*(_portName); SerialPort serialPort = (SerialPort)commPortIdentifier.open(*this*.getClass().getName(), 2000); serialPort.setSerialPortParams(_baudRate, _dataBits, _stopBits, _parity); serialPort.setFlowControlMode( SerialPort.*FLOWCONTROL_XONXOFF_IN* | SerialPort.*FLOWCONTROL_XONXOFF_OUT*); where the baudRate is 9600 the dataBits is 8 the stopBits is 1 and the parity is 0 It seems as the library isn`t taking into account the XON XOFF setting. I would like to know if I`m setting correctly the Flow Control and if you had had any experiences using XON XOFF flow control and could give me some help to solve my problem. I`m very thankful in advance, Yours, Juan Polero -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/b080995a/attachment-0006.html From ehdez.correo at gmail.com Tue Jun 5 07:12:53 2007 From: ehdez.correo at gmail.com (=?ISO-8859-1?Q?Enrique_Hern=E1ndez?=) Date: Tue, 5 Jun 2007 09:12:53 -0400 Subject: [Rxtx] problem with rxtx Message-ID: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Hello: I doing a simple test to show the serial ports. This is the code: import java.util.Enumeration; import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; public class Show { private Enumeration portList; private CommPortIdentifier portId; private SerialPort port; /** Creates a new instance of Show */ public Show() { } public static void main(String args[]){ Show show = new Show(); show.portList = CommPortIdentifier.getPortIdentifiers(); String tPort = ""; System.out.println("========================================="); while(show.portList.hasMoreElements()){ show.portId = (CommPortIdentifier)show.portList.nextElement(); if(show.portId.getPortType() == CommPortIdentifier.PORT_SERIAL) tPort = "Serial"; else tPort = "Parallel"; System.out.println(show.portId.getName() + " " + tPort); } } } whit The problem is that this code not show the serial ports, this show the no use serial ports. I want to connect whit the modem but when windows open and connect the modem my application don't see the port(COMM3) when it is connect. what I can do? Is that the correct way to know the ports? thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/eedd744b/attachment-0006.html From ehdez.correo at gmail.com Tue Jun 5 07:42:13 2007 From: ehdez.correo at gmail.com (=?ISO-8859-1?Q?Enrique_Hern=E1ndez?=) Date: Tue, 5 Jun 2007 09:42:13 -0400 Subject: [Rxtx] serial port Message-ID: <4a814e1f0706050642p4ce9ac7bka80f9479c524c5ea@mail.gmail.com> Hello: How I can ask to the port what device is connect and information about this device. thanks. bye. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/4d10d26a/attachment-0006.html From supsoop at hotmail.com Tue Jun 5 09:29:00 2007 From: supsoop at hotmail.com (soop soop) Date: Tue, 05 Jun 2007 15:29:00 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Message-ID: Hi Guys, Thanks for all your help. I found the problem. I created a user, Tomcat55, for my tomcat but it did not belong to any group. I then added this user to dialout group to have access to the device ttyACM0. Works perfectly! Again permissions was the issue. This also seems to be persistent as a server reboot does not effect the access. Cheers! >From: "Alwyn Schoeman" >Reply-To: RXTX Developers and Users >To: "RXTX Developers and Users" >Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >Date: Tue, 5 Jun 2007 08:10:19 +0200 > >Hi, > >I'm using a similar modem. By default rxtx doesn't look for devices that >start with ACM, so you need to modify the >source code and recompile. > >Look in RXTXCommDriver and add values for ACM in the registerScannedPorts >method in the Linux specific parts. Look for osName.equals("Linux")... > >On 6/4/07, soop soop wrote: >> >>Hi Guys, >> >>Looked through the archives but still cannot figure this out. I have a >>Motorola G24 GPRS/GSM modem that I am connecting to my server running >>Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not >>detecting the port, CommPortIdentifier.getPortIdentifiers(). >> >>I have added the line to RXTXCommDriver: >> >>"ttyACM" // for USB Modems >> >>Rxtx still does not seem to find the port. Is there something I am missing >>to make this port visable? >> >>[ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver >>[ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device >>[ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control >>Model >>driver for USB modems and ISDN adapters >> >>I really need your help as I have moved my server from windows to Linux >>and >>have been down for a few days because of this .. Thanks so much! >> >>_________________________________________________________________ >>PC Magazine's 2007 editors' choice for best Web mail—award-winning Windows >>Live Hotmail. >> >>http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 >> >> >>_______________________________________________ >>Rxtx mailing list >>Rxtx at qbang.org >>http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > >-- >Alwyn Schoeman >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ Need a break? Find your escape route with Live Search Maps. http://maps.live.com/default.aspx?ss=Restaurants~Hotels~Amusement%20Park&cp=33.832922~-117.915659&style=r&lvl=13&tilt=-90&dir=0&alt=-1000&scene=1118863&encType=1&FORM=MGAC01 From netbeans at gatworks.com Tue Jun 5 09:42:31 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 11:42:31 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <46658467.20101@gatworks.com> soop soop wrote: > > Hi Guys, > > Thanks for all your help. I found the problem. I created a user, > Tomcat55, for my tomcat but it did not belong to any group. I then added Look at man pages for the program udev. From tjarvi at qbang.org Tue Jun 5 18:18:17 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Jun 2007 18:18:17 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Message-ID: On Tue, 5 Jun 2007, Enrique Hern?ndez wrote: > The problem is that this code not show the serial ports, this show the no > use serial ports. I want to connect whit the modem but when windows open and > connect the modem my application don't see the port(COMM3) when it is > connect. > what I can do? > Is that the correct way to know the ports? > Hello, We may have problems understanding each other. On windows, the port will not be an available serial port if another application has the port open. That is just how the library behaves. If you can not see the port in the enumerated list, you could not open it. Also note that enumeration only happens once. If you add a port such as a new USB dongle, the port will not be visible until the next time your application runs. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Tue Jun 5 18:45:01 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 20:45:01 -0400 Subject: [Rxtx] problem with rxtx In-Reply-To: References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Message-ID: <4666038D.8090700@gatworks.com> Trent Jarvi wrote: > > > Also note that enumeration only happens once. If you add a port such as > a new USB dongle, the port will not be visible until the next time your > application runs. Is this written in stone ? somewhere? From tjarvi at qbang.org Tue Jun 5 18:54:36 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Jun 2007 18:54:36 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <4666038D.8090700@gatworks.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> Message-ID: On Tue, 5 Jun 2007, Uncle George wrote: > Trent Jarvi wrote: >> >> >> Also note that enumeration only happens once. If you add a port such as >> a new USB dongle, the port will not be visible until the next time your >> application runs. > > Is this written in stone ? somewhere? It is just the current behavior. There is nothing preventing a fix that allows reenumeration. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Tue Jun 5 19:55:19 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 21:55:19 -0400 Subject: [Rxtx] problem with rxtx In-Reply-To: References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> Message-ID: <46661407.4020308@gatworks.com> >> Is this written in stone ? somewhere? > > It is just the current behavior. There is nothing preventing a fix that > allows reenumeration. With usb, ..... , things come and go. Seems a shame that you have to kill application to get at the device u just plugged in. From joachim at buechse.ch Wed Jun 6 01:50:06 2007 From: joachim at buechse.ch (Joachim Buechse) Date: Wed, 6 Jun 2007 09:50:06 +0200 Subject: [Rxtx] problem with rxtx In-Reply-To: <46661407.4020308@gatworks.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> <46661407.4020308@gatworks.com> Message-ID: <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> On MacOS RXTX's enumeration handling is more flexible. It will find new ports that are added during the lifetime of the application. But this is inherently incompatible with suns javax.comm implementation... Regards, Joachim On 06.06.2007, at 03:55, Uncle George wrote: > >>> Is this written in stone ? somewhere? >> >> It is just the current behavior. There is nothing preventing a >> fix that >> allows reenumeration. > > With usb, ..... , things come and go. Seems a shame that you have to > kill application to get at the device u just plugged in. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Jun 6 06:06:48 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Jun 2007 06:06:48 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> <46661407.4020308@gatworks.com> <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> Message-ID: Sun's javax.comm is not a major concern going forward. As long as we do not break old applications using rxtx, I see no reason to limit rxtx to that convention. We have already rejected version 3 from Sun as a dead end and limited our compatability to version 2. That does not mean we will not try to work with Sun and others but the current javax.comm convention (v3) is not a well conceived path. There has been discussion about doing a JSR which is one valid option. On Wed, 6 Jun 2007, Joachim Buechse wrote: > On MacOS RXTX's enumeration handling is more flexible. It will find > new ports that are added during the lifetime of the application. But > this is inherently incompatible with suns javax.comm implementation... > > Regards, > Joachim > > On 06.06.2007, at 03:55, Uncle George wrote: > >> >>>> Is this written in stone ? somewhere? >>> >>> It is just the current behavior. There is nothing preventing a >>> fix that >>> allows reenumeration. >> >> With usb, ..... , things come and go. Seems a shame that you have to >> kill application to get at the device u just plugged in. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From yvespielusenet at free.fr Wed Jun 6 08:46:35 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 16:46:35 +0200 Subject: [Rxtx] [PARALLEL] resource in use Message-ID: <1181141195.3407.20.camel@localhost.localdomain> Hello, I want to use rxtx in my application. I haveto send data to a very old printer (which have a drum and hammers http://perso.orange.fr/tiie/page00010017.html) This is printer is connecter with centronics. It works well but, while it's writting and I putthe printer off-line, after about 45 seconds, I have this error : ------------------------------------- java.io.IOException: La ressource demand?e est en cours d'utilisation. in writeArray at gnu.io.LPRPort.writeArray(Native Method) at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:292) at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:161) at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:156) at mce.buffer.bufferManager.BufferManager$PrintBuffer.run(BufferManager.java:141) The IOexception means "The wanted resource is in use" ------------------------------------- Here is the line 141 of BufferManager : ------------------------------------- while(send){ try{ fos.write(bb); <=== line 141 send = false; } catch(Exception e){ javax.swing.JOptionPane.showMessageDialog(null, "Erreur d'envoie. Veuillez cliquer sur OK pour relancer l'impression de la vignette.\nV?rifiez votre impression !", "Erreur d'envoie", javax.swing.JOptionPane.WARNING_MESSAGE); e.printStackTrace(System.err); System.err.flush(); System.out.println(e); send = true; } } -------------------------------- 'fos' is an outputstream which contains the rxtx stream (this.os is the rxtx outputstream) : -------------------------------- public void write(byte[] bb) throws IOException{ this.write(bb, 0, bb.length); } public void write(byte[] bb, int off, int len) throws IOException{ while(!imp1.isPrinterSelected() || !imp2.isPrinterSelected()){ } this.os.write(bb, off, len); } -------------------------------- Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( can you help me ? thank you :) -- yves piel From yvespielusenet at free.fr Wed Jun 6 09:11:15 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 17:11:15 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181141195.3407.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> Message-ID: <1181142675.3407.23.camel@localhost.localdomain> I forgot to tell that It's under windows XP and java 1.5. Le mercredi 06 juin 2007 ? 16:46 +0200, yves pielusenet a ?crit : > Hello, > I want to use rxtx in my application. I haveto send data to a very old > printer (which have a drum and hammers > http://perso.orange.fr/tiie/page00010017.html) > This is printer is connecter with centronics. It works well but, while > it's writting and I putthe printer off-line, after about 45 seconds, I > have this error : > ------------------------------------- > java.io.IOException: La ressource demand?e est en cours d'utilisation. > in writeArray > at gnu.io.LPRPort.writeArray(Native Method) > at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:292) > at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:161) > at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:156) > at mce.buffer.bufferManager.BufferManager$PrintBuffer.run(BufferManager.java:141) > > The IOexception means "The wanted resource is in use" > ------------------------------------- > > Here is the line 141 of BufferManager : > > ------------------------------------- > while(send){ > try{ > fos.write(bb); <=== line 141 > send = false; > } > catch(Exception e){ > javax.swing.JOptionPane.showMessageDialog(null, "Erreur d'envoie. Veuillez cliquer sur OK pour relancer l'impression de la vignette.\nV?rifiez votre impression !", "Erreur d'envoie", javax.swing.JOptionPane.WARNING_MESSAGE); > e.printStackTrace(System.err); > System.err.flush(); > System.out.println(e); > send = true; > } > } > -------------------------------- > 'fos' is an outputstream which contains the rxtx stream (this.os is the rxtx outputstream) : > > -------------------------------- > public void write(byte[] bb) throws IOException{ > this.write(bb, 0, bb.length); > } > public void write(byte[] bb, int off, int len) throws IOException{ > while(!imp1.isPrinterSelected() || !imp2.isPrinterSelected()){ > } > this.os.write(bb, off, len); > } > -------------------------------- > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > can you help me ? > > thank you :) > From netbeans at gatworks.com Wed Jun 6 09:21:46 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 11:21:46 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181141195.3407.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> Message-ID: <4666D10A.8000507@gatworks.com> } > -------------------------------- > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > can you help me ? > > thank you :) > windoz or linux? ( I guess windoz ) for windoz, there appears to be a timeout ( as Comments suggest ) of about 40seconds. > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } for linux, there is no implied timeout. > if( write( fd, bytes, count ) < 0 ) > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); From netbeans at gatworks.com Wed Jun 6 09:39:41 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 11:39:41 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666D10A.8000507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> Message-ID: <4666D53D.90000@gatworks.com> Uncle George wrote: > } >> -------------------------------- >> >> Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( >> >> can you help me ? From reading the code, I can see your concern. And it appears you are correct, because some of the data will be sent to the OS printer buffers, and then it will refuse to accept anymore. Unfortunately, writeArray does not return the num of characters written :{ So application has no idea to how many characters were accepted by the OS. I dont do windoz, so I cant say with absolute certainty what windoz will do with an off-line condition. If you have the source, and can compile, then maybe u can increase the loop count to hit 4hours? From yvespielusenet at free.fr Wed Jun 6 09:53:25 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 17:53:25 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666D10A.8000507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> Message-ID: <1181145205.3407.35.camel@localhost.localdomain> Thank you for your explanation :) This timeout comes when no data has been send to the printer after 40seconds if I well understand. But why there is such a timeout ? If I setthe printer offline while it's printing I mustn't have an exception. I don't understand why the "printer should solv all problems like buffer full" in 40 seconds. If I pause the printer the buffer will not be emptied, isn't it ? I not very familiar with C/C++, but it seem that the exception is thrown only when countWritten == 0, that means no data at all has been sent. So Is my code is good since when I intercept this exception I send all my buffer again. There is no way that the printer receive two times same bytes ? thanks ps: yes the application is running on windows XP since I developpe under Debian Le mercredi 06 juin 2007 ? 11:21 -0400, Uncle George a ?crit : > } > > -------------------------------- > > > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > > > can you help me ? > > > > thank you :) > > > > windoz or linux? ( I guess windoz ) > > for windoz, there appears to be a timeout ( as Comments suggest ) of > about 40seconds. > > while( count > 0 ){ > > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > > /* > > this are 20 * 2 seconds, in this time a printer (or other parallel device) > > should solv all problems like buffer full, etc > > */ > > if(errorCount++ < 20){ > > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > > continue; > > } > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > for linux, there is no implied timeout. > > if( write( fd, bytes, count ) < 0 ) > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Wed Jun 6 10:34:24 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 12:34:24 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181145205.3407.35.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> Message-ID: <4666E210.30507@gatworks.com> yves pielusenet wrote: > Thank you for your explanation :) > This timeout comes when no data has been send to the printer after > 40seconds if I well understand. But why there is such a timeout ? If I > setthe printer offline while it's printing I mustn't have an exception. > I don't understand why the "printer should solv all problems like buffer > full" in 40 seconds. If I pause the printer the buffer will not be > emptied, isn't it ? > > I not very familiar with C/C++, but it seem that the exception is thrown > only when countWritten == 0, that means no data at all has been sent. So > Is my code is good since when I intercept this exception I send all my > buffer again. There is no way that the printer receive two times same > bytes ? More technically, the function call returns and reports that 0 characters was written in this call. when 0 characters are written, it will check how many times 0 characters was written. If it has tried LESS than 20 times(errorCount), it will sleep() and try to write again. After 20 times, it wont sleep, but throw you the exception. Now suppose you are writing a 120 character line. you off-lined/paused your printer. The OS has room for 80 more characters in it's printer buffer. The WriteFile() will have a char count of 120, but on return the countWritten = 80. You still have 40 more characters to print. Since countWritten != 0, the counters: bytes += countWritten; count -= countWritten; get updated, and the Writefile now has a count of 40 characters. Since the printer is off-line, the countwritten is 0. And so the loop continues, till 40 seconds is up. As to why it is this way, i dont know ( not a windoz maven ); Also the sleep(20) in the loop is not so intuitive to suggest 2 seconds of sleep. I would have guessed 20seconds, or 20milliseconds. But go figure. BTW: Since your computer sends you error messages in French, does it curse in English? :)))) From yvespielusenet at free.fr Thu Jun 7 02:27:44 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Thu, 07 Jun 2007 10:27:44 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666E210.30507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> Message-ID: <1181204864.3501.10.camel@localhost.localdomain> Maybe in my case I should re-compile rxtx and change the code. Instead of send an exception I should display a dialog box to ask if it's printer problem or if it should trie to send bytes. Something like : while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } if(displayDialogBox("Try again to send datas ??")){ errorCount = 0; } else{ throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } } Le mercredi 06 juin 2007 ? 12:34 -0400, Uncle George a ?crit : > yves pielusenet wrote: > > Thank you for your explanation :) > > This timeout comes when no data has been send to the printer after > > 40seconds if I well understand. But why there is such a timeout ? If I > > setthe printer offline while it's printing I mustn't have an exception. > > I don't understand why the "printer should solv all problems like buffer > > full" in 40 seconds. If I pause the printer the buffer will not be > > emptied, isn't it ? > > > > I not very familiar with C/C++, but it seem that the exception is thrown > > only when countWritten == 0, that means no data at all has been sent. So > > Is my code is good since when I intercept this exception I send all my > > buffer again. There is no way that the printer receive two times same > > bytes ? > More technically, the function call returns and reports that 0 > characters was written in this call. > when 0 characters are written, it will check how many times 0 characters > was written. If it has tried LESS than 20 times(errorCount), it will > sleep() and try to write again. > After 20 times, it wont sleep, but throw you the exception. > > Now suppose you are writing a 120 character line. you off-lined/paused > your printer. The OS has room for 80 more characters in it's printer > buffer. The WriteFile() will have a char count of 120, but on return the > countWritten = 80. You still have 40 more characters to print. > Since countWritten != 0, the counters: > bytes += countWritten; > count -= countWritten; > get updated, and the Writefile now has a count of 40 characters. Since > the printer is off-line, the countwritten is 0. And so the loop > continues, till 40 seconds is up. > > As to why it is this way, i dont know ( not a windoz maven ); > Also the sleep(20) in the loop is not so intuitive to suggest 2 seconds > of sleep. I would have guessed 20seconds, or 20milliseconds. But go figure. > > BTW: Since your computer sends you error messages in French, does it > curse in English? :)))) > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 06:11:43 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 08:11:43 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181204864.3501.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> Message-ID: <4667F5FF.8070903@gatworks.com> your suggestion appears good. I dont know what displayDialogBox exactly will do, so all I can say it that it looks good. But I'd like to wait 10min before first dialog box And a 5 min wait for every dialog box there after. And since these are custom solution/choices, maybe a more exact explanation of what the issue is. if(errorCount++ < 300){ // wait 10min ( 10min * 60sec / 2 ) Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } if(displayDialogBox("Printer has Paused. Retry sending data?")){ errorCount = 150; // Wait for 5 min thereafter continue; } > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } yves pielusenet wrote: > Maybe in my case I should re-compile rxtx and change the code. Instead > of send an exception I should display a dialog box to ask if it's > printer problem or if it should trie to send bytes. Something like : > > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > > if(displayDialogBox("Try again to send datas ??")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > } > From yvespielusenet at free.fr Thu Jun 7 07:17:21 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Thu, 07 Jun 2007 15:17:21 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4667F5FF.8070903@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <4667F5FF.8070903@gatworks.com> Message-ID: <1181222241.3501.20.camel@localhost.localdomain> thank you :) 'displayDialogBox()' I think doesn't exist. It was just for the example :) But I think It should not be so complicated to display a dialog box under windows with YES/NO buttons. When yes is clicked it return 0 other it returns 1. Le jeudi 07 juin 2007 ? 08:11 -0400, Uncle George a ?crit : > your suggestion appears good. I dont know what displayDialogBox exactly > will do, so all I can say it that it looks good. > > But I'd like to wait 10min before first dialog box And a 5 min wait for > every dialog box there after. And since these are custom > solution/choices, maybe a more exact explanation of what the issue is. > > if(errorCount++ < 300){ // wait 10min ( 10min * 60sec / 2 ) > Sleep( 20 ); /* make a small pause to execute all other requests > in all other threads */ > continue; > } > > if(displayDialogBox("Printer has Paused. Retry sending data?")){ > errorCount = 150; // Wait for 5 min thereafter > continue; > } > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > > yves pielusenet wrote: > > Maybe in my case I should re-compile rxtx and change the code. Instead > > of send an exception I should display a dialog box to ask if it's > > printer problem or if it should trie to send bytes. Something like : > > > > while( count > 0 ){ > > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > > /* > > this are 20 * 2 seconds, in this time a printer (or other parallel device) > > should solv all problems like buffer full, etc > > */ > > if(errorCount++ < 20){ > > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > > continue; > > } > > > > if(displayDialogBox("Try again to send datas ??")){ > > errorCount = 0; > > } > > else{ > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > } > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 07:41:43 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 09:41:43 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181222241.3501.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <4667F5FF.8070903@gatworks.com> <1181222241.3501.20.camel@localhost.localdomain> Message-ID: <46680B17.8050109@gatworks.com> yves pielusenet wrote: > thank you :) > 'displayDialogBox()' I think doesn't exist. It was just for the > example :) too bad. Good luck. From rtrout at webbresearch.com Thu Jun 7 11:23:04 2007 From: rtrout at webbresearch.com (Robert Trout) Date: Thu, 07 Jun 2007 13:23:04 -0400 Subject: [Rxtx] Disconnected PortServer TS causes Java to hang Message-ID: <1181236984.14186.33.camel@sisyphus.DinkumSoftware.com> I'm running Linux with sun's Java 1.4.2, Java comm API 2.0, RXTX 2.0-7pre1, and the RealPort digi driver. "/dev/ttyrp00" is a RealPort device. My Java application never returns from a ComPortIdentifier.getPortIdentifier("/dev/ttyrp00") call while the Digi PortServer TS 4 is disconnected from the network. If I later re-connect the PortServer, the call returns about 30 seconds later (it's like a serial port read or write is blocking until the PortServer is re- connected). With the PortServer disconnected, minicom immediately responds with "cannot open /dev/ttyrp00: No such file or directory". I would like my Java application to behave similarly. That is, respond with an error condition instead of hanging when the PortServer is not connected. Since minicom and Java behave differently, I think this "hanging" behavior may be due to RXTX or Java? Has anyone had a similar issue? Solutions? Suggestions? Thanks, Robert From vicnevicne at gmail.com Thu Jun 7 12:16:02 2007 From: vicnevicne at gmail.com (Vicne) Date: Thu, 07 Jun 2007 20:16:02 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181204864.3501.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> Message-ID: <46684B62.7080802@gmail.com> yves pielusenet wrote: > Maybe in my case I should re-compile rxtx and change the code. Instead > of send an exception I should display a dialog box to ask if it's > printer problem or if it should trie to send bytes. Something like : > > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > > if(displayDialogBox("Try again to send datas ??")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > } > Sorry to step in without a specific solution to your problem, but I wanted to share my feeling regarding this proposal. AFAIK, it's generally considered bad practice to pop-up a prompt from a library. The main reason is that in general use, you can't guarantee that someone is actually present behind the console. Imagine a print server in a machine room, connected to a park of printers. In that case, when one printer fails, the logical behaviour would be to use an other one. If you change RxTx the way you propose, the printer queue will simply be stuck with a useless "Try again to send data ?" prompt until an administrator opens a remote connection to the print server's console and clicks "no". Second, it would create a dependency upon the existence of a graphical console (if you go the graphical "dialogBox" way). On many applications (typically server or embedded ones), the JVM is "headless" and if you try to pop-up a dialog, your app would throw an exception (at best) or just wouldn't display the prompt anywhere... Going the "text console" way is not more reliable, because on graphical environments, the text console is hidden unless explicitly requested. My advice would be to think again and find another solution. Ideas are : - make the number of retries a parameter so that you can tune it to what you think is reasonable - throw a more specific exception when the number of retries has been reached, so that a specific prompt can be shown at a higher level Anyway, if you feel that the prompt is the way to go in your case, I would at least make that prompt conditional. The least intrusive way would probably be using a system property, like if("true".equals(System.getProperty("org.rxtx.usePrompt")) && displayDialogBox("Retry sending data ?")){ errorCount = 0; } else{ throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } By default, the behaviour would remain as it is now, but you could force the prompts by defining the property at VM launch if desired. (for example : java.exe -Dorg.rxtx.usePrompt=true myApp) Also, you seemed to say you wanted the printer to start again exactly where is stopped. It would indeed be the best way when the printer is put offline for a few seconds. On the other hand, if the printer is turned off (or the printer runs out of paper, or someone steps on the mains cable), then the only way to go back to a "stable" situation would be by printing the item (page, label, etc.) again from scratch... Just my two cents. Vicne PS : By the way, the dialog box thing is very platform dependant on the C-side, and I think the simplest way would probably be to bridge it to a Java call where you can implement it like you proposed : public boolean displayDialogBox(prompt) { return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); } From netbeans at gatworks.com Thu Jun 7 14:08:24 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 16:08:24 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46684B62.7080802@gmail.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> Message-ID: <466865B8.4060004@gatworks.com> My feeling is that the code that was suggested was for his environs ( his shop ). The issue here is that after a 40+ second wait, an exception will be thrown. But you really dont have a way of 'cancelling' all the WriteFiles() that have already occured before the exception so that your writeArray and the Commapi can backtrack to a position in which they are in sync. The main ( really mine ) concern is not to lose data, or replicate data. After 40seconds, 300 seconds, 55min, no matter how long, data should not be lost or duplicated. But as soon as the exception is thrown, that possibility exists. Maybe an event should be thrown instead? Vicne wrote: > yves pielusenet wrote: >> Maybe in my case I should re-compile rxtx and change the code. Instead >> of send an exception I should display a dialog box to ask if it's >> printer problem or if it should trie to send bytes. Something like : >> >> while( count > 0 ){ >> if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ >> /* >> this are 20 * 2 seconds, in this time a printer (or other parallel device) >> should solv all problems like buffer full, etc >> */ >> if(errorCount++ < 20){ >> Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ >> continue; >> } >> >> if(displayDialogBox("Try again to send datas ??")){ >> errorCount = 0; >> } >> else{ >> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >> break; >> } >> } >> > > Sorry to step in without a specific solution to your problem, but I > wanted to share my feeling regarding this proposal. AFAIK, it's > generally considered bad practice to pop-up a prompt from a library. > The main reason is that in general use, you can't guarantee that > someone is actually present behind the console. Imagine a print server > in a machine room, connected to a park of printers. In that case, when > one printer fails, the logical behaviour would be to use an other one. > If you change RxTx the way you propose, the printer queue will simply be > stuck with a useless "Try again to send data ?" prompt until an > administrator opens a remote connection to the print server's console > and clicks "no". > Second, it would create a dependency upon the existence of a > graphical console (if you go the graphical "dialogBox" way). On many > applications (typically server or embedded ones), the JVM is "headless" > and if you try to pop-up a dialog, your app would throw an exception (at > best) or just wouldn't display the prompt anywhere... Going the "text > console" way is not more reliable, because on graphical environments, > the text console is hidden unless explicitly requested. > > My advice would be to think again and find another solution. Ideas are : > - make the number of retries a parameter so that you can tune it to what > you think is reasonable > - throw a more specific exception when the number of retries has been > reached, so that a specific prompt can be shown at a higher level > > Anyway, if you feel that the prompt is the way to go in your case, I > would at least make that prompt conditional. The least intrusive way > would probably be using a system property, like > > if("true".equals(System.getProperty("org.rxtx.usePrompt")) > && displayDialogBox("Retry sending data ?")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > > > By default, the behaviour would remain as it is now, but you could > force the prompts by defining the property at VM launch if desired. (for > example : java.exe -Dorg.rxtx.usePrompt=true myApp) > > > Also, you seemed to say you wanted the printer to start again > exactly where is stopped. It would indeed be the best way when the > printer is put offline for a few seconds. On the other hand, if the > printer is turned off (or the printer runs out of paper, or someone > steps on the mains cable), then the only way to go back to a "stable" > situation would be by printing the item (page, label, etc.) again from > scratch... > > > Just my two cents. > > > Vicne > > PS : By the way, the dialog box thing is very platform dependant on the > C-side, and I think the simplest way would probably be to bridge it to a > Java call where you can implement it like you proposed : > > public boolean displayDialogBox(prompt) { > return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", > JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); > } > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Thu Jun 7 17:48:11 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 Jun 2007 17:48:11 -0600 (MDT) Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <466865B8.4060004@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> Message-ID: An event is possible. I'm amazed this is the largest problem encountered while using the parallel code. How would the write ever exit if we throw events? Isn't this going to lead to hung applications? On Thu, 7 Jun 2007, Uncle George wrote: > My feeling is that the code that was suggested was for his environs ( > his shop ). > > The issue here is that after a 40+ second wait, an exception will be > thrown. But you really dont have a way of 'cancelling' all the > WriteFiles() that have already occured before the exception so that your > writeArray and the Commapi can backtrack to a position in which they are > in sync. > > The main ( really mine ) concern is not to lose data, or replicate data. > After 40seconds, 300 seconds, 55min, no matter how long, data should > not be lost or duplicated. But as soon as the exception is thrown, that > possibility exists. > > Maybe an event should be thrown instead? > > Vicne wrote: >> yves pielusenet wrote: >>> Maybe in my case I should re-compile rxtx and change the code. Instead >>> of send an exception I should display a dialog box to ask if it's >>> printer problem or if it should trie to send bytes. Something like : >>> >>> while( count > 0 ){ >>> if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ >>> /* >>> this are 20 * 2 seconds, in this time a printer (or other parallel device) >>> should solv all problems like buffer full, etc >>> */ >>> if(errorCount++ < 20){ >>> Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ >>> continue; >>> } >>> >>> if(displayDialogBox("Try again to send datas ??")){ >>> errorCount = 0; >>> } >>> else{ >>> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >>> break; >>> } >>> } >>> >> >> Sorry to step in without a specific solution to your problem, but I >> wanted to share my feeling regarding this proposal. AFAIK, it's >> generally considered bad practice to pop-up a prompt from a library. >> The main reason is that in general use, you can't guarantee that >> someone is actually present behind the console. Imagine a print server >> in a machine room, connected to a park of printers. In that case, when >> one printer fails, the logical behaviour would be to use an other one. >> If you change RxTx the way you propose, the printer queue will simply be >> stuck with a useless "Try again to send data ?" prompt until an >> administrator opens a remote connection to the print server's console >> and clicks "no". >> Second, it would create a dependency upon the existence of a >> graphical console (if you go the graphical "dialogBox" way). On many >> applications (typically server or embedded ones), the JVM is "headless" >> and if you try to pop-up a dialog, your app would throw an exception (at >> best) or just wouldn't display the prompt anywhere... Going the "text >> console" way is not more reliable, because on graphical environments, >> the text console is hidden unless explicitly requested. >> >> My advice would be to think again and find another solution. Ideas are : >> - make the number of retries a parameter so that you can tune it to what >> you think is reasonable >> - throw a more specific exception when the number of retries has been >> reached, so that a specific prompt can be shown at a higher level >> >> Anyway, if you feel that the prompt is the way to go in your case, I >> would at least make that prompt conditional. The least intrusive way >> would probably be using a system property, like >> >> if("true".equals(System.getProperty("org.rxtx.usePrompt")) >> && displayDialogBox("Retry sending data ?")){ >> errorCount = 0; >> } >> else{ >> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >> break; >> } >> >> >> By default, the behaviour would remain as it is now, but you could >> force the prompts by defining the property at VM launch if desired. (for >> example : java.exe -Dorg.rxtx.usePrompt=true myApp) >> >> >> Also, you seemed to say you wanted the printer to start again >> exactly where is stopped. It would indeed be the best way when the >> printer is put offline for a few seconds. On the other hand, if the >> printer is turned off (or the printer runs out of paper, or someone >> steps on the mains cable), then the only way to go back to a "stable" >> situation would be by printing the item (page, label, etc.) again from >> scratch... >> >> >> Just my two cents. >> >> >> Vicne >> >> PS : By the way, the dialog box thing is very platform dependant on the >> C-side, and I think the simplest way would probably be to bridge it to a >> Java call where you can implement it like you proposed : >> >> public boolean displayDialogBox(prompt) { >> return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", >> JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); >> } >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 19:18:51 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 21:18:51 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> Message-ID: <4668AE7B.3060409@gatworks.com> The UNIX version of writeArray is not too great either. It is possible that the write will only process some of the bytes. #else if( write( fd, bytes, count ) < 0 ) throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); #endif -------------------------------- Maybe it might be better to have the native function inform the caller of the # of characters written, then the commapi/output-buffer can be modified to reflect the #of chars written. If an exception is to be thrown, for too many loops of chars written == 0, then exception wont affect the state of the output buffer. Then a ParallelPort.restart() can be called to resume printing whats in the buffer. Trent Jarvi wrote: > An event is possible. I'm amazed this is the largest problem encountered > while using the parallel code. > > How would the write ever exit if we throw events? Isn't this going to > lead to hung applications? Sure. If you dont time out, then there is nothing that will force an EXIT from the write(). Issue is what has the OS done with the write. > > On Thu, 7 Jun 2007, Uncle George wrote: > >> My feeling is that the code that was suggested was for his environs ( >> his shop ). From yvespielusenet at free.fr Fri Jun 8 01:09:01 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Fri, 08 Jun 2007 09:09:01 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4668AE7B.3060409@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> Message-ID: <1181286541.3674.10.camel@localhost.localdomain> It is not possible that the rxtx java method write(byte[], int offset, int length) return anint which contains the number of byte really send to the printer instead of an exception ? So this is the programm which will see if all bytes have been sent. If not it can retry to send the unsended bytes. -------------------------------------------------------- int sended = 0; while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ sended += countWritten; /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } return sended; /*throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break;*/ } ... ... return countWritten; ------------------------------------------------ Le jeudi 07 juin 2007 ? 21:18 -0400, Uncle George a ?crit : > The UNIX version of writeArray is not too great either. It is possible > that the write will only process some of the bytes. > > #else > if( write( fd, bytes, count ) < 0 ) > throw_java_exception_system_msg( env, IO_EXCEPTION, > "writeArray" ); > #endif > -------------------------------- > > Maybe it might be better to have the native function inform the caller > of the # of characters written, then the commapi/output-buffer can be > modified to reflect the #of chars written. If an exception is to be > thrown, for too many loops of chars written == 0, then exception wont > affect the state of the output buffer. Then a ParallelPort.restart() can > be called to resume printing whats in the buffer. > > > Trent Jarvi wrote: > > An event is possible. I'm amazed this is the largest problem encountered > > while using the parallel code. > > > > How would the write ever exit if we throw events? Isn't this going to > > lead to hung applications? > Sure. If you dont time out, then there is nothing that will force an > EXIT from the write(). Issue is what has the OS done with the write. > > > > On Thu, 7 Jun 2007, Uncle George wrote: > > > >> My feeling is that the code that was suggested was for his environs ( > >> his shop ). > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Fri Jun 8 03:45:00 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 11:45:00 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181286541.3674.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> Message-ID: <20070608094500.GC21069@elberon.bln.de.ingenico.com> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > It is not possible that the rxtx java method write(byte[], int offset, > int length) return anint which contains the number of byte really send > to the printer instead of an exception ? > So this is the programm which will see if all bytes have been sent. If > not it can retry to send the unsended bytes. I think write() is void because in Java people love to do this since OutputStream :-) Of course on such interfaces you cannot implement something nice. If you would have a int write, you would not implement the interface and no applications expecting this interface would link/work/compile. oki, Steffen P.S.: (OT) If you propose not to implement the Java interfaces (especially not on JNI level), maybe optionally offering a wrapper that removes e.g. the write return value and so on to downgrade the powerful classic old POSIX read/write style to the modern limited Java style, then I agree :-) Same for read. Instead of things like "int avialable()" it is more powerful to have an approach as select(2) offers (to guarante the caller that read/write will not block [nothing else make sense anyway IMHO] but may read/write less bytes then requested). The caller gets full control and the higher level protocols can care about timeouts, invoking read in some loops and/or implement retransmission. On top of such an implementation, where everything is controlled, defined, guaranteed and reliable, someone could use an InputStream or OutputStream style interface. Or even better: don't use them at all :) just BTW :-) St. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From yvespielusenet at free.fr Fri Jun 8 05:52:45 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Fri, 08 Jun 2007 13:52:45 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <20070608094500.GC21069@elberon.bln.de.ingenico.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> Message-ID: <1181303565.11203.3.camel@localhost.localdomain> So maybe a better way should be to create a new Exception class which has a method "int getWrittenByte()". So the Exception should be use to send again bytes which are not printed yet. yves Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : > * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > > It is not possible that the rxtx java method write(byte[], int offset, > > int length) return anint which contains the number of byte really send > > to the printer instead of an exception ? > > So this is the programm which will see if all bytes have been sent. If > > not it can retry to send the unsended bytes. > > I think write() is void because in Java people love to do this > since OutputStream :-) Of course on such interfaces you cannot > implement something nice. If you would have a int write, you > would not implement the interface and no applications expecting > this interface would link/work/compile. > > oki, > > Steffen > > P.S.: (OT) > If you propose not to implement the Java interfaces (especially > not on JNI level), maybe optionally offering a wrapper that > removes e.g. the write return value and so on to downgrade the > powerful classic old POSIX read/write style to the modern limited > Java style, then I agree :-) Same for read. Instead of things > like "int avialable()" it is more powerful to have an approach as > select(2) offers (to guarante the caller that read/write will not > block [nothing else make sense anyway IMHO] but may read/write > less bytes then requested). The caller gets full control and the > higher level protocols can care about timeouts, invoking read in > some loops and/or implement retransmission. On top of such an > implementation, where everything is controlled, defined, > guaranteed and reliable, someone could use an InputStream or > OutputStream style interface. Or even better: don't use them at > all :) just BTW :-) > St. > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > 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. > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > 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. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Fri Jun 8 06:46:21 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 08:46:21 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181303565.11203.3.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> Message-ID: <46694F9D.5080501@gatworks.com> It seems that with outputstream.write(b[]), you become terribly uncoordinated as soon as an exception is thrown. Docs do not say what happens to the data. Yet from a practicable point of view, one would like to know if the write was accepted in-full, or rejected before any writes. There are no in betweens, as partial writes are not reportable. So for an outputstream.write(), in order for it to return, the full write request has to be taken, and stored in an internal output buffer. If there is no room, the write() is suspended, till there is room. Or throw's an IOException( "no room in buffer") ; As the select() loop for write reports buffer room avail, then more of the internal buffer is sent to the printer. yves pielusenet wrote: > So maybe a better way should be to create a new Exception class which > has a method "int getWrittenByte()". So the Exception should be use to > send again bytes which are not printed yet. > > yves > > Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : >> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: >>> It is not possible that the rxtx java method write(byte[], int offset, >>> int length) return anint which contains the number of byte really send >>> to the printer instead of an exception ? >>> So this is the programm which will see if all bytes have been sent. If >>> not it can retry to send the unsended bytes. >> I think write() is void because in Java people love to do this >> since OutputStream :-) Of course on such interfaces you cannot >> implement something nice. If you would have a int write, you >> would not implement the interface and no applications expecting >> this interface would link/work/compile. >> >> oki, >> >> Steffen >> >> P.S.: (OT) >> If you propose not to implement the Java interfaces (especially >> not on JNI level), maybe optionally offering a wrapper that >> removes e.g. the write return value and so on to downgrade the >> powerful classic old POSIX read/write style to the modern limited >> Java style, then I agree :-) Same for read. Instead of things >> like "int avialable()" it is more powerful to have an approach as >> select(2) offers (to guarante the caller that read/write will not >> block [nothing else make sense anyway IMHO] but may read/write >> less bytes then requested). The caller gets full control and the >> higher level protocols can care about timeouts, invoking read in >> some loops and/or implement retransmission. On top of such an >> implementation, where everything is controlled, defined, >> guaranteed and reliable, someone could use an InputStream or >> OutputStream style interface. Or even better: don't use them at >> all :) just BTW :-) >> St. >> >> About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. >> 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. >> >> About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. >> 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. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From Steffen.DETTMER at ingenico.com Fri Jun 8 08:12:18 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 16:12:18 +0200 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <46694F9D.5080501@gatworks.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: <20070608141218.GE21069@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 08:46 -0400: > It seems that with outputstream.write(b[]), you become terribly > uncoordinated as soon as an exception is thrown. Docs do not say what > happens to the data. (yes, so avoiding it seems to be good :)) > Yet from a practicable point of view, one would like to know if the > write was accepted in-full, or rejected before any writes. There are no > in betweens, as partial writes are not reportable. (which is an artificial API limitation. I never understood how this happend when they invented JDK because the well-known BSD socket API and thus [probably] WinSock does this correct, but anyway) > So for an outputstream.write(), in order for it to return, the full > write request has to be taken, and stored in an internal output buffer. > If there is no room, the write() is suspended, till there is room. Or > throw's an IOException( "no room in buffer") ; As the select() loop for > write reports buffer room avail, then more of the internal buffer is > sent to the printer. yes, might be good in case of a printer. May be horrible in case of PPP/TCP or some other transmission control protocol which may e.g. repeat data or even omit parts of it (e.g. internet realtime radio station broadcasting)... So I think the idea of "int write" (e.g. BSD sockets, linux files and so on) still is the best. A clean API / implementation should guarantee and allow implementations (users) to rely on that; assumptions and automatic background-sending and so on may look pragmatic and may even work on the first look, but may fail in other situations. BTW, if e.g. BSD socket API is known, why not simply copy it (until something better is invented :)) instead of fiddling around with JDK APIs? anyway, have a nice weekend everyone :-) oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Fri Jun 8 08:55:56 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 10:55:56 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070608141218.GE21069@elberon.bln.de.ingenico.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> Message-ID: <46696DFC.7000801@gatworks.com> >> write reports buffer room avail, then more of the internal buffer is >> sent to the printer. > > yes, might be good in case of a printer. May be horrible in case > of PPP/TCP or some other transmission control protocol which > may e.g. repeat data or even omit parts of it (e.g. internet > realtime radio station broadcasting)... So I think the idea of > "int write" (e.g. BSD sockets, linux files and so on) still is > the best. A clean API / implementation should guarantee and allow > implementations (users) to rely on that; assumptions and > automatic background-sending and so on may look pragmatic and may > even work on the first look, but may fail in other situations. > BTW, if e.g. BSD socket API is known, why not simply copy it > (until something better is invented :)) instead of fiddling > around with JDK APIs? But we were talking about the Parallel Port, and the transmission of data over the commapi/parallel-port schema. There isn't much in bi-directional software communication. Its a simple write one byte at a time interface. I'm not looking to change the comm-api. I'm just looking to alter the interaction between the Native ParallelPort functions, and the java ParallelPort functions that call them. This might be more readily doable than to get a committee to re-specify java-API specs. BTW: Whats is off-topic? ( help: not looking for def of off-topic ) From j.kenneth.gentle at acm.org Fri Jun 8 08:58:59 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Fri, 08 Jun 2007 10:58:59 -0400 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <20070608141218.GE21069@elberon.bln.de.ingenico.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> Message-ID: <200706081459.l58Ex5rA019991@qbang.org> Perhaps it is a bit late to jump in on this one, but here goes anyway. If the solutions all seem to "break" the contract with "java.io.outputstream", then, as noted, that may not be the appropriate contract. At the risk of being heretical, JDK1.4 introduced the "nio" package to address some of the compatibility issues with C apis mentioned in previous posts. The interface "java.nio.channels.WriteableByteChannel" defines the following single method: int write(ByteBuffer source); int, strangely enough, is the actual number of bytes written. So, if RXTX as written, against the JavaCOMM api and OutputStream, doesn't do what we want, how about writing a different set of bindings using the java.nio classes and as much of the underlying native code as possible. Note that just because the java.nio.channels.WriteableByteChannel sends back a result, OutputStream.write doesn't have to - and they could both call the same underlying native code. My 2 cents - maybe not worth even that... Ken From netbeans at gatworks.com Fri Jun 8 10:37:28 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 12:37:28 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <200706081459.l58Ex5rA019991@qbang.org> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> Message-ID: <466985C8.8000505@gatworks.com> Ken Gentle wrote: > Perhaps it is a bit late to jump in on this one, but here goes anyway. Common in, the waters fine. > > If the solutions all seem to "break" the contract with > "java.io.outputstream", then, as noted, that may not be the > appropriate contract. > How would the contract be broken? The machinery underneath is handling the contract. From j.kenneth.gentle at acm.org Fri Jun 8 10:48:01 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Fri, 08 Jun 2007 12:48:01 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466985C8.8000505@gatworks.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> Message-ID: <200706081648.l58Gm7YA022904@qbang.org> At 12:37 2007-06-08, you wrote: >Ken Gentle wrote: > > > > If the solutions all seem to "break" the contract with > > "java.io.outputstream", then, as noted, that may not be the > > appropriate contract. > > >How would the contract be broken? The machinery underneath is handling >the contract. It seems that a lot of the discussion has been about not only the timeout and being able to adjust it in the "machinery layer", but also about knowing in the Java layer, in the event of a timeout or exception, how many characters have been written to the device. An OutputStream won't ever do this with out an extension and including a return value "breaks" the contract, right? So, go with a Java IO api that *does* return the number of bytes written, out of the NIO package. I know it doesn't allow for a strict implementation of the JavaCOMM API - however, using NIO classes in place of the IO classes isn't that big a break and would allow those applications that need such information a way to get it. Maybe I'm misunderstanding the problem... Ken From netbeans at gatworks.com Fri Jun 8 11:24:14 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 13:24:14 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <200706081648.l58Gm7YA022904@qbang.org> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> Message-ID: <466990BE.7040100@gatworks.com> Ken Gentle wrote: An > OutputStream won't ever do this with out an extension and including a > return value "breaks" the contract, right? > i was not thinking of change the API to OutputSream. Are there specs for how output stream should work internally? for instance: String data = "Hello this is a line of data"; Outputstream.write( data.getbytes() ); ParallelPort.suspend(); int free = ParallelPort.getoutputbufferfree(); There is a symbiotic relationship between outputstream and the functionality of ParallelPort. From Steffen.DETTMER at ingenico.com Fri Jun 8 11:15:39 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 19:15:39 +0200 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <200706081459.l58Ex5rA019991@qbang.org> References: <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> Message-ID: <20070608171539.GK21069@elberon.bln.de.ingenico.com> * Ken Gentle wrote on Fri, Jun 08, 2007 at 10:58 -0400: > If the solutions all seem to "break" the contract with > "java.io.outputstream", then, as noted, that may not be the > appropriate contract. > > At the risk of being heretical, JDK1.4 introduced the "nio" package > to address some of the compatibility issues with C apis mentioned in > previous posts. The interface > "java.nio.channels.WriteableByteChannel" defines the following single method: > > int write(ByteBuffer source); > > int, strangely enough, is the actual number of bytes written. Yes, AFAIK one of the motivations for the NIO interface was, that the JDK-1.3 APIs (InputStream, e.g.) were not powerfull enough, especially for multi-connection-TCP servers or so. I don't know much about it but I've heard of a project where NIO usage was removed because of stability issues in multi-threaded environments and performance limitations under some circumstances. IIRC the "nio.ByteBuffer" is something very special (namely something you cannot implement in Java, it is "magic" or part of the language itself). Not sure if this is such a great idea (but for performance in the end sometimes heavy prices must be paid) :) > So, if RXTX as written, against the JavaCOMM api and OutputStream, > doesn't do what we want, how about writing a different set of > bindings using the java.nio classes and as much of the underlying > native code as possible. Yes, this would be an idea: use a full-featured interface on JNI, and, if wanted, deliver some wrappers converting this to a less-featured Java-compliant interface. However, powerful things as e.g. "select" are difficult to "emulate" if you are e.g. on some (older?) windows. But if you expose the full-featured APIs, you need to emulate them full-featured, theoretically. In the end it depends what you do on the serial line. If you just want to talk to a modem, then you may not need precise timeouts. But if you need to implement complexer protocols which define response times and timeouts, you may quickly get into difficulties. For instance, AFAIK, rxtx 1.7.2 (?) for windows is very messy with timeouts (there is a maximum, higher values are truncated; resolution is 100ms only; the function may take up to twice the timeout because internally it may be called twice). Probably for most people this is OK, but probably not for all. But having precise timeouts should be OK for all :-) Well, in the end it is nice to wish but somewhat hard to implement (many platforms, connections, USB, BlueTooth, whatever). oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Steffen.DETTMER at ingenico.com Fri Jun 8 11:04:22 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 19:04:22 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <46696DFC.7000801@gatworks.com> References: <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <46696DFC.7000801@gatworks.com> Message-ID: <20070608170422.GJ21069@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 10:55 -0400: > > BTW, if e.g. BSD socket API is known, why not simply copy it > > (until something better is invented :)) instead of fiddling > > around with JDK APIs? > > But we were talking about the Parallel Port, and the > transmission of data over the commapi/parallel-port schema. > There isn't much in bi-directional software communication. Its > a simple write one byte at a time interface. First, there are things like PLIP (http://en.wikipedia.org/wiki/Plip) - well, probably not widely used, sure ;) Second, I think if there is a good simple API known to support all that (with known "best practices") or so and there is no forcing need to invent a new one, why not simply using it? > I'm not looking to change the comm-api. I'm just looking to > alter the interaction between the Native ParallelPort > functions, and the java ParallelPort functions that call them. Ahh, yes. I think this is what I tried to ask. Having an usable JNI interface and on top (in pure java) some wrapper to InputStream or whatever could be done (e.g. by ignoring the return value of write or throwing if != length). Developers could then use the full-featured (non-JAVA-standard) API or select among various wrappers (as InputStream). > This might be more readily doable than to get a committee to > re-specify java-API specs. Yes, of course. I'm afraid that the Java APIs change regularily, but still yet with limited success it seems, so maybe they get it in one of the next iterations; who knows, maybe Java-9 has a BSD-like socket API :) SCNR. > BTW: Whats is off-topic? ( help: not looking for def of > off-topic ) I think I started some "re-specify java-API specs" which was OT probably. oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From lists at iDIAcomputing.com Fri Jun 8 18:48:54 2007 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Fri, 08 Jun 2007 20:48:54 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46684B62.7080802@gmail.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> Message-ID: <4669F8F6.3040101@iDIAcomputing.com> Vicne wrote: > Sorry to step in without a specific solution to your problem, but I > wanted to share my feeling regarding this proposal. AFAIK, it's > generally considered bad practice to pop-up a prompt from a library. ... > > My advice would be to think again and find another solution. Ideas are : > - make the number of retries a parameter so that you can tune it to what > you think is reasonable > - throw a more specific exception when the number of retries has been > reached, so that a specific prompt can be shown at a higher level You could also allow the client code to register a callback class which returns a boolean indicating whether to retry or cancel. This callback class could pop up a dialog, if appropriate, or follow some preset policy, or.... - George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From joachim at buechse.ch Sat Jun 9 09:43:16 2007 From: joachim at buechse.ch (Joachim Buechse) Date: Sat, 9 Jun 2007 17:43:16 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46694F9D.5080501@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: You should not forget, that in the case of an exception it may not even be known what happened to the data. You have a kernel buffer, outgoing chip buffer, incoming chip buffer, etc. So of course, it would be nice to know up to which point data was correctly processed, but this feedback does not exist on the hardware or protocol level and hence can in general not be magicly created on the software level... Regards, Joachim On 08.06.2007, at 14:46, Uncle George wrote: > It seems that with outputstream.write(b[]), you become terribly > uncoordinated as soon as an exception is thrown. Docs do not say what > happens to the data. > > Yet from a practicable point of view, one would like to know if the > write was accepted in-full, or rejected before any writes. There > are no > in betweens, as partial writes are not reportable. > > So for an outputstream.write(), in order for it to return, the full > write request has to be taken, and stored in an internal output > buffer. > If there is no room, the write() is suspended, till there is room. Or > throw's an IOException( "no room in buffer") ; As the select() loop > for > write reports buffer room avail, then more of the internal buffer is > sent to the printer. > > > > yves pielusenet wrote: >> So maybe a better way should be to create a new Exception class which >> has a method "int getWrittenByte()". So the Exception should be >> use to >> send again bytes which are not printed yet. >> >> yves >> >> Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : >>> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: >>>> It is not possible that the rxtx java method write(byte[], int >>>> offset, >>>> int length) return anint which contains the number of byte >>>> really send >>>> to the printer instead of an exception ? >>>> So this is the programm which will see if all bytes have been >>>> sent. If >>>> not it can retry to send the unsended bytes. >>> I think write() is void because in Java people love to do this >>> since OutputStream :-) Of course on such interfaces you cannot >>> implement something nice. If you would have a int write, you >>> would not implement the interface and no applications expecting >>> this interface would link/work/compile. >>> >>> oki, >>> >>> Steffen >>> >>> P.S.: (OT) >>> If you propose not to implement the Java interfaces (especially >>> not on JNI level), maybe optionally offering a wrapper that >>> removes e.g. the write return value and so on to downgrade the >>> powerful classic old POSIX read/write style to the modern limited >>> Java style, then I agree :-) Same for read. Instead of things >>> like "int avialable()" it is more powerful to have an approach as >>> select(2) offers (to guarante the caller that read/write will not >>> block [nothing else make sense anyway IMHO] but may read/write >>> less bytes then requested). The caller gets full control and the >>> higher level protocols can care about timeouts, invoking read in >>> some loops and/or implement retransmission. On top of such an >>> implementation, where everything is controlled, defined, >>> guaranteed and reliable, someone could use an InputStream or >>> OutputStream style interface. Or even better: don't use them at >>> all :) just BTW :-) >>> St. >>> >>> About Ingenico Throughout the world businesses rely on Ingenico >>> for secure and expedient electronic transaction acceptance. >>> Ingenico products leverage proven technology, established >>> standards and unparalleled ergonomics to provide optimal >>> reliability, versatility and usability. This comprehensive range >>> of products is complemented by a global array of services and >>> partnerships, enabling businesses in a number of vertical sectors >>> to accept transactions anywhere their business takes them. >>> 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. >>> >>> About Ingenico Throughout the world businesses rely on Ingenico >>> for secure and expedient electronic transaction acceptance. >>> Ingenico products leverage proven technology, established >>> standards and unparalleled ergonomics to provide optimal >>> reliability, versatility and usability. This comprehensive range >>> of products is complemented by a global array of services and >>> partnerships, enabling businesses in a number of vertical sectors >>> to accept transactions anywhere their business takes them. >>> 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. >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx 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 yvespielusenet at free.fr Mon Jun 11 03:15:12 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Mon, 11 Jun 2007 11:15:12 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: <1181553312.8335.14.camel@localhost.localdomain> So can someone tell a solution for my problem :( Must I say to the user to not put the printer off-line ? I can't since he has to do some pauses, verify print, paper conditioning etc... How do other people ? Before I use the parport librarry to read port status : http://www.geocities.com/Juanga69/parport/ (which doesn't work on windows XP) And I send data into the file LPT1 I use to have no problem when printer was disabled. thanks -- yves piel Le samedi 09 juin 2007 ? 17:43 +0200, Joachim Buechse a ?crit : > You should not forget, that in the case of an exception it may not > even be known what happened to the data. > > You have a kernel buffer, outgoing chip buffer, incoming chip buffer, > etc. So of course, it would be nice to know up to which point data > was correctly processed, but this feedback does not exist on the > hardware or protocol level and hence can in general not be magicly > created on the software level... > > Regards, > Joachim > > On 08.06.2007, at 14:46, Uncle George wrote: > > > It seems that with outputstream.write(b[]), you become terribly > > uncoordinated as soon as an exception is thrown. Docs do not say what > > happens to the data. > > > > Yet from a practicable point of view, one would like to know if the > > write was accepted in-full, or rejected before any writes. There > > are no > > in betweens, as partial writes are not reportable. > > > > So for an outputstream.write(), in order for it to return, the full > > write request has to be taken, and stored in an internal output > > buffer. > > If there is no room, the write() is suspended, till there is room. Or > > throw's an IOException( "no room in buffer") ; As the select() loop > > for > > write reports buffer room avail, then more of the internal buffer is > > sent to the printer. > > > > > > > > yves pielusenet wrote: > >> So maybe a better way should be to create a new Exception class which > >> has a method "int getWrittenByte()". So the Exception should be > >> use to > >> send again bytes which are not printed yet. > >> > >> yves > >> > >> Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : > >>> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > >>>> It is not possible that the rxtx java method write(byte[], int > >>>> offset, > >>>> int length) return anint which contains the number of byte > >>>> really send > >>>> to the printer instead of an exception ? > >>>> So this is the programm which will see if all bytes have been > >>>> sent. If > >>>> not it can retry to send the unsended bytes. > >>> I think write() is void because in Java people love to do this > >>> since OutputStream :-) Of course on such interfaces you cannot > >>> implement something nice. If you would have a int write, you > >>> would not implement the interface and no applications expecting > >>> this interface would link/work/compile. > >>> > >>> oki, > >>> > >>> Steffen > >>> > >>> P.S.: (OT) > >>> If you propose not to implement the Java interfaces (especially > >>> not on JNI level), maybe optionally offering a wrapper that > >>> removes e.g. the write return value and so on to downgrade the > >>> powerful classic old POSIX read/write style to the modern limited > >>> Java style, then I agree :-) Same for read. Instead of things > >>> like "int avialable()" it is more powerful to have an approach as > >>> select(2) offers (to guarante the caller that read/write will not > >>> block [nothing else make sense anyway IMHO] but may read/write > >>> less bytes then requested). The caller gets full control and the > >>> higher level protocols can care about timeouts, invoking read in > >>> some loops and/or implement retransmission. On top of such an > >>> implementation, where everything is controlled, defined, > >>> guaranteed and reliable, someone could use an InputStream or > >>> OutputStream style interface. Or even better: don't use them at > >>> all :) just BTW :-) > >>> St. > >>> > >>> About Ingenico Throughout the world businesses rely on Ingenico > >>> for secure and expedient electronic transaction acceptance. > >>> Ingenico products leverage proven technology, established > >>> standards and unparalleled ergonomics to provide optimal > >>> reliability, versatility and usability. This comprehensive range > >>> of products is complemented by a global array of services and > >>> partnerships, enabling businesses in a number of vertical sectors > >>> to accept transactions anywhere their business takes them. > >>> 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. > >>> > >>> About Ingenico Throughout the world businesses rely on Ingenico > >>> for secure and expedient electronic transaction acceptance. > >>> Ingenico products leverage proven technology, established > >>> standards and unparalleled ergonomics to provide optimal > >>> reliability, versatility and usability. This comprehensive range > >>> of products is complemented by a global array of services and > >>> partnerships, enabling businesses in a number of vertical sectors > >>> to accept transactions anywhere their business takes them. > >>> 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. > >>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx 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 > From Steffen.DETTMER at ingenico.com Mon Jun 11 03:56:18 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 11:56:18 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466990BE.7040100@gatworks.com> References: <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> Message-ID: <20070611095618.GA10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 13:24 -0400: > i was not thinking of change the API to OutputSream. Then I think either someone uses OutputStream (and has no reliable information about incomplete writes) or someone uses somethink else. > Are there specs for how output stream should work internally? > > for instance: > String data = "Hello this is a line of data"; > Outputstream.write( data.getbytes() ); > ParallelPort.suspend(); > int free = ParallelPort.getoutputbufferfree(); > > There is a symbiotic relationship between outputstream and the > functionality of ParallelPort. If you need OutputStream "plus something else", in short you're needing "something else". Personally I dislike the code above a lot. The stream "looks" like if it would be an OutputStream, but in fact it isn't. You need to call getoutputbufferfree later to check if write succeeded (but OutputStream promises that write succeedes synchronous, blocking, or throws an exception). So it is not an OutputStream. No application written for OutputStreams would work without change (because it won't know getoutputbufferfree at all). It is not abstracted from ParallelPort. I think this would be wrong. Then I think an alternative interface instead is better. Let's assume we had some "connection" (to distinguish between OutputStreams and Channels). Then why not working as on a file handle in POSIX: do { // ... select maybe using timer ... readyForWrite = ... if (readyForWrite) { int writtenBytes = connection.write(toWrite); toWrite.remove(0, writtenBytes); } while(readyForWrite && toWrite.length > 0); I think, having such a write isn't the big problem. I think, the difficult thing is around "select" - however this would look like. It should be OO, typesafe, performant, supporting multiple connections/channels/streams in various modes and should be orthogonal to other functionalities. Of course, this heavily depends on what the application is doing; for a simple situation (like reading a small, mandatory file from a local disk) this would be to uncomfortable (and offering unneeded features only). just BTW :) oki, Steffen -- // Modeline for VIM. Please don't remove. // (Help: autoindent, expandtab, shiftwidth=4, tabstop=4, textwidth=75) // vi: set ai et sw=4 ts=4 tw=75 ft=java: About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Mon Jun 11 05:38:33 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 07:38:33 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611095618.GA10821@elberon.bln.de.ingenico.com> References: <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> Message-ID: <466D3439.4020805@gatworks.com> Steffen DETTMER wrote: > (but OutputStream promises that write > succeedes synchronous, blocking, or throws an exception). Where is it so written? From Steffen.DETTMER at ingenico.com Mon Jun 11 06:36:50 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 14:36:50 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466D3439.4020805@gatworks.com> References: <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> <466D3439.4020805@gatworks.com> Message-ID: <20070611123650.GI10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Mon, Jun 11, 2007 at 07:38 -0400: > Steffen DETTMER wrote: > > > (but OutputStream promises that write > > succeedes synchronous, blocking, or throws an exception). > > Where is it so written? Now, as you ask, I think it is not written that clearly but follows from specification. mmm... Am I wrong? I understand the API doc in this way: * http://java.sun.com/j2se/1.4.2/docs/api/java/io/OutputStream.html#write(byte[]) > public void write(byte[] b) > throws IOException > > Writes b.length bytes from the specified byte array to this > output stream. The general contract for write(b) is that > it should have exactly the same effect as the call write(b, > 0, b.length). > > Parameters: > b - the data. > Throws: > IOException - if an I/O error occurs. > See Also: > write(byte[], int, int) and there is: > public void write(byte[] b, > int off, > int len) > throws IOException > > Writes len bytes from the specified byte array starting at > offset off to this output stream. The general contract for > write(b, off, len) is that some of the bytes in the array b > are written to the output stream in order; element b[off] > is the first byte written and b[off+len-1] is the last byte > written by this operation. > > The write method of OutputStream calls the write method of > one argument on each of the bytes to be written out. > Subclasses are encouraged to override this method and > provide a more efficient implementation. > > If b is null, a NullPointerException is thrown. > > If off is negative, or len is negative, or off+len is > greater than the length of the array b, then an > IndexOutOfBoundsException is thrown. > > Parameters: > b - the data. > off - the start offset in the data. > len - the number of bytes to write. > Throws: > IOException - if an I/O error occurs. In particular, an > IOException is thrown if the output stream is closed. In general, any specialisation (derived child class) must comform to this. So write in the end is specified (!) as "The write method ... calls the write method ... on each of the bytes to be written out". This is what must be implemented by ANY OutputStream. Of course, there is: "Subclasses are encouraged to override this method and provide a more efficient implementation." which IMHO does not contradict - the more efficient must behave in exactly the same way of course (just wasting less resources than a simple byte-by-byte write). So it does not matter here I think. The write that finally defines the behavior tells basically: > "Writes the specified byte to this output stream. The general > contract for write is that one byte is written to the output > stream. " > > Throws: > IOException - if an I/O error occurs. which IMHO is another way of saying "write writes the byte immediately and returns on success (only), otherwise an exception is thrown". Especially it cannot happen that zero bytes are written (i.e. the specified byte is NOT written) without an exception. So by this write must be synchronous and blocking, because otherwise it could not reliably know if an asynchronous operation will succeede or not (some getAsyncResult or so would be needed). Since write(byte[]) does this for each byte (or with a behavior beeing exactly the same as if it would do), I think this means that the write(byte[]) succeedes synchronous/blocking or throws an exception. Did I an error in reasoning or confused something or so? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From j.kenneth.gentle at acm.org Mon Jun 11 06:51:25 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 11 Jun 2007 08:51:25 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611123650.GI10821@elberon.bln.de.ingenico.com> References: <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> <466D3439.4020805@gatworks.com> <20070611123650.GI10821@elberon.bln.de.ingenico.com> Message-ID: <200706111251.l5BCpS9T017831@qbang.org> It is as Steffen describes. "InputStream" and "OutputStream" are inherently synchronous (which is why so many java programs resort to threads to use them). Anything outside of this "contract" is *not* an InputStream or OutputStream. That is why there is a new package for things that don't behave like the old *Stream classes - the NIO package. If you look carefully at the IO package, you'll note that almost all the classes are _Decorator_ pattern implementations of the *Stream classes - and the interface presents the _same_ behavior to the calling code in all cases - a synchronous operation that completes successfully or throws an exception (with the one exception of "read" that returns a "-1" on end-of-stream. I know I've read this numerous times - I'd suggest checking the Language Spec or one of the books by Bloch or Gosling. Ken At 08:36 2007-06-11, you wrote: >* Uncle George wrote on Mon, Jun 11, 2007 at 07:38 -0400: > > Steffen DETTMER wrote: > > > > > (but OutputStream promises that write > > > succeedes synchronous, blocking, or throws an exception). > > > > Where is it so written? > >Now, as you ask, I think it is not written that clearly but >follows from specification. mmm... > >Am I wrong? > >I understand the API doc in this way: > >* >http://java.sun.com/j2se/1.4.2/docs/api/java/io/OutputStream.html#write(byte[]) > > public void write(byte[] b) > > throws IOException > > > > Writes b.length bytes from the specified byte array to this > > output stream. The general contract for write(b) is that > > it should have exactly the same effect as the call write(b, > > 0, b.length). > > > > Parameters: > > b - the data. > > Throws: > > IOException - if an I/O error occurs. > > See Also: > > write(byte[], int, int) > > >and there is: > > > > public void write(byte[] b, > > int off, > > int len) > > throws IOException > > > > Writes len bytes from the specified byte array starting at > > offset off to this output stream. The general contract for > > write(b, off, len) is that some of the bytes in the array b > > are written to the output stream in order; element b[off] > > is the first byte written and b[off+len-1] is the last byte > > written by this operation. > > > > The write method of OutputStream calls the write method of > > one argument on each of the bytes to be written out. > > Subclasses are encouraged to override this method and > > provide a more efficient implementation. > > > > If b is null, a NullPointerException is thrown. > > > > If off is negative, or len is negative, or off+len is > > greater than the length of the array b, then an > > IndexOutOfBoundsException is thrown. > > > > Parameters: > > b - the data. > > off - the start offset in the data. > > len - the number of bytes to write. > > Throws: > > IOException - if an I/O error occurs. In particular, an > > IOException is thrown if the output stream is closed. > > >In general, any specialisation (derived child class) must comform >to this. So write in the end is specified (!) as "The write >method ... calls the write method ... on each of the bytes to be >written out". This is what must be implemented by ANY >OutputStream. > >Of course, there is: "Subclasses are encouraged to override this >method and provide a more efficient implementation." which IMHO >does not contradict - the more efficient must behave in exactly >the same way of course (just wasting less resources than a simple >byte-by-byte write). So it does not matter here I think. > > > >The write that finally defines the behavior tells basically: > > > "Writes the specified byte to this output stream. The general > > contract for write is that one byte is written to the output > > stream. " > > > > Throws: > > IOException - if an I/O error occurs. > > >which IMHO is another way of saying "write writes the byte >immediately and returns on success (only), otherwise an exception >is thrown". Especially it cannot happen that zero bytes are >written (i.e. the specified byte is NOT written) without an >exception. So by this write must be synchronous and blocking, >because otherwise it could not reliably know if an asynchronous >operation will succeede or not (some getAsyncResult or so would >be needed). > >Since write(byte[]) does this for each byte (or with a behavior >beeing exactly the same as if it would do), I think this means >that the write(byte[]) succeedes synchronous/blocking or throws >an exception. > >Did I an error in reasoning or confused something or so? > >oki, > >Steffen > >About Ingenico Throughout the world businesses rely on Ingenico for >secure and expedient electronic transaction acceptance. Ingenico >products leverage proven technology, established standards and >unparalleled ergonomics to provide optimal reliability, versatility >and usability. This comprehensive range of products is complemented >by a global array of services and partnerships, enabling businesses >in a number of vertical sectors to accept transactions anywhere >their business takes them. >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. > >About Ingenico Throughout the world businesses rely on Ingenico for >secure and expedient electronic transaction acceptance. Ingenico >products leverage proven technology, established standards and >unparalleled ergonomics to provide optimal reliability, versatility >and usability. This comprehensive range of products is complemented >by a global array of services and partnerships, enabling businesses >in a number of vertical sectors to accept transactions anywhere >their business takes them. >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. > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From alesinskyy at googlemail.com Mon Jun 11 07:25:33 2007 From: alesinskyy at googlemail.com (Oleksandr Alesinskyy) Date: Mon, 11 Jun 2007 15:25:33 +0200 Subject: [Rxtx] [OT] select :-) Message-ID: Sorry, but I have to disagree with following statement: "So write in the end is specified (!) as "The write method ... calls the write method ... on each of the bytes to be written out". This is what must be implemented by ANY OutputStream.". This is not part of the specification or contract, it is just revealed implementation detail of the OutputStream. It is not stated anywhere that behavoiur of derived classes shall conform with this one. Statement concerning "synchronous" nature of the output stream is invalid as well. Really synchronous stream does not require flush() but OutputStream has it. From Steffen.DETTMER at ingenico.com Mon Jun 11 08:21:16 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 16:21:16 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: Message-ID: <20070611142116.GN10821@elberon.bln.de.ingenico.com> * Oleksandr Alesinskyy wrote on Mon, Jun 11, 2007 at 15:25 +0200: > Sorry, but I have to disagree with following statement: > "So write in the end is specified (!) as "The write > method ... calls the write method ... on each of the bytes to be > written out". This is what must be implemented by ANY > OutputStream.". > > This is not part of the specification or contract, it is just > revealed implementation detail of the OutputStream. It is not > stated anywhere that behavoiur of derived classes shall conform > with this one. (I didn't meant that the implementation must really write byte by byte, but that it must "look as if it would do" - because all implementations of OutputStream must "look" in the same way [which is another way of saying "do abstract" I think]) I think the API doc is not "revealing implementation details" but it is the *specification* of that interface and derivations must (should) conform to this specification. Isn't this the idea of interfaces? A function that expects an OutputStream should work on ANY OutputStream, shouldn't it? just kidding: I mean, what would be the point in implementing a checksum function as OutputStream.write which throws its result as IOException? Or which requires to call close() as very first operation to tell that the application is about to transmit confidential data? :-) > Statement concerning "synchronous" nature of the output stream > is invalid as well. Really synchronous stream does not require > flush() but OutputStream has it. ahh, interesting point! I think this is another bug in the API. flush() is wrong. Because write specifies "The general contract for write is that one byte is written to the output stream." but not "a byte may be written or buffered". Actually, an application would need to call flush() after each write (or bunch of write calls) to ensure that write really did something otherwise I think. I didn't found in the spec of OutputStream that it would be required to call flush(). This should mean that calling flush is not required which in turn leads to the conclusion that write must be synchrous (private threads are forbidden because not specified :)) which in turn leads to the conclusion that flush() is not needed at all... I mean, what if someone would only store in write and do the "real write" in flush() and never else? An application could write in one stream and read on another one (e.g. in bidirectional communication) and would never get anything back, because nothing was actually written because no flush was called? Then someone could even think that on error in some write the data could remain buffered AND throw an exception, retrying to send the data in the next write. Ohh, and if there would be some message number inside, and underlaying write (e.g. a protocol offering InputStream/OutputStream) would check this and throw "DuplicatedMessageNumber" the stream would only throw it again and again beeing unusable... In short: I have no clue how someone could be able to implement an asynchrounos write (which is realiable and correct) without beeing specific to anything which is not specified by OutputStream. Well, I think in the end OutputStream was not intended for such communication or protocol implementations - but to read a local disk file or so. In case of I/O errors usually you can abort your application and change the hard disk :-) oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Bob_Jacobsen at lbl.gov Mon Jun 11 09:32:23 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Mon, 11 Jun 2007 08:32:23 -0700 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611142116.GN10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> Message-ID: At 4:21 PM +0200 6/11/07, Steffen DETTMER wrote: > > Statement concerning "synchronous" nature of the output stream >> is invalid as well. Really synchronous stream does not require >> flush() but OutputStream has it. > >ahh, interesting point! > >I think this is another bug in the API. flush() is wrong. Because >write specifies "The general contract for write is that one byte >is written to the output stream." but not "a byte may be written >or buffered". > >Actually, an application would need to call flush() after each >write (or bunch of write calls) to ensure that write really did >something otherwise I think. OutputStreams don't _have_ to be synchronous or asynchronous, but the OutputStream API was be arranged so that subclasses _can_ be synchronous or asynchronous. Such generality is the hardest part of getting an API right. Hence, if at some point a program using an OutputStream wants to be sure that the data has been pushed all the way out, flush() is available. For some subclasses, e.g. the buffered ones, this has important behavior. Others write the data from each call, and flush() doesn't do anything. You _can_ omit it in programs that are known to use this second type, but there's no requirement that you do so; the interface is general in that way. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From Steffen.DETTMER at ingenico.com Mon Jun 11 12:32:39 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 20:32:39 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> Message-ID: <20070611183239.GT10821@elberon.bln.de.ingenico.com> * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: > >Actually, an application would need to call flush() after each > >write (or bunch of write calls) to ensure that write really did > >something otherwise I think. > OutputStreams don't _have_ to be synchronous or asynchronous, > but the OutputStream API was be arranged so that subclasses > _can_ be synchronous or asynchronous. Ahh, oki. Thanks for the clarificaion. So in short, flush() MUST be called on OutputStream, this is just not documented correctly or so clearly (right?). So the overall usage semantics would be: 1. call write (multiple times if desired) 2. call flush only if both succeeded, write was successful. If flush fails it remains unknown if a part of the data was written and/or will be repeated. So the spec (API doc) is wrong. Correct would be to tell that write behaves as told as long as it is followed by a call to flush, otherwise data may or may not get lost (depending wheter close() is called and calls flush(), which seems not to be guaranteed/required). BTW, I think it is a little bit... erm... interesting to find the specification (java API doc reference) wrong, having a need to conclude it from the presence of some methods with "it would make no sense if they behave exactly as specified, so specification must be wrong (incomplete)". > Such generality is the hardest part of getting an API right. Yes, seems to be proven ;) > Hence, if at some point a program using an OutputStream wants > to be sure that the data has been pushed all the way out, > flush() is available. For some subclasses, e.g. the buffered > ones, this has important behavior. Others write the data from > each call, and flush() doesn't do anything. > You _can_ omit it in programs that are known to use this second > type, but there's no requirement that you do so; the interface > is general in that way. I think, it still it must be called always, otherwise the application could break if passing a different runtime type as OutputStream. I think, if the application/method needs a special "type of OutputStream" then the parameter type must be a subclass but not OutputStream, maybe a PrintStream or so - otherwise the compiler could not detect this error (passing wrong type). Is this correct? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Bob_Jacobsen at lbl.gov Mon Jun 11 13:00:52 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Mon, 11 Jun 2007 12:00:52 -0700 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611183239.GT10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> Message-ID: At 8:32 PM +0200 6/11/07, Steffen DETTMER wrote: >So the spec (API doc) is wrong. Correct would be to tell that >write behaves as told as long as it is followed by a call to >flush, otherwise data may or may not get lost (depending wheter >close() is called and calls flush(), which seems not to be >guaranteed/required). I'm not entirely sure that the spec is wrong, but reasonable people can differ on this. In the 1.5 JavaDocs, all that the docs say for the write methods is that they write to the _output_ _stream_; there is no guarantee of anything beyond that. Only the flush method has any guarantee about the data, which is >Flushes this output stream and forces any buffered output bytes to >be written out. The general contract of flush is that calling it is >an indication that, if any bytes previously written have been >buffered by the implementation of the output stream, such bytes >should immediately be written to their intended destination. People commonly use various OutputStreams without using flush(), and it often works, but it's a bad practice and will eventually bite them. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From netbeans at gatworks.com Mon Jun 11 13:31:57 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 15:31:57 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611183239.GT10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> Message-ID: <466DA32D.1010602@gatworks.com> Steffen DETTMER wrote: > * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: >>> Actually, an application would need to call flush() after each >>> write (or bunch of write calls) to ensure that write really did >>> something otherwise I think. > >> OutputStreams don't _have_ to be synchronous or asynchronous, >> but the OutputStream API was be arranged so that subclasses >> _can_ be synchronous or asynchronous. > > Ahh, oki. Thanks for the clarificaion. > > So in short, flush() MUST be called on OutputStream, this is just > not documented correctly or so clearly (right?). No. Flush can be called to force all current data in java buffer's to be written to the kernel - NOW. A flush() can also *imply* that, besides writing out the buffer's that java employs, may also imply/ask the kernel to write all data thusfar written to the kernel, to be physically placed on the destination device - NOW. For some OS's there is no need to do a kernel flush(), as the I/O is synchronized already. Since this is java, you never know what OS your on. From tjarvi at qbang.org Mon Jun 11 19:28:27 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Jun 2007 19:28:27 -0600 (MDT) Subject: [Rxtx] [OT] select :-) In-Reply-To: <466DA32D.1010602@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: On Mon, 11 Jun 2007, Uncle George wrote: > Steffen DETTMER wrote: >> * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: >>>> Actually, an application would need to call flush() after each >>>> write (or bunch of write calls) to ensure that write really did >>>> something otherwise I think. >> >>> OutputStreams don't _have_ to be synchronous or asynchronous, >>> but the OutputStream API was be arranged so that subclasses >>> _can_ be synchronous or asynchronous. >> >> Ahh, oki. Thanks for the clarificaion. >> >> So in short, flush() MUST be called on OutputStream, this is just >> not documented correctly or so clearly (right?). > No. > Flush can be called to force all current data in java buffer's to be > written to the kernel - NOW. > > A flush() can also *imply* that, besides writing out the buffer's that > java employs, may also imply/ask the kernel to write all data thusfar > written to the kernel, to be physically placed on the destination device > - NOW. > For some OS's there is no need to do a kernel flush(), as the I/O is > synchronized already. Since this is java, you never know what OS your on. To add to the confusion, flush on the C side throws away data. drain makes sure it is written. Looking at the ParallelImp.c we can probably do better. /* we set a timeout because all calls are sequentiell (also with asynchron) this means that the default timeout of unlimited blocks all calls (also close and status request) if the device is down */ GetCommTimeouts( (HANDLE)fd, &timeouts ); timeouts.WriteTotalTimeoutMultiplier = 0; timeouts.WriteTotalTimeoutConstant = 2000; /* 2000 is the min value for the default Windows NT and Windows 2000 driver */ SetCommTimeouts( (HANDLE)fd, &timeouts ); while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } errorCount = 0; bytes += countWritten; count -= countWritten; } LPRPort has some timeout code that appears to be doing nothing but flipping bits back and forth right now. The commapi rxtx follows allows for timeout control from javax.comm.CommPort. The above is a solution that worked in one specific use case. With timeouts in place, the original 'old printer going offline' problem could be solved. That printer code isn't written in stone. In fact it was ajusted from being able to print 'asdf' to a daisy wheel printer to working for one person. BTW, I've finished teaching after hours tonight and will be moving forward with a new rxtx release in my free time. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Jun 11 21:28:04 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 23:28:04 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: <466E12C4.1010305@gatworks.com> > Looking at the ParallelImp.c we can probably do better. > The problem stemmed from the possibility that the writev routine could have written some of the buffer, in chunks, printer pauses, refuses any more chunks, and a timeout occurs. Do you or do you not cause an exception to be thrown? Is there a way to set timeout for a ParallelPort data output stream? I cant find it. From tjarvi at qbang.org Mon Jun 11 22:17:23 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Jun 2007 22:17:23 -0600 (MDT) Subject: [Rxtx] [OT] select :-) In-Reply-To: <466E12C4.1010305@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> <466E12C4.1010305@gatworks.com> Message-ID: On Mon, 11 Jun 2007, Uncle George wrote: >> Looking at the ParallelImp.c we can probably do better. >> > The problem stemmed from the possibility that the writev routine could > have written some of the buffer, in chunks, printer pauses, refuses any > more chunks, and a timeout occurs. Do you or do you not cause an > exception to be thrown? > > Is there a way to set timeout for a ParallelPort data output stream? I > cant find it. hmm I looked again after you asked. The timeouts are only controllable on the receive side. This comes from CommPort; the parent. So what we are talking about is some bytes in memory that rxtx has and is supposed to write. A buffer perhaps? The approach with rxtx in the past has been to ignore output buffer sizes. The assumption is that the library does not know how to best handle buffers. There are buffered output streams that can do buffering on top of rxtx for instance. There is also a question regarding what was actually ment when the API was put together. My suspicion is that it was put together while looking at one OS API and was never ment to be anything more than a hook into that API. The comments are fairly telling combined with reading the w32 API. So looking at the problem again.. The current timeout behavior appears fairly arbitrary. Presumably this is to prevent a program from hanging instead of using a helper thread to write - heavy handed for new programmers. Even so, I don't think the write should timeout at all if it is not configurable. >From the API perspective, "What Timeout?" -- Trent Jarvi tjarvi at qbang.org From Steffen.DETTMER at ingenico.com Tue Jun 12 02:14:48 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 12 Jun 2007 10:14:48 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466DA32D.1010602@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: <20070612081447.GU10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Mon, Jun 11, 2007 at 15:31 -0400: > Steffen DETTMER wrote: > > Ahh, oki. Thanks for the clarificaion. > > > > So in short, flush() MUST be called on OutputStream, this is just > > not documented correctly or so clearly (right?). > No. hum (though now I got it, but...). > Flush can be called to force all current data in java buffer's to be > written to the kernel - NOW. > > A flush() can also *imply* that, besides writing out the > buffer's that java employs, may also imply/ask the kernel to > write all data thusfar written to the kernel, to be physically > placed on the destination device - NOW. > > For some OS's there is no need to do a kernel flush(), as the I/O is > synchronized already. Since this is java, you never know what OS your on. (well, but if you're going to kernel level, even flush cannot guarantee that data will "be physically placed". Maybe you're flushing to a file via NFS (and the client "thinks" that it was written, but maybe it was just buffered by the NFS server) or so... but of course such exceptions of the rules are constructable always.) Well, you tell that depending on the OS it can be that flush is needed or it can be that flush is not needed (beacuse the I/O is synchronized already), right? Also, applications should work on any OS, which includes the OSes that do need flush. Since the application cannot know whether flush is needed or not because it doesn't know what the OS is doing, it has to call flush, hasn't it? I mean, if it would not call flush then it would not work on such OSes (except the written data would not be needed at all, but in this would be an artificial example :)). Since applications are supposed to work this would be wrong, wouldn't it? So would it be correct to say: "Applications, that should work under all OSes (including the OSes where the I/O is not synchronised already), have to call flush on OutputStream to ensure the data is transfered to the kernel." or is this wrong? If so, then I'm afraid I missed the point again :( oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Tue Jun 12 04:46:52 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 12 Jun 2007 06:46:52 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070612081447.GU10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> <20070612081447.GU10821@elberon.bln.de.ingenico.com> Message-ID: <466E799C.7060700@gatworks.com> S > (well, but if you're going to kernel level, even flush cannot > guarantee that data will "be physically placed". Thats true now-a-days because ( from "man 2 sync" ) : > According to the standard specification (e.g., SVID), sync() schedules > the writes, but may return before the actual writing is done. However, > since version 1.3.20 Linux does actually wait. (This still does not > guarantee data integrity: modern disks have large caches.) My disk drive has 8mb cache. Maybe you're > flushing to a file via NFS (and the client "thinks" that it was > written, but maybe it was just buffered by the NFS server) or > so... but of course such exceptions of the rules are > constructable always.) > > Well, you tell that depending on the OS it can be that flush is > needed or it can be that flush is not needed (beacuse the I/O is > synchronized already), right? Also, applications should work on > any OS, which includes the OSes that do need flush. Its not OS's that need flush, its applications that want to have some assurance that data is written to the device that really needs to use flush. If your program ( or thread ) dies then it is in your best interest to write out the critical data as soon as possible, as economical as possible. These are trade-off's that the application programmer makes. A big buffer may mean big loss of data, a small buffer may mean spending too much time writing out data. > > > So would it be correct to say: > > "Applications, that should work under all OSes (including the > OSes where the I/O is not synchronised already), have to call > flush on OutputStream to ensure the data is transfered to the > kernel." > > or is this wrong? If so, then I'm afraid I missed the point again > :( > No that is not wrong. Ensuring that data is transfered to the OS is just about what any application can do. From tjarvi at qbang.org Thu Jun 14 08:16:47 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 14 Jun 2007 08:16:47 -0600 (MDT) Subject: [Rxtx] rxtx and usb-serial solution In-Reply-To: References: Message-ID: On Thu, 14 Jun 2007, Vladimir Kirtchev wrote: > Hi Trent, > > I develop a Java application which communicates with devices which have > USB-to-Serial bridge in them. The target OS is Linux. So for this purpose I > use RXTX. > > But I encountered a strange problem - when reading from the InputStream, I > receive series of zeros. I have this problem under Linux only. Under Windows > it is fine. > Actually this problem is the same as the one described here: > http://marc.info/?l=rxtx&m=109703190731748&w=2. > > > So I searched for the problem in the native code. And found that the root of > the problem is in SerialImp.c, > int configure_port( int fd ) > { > ... > ttyset.c_iflag = INPCK; > ... > } > > This line enables input parity checking, and the data sent from the device > is processed by the OS driver before being read with read(). > In this case the driver detects some problem and sets the received bytes to > zero. > > On the other hand in the Java part a set the serial port parameters with > SerialPort.PARITY_NONE. According to me, except all other things, this > should also disable INPCK in c_iflag. > > So I refactored the method translate_parity(...) to the following: > > int translate_parity( JNIEnv *env, struct termios *ttyset, jint parity ) > { > ENTER( "translate_parity" ); > #ifdef CMSPAR > ttyset->c_cflag &= ~(PARENB | PARODD | CMSPAR ); > #endif /* CMSPAR */ > switch( parity ) { > case JPARITY_NONE: > ttyset->c_iflag &= ~INPCK; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_EVEN: > ttyset->c_cflag |= PARENB; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_ODD: > ttyset->c_cflag |= PARENB | PARODD; > LEAVE( "translate_parity" ); > return 0; > #ifdef CMSPAR > case JPARITY_MARK: > ttyset->c_cflag |= PARENB | PARODD | CMSPAR; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_SPACE: > ttyset->c_cflag |= PARENB | CMSPAR; > LEAVE( "translate_parity" ); > return 0; > #endif /* CMSPAR */ > default: > printf("Parity missed %i\n", (int) parity ); > } > > LEAVE( "translate_parity" ); > /* > For some reason the native exceptions are not being caught. Moving this > to the Java side fixed the issue. taj. > throw_java_exception( env, UNSUPPORTED_COMM_OPERATION, > "", "parity value not supported" ); > */ > return 1; > } > > This modification solved the problem and now it works correctly under Linux. > > I think I will be a nice if this is idea is included in a future release of > RXTX. > > Thanks Vadim, I'll try that out. Forwarding to the rxtx mail-list too. This is probably not going to help USB drivers on windows which I'm sure some are looking for. As far as I can tell, windows USB bluetooth and serial dongles are limited by driver functionality. Some are good and others lack key features. -- Trent Jarvi tjarvi at qbang.org From dan.sandberg.lists at gmail.com Mon Jun 18 14:43:39 2007 From: dan.sandberg.lists at gmail.com (Dan Sandberg) Date: Mon, 18 Jun 2007 13:43:39 -0700 Subject: [Rxtx] Fix for JNI Get/Set Field Errors Message-ID: <4676EE7B.7060800@gmail.com> Hi, I've fixed the problems that cause the following JNI error when extra JNI checking ( -Xjni:check ) is turned on. FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) The problem was basically that GetLong was being used to get ints, and SetInt was used for longs. The patch below fixes this. Please let me know if there are any questions / problems. Cheers, -Dan diff -aur old/SerialImp.c src/SerialImp.c --- old/SerialImp.c 2007-06-18 13:24:33.000000000 -0700 +++ src/SerialImp.c 2007-06-18 06:26:26.000000000 -0700 @@ -1337,7 +1337,7 @@ report("init_threads: get eis\n"); jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); report("init_threads: set eis\n"); - (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); + (*eis->env)->SetLongField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); report("init_threads: stop\n"); report_time_end( ); return( 1 ); @@ -1530,7 +1530,7 @@ jobject jobj, jboolean interrupted ) { int fd = get_java_var( env, jobj,"fd","I" ); - struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var( env, jobj, "eis", "J" ); + struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var_long( env, jobj, "eis", "J" ); int result, count=0; char message[80]; @@ -2939,7 +2939,7 @@ /* TRENT */ int flag, count = 0; struct event_info_struct *eis = ( struct event_info_struct * ) - get_java_var( env, *jobj,"eis","J" ); + get_java_var_long( env, *jobj,"eis","J" ); report_time_start(); flag = eis->eventflags[SPE_DATA_AVAILABLE]; @@ -4873,9 +4873,9 @@ exceptions: none comments: ----------------------------------------------------------*/ -size_t get_java_var( JNIEnv *env, jobject jobj, char *id, char *type ) +long get_java_var_long( JNIEnv *env, jobject jobj, char *id, char *type ) { - int result = 0; + long result = 0; jclass jclazz = (*env)->GetObjectClass( env, jobj ); jfieldID jfd = (*env)->GetFieldID( env, jclazz, id, type ); @@ -4889,7 +4889,11 @@ LEAVE( "get_java_var" ); return result; } - result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); + if ( !strcmp( type, "J" ) ) { + result = (long)( (*env)->GetLongField( env, jobj, jfd ) ); + } else { + result = (int) ( (*env)->GetIntField( env, jobj, jfd ) ); + } /* ct7 & gel * Added DeleteLocalRef */ (*env)->DeleteLocalRef( env, jclazz ); if(!strncmp( "fd",id,2) && result == 0) @@ -4900,6 +4904,10 @@ return result; } +int get_java_var( JNIEnv *env, jobject jobj, char *id, char *type ) { + return (int) get_java_var_long( env, jobj, id, type ); +} + /*---------------------------------------------------------- throw_java_exception diff -aur old/SerialImp.h src/SerialImp.h --- old/SerialImp.h 2007-06-18 13:24:39.000000000 -0700 +++ src/SerialImp.h 2007-06-18 06:23:43.000000000 -0700 @@ -413,7 +413,8 @@ void system_wait(); void finalize_event_info_struct( struct event_info_struct * ); int read_byte_array( JNIEnv *, jobject *, int, unsigned char *, int, int ); -size_t get_java_var( JNIEnv *, jobject, char *, char * ); +int get_java_var( JNIEnv *, jobject, char *, char * ); +long get_java_var_long( JNIEnv *, jobject, char *, char * ); jboolean is_interrupted( struct event_info_struct * ); int send_event(struct event_info_struct *, jint, int ); void dump_termios(char *,struct termios *); From yvespielusenet at free.fr Tue Jun 26 03:41:58 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 11:41:58 +0200 Subject: [Rxtx] [PARALLEL] resource in use Message-ID: <1182850918.3483.10.camel@localhost.localdomain> Hello, So now I want to modify the timeout of the library for parallel port. I have downloaded source code. There is a makefile for migw. SO I have installed mingw on ubuntu and modified the makefile.mingw32 to set it for my system. I have no error but some warnings. The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But When I want to use it the jvm crash :( How can I know what is wrong ? How rxtx windows release has been done ? thanks -- yves piel From netbeans at gatworks.com Fri Jun 1 05:38:50 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 07:38:50 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <465F7ADD.1010501@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> Message-ID: <4660054A.2040202@gatworks.com> Manuel Naranjo wrote: In the case of my module, you can > unplug the device but it will not delete the symlink until those apps > that had opened the port has closed it. This is done this way to avoid > kernel panics. What does this mean to user code ? I have tried the alternate route ( other than closing ) which is sleep inbetween the I/O errors ( an unplugged USB device). When the device is plugged back in, The writes to the device still get an I/O error. This would seem to be a lost cause for the application. From netbeans at gatworks.com Fri Jun 1 06:35:48 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 08:35:48 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <465F7ADD.1010501@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> Message-ID: <466012A4.90608@gatworks.com> Manuel Naranjo wrote: In the case of my module, you can > unplug the device but it will not delete the symlink until those apps > that had opened the port has closed it. T Did u also mean for this to happen? USB0 was not closed by application. Apparently USB1 got created when USB device was plugged back in. There is only one USB device on a 4 port USB hub. This also seems to suggest that application recovery to be impossible. > Jun 1 07:10:08 mylaptop kernel: garmin_gps 1-1.4:1.0: Garmin GPS usb/tty converter detected > Jun 1 07:10:08 mylaptop kernel: usb 1-1.4: Garmin GPS usb/tty converter now attached to ttyUSB0 > Jun 1 07:15:17 mylaptop kernel: usb 1-1: USB disconnect, address 4 > Jun 1 07:15:17 mylaptop kernel: usb 1-1.4: USB disconnect, address 5 > Jun 1 07:15:17 mylaptop kernel: garmin_gps 1-1.4:1.0: device disconnected > Jun 1 07:15:26 mylaptop kernel: usb 1-1: new full speed USB device using uhci_hcd and address 6 > Jun 1 07:15:26 mylaptop kernel: hub 1-1:1.0: USB hub found > Jun 1 07:15:26 mylaptop kernel: hub 1-1:1.0: 4 ports detected > Jun 1 07:15:27 mylaptop kernel: usb 1-1.4: new full speed USB device using uhci_hcd and address 7 > Jun 1 07:15:27 mylaptop kernel: garmin_gps 1-1.4:1.0: Garmin GPS usb/tty converter detected > Jun 1 07:15:27 mylaptop kernel: usb 1-1.4: Garmin GPS usb/tty converter now attached to ttyUSB1 From naranjo.manuel at gmail.com Fri Jun 1 09:17:22 2007 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Fri, 01 Jun 2007 12:17:22 -0300 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <466012A4.90608@gatworks.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> <466012A4.90608@gatworks.com> Message-ID: <46603882.5050701@gmail.com> Uncle George escribi?: > Manuel Naranjo wrote: > In the case of my module, you can > >> unplug the device but it will not delete the symlink until those apps >> that had opened the port has closed it. T >> > > Did u also mean for this to happen? USB0 was not closed by application. > > Apparently USB1 got created when USB device was plugged back in. There > is only one USB device on a 4 port USB hub. > > This also seems to suggest that application recovery to be impossible. > Exactly there's a dead symlink (you can read and write to it and nothing will happen) and a new port will be created when a new device is connencted. From netbeans at gatworks.com Fri Jun 1 10:20:46 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 12:20:46 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <46603882.5050701@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> <466012A4.90608@gatworks.com> <46603882.5050701@gmail.com> Message-ID: <4660475E.5090202@gatworks.com> Not sure what u mean by "symlink". U cant read/write to it anymore. U get I/O error. In this scenario the device effectively went dead, and only solution is to close the channel. reconnecting the USB device, although dead, but not closed, will create a second device. This does not seem to be a desirable side-effect. The user will now have ttyUSB1, wondering where did ttyUSB0 go to. The application will also be in a confused state, as well as RXTX, because RXTX wont know about ttyUSB1. Manuel Naranjo wrote: > Uncle George escribi?: >> Manuel Naranjo wrote: >> In the case of my module, you can >> >>> unplug the device but it will not delete the symlink until those apps >>> that had opened the port has closed it. T >>> >> Did u also mean for this to happen? USB0 was not closed by application. >> >> Apparently USB1 got created when USB device was plugged back in. There >> is only one USB device on a 4 port USB hub. >> >> This also seems to suggest that application recovery to be impossible. >> > Exactly there's a dead symlink (you can read and write to it and nothing > will happen) and a new port will be created when a new device is connencted. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From arnab.bhaumik at gmail.com Mon Jun 4 01:40:16 2007 From: arnab.bhaumik at gmail.com (arnab bhaumik) Date: Mon, 4 Jun 2007 13:10:16 +0530 Subject: [Rxtx] full duplex com port with rxtx Message-ID: hi , till now i did half duplex communication with rxtx package on com package. my question is : is it possible to use com port with full duplex mode with rxtx package . ther is example of SimpleRead class and SimpleWrite class. it is clear that if i can use both the class simultaneously then full duplex is possible......... arnab/vu2bpw -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070604/6edb0453/attachment-0007.html From lists at iDIAcomputing.com Mon Jun 4 07:53:17 2007 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Mon, 04 Jun 2007 09:53:17 -0400 Subject: [Rxtx] full duplex com port with rxtx In-Reply-To: References: Message-ID: <4664194D.90301@iDIAcomputing.com> arnab bhaumik wrote: > hi , > > till now i did half duplex communication with rxtx package on com > package. > > my question is : is it possible to use com port with full duplex mode > with rxtx package . > > > ther is example of SimpleRead class and SimpleWrite class. it is > clear that if i can use both the class simultaneously then full duplex > is possible......... I haven't looked at the SimpleRead and SimpleWrite classes (I originally wrote my code for the javax.comm api), but full duplex is certainly possible. My CommReader class requires an object analogous to a OutputStream or Writer. When started, it spawns a thread that reads the comm port and writes to that output device. In this way the input is asynchronous and dependent on the actual input data. For full duplex, I extend that class with CommReaderWriter, which adds synchronous output methods. Hope that helps, George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From supsoop at hotmail.com Mon Jun 4 15:21:06 2007 From: supsoop at hotmail.com (soop soop) Date: Mon, 04 Jun 2007 21:21:06 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- Message-ID: Hi Guys, Looked through the archives but still cannot figure this out. I have a Motorola G24 GPRS/GSM modem that I am connecting to my server running Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not detecting the port, CommPortIdentifier.getPortIdentifiers(). I have added the line to RXTXCommDriver: "ttyACM" // for USB Modems Rxtx still does not seem to find the port. Is there something I am missing to make this port visable? [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control Model driver for USB modems and ISDN adapters I really need your help as I have moved my server from windows to Linux and have been down for a few days because of this .. Thanks so much! _________________________________________________________________ PC Magazine’s 2007 editors’ choice for best Web mail—award-winning Windows Live Hotmail. http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 From tjarvi at qbang.org Mon Jun 4 16:17:35 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Jun 2007 16:17:35 -0600 (MDT) Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: On Mon, 4 Jun 2007, soop soop wrote: > Hi Guys, > > Looked through the archives but still cannot figure this out. I have a > Motorola G24 GPRS/GSM modem that I am connecting to my server running Ubuntu. > I can see my modem as is shows up as ttyACM0, but RXTX is not detecting the > port, CommPortIdentifier.getPortIdentifiers(). > > I have added the line to RXTXCommDriver: > > "ttyACM" // for USB Modems > > Rxtx still does not seem to find the port. Is there something I am missing to > make this port visable? > > [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver > [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device > [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control Model > driver for USB modems and ISDN adapters > > I really need your help as I have moved my server from windows to Linux and > have been down for a few days because of this .. Thanks so much! > You could try the INSTALL documentation that comes with the source for possible solutions. Those usually involve lockfile creation, permissions on the device file or the device is in use by another application (even another session of your application). The usual commands: ls -l /dev/ttyACM0 fuser /dev/ttyACM0 touch /var/lock/LCK.testfile && rm -f /var/lock/LCK.testfile whoami To disable lockfiles: ../configure --disable-lockfiles && make install -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Jun 4 16:22:52 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 04 Jun 2007 18:22:52 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <466490BC.3090801@gatworks.com> soop soop wrote: > I really need your help as I have moved my server from windows to Linux > and have been down for a few days because of this .. Thanks so much! can u open the device ? ie is the file protection/permissions keeping you out? From supsoop at hotmail.com Mon Jun 4 16:44:40 2007 From: supsoop at hotmail.com (soop soop) Date: Mon, 04 Jun 2007 22:44:40 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <466490BC.3090801@gatworks.com> Message-ID: Thanks for the reply, I see no exceptions being thrown, just no detection of the port whats so ever. I will run rxtx in debug mode and log. If this were a permissions issue would I not see some exceptions being thrown? >From: Uncle George >Reply-To: RXTX Developers and Users >To: RXTX Developers and Users >Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >Date: Mon, 04 Jun 2007 18:22:52 -0400 > >soop soop wrote: > > > I really need your help as I have moved my server from windows to Linux > > and have been down for a few days because of this .. Thanks so much! > >can u open the device ? ie is the file protection/permissions keeping >you out? >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ Get a preview of Live Earth, the hottest event this summer - only on MSN http://liveearth.msn.com?source=msntaglineliveearthhm From netbeans at gatworks.com Mon Jun 4 17:06:15 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 04 Jun 2007 19:06:15 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <46649AE7.10405@gatworks.com> Exceptions on what? On startup it wants to lookup all devices in /dev that it is capable of opening ( within the list of specific 'comm' devices ). If it cannot open, then does not get onto list. Part of this process, if configured, will also test if the "LOCK" schema can also be opened for the device. then it gets on the list of avail comm port. soop soop wrote: > Thanks for the reply, > > I see no exceptions being thrown, just no detection of the port whats so > ever. I will run rxtx in debug mode and log. If this were a permissions > issue would I not see some exceptions being thrown? > > >> From: Uncle George >> Reply-To: RXTX Developers and Users >> To: RXTX Developers and Users >> Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >> Date: Mon, 04 Jun 2007 18:22:52 -0400 >> >> soop soop wrote: >> >>> I really need your help as I have moved my server from windows to Linux >>> and have been down for a few days because of this .. Thanks so much! >> can u open the device ? ie is the file protection/permissions keeping >> you out? >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _________________________________________________________________ > Get a preview of Live Earth, the hottest event this summer - only on MSN > http://liveearth.msn.com?source=msntaglineliveearthhm > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From alex.flint at gmail.com Mon Jun 4 21:31:49 2007 From: alex.flint at gmail.com (Alex Flint) Date: Tue, 5 Jun 2007 13:01:49 +0930 Subject: [Rxtx] random EXCEPTION_ACCESS_VIOLATION errors Message-ID: Hi All, I'm running winXP and RXTX 2.1-7r2 (the latest from the webpage as of June 2007). I'm sending sequences of 64 lines (each line has about 15 chars) at various intervals. The strings are sent fine, until I get the following error (from hs_err_pid3316.log, at the end of this email). What can I do to avoid the error? Obviously this is a low-level memory exception, but is there any way I can keep the JVM running after such an error? I noticed the exact same problem here: http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20070129/1180520.html Cheers, Alex # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x100034fb, pid=3316, tid=2400 # # Java VM: Java HotSpot(TM) Client VM (1.6.0_01-b06 mixed mode, sharing) # Problematic frame: # C [rxtxSerial.dll+0x34fb] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # --------------- T H R E A D --------------- Current thread (0x00386400): JavaThread "main" [_thread_in_native, id=2400] siginfo: ExceptionCode=0xc0000005, reading address 0x20726f78 Registers: EAX=0x20726f20, EBX=0x6d8922c0, ECX=0x00000005, EDX=0x20726f20 ESP=0x003efa30, EBP=0x003efb68, ESI=0x269728a0, EDI=0x00386400 EIP=0x100034fb, EFLAGS=0x00010212 Top of Stack: (sp=0x003efa30) 0x003efa30: 003efa3c 003efa64 0000000f ffffffff 0x003efa40: 003efa40 2a97f808 003efa6c 2b190ca8 0x003efa50: 00000000 2b190ec0 003efa90 008e2dd7 0x003efa60: 003efa90 008e2dd7 26977f88 6d815e72 0x003efa70: 00000004 2696eae0 0000008a 003efb0c 0x003efa80: 6d852b4a 2696eae0 00000003 26970930 0x003efa90: 000000cb 2696eae0 6d86b264 00385d40 0x003efaa0: 0000003f 003efb0c 26977f90 2ace65d8 Instructions: (pc=0x100034fb) 0x100034eb: ff ff 8d 76 00 eb 02 89 f6 90 8b 45 f8 8b 55 f8 0x100034fb: 8b 4a 58 83 c9 04 89 48 58 83 c4 f8 8b 45 f8 8b Stack: [0x003a0000,0x003f0000), sp=0x003efa30, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x34fb] Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j gnu.io.RXTXPort.writeArray([BIIZ)V+0 j gnu.io.RXTXPort$SerialOutputStream.write([B)V+76 j com.bjt.media.server.CommLink.send(Ljava/lang/String;)V+48 j com.bjt.media.server.DigitoolConnection.select(I)V+73 j com.bjt.media.server.DigitoolConnection.main([Ljava/lang/String;)V+74 v ~StubRoutines::call_stub --------------- P R O C E S S --------------- Java Threads: ( => current thread ) 0x02a69400 JavaThread "Thread-0" [_thread_in_native, id=3052] 0x02a4d000 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=3920] 0x02a48400 JavaThread "CompilerThread0" daemon [_thread_blocked, id=1968] 0x02a47400 JavaThread "Attach Listener" daemon [_thread_blocked, id=2984] 0x02a46400 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=2660] 0x02a41c00 JavaThread "Finalizer" daemon [_thread_blocked, id=3924] 0x02a3d800 JavaThread "Reference Handler" daemon [_thread_blocked, id=4008] =>0x00386400 JavaThread "main" [_thread_in_native, id=2400] Other Threads: 0x02a34400 VMThread [id=3708] 0x02a4e800 WatcherThread [id=3964] VM state:not at safepoint (normal execution) VM Mutex/Monitor currently owned by a thread: None Heap def new generation total 960K, used 131K [0x22960000, 0x22a60000, 0x22e40000) eden space 896K, 7% used [0x22960000, 0x22970ea8, 0x22a40000) from space 64K, 99% used [0x22a50000, 0x22a5fff8, 0x22a60000) to space 64K, 0% used [0x22a40000, 0x22a40000, 0x22a50000) tenured generation total 4096K, used 76K [0x22e40000, 0x23240000, 0x26960000) the space 4096K, 1% used [0x22e40000, 0x22e53060, 0x22e53200, 0x23240000) compacting perm gen total 12288K, used 137K [0x26960000, 0x27560000, 0x2a960000) the space 12288K, 1% used [0x26960000, 0x26982518, 0x26982600, 0x27560000) ro space 8192K, 62% used [0x2a960000, 0x2ae5e4e8, 0x2ae5e600, 0x2b160000) rw space 12288K, 52% used [0x2b160000, 0x2b7a0e78, 0x2b7a1000, 0x2bd60000) Dynamic libraries: 0x00400000 - 0x00423000 C:\Program Files\Java\jre1.6.0_01\bin\javaw.exe 0x7c900000 - 0x7c9b0000 C:\WINDOWS\system32\ntdll.dll 0x7c800000 - 0x7c8f4000 C:\WINDOWS\system32\kernel32.dll 0x77dd0000 - 0x77e6b000 C:\WINDOWS\system32\ADVAPI32.dll 0x77e70000 - 0x77f01000 C:\WINDOWS\system32\RPCRT4.dll 0x7e410000 - 0x7e4a0000 C:\WINDOWS\system32\USER32.dll 0x77f10000 - 0x77f57000 C:\WINDOWS\system32\GDI32.dll 0x76390000 - 0x763ad000 C:\WINDOWS\system32\IMM32.DLL 0x7c340000 - 0x7c396000 C:\Program Files\Java\jre1.6.0_01\bin\msvcr71.dll 0x6d7c0000 - 0x6da07000 C:\Program Files\Java\jre1.6.0_01\bin\client\jvm.dll 0x76b40000 - 0x76b6d000 C:\WINDOWS\system32\WINMM.dll 0x5cd70000 - 0x5cd77000 C:\WINDOWS\system32\serwvdrv.dll 0x5b0a0000 - 0x5b0a7000 C:\WINDOWS\system32\umdmxfrm.dll 0x6d310000 - 0x6d318000 C:\Program Files\Java\jre1.6.0_01\bin\hpi.dll 0x76bf0000 - 0x76bfb000 C:\WINDOWS\system32\PSAPI.DLL 0x6d770000 - 0x6d77c000 C:\Program Files\Java\jre1.6.0_01\bin\verify.dll 0x6d3b0000 - 0x6d3cf000 C:\Program Files\Java\jre1.6.0_01\bin\java.dll 0x6d7b0000 - 0x6d7bf000 C:\Program Files\Java\jre1.6.0_01\bin\zip.dll 0x10000000 - 0x10012000 C:\Documents and Settings\Alex\workspace\MediaServer\rxtxSerial.dll 0x73d90000 - 0x73db7000 C:\WINDOWS\system32\crtdll.dll VM Arguments: jvm_args: -Djava.library.path=C:\Documents and Settings\Alex\workspace\MediaServer java_command: com.bjt.media.server.DigitoolConnection Launcher Type: SUN_STANDARD Environment Variables: CLASSPATH=.;C:\Program Files\Java\j2re1.4.2_07\lib\ext\QTJava.zip PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\wbem;c:\applications\php;C:\Program Files\MATLAB\R2006a\bin\win32;C:\Roger\Projects\UAV\Bin\Debug;C:\Program Files\Microsoft SQL Server\80\Tools\Binn\;c:\Program Files\Microsoft SQL Server\90\Tools\binn\;C:\Program Files\QuickTime\QTSystem\;C:\Pfps\system;C:\Program Files\Java\jdk1.6.0_01\bin;C:\Program Files\Java\jdk1.6.0_01\jre\bin USERNAME=Alex OS=Windows_NT PROCESSOR_IDENTIFIER=x86 Family 15 Model 4 Stepping 1, GenuineIntel --------------- S Y S T E M --------------- OS: Windows XP Build 2600 Service Pack 2 CPU:total 1 family 15, cmov, cx8, fxsr, mmx, sse, sse2 Memory: 4k page, physical 1046508k(275288k free), swap 2522816k(1909176k free) vm_info: Java HotSpot(TM) Client VM (1.6.0_01-b06) for windows-x86, built on Mar 14 2007 00:24:02 by "java_re" with unknown MS VC++:1310 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070604/c87ae1f0/attachment-0007.html From alwyn.schoeman at gmail.com Tue Jun 5 00:10:19 2007 From: alwyn.schoeman at gmail.com (Alwyn Schoeman) Date: Tue, 5 Jun 2007 08:10:19 +0200 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Hi, I'm using a similar modem. By default rxtx doesn't look for devices that start with ACM, so you need to modify the source code and recompile. Look in RXTXCommDriver and add values for ACM in the registerScannedPorts method in the Linux specific parts. Look for osName.equals("Linux")... On 6/4/07, soop soop wrote: > > Hi Guys, > > Looked through the archives but still cannot figure this out. I have a > Motorola G24 GPRS/GSM modem that I am connecting to my server running > Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not > detecting the port, CommPortIdentifier.getPortIdentifiers(). > > I have added the line to RXTXCommDriver: > > "ttyACM" // for USB Modems > > Rxtx still does not seem to find the port. Is there something I am missing > to make this port visable? > > [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver > [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device > [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control > Model > driver for USB modems and ISDN adapters > > I really need your help as I have moved my server from windows to Linux > and > have been down for a few days because of this .. Thanks so much! > > _________________________________________________________________ > PC Magazine's 2007 editors' choice for best Web mail?award-winning Windows > Live Hotmail. > > http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -- Alwyn Schoeman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/b6cb3053/attachment-0007.html From naranjo.manuel at gmail.com Tue Jun 5 06:48:45 2007 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Tue, 05 Jun 2007 09:48:45 -0300 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> References: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Message-ID: <46655BAD.7010501@gmail.com> That's right, an easier solution is creating symlinks to acm. For example make ttyS70 to 79 point to ACM0 to 9 and that will help you a lot, and doesn't even require compile. > Hi, > > I'm using a similar modem. By default rxtx doesn't look for devices > that start with ACM, so you need to modify the > source code and recompile. > > Look in RXTXCommDriver and add values for ACM in the > registerScannedPorts method in the Linux specific parts. Look for > osName.equals("Linux")... > From juanemc2 at gmail.com Tue Jun 5 07:02:43 2007 From: juanemc2 at gmail.com (Juan) Date: Tue, 5 Jun 2007 10:02:43 -0300 Subject: [Rxtx] Problems with Epson TMU220B POSPrinter using XON/XOFF Flow Control and rxtx jar and dll's with the serial port. Message-ID: Hi!, I?m having trouble printing to the serial port using the latest version of rxtx jar and dll's with an Epson POSPrinter. I`ve switched the printer to work with XON/XOFF Flow Control and have watched the serial port to be sure the printer is sending the XON XOFF stop and go characters. I`ve setted the port like this: CommPortIdentifier commPortIdentifier = CommPortIdentifier.* getPortIdentifier*(_portName); SerialPort serialPort = (SerialPort)commPortIdentifier.open(*this*.getClass().getName(), 2000); serialPort.setSerialPortParams(_baudRate, _dataBits, _stopBits, _parity); serialPort.setFlowControlMode( SerialPort.*FLOWCONTROL_XONXOFF_IN* | SerialPort.*FLOWCONTROL_XONXOFF_OUT*); where the baudRate is 9600 the dataBits is 8 the stopBits is 1 and the parity is 0 It seems as the library isn`t taking into account the XON XOFF setting. I would like to know if I`m setting correctly the Flow Control and if you had had any experiences using XON XOFF flow control and could give me some help to solve my problem. I`m very thankful in advance, Yours, Juan Polero -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/b080995a/attachment-0007.html From ehdez.correo at gmail.com Tue Jun 5 07:12:53 2007 From: ehdez.correo at gmail.com (=?ISO-8859-1?Q?Enrique_Hern=E1ndez?=) Date: Tue, 5 Jun 2007 09:12:53 -0400 Subject: [Rxtx] problem with rxtx Message-ID: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Hello: I doing a simple test to show the serial ports. This is the code: import java.util.Enumeration; import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; public class Show { private Enumeration portList; private CommPortIdentifier portId; private SerialPort port; /** Creates a new instance of Show */ public Show() { } public static void main(String args[]){ Show show = new Show(); show.portList = CommPortIdentifier.getPortIdentifiers(); String tPort = ""; System.out.println("========================================="); while(show.portList.hasMoreElements()){ show.portId = (CommPortIdentifier)show.portList.nextElement(); if(show.portId.getPortType() == CommPortIdentifier.PORT_SERIAL) tPort = "Serial"; else tPort = "Parallel"; System.out.println(show.portId.getName() + " " + tPort); } } } whit The problem is that this code not show the serial ports, this show the no use serial ports. I want to connect whit the modem but when windows open and connect the modem my application don't see the port(COMM3) when it is connect. what I can do? Is that the correct way to know the ports? thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/eedd744b/attachment-0007.html From ehdez.correo at gmail.com Tue Jun 5 07:42:13 2007 From: ehdez.correo at gmail.com (=?ISO-8859-1?Q?Enrique_Hern=E1ndez?=) Date: Tue, 5 Jun 2007 09:42:13 -0400 Subject: [Rxtx] serial port Message-ID: <4a814e1f0706050642p4ce9ac7bka80f9479c524c5ea@mail.gmail.com> Hello: How I can ask to the port what device is connect and information about this device. thanks. bye. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/4d10d26a/attachment-0007.html From supsoop at hotmail.com Tue Jun 5 09:29:00 2007 From: supsoop at hotmail.com (soop soop) Date: Tue, 05 Jun 2007 15:29:00 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Message-ID: Hi Guys, Thanks for all your help. I found the problem. I created a user, Tomcat55, for my tomcat but it did not belong to any group. I then added this user to dialout group to have access to the device ttyACM0. Works perfectly! Again permissions was the issue. This also seems to be persistent as a server reboot does not effect the access. Cheers! >From: "Alwyn Schoeman" >Reply-To: RXTX Developers and Users >To: "RXTX Developers and Users" >Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >Date: Tue, 5 Jun 2007 08:10:19 +0200 > >Hi, > >I'm using a similar modem. By default rxtx doesn't look for devices that >start with ACM, so you need to modify the >source code and recompile. > >Look in RXTXCommDriver and add values for ACM in the registerScannedPorts >method in the Linux specific parts. Look for osName.equals("Linux")... > >On 6/4/07, soop soop wrote: >> >>Hi Guys, >> >>Looked through the archives but still cannot figure this out. I have a >>Motorola G24 GPRS/GSM modem that I am connecting to my server running >>Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not >>detecting the port, CommPortIdentifier.getPortIdentifiers(). >> >>I have added the line to RXTXCommDriver: >> >>"ttyACM" // for USB Modems >> >>Rxtx still does not seem to find the port. Is there something I am missing >>to make this port visable? >> >>[ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver >>[ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device >>[ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control >>Model >>driver for USB modems and ISDN adapters >> >>I really need your help as I have moved my server from windows to Linux >>and >>have been down for a few days because of this .. Thanks so much! >> >>_________________________________________________________________ >>PC Magazine's 2007 editors' choice for best Web mail—award-winning Windows >>Live Hotmail. >> >>http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 >> >> >>_______________________________________________ >>Rxtx mailing list >>Rxtx at qbang.org >>http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > >-- >Alwyn Schoeman >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ Need a break? Find your escape route with Live Search Maps. http://maps.live.com/default.aspx?ss=Restaurants~Hotels~Amusement%20Park&cp=33.832922~-117.915659&style=r&lvl=13&tilt=-90&dir=0&alt=-1000&scene=1118863&encType=1&FORM=MGAC01 From netbeans at gatworks.com Tue Jun 5 09:42:31 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 11:42:31 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <46658467.20101@gatworks.com> soop soop wrote: > > Hi Guys, > > Thanks for all your help. I found the problem. I created a user, > Tomcat55, for my tomcat but it did not belong to any group. I then added Look at man pages for the program udev. From tjarvi at qbang.org Tue Jun 5 18:18:17 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Jun 2007 18:18:17 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Message-ID: On Tue, 5 Jun 2007, Enrique Hern?ndez wrote: > The problem is that this code not show the serial ports, this show the no > use serial ports. I want to connect whit the modem but when windows open and > connect the modem my application don't see the port(COMM3) when it is > connect. > what I can do? > Is that the correct way to know the ports? > Hello, We may have problems understanding each other. On windows, the port will not be an available serial port if another application has the port open. That is just how the library behaves. If you can not see the port in the enumerated list, you could not open it. Also note that enumeration only happens once. If you add a port such as a new USB dongle, the port will not be visible until the next time your application runs. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Tue Jun 5 18:45:01 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 20:45:01 -0400 Subject: [Rxtx] problem with rxtx In-Reply-To: References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Message-ID: <4666038D.8090700@gatworks.com> Trent Jarvi wrote: > > > Also note that enumeration only happens once. If you add a port such as > a new USB dongle, the port will not be visible until the next time your > application runs. Is this written in stone ? somewhere? From tjarvi at qbang.org Tue Jun 5 18:54:36 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Jun 2007 18:54:36 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <4666038D.8090700@gatworks.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> Message-ID: On Tue, 5 Jun 2007, Uncle George wrote: > Trent Jarvi wrote: >> >> >> Also note that enumeration only happens once. If you add a port such as >> a new USB dongle, the port will not be visible until the next time your >> application runs. > > Is this written in stone ? somewhere? It is just the current behavior. There is nothing preventing a fix that allows reenumeration. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Tue Jun 5 19:55:19 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 21:55:19 -0400 Subject: [Rxtx] problem with rxtx In-Reply-To: References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> Message-ID: <46661407.4020308@gatworks.com> >> Is this written in stone ? somewhere? > > It is just the current behavior. There is nothing preventing a fix that > allows reenumeration. With usb, ..... , things come and go. Seems a shame that you have to kill application to get at the device u just plugged in. From joachim at buechse.ch Wed Jun 6 01:50:06 2007 From: joachim at buechse.ch (Joachim Buechse) Date: Wed, 6 Jun 2007 09:50:06 +0200 Subject: [Rxtx] problem with rxtx In-Reply-To: <46661407.4020308@gatworks.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> <46661407.4020308@gatworks.com> Message-ID: <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> On MacOS RXTX's enumeration handling is more flexible. It will find new ports that are added during the lifetime of the application. But this is inherently incompatible with suns javax.comm implementation... Regards, Joachim On 06.06.2007, at 03:55, Uncle George wrote: > >>> Is this written in stone ? somewhere? >> >> It is just the current behavior. There is nothing preventing a >> fix that >> allows reenumeration. > > With usb, ..... , things come and go. Seems a shame that you have to > kill application to get at the device u just plugged in. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Jun 6 06:06:48 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Jun 2007 06:06:48 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> <46661407.4020308@gatworks.com> <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> Message-ID: Sun's javax.comm is not a major concern going forward. As long as we do not break old applications using rxtx, I see no reason to limit rxtx to that convention. We have already rejected version 3 from Sun as a dead end and limited our compatability to version 2. That does not mean we will not try to work with Sun and others but the current javax.comm convention (v3) is not a well conceived path. There has been discussion about doing a JSR which is one valid option. On Wed, 6 Jun 2007, Joachim Buechse wrote: > On MacOS RXTX's enumeration handling is more flexible. It will find > new ports that are added during the lifetime of the application. But > this is inherently incompatible with suns javax.comm implementation... > > Regards, > Joachim > > On 06.06.2007, at 03:55, Uncle George wrote: > >> >>>> Is this written in stone ? somewhere? >>> >>> It is just the current behavior. There is nothing preventing a >>> fix that >>> allows reenumeration. >> >> With usb, ..... , things come and go. Seems a shame that you have to >> kill application to get at the device u just plugged in. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From yvespielusenet at free.fr Wed Jun 6 08:46:35 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 16:46:35 +0200 Subject: [Rxtx] [PARALLEL] resource in use Message-ID: <1181141195.3407.20.camel@localhost.localdomain> Hello, I want to use rxtx in my application. I haveto send data to a very old printer (which have a drum and hammers http://perso.orange.fr/tiie/page00010017.html) This is printer is connecter with centronics. It works well but, while it's writting and I putthe printer off-line, after about 45 seconds, I have this error : ------------------------------------- java.io.IOException: La ressource demand?e est en cours d'utilisation. in writeArray at gnu.io.LPRPort.writeArray(Native Method) at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:292) at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:161) at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:156) at mce.buffer.bufferManager.BufferManager$PrintBuffer.run(BufferManager.java:141) The IOexception means "The wanted resource is in use" ------------------------------------- Here is the line 141 of BufferManager : ------------------------------------- while(send){ try{ fos.write(bb); <=== line 141 send = false; } catch(Exception e){ javax.swing.JOptionPane.showMessageDialog(null, "Erreur d'envoie. Veuillez cliquer sur OK pour relancer l'impression de la vignette.\nV?rifiez votre impression !", "Erreur d'envoie", javax.swing.JOptionPane.WARNING_MESSAGE); e.printStackTrace(System.err); System.err.flush(); System.out.println(e); send = true; } } -------------------------------- 'fos' is an outputstream which contains the rxtx stream (this.os is the rxtx outputstream) : -------------------------------- public void write(byte[] bb) throws IOException{ this.write(bb, 0, bb.length); } public void write(byte[] bb, int off, int len) throws IOException{ while(!imp1.isPrinterSelected() || !imp2.isPrinterSelected()){ } this.os.write(bb, off, len); } -------------------------------- Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( can you help me ? thank you :) -- yves piel From yvespielusenet at free.fr Wed Jun 6 09:11:15 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 17:11:15 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181141195.3407.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> Message-ID: <1181142675.3407.23.camel@localhost.localdomain> I forgot to tell that It's under windows XP and java 1.5. Le mercredi 06 juin 2007 ? 16:46 +0200, yves pielusenet a ?crit : > Hello, > I want to use rxtx in my application. I haveto send data to a very old > printer (which have a drum and hammers > http://perso.orange.fr/tiie/page00010017.html) > This is printer is connecter with centronics. It works well but, while > it's writting and I putthe printer off-line, after about 45 seconds, I > have this error : > ------------------------------------- > java.io.IOException: La ressource demand?e est en cours d'utilisation. > in writeArray > at gnu.io.LPRPort.writeArray(Native Method) > at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:292) > at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:161) > at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:156) > at mce.buffer.bufferManager.BufferManager$PrintBuffer.run(BufferManager.java:141) > > The IOexception means "The wanted resource is in use" > ------------------------------------- > > Here is the line 141 of BufferManager : > > ------------------------------------- > while(send){ > try{ > fos.write(bb); <=== line 141 > send = false; > } > catch(Exception e){ > javax.swing.JOptionPane.showMessageDialog(null, "Erreur d'envoie. Veuillez cliquer sur OK pour relancer l'impression de la vignette.\nV?rifiez votre impression !", "Erreur d'envoie", javax.swing.JOptionPane.WARNING_MESSAGE); > e.printStackTrace(System.err); > System.err.flush(); > System.out.println(e); > send = true; > } > } > -------------------------------- > 'fos' is an outputstream which contains the rxtx stream (this.os is the rxtx outputstream) : > > -------------------------------- > public void write(byte[] bb) throws IOException{ > this.write(bb, 0, bb.length); > } > public void write(byte[] bb, int off, int len) throws IOException{ > while(!imp1.isPrinterSelected() || !imp2.isPrinterSelected()){ > } > this.os.write(bb, off, len); > } > -------------------------------- > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > can you help me ? > > thank you :) > From netbeans at gatworks.com Wed Jun 6 09:21:46 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 11:21:46 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181141195.3407.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> Message-ID: <4666D10A.8000507@gatworks.com> } > -------------------------------- > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > can you help me ? > > thank you :) > windoz or linux? ( I guess windoz ) for windoz, there appears to be a timeout ( as Comments suggest ) of about 40seconds. > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } for linux, there is no implied timeout. > if( write( fd, bytes, count ) < 0 ) > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); From netbeans at gatworks.com Wed Jun 6 09:39:41 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 11:39:41 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666D10A.8000507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> Message-ID: <4666D53D.90000@gatworks.com> Uncle George wrote: > } >> -------------------------------- >> >> Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( >> >> can you help me ? From reading the code, I can see your concern. And it appears you are correct, because some of the data will be sent to the OS printer buffers, and then it will refuse to accept anymore. Unfortunately, writeArray does not return the num of characters written :{ So application has no idea to how many characters were accepted by the OS. I dont do windoz, so I cant say with absolute certainty what windoz will do with an off-line condition. If you have the source, and can compile, then maybe u can increase the loop count to hit 4hours? From yvespielusenet at free.fr Wed Jun 6 09:53:25 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 17:53:25 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666D10A.8000507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> Message-ID: <1181145205.3407.35.camel@localhost.localdomain> Thank you for your explanation :) This timeout comes when no data has been send to the printer after 40seconds if I well understand. But why there is such a timeout ? If I setthe printer offline while it's printing I mustn't have an exception. I don't understand why the "printer should solv all problems like buffer full" in 40 seconds. If I pause the printer the buffer will not be emptied, isn't it ? I not very familiar with C/C++, but it seem that the exception is thrown only when countWritten == 0, that means no data at all has been sent. So Is my code is good since when I intercept this exception I send all my buffer again. There is no way that the printer receive two times same bytes ? thanks ps: yes the application is running on windows XP since I developpe under Debian Le mercredi 06 juin 2007 ? 11:21 -0400, Uncle George a ?crit : > } > > -------------------------------- > > > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > > > can you help me ? > > > > thank you :) > > > > windoz or linux? ( I guess windoz ) > > for windoz, there appears to be a timeout ( as Comments suggest ) of > about 40seconds. > > while( count > 0 ){ > > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > > /* > > this are 20 * 2 seconds, in this time a printer (or other parallel device) > > should solv all problems like buffer full, etc > > */ > > if(errorCount++ < 20){ > > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > > continue; > > } > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > for linux, there is no implied timeout. > > if( write( fd, bytes, count ) < 0 ) > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Wed Jun 6 10:34:24 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 12:34:24 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181145205.3407.35.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> Message-ID: <4666E210.30507@gatworks.com> yves pielusenet wrote: > Thank you for your explanation :) > This timeout comes when no data has been send to the printer after > 40seconds if I well understand. But why there is such a timeout ? If I > setthe printer offline while it's printing I mustn't have an exception. > I don't understand why the "printer should solv all problems like buffer > full" in 40 seconds. If I pause the printer the buffer will not be > emptied, isn't it ? > > I not very familiar with C/C++, but it seem that the exception is thrown > only when countWritten == 0, that means no data at all has been sent. So > Is my code is good since when I intercept this exception I send all my > buffer again. There is no way that the printer receive two times same > bytes ? More technically, the function call returns and reports that 0 characters was written in this call. when 0 characters are written, it will check how many times 0 characters was written. If it has tried LESS than 20 times(errorCount), it will sleep() and try to write again. After 20 times, it wont sleep, but throw you the exception. Now suppose you are writing a 120 character line. you off-lined/paused your printer. The OS has room for 80 more characters in it's printer buffer. The WriteFile() will have a char count of 120, but on return the countWritten = 80. You still have 40 more characters to print. Since countWritten != 0, the counters: bytes += countWritten; count -= countWritten; get updated, and the Writefile now has a count of 40 characters. Since the printer is off-line, the countwritten is 0. And so the loop continues, till 40 seconds is up. As to why it is this way, i dont know ( not a windoz maven ); Also the sleep(20) in the loop is not so intuitive to suggest 2 seconds of sleep. I would have guessed 20seconds, or 20milliseconds. But go figure. BTW: Since your computer sends you error messages in French, does it curse in English? :)))) From yvespielusenet at free.fr Thu Jun 7 02:27:44 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Thu, 07 Jun 2007 10:27:44 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666E210.30507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> Message-ID: <1181204864.3501.10.camel@localhost.localdomain> Maybe in my case I should re-compile rxtx and change the code. Instead of send an exception I should display a dialog box to ask if it's printer problem or if it should trie to send bytes. Something like : while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } if(displayDialogBox("Try again to send datas ??")){ errorCount = 0; } else{ throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } } Le mercredi 06 juin 2007 ? 12:34 -0400, Uncle George a ?crit : > yves pielusenet wrote: > > Thank you for your explanation :) > > This timeout comes when no data has been send to the printer after > > 40seconds if I well understand. But why there is such a timeout ? If I > > setthe printer offline while it's printing I mustn't have an exception. > > I don't understand why the "printer should solv all problems like buffer > > full" in 40 seconds. If I pause the printer the buffer will not be > > emptied, isn't it ? > > > > I not very familiar with C/C++, but it seem that the exception is thrown > > only when countWritten == 0, that means no data at all has been sent. So > > Is my code is good since when I intercept this exception I send all my > > buffer again. There is no way that the printer receive two times same > > bytes ? > More technically, the function call returns and reports that 0 > characters was written in this call. > when 0 characters are written, it will check how many times 0 characters > was written. If it has tried LESS than 20 times(errorCount), it will > sleep() and try to write again. > After 20 times, it wont sleep, but throw you the exception. > > Now suppose you are writing a 120 character line. you off-lined/paused > your printer. The OS has room for 80 more characters in it's printer > buffer. The WriteFile() will have a char count of 120, but on return the > countWritten = 80. You still have 40 more characters to print. > Since countWritten != 0, the counters: > bytes += countWritten; > count -= countWritten; > get updated, and the Writefile now has a count of 40 characters. Since > the printer is off-line, the countwritten is 0. And so the loop > continues, till 40 seconds is up. > > As to why it is this way, i dont know ( not a windoz maven ); > Also the sleep(20) in the loop is not so intuitive to suggest 2 seconds > of sleep. I would have guessed 20seconds, or 20milliseconds. But go figure. > > BTW: Since your computer sends you error messages in French, does it > curse in English? :)))) > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 06:11:43 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 08:11:43 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181204864.3501.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> Message-ID: <4667F5FF.8070903@gatworks.com> your suggestion appears good. I dont know what displayDialogBox exactly will do, so all I can say it that it looks good. But I'd like to wait 10min before first dialog box And a 5 min wait for every dialog box there after. And since these are custom solution/choices, maybe a more exact explanation of what the issue is. if(errorCount++ < 300){ // wait 10min ( 10min * 60sec / 2 ) Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } if(displayDialogBox("Printer has Paused. Retry sending data?")){ errorCount = 150; // Wait for 5 min thereafter continue; } > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } yves pielusenet wrote: > Maybe in my case I should re-compile rxtx and change the code. Instead > of send an exception I should display a dialog box to ask if it's > printer problem or if it should trie to send bytes. Something like : > > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > > if(displayDialogBox("Try again to send datas ??")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > } > From yvespielusenet at free.fr Thu Jun 7 07:17:21 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Thu, 07 Jun 2007 15:17:21 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4667F5FF.8070903@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <4667F5FF.8070903@gatworks.com> Message-ID: <1181222241.3501.20.camel@localhost.localdomain> thank you :) 'displayDialogBox()' I think doesn't exist. It was just for the example :) But I think It should not be so complicated to display a dialog box under windows with YES/NO buttons. When yes is clicked it return 0 other it returns 1. Le jeudi 07 juin 2007 ? 08:11 -0400, Uncle George a ?crit : > your suggestion appears good. I dont know what displayDialogBox exactly > will do, so all I can say it that it looks good. > > But I'd like to wait 10min before first dialog box And a 5 min wait for > every dialog box there after. And since these are custom > solution/choices, maybe a more exact explanation of what the issue is. > > if(errorCount++ < 300){ // wait 10min ( 10min * 60sec / 2 ) > Sleep( 20 ); /* make a small pause to execute all other requests > in all other threads */ > continue; > } > > if(displayDialogBox("Printer has Paused. Retry sending data?")){ > errorCount = 150; // Wait for 5 min thereafter > continue; > } > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > > yves pielusenet wrote: > > Maybe in my case I should re-compile rxtx and change the code. Instead > > of send an exception I should display a dialog box to ask if it's > > printer problem or if it should trie to send bytes. Something like : > > > > while( count > 0 ){ > > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > > /* > > this are 20 * 2 seconds, in this time a printer (or other parallel device) > > should solv all problems like buffer full, etc > > */ > > if(errorCount++ < 20){ > > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > > continue; > > } > > > > if(displayDialogBox("Try again to send datas ??")){ > > errorCount = 0; > > } > > else{ > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > } > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 07:41:43 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 09:41:43 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181222241.3501.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <4667F5FF.8070903@gatworks.com> <1181222241.3501.20.camel@localhost.localdomain> Message-ID: <46680B17.8050109@gatworks.com> yves pielusenet wrote: > thank you :) > 'displayDialogBox()' I think doesn't exist. It was just for the > example :) too bad. Good luck. From rtrout at webbresearch.com Thu Jun 7 11:23:04 2007 From: rtrout at webbresearch.com (Robert Trout) Date: Thu, 07 Jun 2007 13:23:04 -0400 Subject: [Rxtx] Disconnected PortServer TS causes Java to hang Message-ID: <1181236984.14186.33.camel@sisyphus.DinkumSoftware.com> I'm running Linux with sun's Java 1.4.2, Java comm API 2.0, RXTX 2.0-7pre1, and the RealPort digi driver. "/dev/ttyrp00" is a RealPort device. My Java application never returns from a ComPortIdentifier.getPortIdentifier("/dev/ttyrp00") call while the Digi PortServer TS 4 is disconnected from the network. If I later re-connect the PortServer, the call returns about 30 seconds later (it's like a serial port read or write is blocking until the PortServer is re- connected). With the PortServer disconnected, minicom immediately responds with "cannot open /dev/ttyrp00: No such file or directory". I would like my Java application to behave similarly. That is, respond with an error condition instead of hanging when the PortServer is not connected. Since minicom and Java behave differently, I think this "hanging" behavior may be due to RXTX or Java? Has anyone had a similar issue? Solutions? Suggestions? Thanks, Robert From vicnevicne at gmail.com Thu Jun 7 12:16:02 2007 From: vicnevicne at gmail.com (Vicne) Date: Thu, 07 Jun 2007 20:16:02 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181204864.3501.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> Message-ID: <46684B62.7080802@gmail.com> yves pielusenet wrote: > Maybe in my case I should re-compile rxtx and change the code. Instead > of send an exception I should display a dialog box to ask if it's > printer problem or if it should trie to send bytes. Something like : > > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > > if(displayDialogBox("Try again to send datas ??")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > } > Sorry to step in without a specific solution to your problem, but I wanted to share my feeling regarding this proposal. AFAIK, it's generally considered bad practice to pop-up a prompt from a library. The main reason is that in general use, you can't guarantee that someone is actually present behind the console. Imagine a print server in a machine room, connected to a park of printers. In that case, when one printer fails, the logical behaviour would be to use an other one. If you change RxTx the way you propose, the printer queue will simply be stuck with a useless "Try again to send data ?" prompt until an administrator opens a remote connection to the print server's console and clicks "no". Second, it would create a dependency upon the existence of a graphical console (if you go the graphical "dialogBox" way). On many applications (typically server or embedded ones), the JVM is "headless" and if you try to pop-up a dialog, your app would throw an exception (at best) or just wouldn't display the prompt anywhere... Going the "text console" way is not more reliable, because on graphical environments, the text console is hidden unless explicitly requested. My advice would be to think again and find another solution. Ideas are : - make the number of retries a parameter so that you can tune it to what you think is reasonable - throw a more specific exception when the number of retries has been reached, so that a specific prompt can be shown at a higher level Anyway, if you feel that the prompt is the way to go in your case, I would at least make that prompt conditional. The least intrusive way would probably be using a system property, like if("true".equals(System.getProperty("org.rxtx.usePrompt")) && displayDialogBox("Retry sending data ?")){ errorCount = 0; } else{ throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } By default, the behaviour would remain as it is now, but you could force the prompts by defining the property at VM launch if desired. (for example : java.exe -Dorg.rxtx.usePrompt=true myApp) Also, you seemed to say you wanted the printer to start again exactly where is stopped. It would indeed be the best way when the printer is put offline for a few seconds. On the other hand, if the printer is turned off (or the printer runs out of paper, or someone steps on the mains cable), then the only way to go back to a "stable" situation would be by printing the item (page, label, etc.) again from scratch... Just my two cents. Vicne PS : By the way, the dialog box thing is very platform dependant on the C-side, and I think the simplest way would probably be to bridge it to a Java call where you can implement it like you proposed : public boolean displayDialogBox(prompt) { return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); } From netbeans at gatworks.com Thu Jun 7 14:08:24 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 16:08:24 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46684B62.7080802@gmail.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> Message-ID: <466865B8.4060004@gatworks.com> My feeling is that the code that was suggested was for his environs ( his shop ). The issue here is that after a 40+ second wait, an exception will be thrown. But you really dont have a way of 'cancelling' all the WriteFiles() that have already occured before the exception so that your writeArray and the Commapi can backtrack to a position in which they are in sync. The main ( really mine ) concern is not to lose data, or replicate data. After 40seconds, 300 seconds, 55min, no matter how long, data should not be lost or duplicated. But as soon as the exception is thrown, that possibility exists. Maybe an event should be thrown instead? Vicne wrote: > yves pielusenet wrote: >> Maybe in my case I should re-compile rxtx and change the code. Instead >> of send an exception I should display a dialog box to ask if it's >> printer problem or if it should trie to send bytes. Something like : >> >> while( count > 0 ){ >> if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ >> /* >> this are 20 * 2 seconds, in this time a printer (or other parallel device) >> should solv all problems like buffer full, etc >> */ >> if(errorCount++ < 20){ >> Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ >> continue; >> } >> >> if(displayDialogBox("Try again to send datas ??")){ >> errorCount = 0; >> } >> else{ >> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >> break; >> } >> } >> > > Sorry to step in without a specific solution to your problem, but I > wanted to share my feeling regarding this proposal. AFAIK, it's > generally considered bad practice to pop-up a prompt from a library. > The main reason is that in general use, you can't guarantee that > someone is actually present behind the console. Imagine a print server > in a machine room, connected to a park of printers. In that case, when > one printer fails, the logical behaviour would be to use an other one. > If you change RxTx the way you propose, the printer queue will simply be > stuck with a useless "Try again to send data ?" prompt until an > administrator opens a remote connection to the print server's console > and clicks "no". > Second, it would create a dependency upon the existence of a > graphical console (if you go the graphical "dialogBox" way). On many > applications (typically server or embedded ones), the JVM is "headless" > and if you try to pop-up a dialog, your app would throw an exception (at > best) or just wouldn't display the prompt anywhere... Going the "text > console" way is not more reliable, because on graphical environments, > the text console is hidden unless explicitly requested. > > My advice would be to think again and find another solution. Ideas are : > - make the number of retries a parameter so that you can tune it to what > you think is reasonable > - throw a more specific exception when the number of retries has been > reached, so that a specific prompt can be shown at a higher level > > Anyway, if you feel that the prompt is the way to go in your case, I > would at least make that prompt conditional. The least intrusive way > would probably be using a system property, like > > if("true".equals(System.getProperty("org.rxtx.usePrompt")) > && displayDialogBox("Retry sending data ?")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > > > By default, the behaviour would remain as it is now, but you could > force the prompts by defining the property at VM launch if desired. (for > example : java.exe -Dorg.rxtx.usePrompt=true myApp) > > > Also, you seemed to say you wanted the printer to start again > exactly where is stopped. It would indeed be the best way when the > printer is put offline for a few seconds. On the other hand, if the > printer is turned off (or the printer runs out of paper, or someone > steps on the mains cable), then the only way to go back to a "stable" > situation would be by printing the item (page, label, etc.) again from > scratch... > > > Just my two cents. > > > Vicne > > PS : By the way, the dialog box thing is very platform dependant on the > C-side, and I think the simplest way would probably be to bridge it to a > Java call where you can implement it like you proposed : > > public boolean displayDialogBox(prompt) { > return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", > JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); > } > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Thu Jun 7 17:48:11 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 Jun 2007 17:48:11 -0600 (MDT) Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <466865B8.4060004@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> Message-ID: An event is possible. I'm amazed this is the largest problem encountered while using the parallel code. How would the write ever exit if we throw events? Isn't this going to lead to hung applications? On Thu, 7 Jun 2007, Uncle George wrote: > My feeling is that the code that was suggested was for his environs ( > his shop ). > > The issue here is that after a 40+ second wait, an exception will be > thrown. But you really dont have a way of 'cancelling' all the > WriteFiles() that have already occured before the exception so that your > writeArray and the Commapi can backtrack to a position in which they are > in sync. > > The main ( really mine ) concern is not to lose data, or replicate data. > After 40seconds, 300 seconds, 55min, no matter how long, data should > not be lost or duplicated. But as soon as the exception is thrown, that > possibility exists. > > Maybe an event should be thrown instead? > > Vicne wrote: >> yves pielusenet wrote: >>> Maybe in my case I should re-compile rxtx and change the code. Instead >>> of send an exception I should display a dialog box to ask if it's >>> printer problem or if it should trie to send bytes. Something like : >>> >>> while( count > 0 ){ >>> if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ >>> /* >>> this are 20 * 2 seconds, in this time a printer (or other parallel device) >>> should solv all problems like buffer full, etc >>> */ >>> if(errorCount++ < 20){ >>> Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ >>> continue; >>> } >>> >>> if(displayDialogBox("Try again to send datas ??")){ >>> errorCount = 0; >>> } >>> else{ >>> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >>> break; >>> } >>> } >>> >> >> Sorry to step in without a specific solution to your problem, but I >> wanted to share my feeling regarding this proposal. AFAIK, it's >> generally considered bad practice to pop-up a prompt from a library. >> The main reason is that in general use, you can't guarantee that >> someone is actually present behind the console. Imagine a print server >> in a machine room, connected to a park of printers. In that case, when >> one printer fails, the logical behaviour would be to use an other one. >> If you change RxTx the way you propose, the printer queue will simply be >> stuck with a useless "Try again to send data ?" prompt until an >> administrator opens a remote connection to the print server's console >> and clicks "no". >> Second, it would create a dependency upon the existence of a >> graphical console (if you go the graphical "dialogBox" way). On many >> applications (typically server or embedded ones), the JVM is "headless" >> and if you try to pop-up a dialog, your app would throw an exception (at >> best) or just wouldn't display the prompt anywhere... Going the "text >> console" way is not more reliable, because on graphical environments, >> the text console is hidden unless explicitly requested. >> >> My advice would be to think again and find another solution. Ideas are : >> - make the number of retries a parameter so that you can tune it to what >> you think is reasonable >> - throw a more specific exception when the number of retries has been >> reached, so that a specific prompt can be shown at a higher level >> >> Anyway, if you feel that the prompt is the way to go in your case, I >> would at least make that prompt conditional. The least intrusive way >> would probably be using a system property, like >> >> if("true".equals(System.getProperty("org.rxtx.usePrompt")) >> && displayDialogBox("Retry sending data ?")){ >> errorCount = 0; >> } >> else{ >> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >> break; >> } >> >> >> By default, the behaviour would remain as it is now, but you could >> force the prompts by defining the property at VM launch if desired. (for >> example : java.exe -Dorg.rxtx.usePrompt=true myApp) >> >> >> Also, you seemed to say you wanted the printer to start again >> exactly where is stopped. It would indeed be the best way when the >> printer is put offline for a few seconds. On the other hand, if the >> printer is turned off (or the printer runs out of paper, or someone >> steps on the mains cable), then the only way to go back to a "stable" >> situation would be by printing the item (page, label, etc.) again from >> scratch... >> >> >> Just my two cents. >> >> >> Vicne >> >> PS : By the way, the dialog box thing is very platform dependant on the >> C-side, and I think the simplest way would probably be to bridge it to a >> Java call where you can implement it like you proposed : >> >> public boolean displayDialogBox(prompt) { >> return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", >> JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); >> } >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 19:18:51 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 21:18:51 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> Message-ID: <4668AE7B.3060409@gatworks.com> The UNIX version of writeArray is not too great either. It is possible that the write will only process some of the bytes. #else if( write( fd, bytes, count ) < 0 ) throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); #endif -------------------------------- Maybe it might be better to have the native function inform the caller of the # of characters written, then the commapi/output-buffer can be modified to reflect the #of chars written. If an exception is to be thrown, for too many loops of chars written == 0, then exception wont affect the state of the output buffer. Then a ParallelPort.restart() can be called to resume printing whats in the buffer. Trent Jarvi wrote: > An event is possible. I'm amazed this is the largest problem encountered > while using the parallel code. > > How would the write ever exit if we throw events? Isn't this going to > lead to hung applications? Sure. If you dont time out, then there is nothing that will force an EXIT from the write(). Issue is what has the OS done with the write. > > On Thu, 7 Jun 2007, Uncle George wrote: > >> My feeling is that the code that was suggested was for his environs ( >> his shop ). From yvespielusenet at free.fr Fri Jun 8 01:09:01 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Fri, 08 Jun 2007 09:09:01 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4668AE7B.3060409@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> Message-ID: <1181286541.3674.10.camel@localhost.localdomain> It is not possible that the rxtx java method write(byte[], int offset, int length) return anint which contains the number of byte really send to the printer instead of an exception ? So this is the programm which will see if all bytes have been sent. If not it can retry to send the unsended bytes. -------------------------------------------------------- int sended = 0; while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ sended += countWritten; /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } return sended; /*throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break;*/ } ... ... return countWritten; ------------------------------------------------ Le jeudi 07 juin 2007 ? 21:18 -0400, Uncle George a ?crit : > The UNIX version of writeArray is not too great either. It is possible > that the write will only process some of the bytes. > > #else > if( write( fd, bytes, count ) < 0 ) > throw_java_exception_system_msg( env, IO_EXCEPTION, > "writeArray" ); > #endif > -------------------------------- > > Maybe it might be better to have the native function inform the caller > of the # of characters written, then the commapi/output-buffer can be > modified to reflect the #of chars written. If an exception is to be > thrown, for too many loops of chars written == 0, then exception wont > affect the state of the output buffer. Then a ParallelPort.restart() can > be called to resume printing whats in the buffer. > > > Trent Jarvi wrote: > > An event is possible. I'm amazed this is the largest problem encountered > > while using the parallel code. > > > > How would the write ever exit if we throw events? Isn't this going to > > lead to hung applications? > Sure. If you dont time out, then there is nothing that will force an > EXIT from the write(). Issue is what has the OS done with the write. > > > > On Thu, 7 Jun 2007, Uncle George wrote: > > > >> My feeling is that the code that was suggested was for his environs ( > >> his shop ). > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Fri Jun 8 03:45:00 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 11:45:00 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181286541.3674.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> Message-ID: <20070608094500.GC21069@elberon.bln.de.ingenico.com> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > It is not possible that the rxtx java method write(byte[], int offset, > int length) return anint which contains the number of byte really send > to the printer instead of an exception ? > So this is the programm which will see if all bytes have been sent. If > not it can retry to send the unsended bytes. I think write() is void because in Java people love to do this since OutputStream :-) Of course on such interfaces you cannot implement something nice. If you would have a int write, you would not implement the interface and no applications expecting this interface would link/work/compile. oki, Steffen P.S.: (OT) If you propose not to implement the Java interfaces (especially not on JNI level), maybe optionally offering a wrapper that removes e.g. the write return value and so on to downgrade the powerful classic old POSIX read/write style to the modern limited Java style, then I agree :-) Same for read. Instead of things like "int avialable()" it is more powerful to have an approach as select(2) offers (to guarante the caller that read/write will not block [nothing else make sense anyway IMHO] but may read/write less bytes then requested). The caller gets full control and the higher level protocols can care about timeouts, invoking read in some loops and/or implement retransmission. On top of such an implementation, where everything is controlled, defined, guaranteed and reliable, someone could use an InputStream or OutputStream style interface. Or even better: don't use them at all :) just BTW :-) St. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From yvespielusenet at free.fr Fri Jun 8 05:52:45 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Fri, 08 Jun 2007 13:52:45 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <20070608094500.GC21069@elberon.bln.de.ingenico.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> Message-ID: <1181303565.11203.3.camel@localhost.localdomain> So maybe a better way should be to create a new Exception class which has a method "int getWrittenByte()". So the Exception should be use to send again bytes which are not printed yet. yves Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : > * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > > It is not possible that the rxtx java method write(byte[], int offset, > > int length) return anint which contains the number of byte really send > > to the printer instead of an exception ? > > So this is the programm which will see if all bytes have been sent. If > > not it can retry to send the unsended bytes. > > I think write() is void because in Java people love to do this > since OutputStream :-) Of course on such interfaces you cannot > implement something nice. If you would have a int write, you > would not implement the interface and no applications expecting > this interface would link/work/compile. > > oki, > > Steffen > > P.S.: (OT) > If you propose not to implement the Java interfaces (especially > not on JNI level), maybe optionally offering a wrapper that > removes e.g. the write return value and so on to downgrade the > powerful classic old POSIX read/write style to the modern limited > Java style, then I agree :-) Same for read. Instead of things > like "int avialable()" it is more powerful to have an approach as > select(2) offers (to guarante the caller that read/write will not > block [nothing else make sense anyway IMHO] but may read/write > less bytes then requested). The caller gets full control and the > higher level protocols can care about timeouts, invoking read in > some loops and/or implement retransmission. On top of such an > implementation, where everything is controlled, defined, > guaranteed and reliable, someone could use an InputStream or > OutputStream style interface. Or even better: don't use them at > all :) just BTW :-) > St. > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > 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. > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > 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. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Fri Jun 8 06:46:21 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 08:46:21 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181303565.11203.3.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> Message-ID: <46694F9D.5080501@gatworks.com> It seems that with outputstream.write(b[]), you become terribly uncoordinated as soon as an exception is thrown. Docs do not say what happens to the data. Yet from a practicable point of view, one would like to know if the write was accepted in-full, or rejected before any writes. There are no in betweens, as partial writes are not reportable. So for an outputstream.write(), in order for it to return, the full write request has to be taken, and stored in an internal output buffer. If there is no room, the write() is suspended, till there is room. Or throw's an IOException( "no room in buffer") ; As the select() loop for write reports buffer room avail, then more of the internal buffer is sent to the printer. yves pielusenet wrote: > So maybe a better way should be to create a new Exception class which > has a method "int getWrittenByte()". So the Exception should be use to > send again bytes which are not printed yet. > > yves > > Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : >> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: >>> It is not possible that the rxtx java method write(byte[], int offset, >>> int length) return anint which contains the number of byte really send >>> to the printer instead of an exception ? >>> So this is the programm which will see if all bytes have been sent. If >>> not it can retry to send the unsended bytes. >> I think write() is void because in Java people love to do this >> since OutputStream :-) Of course on such interfaces you cannot >> implement something nice. If you would have a int write, you >> would not implement the interface and no applications expecting >> this interface would link/work/compile. >> >> oki, >> >> Steffen >> >> P.S.: (OT) >> If you propose not to implement the Java interfaces (especially >> not on JNI level), maybe optionally offering a wrapper that >> removes e.g. the write return value and so on to downgrade the >> powerful classic old POSIX read/write style to the modern limited >> Java style, then I agree :-) Same for read. Instead of things >> like "int avialable()" it is more powerful to have an approach as >> select(2) offers (to guarante the caller that read/write will not >> block [nothing else make sense anyway IMHO] but may read/write >> less bytes then requested). The caller gets full control and the >> higher level protocols can care about timeouts, invoking read in >> some loops and/or implement retransmission. On top of such an >> implementation, where everything is controlled, defined, >> guaranteed and reliable, someone could use an InputStream or >> OutputStream style interface. Or even better: don't use them at >> all :) just BTW :-) >> St. >> >> About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. >> 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. >> >> About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. >> 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. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From Steffen.DETTMER at ingenico.com Fri Jun 8 08:12:18 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 16:12:18 +0200 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <46694F9D.5080501@gatworks.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: <20070608141218.GE21069@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 08:46 -0400: > It seems that with outputstream.write(b[]), you become terribly > uncoordinated as soon as an exception is thrown. Docs do not say what > happens to the data. (yes, so avoiding it seems to be good :)) > Yet from a practicable point of view, one would like to know if the > write was accepted in-full, or rejected before any writes. There are no > in betweens, as partial writes are not reportable. (which is an artificial API limitation. I never understood how this happend when they invented JDK because the well-known BSD socket API and thus [probably] WinSock does this correct, but anyway) > So for an outputstream.write(), in order for it to return, the full > write request has to be taken, and stored in an internal output buffer. > If there is no room, the write() is suspended, till there is room. Or > throw's an IOException( "no room in buffer") ; As the select() loop for > write reports buffer room avail, then more of the internal buffer is > sent to the printer. yes, might be good in case of a printer. May be horrible in case of PPP/TCP or some other transmission control protocol which may e.g. repeat data or even omit parts of it (e.g. internet realtime radio station broadcasting)... So I think the idea of "int write" (e.g. BSD sockets, linux files and so on) still is the best. A clean API / implementation should guarantee and allow implementations (users) to rely on that; assumptions and automatic background-sending and so on may look pragmatic and may even work on the first look, but may fail in other situations. BTW, if e.g. BSD socket API is known, why not simply copy it (until something better is invented :)) instead of fiddling around with JDK APIs? anyway, have a nice weekend everyone :-) oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Fri Jun 8 08:55:56 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 10:55:56 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070608141218.GE21069@elberon.bln.de.ingenico.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> Message-ID: <46696DFC.7000801@gatworks.com> >> write reports buffer room avail, then more of the internal buffer is >> sent to the printer. > > yes, might be good in case of a printer. May be horrible in case > of PPP/TCP or some other transmission control protocol which > may e.g. repeat data or even omit parts of it (e.g. internet > realtime radio station broadcasting)... So I think the idea of > "int write" (e.g. BSD sockets, linux files and so on) still is > the best. A clean API / implementation should guarantee and allow > implementations (users) to rely on that; assumptions and > automatic background-sending and so on may look pragmatic and may > even work on the first look, but may fail in other situations. > BTW, if e.g. BSD socket API is known, why not simply copy it > (until something better is invented :)) instead of fiddling > around with JDK APIs? But we were talking about the Parallel Port, and the transmission of data over the commapi/parallel-port schema. There isn't much in bi-directional software communication. Its a simple write one byte at a time interface. I'm not looking to change the comm-api. I'm just looking to alter the interaction between the Native ParallelPort functions, and the java ParallelPort functions that call them. This might be more readily doable than to get a committee to re-specify java-API specs. BTW: Whats is off-topic? ( help: not looking for def of off-topic ) From j.kenneth.gentle at acm.org Fri Jun 8 08:58:59 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Fri, 08 Jun 2007 10:58:59 -0400 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <20070608141218.GE21069@elberon.bln.de.ingenico.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> Message-ID: <200706081459.l58Ex5rA019991@qbang.org> Perhaps it is a bit late to jump in on this one, but here goes anyway. If the solutions all seem to "break" the contract with "java.io.outputstream", then, as noted, that may not be the appropriate contract. At the risk of being heretical, JDK1.4 introduced the "nio" package to address some of the compatibility issues with C apis mentioned in previous posts. The interface "java.nio.channels.WriteableByteChannel" defines the following single method: int write(ByteBuffer source); int, strangely enough, is the actual number of bytes written. So, if RXTX as written, against the JavaCOMM api and OutputStream, doesn't do what we want, how about writing a different set of bindings using the java.nio classes and as much of the underlying native code as possible. Note that just because the java.nio.channels.WriteableByteChannel sends back a result, OutputStream.write doesn't have to - and they could both call the same underlying native code. My 2 cents - maybe not worth even that... Ken From netbeans at gatworks.com Fri Jun 8 10:37:28 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 12:37:28 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <200706081459.l58Ex5rA019991@qbang.org> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> Message-ID: <466985C8.8000505@gatworks.com> Ken Gentle wrote: > Perhaps it is a bit late to jump in on this one, but here goes anyway. Common in, the waters fine. > > If the solutions all seem to "break" the contract with > "java.io.outputstream", then, as noted, that may not be the > appropriate contract. > How would the contract be broken? The machinery underneath is handling the contract. From j.kenneth.gentle at acm.org Fri Jun 8 10:48:01 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Fri, 08 Jun 2007 12:48:01 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466985C8.8000505@gatworks.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> Message-ID: <200706081648.l58Gm7YA022904@qbang.org> At 12:37 2007-06-08, you wrote: >Ken Gentle wrote: > > > > If the solutions all seem to "break" the contract with > > "java.io.outputstream", then, as noted, that may not be the > > appropriate contract. > > >How would the contract be broken? The machinery underneath is handling >the contract. It seems that a lot of the discussion has been about not only the timeout and being able to adjust it in the "machinery layer", but also about knowing in the Java layer, in the event of a timeout or exception, how many characters have been written to the device. An OutputStream won't ever do this with out an extension and including a return value "breaks" the contract, right? So, go with a Java IO api that *does* return the number of bytes written, out of the NIO package. I know it doesn't allow for a strict implementation of the JavaCOMM API - however, using NIO classes in place of the IO classes isn't that big a break and would allow those applications that need such information a way to get it. Maybe I'm misunderstanding the problem... Ken From netbeans at gatworks.com Fri Jun 8 11:24:14 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 13:24:14 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <200706081648.l58Gm7YA022904@qbang.org> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> Message-ID: <466990BE.7040100@gatworks.com> Ken Gentle wrote: An > OutputStream won't ever do this with out an extension and including a > return value "breaks" the contract, right? > i was not thinking of change the API to OutputSream. Are there specs for how output stream should work internally? for instance: String data = "Hello this is a line of data"; Outputstream.write( data.getbytes() ); ParallelPort.suspend(); int free = ParallelPort.getoutputbufferfree(); There is a symbiotic relationship between outputstream and the functionality of ParallelPort. From Steffen.DETTMER at ingenico.com Fri Jun 8 11:15:39 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 19:15:39 +0200 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <200706081459.l58Ex5rA019991@qbang.org> References: <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> Message-ID: <20070608171539.GK21069@elberon.bln.de.ingenico.com> * Ken Gentle wrote on Fri, Jun 08, 2007 at 10:58 -0400: > If the solutions all seem to "break" the contract with > "java.io.outputstream", then, as noted, that may not be the > appropriate contract. > > At the risk of being heretical, JDK1.4 introduced the "nio" package > to address some of the compatibility issues with C apis mentioned in > previous posts. The interface > "java.nio.channels.WriteableByteChannel" defines the following single method: > > int write(ByteBuffer source); > > int, strangely enough, is the actual number of bytes written. Yes, AFAIK one of the motivations for the NIO interface was, that the JDK-1.3 APIs (InputStream, e.g.) were not powerfull enough, especially for multi-connection-TCP servers or so. I don't know much about it but I've heard of a project where NIO usage was removed because of stability issues in multi-threaded environments and performance limitations under some circumstances. IIRC the "nio.ByteBuffer" is something very special (namely something you cannot implement in Java, it is "magic" or part of the language itself). Not sure if this is such a great idea (but for performance in the end sometimes heavy prices must be paid) :) > So, if RXTX as written, against the JavaCOMM api and OutputStream, > doesn't do what we want, how about writing a different set of > bindings using the java.nio classes and as much of the underlying > native code as possible. Yes, this would be an idea: use a full-featured interface on JNI, and, if wanted, deliver some wrappers converting this to a less-featured Java-compliant interface. However, powerful things as e.g. "select" are difficult to "emulate" if you are e.g. on some (older?) windows. But if you expose the full-featured APIs, you need to emulate them full-featured, theoretically. In the end it depends what you do on the serial line. If you just want to talk to a modem, then you may not need precise timeouts. But if you need to implement complexer protocols which define response times and timeouts, you may quickly get into difficulties. For instance, AFAIK, rxtx 1.7.2 (?) for windows is very messy with timeouts (there is a maximum, higher values are truncated; resolution is 100ms only; the function may take up to twice the timeout because internally it may be called twice). Probably for most people this is OK, but probably not for all. But having precise timeouts should be OK for all :-) Well, in the end it is nice to wish but somewhat hard to implement (many platforms, connections, USB, BlueTooth, whatever). oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Steffen.DETTMER at ingenico.com Fri Jun 8 11:04:22 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 19:04:22 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <46696DFC.7000801@gatworks.com> References: <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <46696DFC.7000801@gatworks.com> Message-ID: <20070608170422.GJ21069@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 10:55 -0400: > > BTW, if e.g. BSD socket API is known, why not simply copy it > > (until something better is invented :)) instead of fiddling > > around with JDK APIs? > > But we were talking about the Parallel Port, and the > transmission of data over the commapi/parallel-port schema. > There isn't much in bi-directional software communication. Its > a simple write one byte at a time interface. First, there are things like PLIP (http://en.wikipedia.org/wiki/Plip) - well, probably not widely used, sure ;) Second, I think if there is a good simple API known to support all that (with known "best practices") or so and there is no forcing need to invent a new one, why not simply using it? > I'm not looking to change the comm-api. I'm just looking to > alter the interaction between the Native ParallelPort > functions, and the java ParallelPort functions that call them. Ahh, yes. I think this is what I tried to ask. Having an usable JNI interface and on top (in pure java) some wrapper to InputStream or whatever could be done (e.g. by ignoring the return value of write or throwing if != length). Developers could then use the full-featured (non-JAVA-standard) API or select among various wrappers (as InputStream). > This might be more readily doable than to get a committee to > re-specify java-API specs. Yes, of course. I'm afraid that the Java APIs change regularily, but still yet with limited success it seems, so maybe they get it in one of the next iterations; who knows, maybe Java-9 has a BSD-like socket API :) SCNR. > BTW: Whats is off-topic? ( help: not looking for def of > off-topic ) I think I started some "re-specify java-API specs" which was OT probably. oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From lists at iDIAcomputing.com Fri Jun 8 18:48:54 2007 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Fri, 08 Jun 2007 20:48:54 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46684B62.7080802@gmail.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> Message-ID: <4669F8F6.3040101@iDIAcomputing.com> Vicne wrote: > Sorry to step in without a specific solution to your problem, but I > wanted to share my feeling regarding this proposal. AFAIK, it's > generally considered bad practice to pop-up a prompt from a library. ... > > My advice would be to think again and find another solution. Ideas are : > - make the number of retries a parameter so that you can tune it to what > you think is reasonable > - throw a more specific exception when the number of retries has been > reached, so that a specific prompt can be shown at a higher level You could also allow the client code to register a callback class which returns a boolean indicating whether to retry or cancel. This callback class could pop up a dialog, if appropriate, or follow some preset policy, or.... - George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From joachim at buechse.ch Sat Jun 9 09:43:16 2007 From: joachim at buechse.ch (Joachim Buechse) Date: Sat, 9 Jun 2007 17:43:16 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46694F9D.5080501@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: You should not forget, that in the case of an exception it may not even be known what happened to the data. You have a kernel buffer, outgoing chip buffer, incoming chip buffer, etc. So of course, it would be nice to know up to which point data was correctly processed, but this feedback does not exist on the hardware or protocol level and hence can in general not be magicly created on the software level... Regards, Joachim On 08.06.2007, at 14:46, Uncle George wrote: > It seems that with outputstream.write(b[]), you become terribly > uncoordinated as soon as an exception is thrown. Docs do not say what > happens to the data. > > Yet from a practicable point of view, one would like to know if the > write was accepted in-full, or rejected before any writes. There > are no > in betweens, as partial writes are not reportable. > > So for an outputstream.write(), in order for it to return, the full > write request has to be taken, and stored in an internal output > buffer. > If there is no room, the write() is suspended, till there is room. Or > throw's an IOException( "no room in buffer") ; As the select() loop > for > write reports buffer room avail, then more of the internal buffer is > sent to the printer. > > > > yves pielusenet wrote: >> So maybe a better way should be to create a new Exception class which >> has a method "int getWrittenByte()". So the Exception should be >> use to >> send again bytes which are not printed yet. >> >> yves >> >> Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : >>> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: >>>> It is not possible that the rxtx java method write(byte[], int >>>> offset, >>>> int length) return anint which contains the number of byte >>>> really send >>>> to the printer instead of an exception ? >>>> So this is the programm which will see if all bytes have been >>>> sent. If >>>> not it can retry to send the unsended bytes. >>> I think write() is void because in Java people love to do this >>> since OutputStream :-) Of course on such interfaces you cannot >>> implement something nice. If you would have a int write, you >>> would not implement the interface and no applications expecting >>> this interface would link/work/compile. >>> >>> oki, >>> >>> Steffen >>> >>> P.S.: (OT) >>> If you propose not to implement the Java interfaces (especially >>> not on JNI level), maybe optionally offering a wrapper that >>> removes e.g. the write return value and so on to downgrade the >>> powerful classic old POSIX read/write style to the modern limited >>> Java style, then I agree :-) Same for read. Instead of things >>> like "int avialable()" it is more powerful to have an approach as >>> select(2) offers (to guarante the caller that read/write will not >>> block [nothing else make sense anyway IMHO] but may read/write >>> less bytes then requested). The caller gets full control and the >>> higher level protocols can care about timeouts, invoking read in >>> some loops and/or implement retransmission. On top of such an >>> implementation, where everything is controlled, defined, >>> guaranteed and reliable, someone could use an InputStream or >>> OutputStream style interface. Or even better: don't use them at >>> all :) just BTW :-) >>> St. >>> >>> About Ingenico Throughout the world businesses rely on Ingenico >>> for secure and expedient electronic transaction acceptance. >>> Ingenico products leverage proven technology, established >>> standards and unparalleled ergonomics to provide optimal >>> reliability, versatility and usability. This comprehensive range >>> of products is complemented by a global array of services and >>> partnerships, enabling businesses in a number of vertical sectors >>> to accept transactions anywhere their business takes them. >>> 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. >>> >>> About Ingenico Throughout the world businesses rely on Ingenico >>> for secure and expedient electronic transaction acceptance. >>> Ingenico products leverage proven technology, established >>> standards and unparalleled ergonomics to provide optimal >>> reliability, versatility and usability. This comprehensive range >>> of products is complemented by a global array of services and >>> partnerships, enabling businesses in a number of vertical sectors >>> to accept transactions anywhere their business takes them. >>> 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. >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx 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 yvespielusenet at free.fr Mon Jun 11 03:15:12 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Mon, 11 Jun 2007 11:15:12 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: <1181553312.8335.14.camel@localhost.localdomain> So can someone tell a solution for my problem :( Must I say to the user to not put the printer off-line ? I can't since he has to do some pauses, verify print, paper conditioning etc... How do other people ? Before I use the parport librarry to read port status : http://www.geocities.com/Juanga69/parport/ (which doesn't work on windows XP) And I send data into the file LPT1 I use to have no problem when printer was disabled. thanks -- yves piel Le samedi 09 juin 2007 ? 17:43 +0200, Joachim Buechse a ?crit : > You should not forget, that in the case of an exception it may not > even be known what happened to the data. > > You have a kernel buffer, outgoing chip buffer, incoming chip buffer, > etc. So of course, it would be nice to know up to which point data > was correctly processed, but this feedback does not exist on the > hardware or protocol level and hence can in general not be magicly > created on the software level... > > Regards, > Joachim > > On 08.06.2007, at 14:46, Uncle George wrote: > > > It seems that with outputstream.write(b[]), you become terribly > > uncoordinated as soon as an exception is thrown. Docs do not say what > > happens to the data. > > > > Yet from a practicable point of view, one would like to know if the > > write was accepted in-full, or rejected before any writes. There > > are no > > in betweens, as partial writes are not reportable. > > > > So for an outputstream.write(), in order for it to return, the full > > write request has to be taken, and stored in an internal output > > buffer. > > If there is no room, the write() is suspended, till there is room. Or > > throw's an IOException( "no room in buffer") ; As the select() loop > > for > > write reports buffer room avail, then more of the internal buffer is > > sent to the printer. > > > > > > > > yves pielusenet wrote: > >> So maybe a better way should be to create a new Exception class which > >> has a method "int getWrittenByte()". So the Exception should be > >> use to > >> send again bytes which are not printed yet. > >> > >> yves > >> > >> Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : > >>> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > >>>> It is not possible that the rxtx java method write(byte[], int > >>>> offset, > >>>> int length) return anint which contains the number of byte > >>>> really send > >>>> to the printer instead of an exception ? > >>>> So this is the programm which will see if all bytes have been > >>>> sent. If > >>>> not it can retry to send the unsended bytes. > >>> I think write() is void because in Java people love to do this > >>> since OutputStream :-) Of course on such interfaces you cannot > >>> implement something nice. If you would have a int write, you > >>> would not implement the interface and no applications expecting > >>> this interface would link/work/compile. > >>> > >>> oki, > >>> > >>> Steffen > >>> > >>> P.S.: (OT) > >>> If you propose not to implement the Java interfaces (especially > >>> not on JNI level), maybe optionally offering a wrapper that > >>> removes e.g. the write return value and so on to downgrade the > >>> powerful classic old POSIX read/write style to the modern limited > >>> Java style, then I agree :-) Same for read. Instead of things > >>> like "int avialable()" it is more powerful to have an approach as > >>> select(2) offers (to guarante the caller that read/write will not > >>> block [nothing else make sense anyway IMHO] but may read/write > >>> less bytes then requested). The caller gets full control and the > >>> higher level protocols can care about timeouts, invoking read in > >>> some loops and/or implement retransmission. On top of such an > >>> implementation, where everything is controlled, defined, > >>> guaranteed and reliable, someone could use an InputStream or > >>> OutputStream style interface. Or even better: don't use them at > >>> all :) just BTW :-) > >>> St. > >>> > >>> About Ingenico Throughout the world businesses rely on Ingenico > >>> for secure and expedient electronic transaction acceptance. > >>> Ingenico products leverage proven technology, established > >>> standards and unparalleled ergonomics to provide optimal > >>> reliability, versatility and usability. This comprehensive range > >>> of products is complemented by a global array of services and > >>> partnerships, enabling businesses in a number of vertical sectors > >>> to accept transactions anywhere their business takes them. > >>> 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. > >>> > >>> About Ingenico Throughout the world businesses rely on Ingenico > >>> for secure and expedient electronic transaction acceptance. > >>> Ingenico products leverage proven technology, established > >>> standards and unparalleled ergonomics to provide optimal > >>> reliability, versatility and usability. This comprehensive range > >>> of products is complemented by a global array of services and > >>> partnerships, enabling businesses in a number of vertical sectors > >>> to accept transactions anywhere their business takes them. > >>> 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. > >>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx 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 > From Steffen.DETTMER at ingenico.com Mon Jun 11 03:56:18 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 11:56:18 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466990BE.7040100@gatworks.com> References: <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> Message-ID: <20070611095618.GA10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 13:24 -0400: > i was not thinking of change the API to OutputSream. Then I think either someone uses OutputStream (and has no reliable information about incomplete writes) or someone uses somethink else. > Are there specs for how output stream should work internally? > > for instance: > String data = "Hello this is a line of data"; > Outputstream.write( data.getbytes() ); > ParallelPort.suspend(); > int free = ParallelPort.getoutputbufferfree(); > > There is a symbiotic relationship between outputstream and the > functionality of ParallelPort. If you need OutputStream "plus something else", in short you're needing "something else". Personally I dislike the code above a lot. The stream "looks" like if it would be an OutputStream, but in fact it isn't. You need to call getoutputbufferfree later to check if write succeeded (but OutputStream promises that write succeedes synchronous, blocking, or throws an exception). So it is not an OutputStream. No application written for OutputStreams would work without change (because it won't know getoutputbufferfree at all). It is not abstracted from ParallelPort. I think this would be wrong. Then I think an alternative interface instead is better. Let's assume we had some "connection" (to distinguish between OutputStreams and Channels). Then why not working as on a file handle in POSIX: do { // ... select maybe using timer ... readyForWrite = ... if (readyForWrite) { int writtenBytes = connection.write(toWrite); toWrite.remove(0, writtenBytes); } while(readyForWrite && toWrite.length > 0); I think, having such a write isn't the big problem. I think, the difficult thing is around "select" - however this would look like. It should be OO, typesafe, performant, supporting multiple connections/channels/streams in various modes and should be orthogonal to other functionalities. Of course, this heavily depends on what the application is doing; for a simple situation (like reading a small, mandatory file from a local disk) this would be to uncomfortable (and offering unneeded features only). just BTW :) oki, Steffen -- // Modeline for VIM. Please don't remove. // (Help: autoindent, expandtab, shiftwidth=4, tabstop=4, textwidth=75) // vi: set ai et sw=4 ts=4 tw=75 ft=java: About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Mon Jun 11 05:38:33 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 07:38:33 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611095618.GA10821@elberon.bln.de.ingenico.com> References: <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> Message-ID: <466D3439.4020805@gatworks.com> Steffen DETTMER wrote: > (but OutputStream promises that write > succeedes synchronous, blocking, or throws an exception). Where is it so written? From Steffen.DETTMER at ingenico.com Mon Jun 11 06:36:50 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 14:36:50 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466D3439.4020805@gatworks.com> References: <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> <466D3439.4020805@gatworks.com> Message-ID: <20070611123650.GI10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Mon, Jun 11, 2007 at 07:38 -0400: > Steffen DETTMER wrote: > > > (but OutputStream promises that write > > succeedes synchronous, blocking, or throws an exception). > > Where is it so written? Now, as you ask, I think it is not written that clearly but follows from specification. mmm... Am I wrong? I understand the API doc in this way: * http://java.sun.com/j2se/1.4.2/docs/api/java/io/OutputStream.html#write(byte[]) > public void write(byte[] b) > throws IOException > > Writes b.length bytes from the specified byte array to this > output stream. The general contract for write(b) is that > it should have exactly the same effect as the call write(b, > 0, b.length). > > Parameters: > b - the data. > Throws: > IOException - if an I/O error occurs. > See Also: > write(byte[], int, int) and there is: > public void write(byte[] b, > int off, > int len) > throws IOException > > Writes len bytes from the specified byte array starting at > offset off to this output stream. The general contract for > write(b, off, len) is that some of the bytes in the array b > are written to the output stream in order; element b[off] > is the first byte written and b[off+len-1] is the last byte > written by this operation. > > The write method of OutputStream calls the write method of > one argument on each of the bytes to be written out. > Subclasses are encouraged to override this method and > provide a more efficient implementation. > > If b is null, a NullPointerException is thrown. > > If off is negative, or len is negative, or off+len is > greater than the length of the array b, then an > IndexOutOfBoundsException is thrown. > > Parameters: > b - the data. > off - the start offset in the data. > len - the number of bytes to write. > Throws: > IOException - if an I/O error occurs. In particular, an > IOException is thrown if the output stream is closed. In general, any specialisation (derived child class) must comform to this. So write in the end is specified (!) as "The write method ... calls the write method ... on each of the bytes to be written out". This is what must be implemented by ANY OutputStream. Of course, there is: "Subclasses are encouraged to override this method and provide a more efficient implementation." which IMHO does not contradict - the more efficient must behave in exactly the same way of course (just wasting less resources than a simple byte-by-byte write). So it does not matter here I think. The write that finally defines the behavior tells basically: > "Writes the specified byte to this output stream. The general > contract for write is that one byte is written to the output > stream. " > > Throws: > IOException - if an I/O error occurs. which IMHO is another way of saying "write writes the byte immediately and returns on success (only), otherwise an exception is thrown". Especially it cannot happen that zero bytes are written (i.e. the specified byte is NOT written) without an exception. So by this write must be synchronous and blocking, because otherwise it could not reliably know if an asynchronous operation will succeede or not (some getAsyncResult or so would be needed). Since write(byte[]) does this for each byte (or with a behavior beeing exactly the same as if it would do), I think this means that the write(byte[]) succeedes synchronous/blocking or throws an exception. Did I an error in reasoning or confused something or so? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From j.kenneth.gentle at acm.org Mon Jun 11 06:51:25 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 11 Jun 2007 08:51:25 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611123650.GI10821@elberon.bln.de.ingenico.com> References: <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> <466D3439.4020805@gatworks.com> <20070611123650.GI10821@elberon.bln.de.ingenico.com> Message-ID: <200706111251.l5BCpS9T017831@qbang.org> It is as Steffen describes. "InputStream" and "OutputStream" are inherently synchronous (which is why so many java programs resort to threads to use them). Anything outside of this "contract" is *not* an InputStream or OutputStream. That is why there is a new package for things that don't behave like the old *Stream classes - the NIO package. If you look carefully at the IO package, you'll note that almost all the classes are _Decorator_ pattern implementations of the *Stream classes - and the interface presents the _same_ behavior to the calling code in all cases - a synchronous operation that completes successfully or throws an exception (with the one exception of "read" that returns a "-1" on end-of-stream. I know I've read this numerous times - I'd suggest checking the Language Spec or one of the books by Bloch or Gosling. Ken At 08:36 2007-06-11, you wrote: >* Uncle George wrote on Mon, Jun 11, 2007 at 07:38 -0400: > > Steffen DETTMER wrote: > > > > > (but OutputStream promises that write > > > succeedes synchronous, blocking, or throws an exception). > > > > Where is it so written? > >Now, as you ask, I think it is not written that clearly but >follows from specification. mmm... > >Am I wrong? > >I understand the API doc in this way: > >* >http://java.sun.com/j2se/1.4.2/docs/api/java/io/OutputStream.html#write(byte[]) > > public void write(byte[] b) > > throws IOException > > > > Writes b.length bytes from the specified byte array to this > > output stream. The general contract for write(b) is that > > it should have exactly the same effect as the call write(b, > > 0, b.length). > > > > Parameters: > > b - the data. > > Throws: > > IOException - if an I/O error occurs. > > See Also: > > write(byte[], int, int) > > >and there is: > > > > public void write(byte[] b, > > int off, > > int len) > > throws IOException > > > > Writes len bytes from the specified byte array starting at > > offset off to this output stream. The general contract for > > write(b, off, len) is that some of the bytes in the array b > > are written to the output stream in order; element b[off] > > is the first byte written and b[off+len-1] is the last byte > > written by this operation. > > > > The write method of OutputStream calls the write method of > > one argument on each of the bytes to be written out. > > Subclasses are encouraged to override this method and > > provide a more efficient implementation. > > > > If b is null, a NullPointerException is thrown. > > > > If off is negative, or len is negative, or off+len is > > greater than the length of the array b, then an > > IndexOutOfBoundsException is thrown. > > > > Parameters: > > b - the data. > > off - the start offset in the data. > > len - the number of bytes to write. > > Throws: > > IOException - if an I/O error occurs. In particular, an > > IOException is thrown if the output stream is closed. > > >In general, any specialisation (derived child class) must comform >to this. So write in the end is specified (!) as "The write >method ... calls the write method ... on each of the bytes to be >written out". This is what must be implemented by ANY >OutputStream. > >Of course, there is: "Subclasses are encouraged to override this >method and provide a more efficient implementation." which IMHO >does not contradict - the more efficient must behave in exactly >the same way of course (just wasting less resources than a simple >byte-by-byte write). So it does not matter here I think. > > > >The write that finally defines the behavior tells basically: > > > "Writes the specified byte to this output stream. The general > > contract for write is that one byte is written to the output > > stream. " > > > > Throws: > > IOException - if an I/O error occurs. > > >which IMHO is another way of saying "write writes the byte >immediately and returns on success (only), otherwise an exception >is thrown". Especially it cannot happen that zero bytes are >written (i.e. the specified byte is NOT written) without an >exception. So by this write must be synchronous and blocking, >because otherwise it could not reliably know if an asynchronous >operation will succeede or not (some getAsyncResult or so would >be needed). > >Since write(byte[]) does this for each byte (or with a behavior >beeing exactly the same as if it would do), I think this means >that the write(byte[]) succeedes synchronous/blocking or throws >an exception. > >Did I an error in reasoning or confused something or so? > >oki, > >Steffen > >About Ingenico Throughout the world businesses rely on Ingenico for >secure and expedient electronic transaction acceptance. Ingenico >products leverage proven technology, established standards and >unparalleled ergonomics to provide optimal reliability, versatility >and usability. This comprehensive range of products is complemented >by a global array of services and partnerships, enabling businesses >in a number of vertical sectors to accept transactions anywhere >their business takes them. >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. > >About Ingenico Throughout the world businesses rely on Ingenico for >secure and expedient electronic transaction acceptance. Ingenico >products leverage proven technology, established standards and >unparalleled ergonomics to provide optimal reliability, versatility >and usability. This comprehensive range of products is complemented >by a global array of services and partnerships, enabling businesses >in a number of vertical sectors to accept transactions anywhere >their business takes them. >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. > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From alesinskyy at googlemail.com Mon Jun 11 07:25:33 2007 From: alesinskyy at googlemail.com (Oleksandr Alesinskyy) Date: Mon, 11 Jun 2007 15:25:33 +0200 Subject: [Rxtx] [OT] select :-) Message-ID: Sorry, but I have to disagree with following statement: "So write in the end is specified (!) as "The write method ... calls the write method ... on each of the bytes to be written out". This is what must be implemented by ANY OutputStream.". This is not part of the specification or contract, it is just revealed implementation detail of the OutputStream. It is not stated anywhere that behavoiur of derived classes shall conform with this one. Statement concerning "synchronous" nature of the output stream is invalid as well. Really synchronous stream does not require flush() but OutputStream has it. From Steffen.DETTMER at ingenico.com Mon Jun 11 08:21:16 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 16:21:16 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: Message-ID: <20070611142116.GN10821@elberon.bln.de.ingenico.com> * Oleksandr Alesinskyy wrote on Mon, Jun 11, 2007 at 15:25 +0200: > Sorry, but I have to disagree with following statement: > "So write in the end is specified (!) as "The write > method ... calls the write method ... on each of the bytes to be > written out". This is what must be implemented by ANY > OutputStream.". > > This is not part of the specification or contract, it is just > revealed implementation detail of the OutputStream. It is not > stated anywhere that behavoiur of derived classes shall conform > with this one. (I didn't meant that the implementation must really write byte by byte, but that it must "look as if it would do" - because all implementations of OutputStream must "look" in the same way [which is another way of saying "do abstract" I think]) I think the API doc is not "revealing implementation details" but it is the *specification* of that interface and derivations must (should) conform to this specification. Isn't this the idea of interfaces? A function that expects an OutputStream should work on ANY OutputStream, shouldn't it? just kidding: I mean, what would be the point in implementing a checksum function as OutputStream.write which throws its result as IOException? Or which requires to call close() as very first operation to tell that the application is about to transmit confidential data? :-) > Statement concerning "synchronous" nature of the output stream > is invalid as well. Really synchronous stream does not require > flush() but OutputStream has it. ahh, interesting point! I think this is another bug in the API. flush() is wrong. Because write specifies "The general contract for write is that one byte is written to the output stream." but not "a byte may be written or buffered". Actually, an application would need to call flush() after each write (or bunch of write calls) to ensure that write really did something otherwise I think. I didn't found in the spec of OutputStream that it would be required to call flush(). This should mean that calling flush is not required which in turn leads to the conclusion that write must be synchrous (private threads are forbidden because not specified :)) which in turn leads to the conclusion that flush() is not needed at all... I mean, what if someone would only store in write and do the "real write" in flush() and never else? An application could write in one stream and read on another one (e.g. in bidirectional communication) and would never get anything back, because nothing was actually written because no flush was called? Then someone could even think that on error in some write the data could remain buffered AND throw an exception, retrying to send the data in the next write. Ohh, and if there would be some message number inside, and underlaying write (e.g. a protocol offering InputStream/OutputStream) would check this and throw "DuplicatedMessageNumber" the stream would only throw it again and again beeing unusable... In short: I have no clue how someone could be able to implement an asynchrounos write (which is realiable and correct) without beeing specific to anything which is not specified by OutputStream. Well, I think in the end OutputStream was not intended for such communication or protocol implementations - but to read a local disk file or so. In case of I/O errors usually you can abort your application and change the hard disk :-) oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Bob_Jacobsen at lbl.gov Mon Jun 11 09:32:23 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Mon, 11 Jun 2007 08:32:23 -0700 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611142116.GN10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> Message-ID: At 4:21 PM +0200 6/11/07, Steffen DETTMER wrote: > > Statement concerning "synchronous" nature of the output stream >> is invalid as well. Really synchronous stream does not require >> flush() but OutputStream has it. > >ahh, interesting point! > >I think this is another bug in the API. flush() is wrong. Because >write specifies "The general contract for write is that one byte >is written to the output stream." but not "a byte may be written >or buffered". > >Actually, an application would need to call flush() after each >write (or bunch of write calls) to ensure that write really did >something otherwise I think. OutputStreams don't _have_ to be synchronous or asynchronous, but the OutputStream API was be arranged so that subclasses _can_ be synchronous or asynchronous. Such generality is the hardest part of getting an API right. Hence, if at some point a program using an OutputStream wants to be sure that the data has been pushed all the way out, flush() is available. For some subclasses, e.g. the buffered ones, this has important behavior. Others write the data from each call, and flush() doesn't do anything. You _can_ omit it in programs that are known to use this second type, but there's no requirement that you do so; the interface is general in that way. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From Steffen.DETTMER at ingenico.com Mon Jun 11 12:32:39 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 20:32:39 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> Message-ID: <20070611183239.GT10821@elberon.bln.de.ingenico.com> * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: > >Actually, an application would need to call flush() after each > >write (or bunch of write calls) to ensure that write really did > >something otherwise I think. > OutputStreams don't _have_ to be synchronous or asynchronous, > but the OutputStream API was be arranged so that subclasses > _can_ be synchronous or asynchronous. Ahh, oki. Thanks for the clarificaion. So in short, flush() MUST be called on OutputStream, this is just not documented correctly or so clearly (right?). So the overall usage semantics would be: 1. call write (multiple times if desired) 2. call flush only if both succeeded, write was successful. If flush fails it remains unknown if a part of the data was written and/or will be repeated. So the spec (API doc) is wrong. Correct would be to tell that write behaves as told as long as it is followed by a call to flush, otherwise data may or may not get lost (depending wheter close() is called and calls flush(), which seems not to be guaranteed/required). BTW, I think it is a little bit... erm... interesting to find the specification (java API doc reference) wrong, having a need to conclude it from the presence of some methods with "it would make no sense if they behave exactly as specified, so specification must be wrong (incomplete)". > Such generality is the hardest part of getting an API right. Yes, seems to be proven ;) > Hence, if at some point a program using an OutputStream wants > to be sure that the data has been pushed all the way out, > flush() is available. For some subclasses, e.g. the buffered > ones, this has important behavior. Others write the data from > each call, and flush() doesn't do anything. > You _can_ omit it in programs that are known to use this second > type, but there's no requirement that you do so; the interface > is general in that way. I think, it still it must be called always, otherwise the application could break if passing a different runtime type as OutputStream. I think, if the application/method needs a special "type of OutputStream" then the parameter type must be a subclass but not OutputStream, maybe a PrintStream or so - otherwise the compiler could not detect this error (passing wrong type). Is this correct? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Bob_Jacobsen at lbl.gov Mon Jun 11 13:00:52 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Mon, 11 Jun 2007 12:00:52 -0700 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611183239.GT10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> Message-ID: At 8:32 PM +0200 6/11/07, Steffen DETTMER wrote: >So the spec (API doc) is wrong. Correct would be to tell that >write behaves as told as long as it is followed by a call to >flush, otherwise data may or may not get lost (depending wheter >close() is called and calls flush(), which seems not to be >guaranteed/required). I'm not entirely sure that the spec is wrong, but reasonable people can differ on this. In the 1.5 JavaDocs, all that the docs say for the write methods is that they write to the _output_ _stream_; there is no guarantee of anything beyond that. Only the flush method has any guarantee about the data, which is >Flushes this output stream and forces any buffered output bytes to >be written out. The general contract of flush is that calling it is >an indication that, if any bytes previously written have been >buffered by the implementation of the output stream, such bytes >should immediately be written to their intended destination. People commonly use various OutputStreams without using flush(), and it often works, but it's a bad practice and will eventually bite them. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From netbeans at gatworks.com Mon Jun 11 13:31:57 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 15:31:57 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611183239.GT10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> Message-ID: <466DA32D.1010602@gatworks.com> Steffen DETTMER wrote: > * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: >>> Actually, an application would need to call flush() after each >>> write (or bunch of write calls) to ensure that write really did >>> something otherwise I think. > >> OutputStreams don't _have_ to be synchronous or asynchronous, >> but the OutputStream API was be arranged so that subclasses >> _can_ be synchronous or asynchronous. > > Ahh, oki. Thanks for the clarificaion. > > So in short, flush() MUST be called on OutputStream, this is just > not documented correctly or so clearly (right?). No. Flush can be called to force all current data in java buffer's to be written to the kernel - NOW. A flush() can also *imply* that, besides writing out the buffer's that java employs, may also imply/ask the kernel to write all data thusfar written to the kernel, to be physically placed on the destination device - NOW. For some OS's there is no need to do a kernel flush(), as the I/O is synchronized already. Since this is java, you never know what OS your on. From tjarvi at qbang.org Mon Jun 11 19:28:27 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Jun 2007 19:28:27 -0600 (MDT) Subject: [Rxtx] [OT] select :-) In-Reply-To: <466DA32D.1010602@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: On Mon, 11 Jun 2007, Uncle George wrote: > Steffen DETTMER wrote: >> * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: >>>> Actually, an application would need to call flush() after each >>>> write (or bunch of write calls) to ensure that write really did >>>> something otherwise I think. >> >>> OutputStreams don't _have_ to be synchronous or asynchronous, >>> but the OutputStream API was be arranged so that subclasses >>> _can_ be synchronous or asynchronous. >> >> Ahh, oki. Thanks for the clarificaion. >> >> So in short, flush() MUST be called on OutputStream, this is just >> not documented correctly or so clearly (right?). > No. > Flush can be called to force all current data in java buffer's to be > written to the kernel - NOW. > > A flush() can also *imply* that, besides writing out the buffer's that > java employs, may also imply/ask the kernel to write all data thusfar > written to the kernel, to be physically placed on the destination device > - NOW. > For some OS's there is no need to do a kernel flush(), as the I/O is > synchronized already. Since this is java, you never know what OS your on. To add to the confusion, flush on the C side throws away data. drain makes sure it is written. Looking at the ParallelImp.c we can probably do better. /* we set a timeout because all calls are sequentiell (also with asynchron) this means that the default timeout of unlimited blocks all calls (also close and status request) if the device is down */ GetCommTimeouts( (HANDLE)fd, &timeouts ); timeouts.WriteTotalTimeoutMultiplier = 0; timeouts.WriteTotalTimeoutConstant = 2000; /* 2000 is the min value for the default Windows NT and Windows 2000 driver */ SetCommTimeouts( (HANDLE)fd, &timeouts ); while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } errorCount = 0; bytes += countWritten; count -= countWritten; } LPRPort has some timeout code that appears to be doing nothing but flipping bits back and forth right now. The commapi rxtx follows allows for timeout control from javax.comm.CommPort. The above is a solution that worked in one specific use case. With timeouts in place, the original 'old printer going offline' problem could be solved. That printer code isn't written in stone. In fact it was ajusted from being able to print 'asdf' to a daisy wheel printer to working for one person. BTW, I've finished teaching after hours tonight and will be moving forward with a new rxtx release in my free time. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Jun 11 21:28:04 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 23:28:04 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: <466E12C4.1010305@gatworks.com> > Looking at the ParallelImp.c we can probably do better. > The problem stemmed from the possibility that the writev routine could have written some of the buffer, in chunks, printer pauses, refuses any more chunks, and a timeout occurs. Do you or do you not cause an exception to be thrown? Is there a way to set timeout for a ParallelPort data output stream? I cant find it. From tjarvi at qbang.org Mon Jun 11 22:17:23 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Jun 2007 22:17:23 -0600 (MDT) Subject: [Rxtx] [OT] select :-) In-Reply-To: <466E12C4.1010305@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> <466E12C4.1010305@gatworks.com> Message-ID: On Mon, 11 Jun 2007, Uncle George wrote: >> Looking at the ParallelImp.c we can probably do better. >> > The problem stemmed from the possibility that the writev routine could > have written some of the buffer, in chunks, printer pauses, refuses any > more chunks, and a timeout occurs. Do you or do you not cause an > exception to be thrown? > > Is there a way to set timeout for a ParallelPort data output stream? I > cant find it. hmm I looked again after you asked. The timeouts are only controllable on the receive side. This comes from CommPort; the parent. So what we are talking about is some bytes in memory that rxtx has and is supposed to write. A buffer perhaps? The approach with rxtx in the past has been to ignore output buffer sizes. The assumption is that the library does not know how to best handle buffers. There are buffered output streams that can do buffering on top of rxtx for instance. There is also a question regarding what was actually ment when the API was put together. My suspicion is that it was put together while looking at one OS API and was never ment to be anything more than a hook into that API. The comments are fairly telling combined with reading the w32 API. So looking at the problem again.. The current timeout behavior appears fairly arbitrary. Presumably this is to prevent a program from hanging instead of using a helper thread to write - heavy handed for new programmers. Even so, I don't think the write should timeout at all if it is not configurable. >From the API perspective, "What Timeout?" -- Trent Jarvi tjarvi at qbang.org From Steffen.DETTMER at ingenico.com Tue Jun 12 02:14:48 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 12 Jun 2007 10:14:48 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466DA32D.1010602@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: <20070612081447.GU10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Mon, Jun 11, 2007 at 15:31 -0400: > Steffen DETTMER wrote: > > Ahh, oki. Thanks for the clarificaion. > > > > So in short, flush() MUST be called on OutputStream, this is just > > not documented correctly or so clearly (right?). > No. hum (though now I got it, but...). > Flush can be called to force all current data in java buffer's to be > written to the kernel - NOW. > > A flush() can also *imply* that, besides writing out the > buffer's that java employs, may also imply/ask the kernel to > write all data thusfar written to the kernel, to be physically > placed on the destination device - NOW. > > For some OS's there is no need to do a kernel flush(), as the I/O is > synchronized already. Since this is java, you never know what OS your on. (well, but if you're going to kernel level, even flush cannot guarantee that data will "be physically placed". Maybe you're flushing to a file via NFS (and the client "thinks" that it was written, but maybe it was just buffered by the NFS server) or so... but of course such exceptions of the rules are constructable always.) Well, you tell that depending on the OS it can be that flush is needed or it can be that flush is not needed (beacuse the I/O is synchronized already), right? Also, applications should work on any OS, which includes the OSes that do need flush. Since the application cannot know whether flush is needed or not because it doesn't know what the OS is doing, it has to call flush, hasn't it? I mean, if it would not call flush then it would not work on such OSes (except the written data would not be needed at all, but in this would be an artificial example :)). Since applications are supposed to work this would be wrong, wouldn't it? So would it be correct to say: "Applications, that should work under all OSes (including the OSes where the I/O is not synchronised already), have to call flush on OutputStream to ensure the data is transfered to the kernel." or is this wrong? If so, then I'm afraid I missed the point again :( oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Tue Jun 12 04:46:52 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 12 Jun 2007 06:46:52 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070612081447.GU10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> <20070612081447.GU10821@elberon.bln.de.ingenico.com> Message-ID: <466E799C.7060700@gatworks.com> S > (well, but if you're going to kernel level, even flush cannot > guarantee that data will "be physically placed". Thats true now-a-days because ( from "man 2 sync" ) : > According to the standard specification (e.g., SVID), sync() schedules > the writes, but may return before the actual writing is done. However, > since version 1.3.20 Linux does actually wait. (This still does not > guarantee data integrity: modern disks have large caches.) My disk drive has 8mb cache. Maybe you're > flushing to a file via NFS (and the client "thinks" that it was > written, but maybe it was just buffered by the NFS server) or > so... but of course such exceptions of the rules are > constructable always.) > > Well, you tell that depending on the OS it can be that flush is > needed or it can be that flush is not needed (beacuse the I/O is > synchronized already), right? Also, applications should work on > any OS, which includes the OSes that do need flush. Its not OS's that need flush, its applications that want to have some assurance that data is written to the device that really needs to use flush. If your program ( or thread ) dies then it is in your best interest to write out the critical data as soon as possible, as economical as possible. These are trade-off's that the application programmer makes. A big buffer may mean big loss of data, a small buffer may mean spending too much time writing out data. > > > So would it be correct to say: > > "Applications, that should work under all OSes (including the > OSes where the I/O is not synchronised already), have to call > flush on OutputStream to ensure the data is transfered to the > kernel." > > or is this wrong? If so, then I'm afraid I missed the point again > :( > No that is not wrong. Ensuring that data is transfered to the OS is just about what any application can do. From tjarvi at qbang.org Thu Jun 14 08:16:47 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 14 Jun 2007 08:16:47 -0600 (MDT) Subject: [Rxtx] rxtx and usb-serial solution In-Reply-To: References: Message-ID: On Thu, 14 Jun 2007, Vladimir Kirtchev wrote: > Hi Trent, > > I develop a Java application which communicates with devices which have > USB-to-Serial bridge in them. The target OS is Linux. So for this purpose I > use RXTX. > > But I encountered a strange problem - when reading from the InputStream, I > receive series of zeros. I have this problem under Linux only. Under Windows > it is fine. > Actually this problem is the same as the one described here: > http://marc.info/?l=rxtx&m=109703190731748&w=2. > > > So I searched for the problem in the native code. And found that the root of > the problem is in SerialImp.c, > int configure_port( int fd ) > { > ... > ttyset.c_iflag = INPCK; > ... > } > > This line enables input parity checking, and the data sent from the device > is processed by the OS driver before being read with read(). > In this case the driver detects some problem and sets the received bytes to > zero. > > On the other hand in the Java part a set the serial port parameters with > SerialPort.PARITY_NONE. According to me, except all other things, this > should also disable INPCK in c_iflag. > > So I refactored the method translate_parity(...) to the following: > > int translate_parity( JNIEnv *env, struct termios *ttyset, jint parity ) > { > ENTER( "translate_parity" ); > #ifdef CMSPAR > ttyset->c_cflag &= ~(PARENB | PARODD | CMSPAR ); > #endif /* CMSPAR */ > switch( parity ) { > case JPARITY_NONE: > ttyset->c_iflag &= ~INPCK; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_EVEN: > ttyset->c_cflag |= PARENB; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_ODD: > ttyset->c_cflag |= PARENB | PARODD; > LEAVE( "translate_parity" ); > return 0; > #ifdef CMSPAR > case JPARITY_MARK: > ttyset->c_cflag |= PARENB | PARODD | CMSPAR; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_SPACE: > ttyset->c_cflag |= PARENB | CMSPAR; > LEAVE( "translate_parity" ); > return 0; > #endif /* CMSPAR */ > default: > printf("Parity missed %i\n", (int) parity ); > } > > LEAVE( "translate_parity" ); > /* > For some reason the native exceptions are not being caught. Moving this > to the Java side fixed the issue. taj. > throw_java_exception( env, UNSUPPORTED_COMM_OPERATION, > "", "parity value not supported" ); > */ > return 1; > } > > This modification solved the problem and now it works correctly under Linux. > > I think I will be a nice if this is idea is included in a future release of > RXTX. > > Thanks Vadim, I'll try that out. Forwarding to the rxtx mail-list too. This is probably not going to help USB drivers on windows which I'm sure some are looking for. As far as I can tell, windows USB bluetooth and serial dongles are limited by driver functionality. Some are good and others lack key features. -- Trent Jarvi tjarvi at qbang.org From dan.sandberg.lists at gmail.com Mon Jun 18 14:43:39 2007 From: dan.sandberg.lists at gmail.com (Dan Sandberg) Date: Mon, 18 Jun 2007 13:43:39 -0700 Subject: [Rxtx] Fix for JNI Get/Set Field Errors Message-ID: <4676EE7B.7060800@gmail.com> Hi, I've fixed the problems that cause the following JNI error when extra JNI checking ( -Xjni:check ) is turned on. FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) The problem was basically that GetLong was being used to get ints, and SetInt was used for longs. The patch below fixes this. Please let me know if there are any questions / problems. Cheers, -Dan diff -aur old/SerialImp.c src/SerialImp.c --- old/SerialImp.c 2007-06-18 13:24:33.000000000 -0700 +++ src/SerialImp.c 2007-06-18 06:26:26.000000000 -0700 @@ -1337,7 +1337,7 @@ report("init_threads: get eis\n"); jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); report("init_threads: set eis\n"); - (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); + (*eis->env)->SetLongField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); report("init_threads: stop\n"); report_time_end( ); return( 1 ); @@ -1530,7 +1530,7 @@ jobject jobj, jboolean interrupted ) { int fd = get_java_var( env, jobj,"fd","I" ); - struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var( env, jobj, "eis", "J" ); + struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var_long( env, jobj, "eis", "J" ); int result, count=0; char message[80]; @@ -2939,7 +2939,7 @@ /* TRENT */ int flag, count = 0; struct event_info_struct *eis = ( struct event_info_struct * ) - get_java_var( env, *jobj,"eis","J" ); + get_java_var_long( env, *jobj,"eis","J" ); report_time_start(); flag = eis->eventflags[SPE_DATA_AVAILABLE]; @@ -4873,9 +4873,9 @@ exceptions: none comments: ----------------------------------------------------------*/ -size_t get_java_var( JNIEnv *env, jobject jobj, char *id, char *type ) +long get_java_var_long( JNIEnv *env, jobject jobj, char *id, char *type ) { - int result = 0; + long result = 0; jclass jclazz = (*env)->GetObjectClass( env, jobj ); jfieldID jfd = (*env)->GetFieldID( env, jclazz, id, type ); @@ -4889,7 +4889,11 @@ LEAVE( "get_java_var" ); return result; } - result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); + if ( !strcmp( type, "J" ) ) { + result = (long)( (*env)->GetLongField( env, jobj, jfd ) ); + } else { + result = (int) ( (*env)->GetIntField( env, jobj, jfd ) ); + } /* ct7 & gel * Added DeleteLocalRef */ (*env)->DeleteLocalRef( env, jclazz ); if(!strncmp( "fd",id,2) && result == 0) @@ -4900,6 +4904,10 @@ return result; } +int get_java_var( JNIEnv *env, jobject jobj, char *id, char *type ) { + return (int) get_java_var_long( env, jobj, id, type ); +} + /*---------------------------------------------------------- throw_java_exception diff -aur old/SerialImp.h src/SerialImp.h --- old/SerialImp.h 2007-06-18 13:24:39.000000000 -0700 +++ src/SerialImp.h 2007-06-18 06:23:43.000000000 -0700 @@ -413,7 +413,8 @@ void system_wait(); void finalize_event_info_struct( struct event_info_struct * ); int read_byte_array( JNIEnv *, jobject *, int, unsigned char *, int, int ); -size_t get_java_var( JNIEnv *, jobject, char *, char * ); +int get_java_var( JNIEnv *, jobject, char *, char * ); +long get_java_var_long( JNIEnv *, jobject, char *, char * ); jboolean is_interrupted( struct event_info_struct * ); int send_event(struct event_info_struct *, jint, int ); void dump_termios(char *,struct termios *); From yvespielusenet at free.fr Tue Jun 26 03:41:58 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 11:41:58 +0200 Subject: [Rxtx] [PARALLEL] resource in use Message-ID: <1182850918.3483.10.camel@localhost.localdomain> Hello, So now I want to modify the timeout of the library for parallel port. I have downloaded source code. There is a makefile for migw. SO I have installed mingw on ubuntu and modified the makefile.mingw32 to set it for my system. I have no error but some warnings. The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But When I want to use it the jvm crash :( How can I know what is wrong ? How rxtx windows release has been done ? thanks -- yves piel From yvespielusenet at free.fr Tue Jun 26 07:17:02 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 15:17:02 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182850918.3483.10.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> Message-ID: <1182863822.3483.17.camel@localhost.localdomain> Here is the Makefile I use, the output of the 'make' and the log of the jvm when it crashed : - The Makefile : http://yvespiel.free.fr/rxtx/Makefile - The make output : http://yvespiel.free.fr/rxtx/compile.txt - The crash log : http://yvespiel.free.fr/rxtx/hs_err_pid2100.log I have compiled rxtx under Debian testing with mingw : narma at linimi:/tmp/err$ dpkg -l | grep mingw ii mingw32 3.4.5.20060117.1.dfsg-3 ii mingw32-binutils 2.17.50-20070129.1-1 ii mingw32-runtime 3.12-1 thanks fort help :) Le mardi 26 juin 2007 ? 11:41 +0200, yves pielusenet a ?crit : > Hello, > So now I want to modify the timeout of the library for parallel port. I > have downloaded source code. There is a makefile for migw. SO I have > installed mingw on ubuntu and modified the makefile.mingw32 to set it > for my system. > I have no error but some warnings. > The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But > When I want to use it the jvm crash :( > > How can I know what is wrong ? > > How rxtx windows release has been done ? > > thanks > From yvespielusenet at free.fr Tue Jun 26 07:40:11 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 15:40:11 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182863822.3483.17.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> <1182863822.3483.17.camel@localhost.localdomain> Message-ID: <1182865211.3483.21.camel@localhost.localdomain> I have add the options '--enable-stdcall-fixup' to the 'i586-mingw32msvc-ld' commande. Now I have no warning. But the JVM always crashes :( The output seems more detailled, but I don't understand anything... Here is files : http://yvespiel.free.fr/rxtx/2/ -- yves piel Le mardi 26 juin 2007 ? 15:17 +0200, yves pielusenet a ?crit : > Here is the Makefile I use, the output of the 'make' and the log of the > jvm when it crashed : > > - The Makefile : http://yvespiel.free.fr/rxtx/Makefile > - The make output : http://yvespiel.free.fr/rxtx/compile.txt > - The crash log : http://yvespiel.free.fr/rxtx/hs_err_pid2100.log > > I have compiled rxtx under Debian testing with mingw : > narma at linimi:/tmp/err$ dpkg -l | grep mingw > ii mingw32 3.4.5.20060117.1.dfsg-3 > ii mingw32-binutils 2.17.50-20070129.1-1 > ii mingw32-runtime 3.12-1 > > thanks fort help :) > > > Le mardi 26 juin 2007 ? 11:41 +0200, yves pielusenet a ?crit : > > Hello, > > So now I want to modify the timeout of the library for parallel port. I > > have downloaded source code. There is a makefile for migw. SO I have > > installed mingw on ubuntu and modified the makefile.mingw32 to set it > > for my system. > > I have no error but some warnings. > > The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But > > When I want to use it the jvm crash :( > > > > How can I know what is wrong ? > > > > How rxtx windows release has been done ? > > > > thanks > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From yvespielusenet at free.fr Tue Jun 26 08:27:42 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 16:27:42 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182865211.3483.21.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> <1182863822.3483.17.camel@localhost.localdomain> <1182865211.3483.21.camel@localhost.localdomain> Message-ID: <1182868062.3483.24.camel@localhost.localdomain> I think thant the include files of jdk were not for windows but for linux. So I have copied include/ folder from windows to linux and I modified the Makefile to use those file. It compile fine but the JVM always crash :( http://yvespiel.free.fr/rxtx/3/ Le mardi 26 juin 2007 ? 15:40 +0200, yves pielusenet a ?crit : > I have add the options '--enable-stdcall-fixup' to the > 'i586-mingw32msvc-ld' commande. Now I have no warning. But the JVM > always crashes :( The output seems more detailled, but I don't > understand anything... > Here is files : > http://yvespiel.free.fr/rxtx/2/ > From netbeans at gatworks.com Fri Jun 1 05:38:50 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 07:38:50 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <465F7ADD.1010501@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> Message-ID: <4660054A.2040202@gatworks.com> Manuel Naranjo wrote: In the case of my module, you can > unplug the device but it will not delete the symlink until those apps > that had opened the port has closed it. This is done this way to avoid > kernel panics. What does this mean to user code ? I have tried the alternate route ( other than closing ) which is sleep inbetween the I/O errors ( an unplugged USB device). When the device is plugged back in, The writes to the device still get an I/O error. This would seem to be a lost cause for the application. From netbeans at gatworks.com Fri Jun 1 06:35:48 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 08:35:48 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <465F7ADD.1010501@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> Message-ID: <466012A4.90608@gatworks.com> Manuel Naranjo wrote: In the case of my module, you can > unplug the device but it will not delete the symlink until those apps > that had opened the port has closed it. T Did u also mean for this to happen? USB0 was not closed by application. Apparently USB1 got created when USB device was plugged back in. There is only one USB device on a 4 port USB hub. This also seems to suggest that application recovery to be impossible. > Jun 1 07:10:08 mylaptop kernel: garmin_gps 1-1.4:1.0: Garmin GPS usb/tty converter detected > Jun 1 07:10:08 mylaptop kernel: usb 1-1.4: Garmin GPS usb/tty converter now attached to ttyUSB0 > Jun 1 07:15:17 mylaptop kernel: usb 1-1: USB disconnect, address 4 > Jun 1 07:15:17 mylaptop kernel: usb 1-1.4: USB disconnect, address 5 > Jun 1 07:15:17 mylaptop kernel: garmin_gps 1-1.4:1.0: device disconnected > Jun 1 07:15:26 mylaptop kernel: usb 1-1: new full speed USB device using uhci_hcd and address 6 > Jun 1 07:15:26 mylaptop kernel: hub 1-1:1.0: USB hub found > Jun 1 07:15:26 mylaptop kernel: hub 1-1:1.0: 4 ports detected > Jun 1 07:15:27 mylaptop kernel: usb 1-1.4: new full speed USB device using uhci_hcd and address 7 > Jun 1 07:15:27 mylaptop kernel: garmin_gps 1-1.4:1.0: Garmin GPS usb/tty converter detected > Jun 1 07:15:27 mylaptop kernel: usb 1-1.4: Garmin GPS usb/tty converter now attached to ttyUSB1 From naranjo.manuel at gmail.com Fri Jun 1 09:17:22 2007 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Fri, 01 Jun 2007 12:17:22 -0300 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <466012A4.90608@gatworks.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> <466012A4.90608@gatworks.com> Message-ID: <46603882.5050701@gmail.com> Uncle George escribi?: > Manuel Naranjo wrote: > In the case of my module, you can > >> unplug the device but it will not delete the symlink until those apps >> that had opened the port has closed it. T >> > > Did u also mean for this to happen? USB0 was not closed by application. > > Apparently USB1 got created when USB device was plugged back in. There > is only one USB device on a 4 port USB hub. > > This also seems to suggest that application recovery to be impossible. > Exactly there's a dead symlink (you can read and write to it and nothing will happen) and a new port will be created when a new device is connencted. From netbeans at gatworks.com Fri Jun 1 10:20:46 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 12:20:46 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <46603882.5050701@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> <466012A4.90608@gatworks.com> <46603882.5050701@gmail.com> Message-ID: <4660475E.5090202@gatworks.com> Not sure what u mean by "symlink". U cant read/write to it anymore. U get I/O error. In this scenario the device effectively went dead, and only solution is to close the channel. reconnecting the USB device, although dead, but not closed, will create a second device. This does not seem to be a desirable side-effect. The user will now have ttyUSB1, wondering where did ttyUSB0 go to. The application will also be in a confused state, as well as RXTX, because RXTX wont know about ttyUSB1. Manuel Naranjo wrote: > Uncle George escribi?: >> Manuel Naranjo wrote: >> In the case of my module, you can >> >>> unplug the device but it will not delete the symlink until those apps >>> that had opened the port has closed it. T >>> >> Did u also mean for this to happen? USB0 was not closed by application. >> >> Apparently USB1 got created when USB device was plugged back in. There >> is only one USB device on a 4 port USB hub. >> >> This also seems to suggest that application recovery to be impossible. >> > Exactly there's a dead symlink (you can read and write to it and nothing > will happen) and a new port will be created when a new device is connencted. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From arnab.bhaumik at gmail.com Mon Jun 4 01:40:16 2007 From: arnab.bhaumik at gmail.com (arnab bhaumik) Date: Mon, 4 Jun 2007 13:10:16 +0530 Subject: [Rxtx] full duplex com port with rxtx Message-ID: hi , till now i did half duplex communication with rxtx package on com package. my question is : is it possible to use com port with full duplex mode with rxtx package . ther is example of SimpleRead class and SimpleWrite class. it is clear that if i can use both the class simultaneously then full duplex is possible......... arnab/vu2bpw -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070604/6edb0453/attachment-0008.html From lists at iDIAcomputing.com Mon Jun 4 07:53:17 2007 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Mon, 04 Jun 2007 09:53:17 -0400 Subject: [Rxtx] full duplex com port with rxtx In-Reply-To: References: Message-ID: <4664194D.90301@iDIAcomputing.com> arnab bhaumik wrote: > hi , > > till now i did half duplex communication with rxtx package on com > package. > > my question is : is it possible to use com port with full duplex mode > with rxtx package . > > > ther is example of SimpleRead class and SimpleWrite class. it is > clear that if i can use both the class simultaneously then full duplex > is possible......... I haven't looked at the SimpleRead and SimpleWrite classes (I originally wrote my code for the javax.comm api), but full duplex is certainly possible. My CommReader class requires an object analogous to a OutputStream or Writer. When started, it spawns a thread that reads the comm port and writes to that output device. In this way the input is asynchronous and dependent on the actual input data. For full duplex, I extend that class with CommReaderWriter, which adds synchronous output methods. Hope that helps, George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From supsoop at hotmail.com Mon Jun 4 15:21:06 2007 From: supsoop at hotmail.com (soop soop) Date: Mon, 04 Jun 2007 21:21:06 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- Message-ID: Hi Guys, Looked through the archives but still cannot figure this out. I have a Motorola G24 GPRS/GSM modem that I am connecting to my server running Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not detecting the port, CommPortIdentifier.getPortIdentifiers(). I have added the line to RXTXCommDriver: "ttyACM" // for USB Modems Rxtx still does not seem to find the port. Is there something I am missing to make this port visable? [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control Model driver for USB modems and ISDN adapters I really need your help as I have moved my server from windows to Linux and have been down for a few days because of this .. Thanks so much! _________________________________________________________________ PC Magazine’s 2007 editors’ choice for best Web mail—award-winning Windows Live Hotmail. http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 From tjarvi at qbang.org Mon Jun 4 16:17:35 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Jun 2007 16:17:35 -0600 (MDT) Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: On Mon, 4 Jun 2007, soop soop wrote: > Hi Guys, > > Looked through the archives but still cannot figure this out. I have a > Motorola G24 GPRS/GSM modem that I am connecting to my server running Ubuntu. > I can see my modem as is shows up as ttyACM0, but RXTX is not detecting the > port, CommPortIdentifier.getPortIdentifiers(). > > I have added the line to RXTXCommDriver: > > "ttyACM" // for USB Modems > > Rxtx still does not seem to find the port. Is there something I am missing to > make this port visable? > > [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver > [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device > [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control Model > driver for USB modems and ISDN adapters > > I really need your help as I have moved my server from windows to Linux and > have been down for a few days because of this .. Thanks so much! > You could try the INSTALL documentation that comes with the source for possible solutions. Those usually involve lockfile creation, permissions on the device file or the device is in use by another application (even another session of your application). The usual commands: ls -l /dev/ttyACM0 fuser /dev/ttyACM0 touch /var/lock/LCK.testfile && rm -f /var/lock/LCK.testfile whoami To disable lockfiles: ../configure --disable-lockfiles && make install -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Jun 4 16:22:52 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 04 Jun 2007 18:22:52 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <466490BC.3090801@gatworks.com> soop soop wrote: > I really need your help as I have moved my server from windows to Linux > and have been down for a few days because of this .. Thanks so much! can u open the device ? ie is the file protection/permissions keeping you out? From supsoop at hotmail.com Mon Jun 4 16:44:40 2007 From: supsoop at hotmail.com (soop soop) Date: Mon, 04 Jun 2007 22:44:40 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <466490BC.3090801@gatworks.com> Message-ID: Thanks for the reply, I see no exceptions being thrown, just no detection of the port whats so ever. I will run rxtx in debug mode and log. If this were a permissions issue would I not see some exceptions being thrown? >From: Uncle George >Reply-To: RXTX Developers and Users >To: RXTX Developers and Users >Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >Date: Mon, 04 Jun 2007 18:22:52 -0400 > >soop soop wrote: > > > I really need your help as I have moved my server from windows to Linux > > and have been down for a few days because of this .. Thanks so much! > >can u open the device ? ie is the file protection/permissions keeping >you out? >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ Get a preview of Live Earth, the hottest event this summer - only on MSN http://liveearth.msn.com?source=msntaglineliveearthhm From netbeans at gatworks.com Mon Jun 4 17:06:15 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 04 Jun 2007 19:06:15 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <46649AE7.10405@gatworks.com> Exceptions on what? On startup it wants to lookup all devices in /dev that it is capable of opening ( within the list of specific 'comm' devices ). If it cannot open, then does not get onto list. Part of this process, if configured, will also test if the "LOCK" schema can also be opened for the device. then it gets on the list of avail comm port. soop soop wrote: > Thanks for the reply, > > I see no exceptions being thrown, just no detection of the port whats so > ever. I will run rxtx in debug mode and log. If this were a permissions > issue would I not see some exceptions being thrown? > > >> From: Uncle George >> Reply-To: RXTX Developers and Users >> To: RXTX Developers and Users >> Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >> Date: Mon, 04 Jun 2007 18:22:52 -0400 >> >> soop soop wrote: >> >>> I really need your help as I have moved my server from windows to Linux >>> and have been down for a few days because of this .. Thanks so much! >> can u open the device ? ie is the file protection/permissions keeping >> you out? >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _________________________________________________________________ > Get a preview of Live Earth, the hottest event this summer - only on MSN > http://liveearth.msn.com?source=msntaglineliveearthhm > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From alex.flint at gmail.com Mon Jun 4 21:31:49 2007 From: alex.flint at gmail.com (Alex Flint) Date: Tue, 5 Jun 2007 13:01:49 +0930 Subject: [Rxtx] random EXCEPTION_ACCESS_VIOLATION errors Message-ID: Hi All, I'm running winXP and RXTX 2.1-7r2 (the latest from the webpage as of June 2007). I'm sending sequences of 64 lines (each line has about 15 chars) at various intervals. The strings are sent fine, until I get the following error (from hs_err_pid3316.log, at the end of this email). What can I do to avoid the error? Obviously this is a low-level memory exception, but is there any way I can keep the JVM running after such an error? I noticed the exact same problem here: http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20070129/1180520.html Cheers, Alex # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x100034fb, pid=3316, tid=2400 # # Java VM: Java HotSpot(TM) Client VM (1.6.0_01-b06 mixed mode, sharing) # Problematic frame: # C [rxtxSerial.dll+0x34fb] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # --------------- T H R E A D --------------- Current thread (0x00386400): JavaThread "main" [_thread_in_native, id=2400] siginfo: ExceptionCode=0xc0000005, reading address 0x20726f78 Registers: EAX=0x20726f20, EBX=0x6d8922c0, ECX=0x00000005, EDX=0x20726f20 ESP=0x003efa30, EBP=0x003efb68, ESI=0x269728a0, EDI=0x00386400 EIP=0x100034fb, EFLAGS=0x00010212 Top of Stack: (sp=0x003efa30) 0x003efa30: 003efa3c 003efa64 0000000f ffffffff 0x003efa40: 003efa40 2a97f808 003efa6c 2b190ca8 0x003efa50: 00000000 2b190ec0 003efa90 008e2dd7 0x003efa60: 003efa90 008e2dd7 26977f88 6d815e72 0x003efa70: 00000004 2696eae0 0000008a 003efb0c 0x003efa80: 6d852b4a 2696eae0 00000003 26970930 0x003efa90: 000000cb 2696eae0 6d86b264 00385d40 0x003efaa0: 0000003f 003efb0c 26977f90 2ace65d8 Instructions: (pc=0x100034fb) 0x100034eb: ff ff 8d 76 00 eb 02 89 f6 90 8b 45 f8 8b 55 f8 0x100034fb: 8b 4a 58 83 c9 04 89 48 58 83 c4 f8 8b 45 f8 8b Stack: [0x003a0000,0x003f0000), sp=0x003efa30, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x34fb] Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j gnu.io.RXTXPort.writeArray([BIIZ)V+0 j gnu.io.RXTXPort$SerialOutputStream.write([B)V+76 j com.bjt.media.server.CommLink.send(Ljava/lang/String;)V+48 j com.bjt.media.server.DigitoolConnection.select(I)V+73 j com.bjt.media.server.DigitoolConnection.main([Ljava/lang/String;)V+74 v ~StubRoutines::call_stub --------------- P R O C E S S --------------- Java Threads: ( => current thread ) 0x02a69400 JavaThread "Thread-0" [_thread_in_native, id=3052] 0x02a4d000 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=3920] 0x02a48400 JavaThread "CompilerThread0" daemon [_thread_blocked, id=1968] 0x02a47400 JavaThread "Attach Listener" daemon [_thread_blocked, id=2984] 0x02a46400 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=2660] 0x02a41c00 JavaThread "Finalizer" daemon [_thread_blocked, id=3924] 0x02a3d800 JavaThread "Reference Handler" daemon [_thread_blocked, id=4008] =>0x00386400 JavaThread "main" [_thread_in_native, id=2400] Other Threads: 0x02a34400 VMThread [id=3708] 0x02a4e800 WatcherThread [id=3964] VM state:not at safepoint (normal execution) VM Mutex/Monitor currently owned by a thread: None Heap def new generation total 960K, used 131K [0x22960000, 0x22a60000, 0x22e40000) eden space 896K, 7% used [0x22960000, 0x22970ea8, 0x22a40000) from space 64K, 99% used [0x22a50000, 0x22a5fff8, 0x22a60000) to space 64K, 0% used [0x22a40000, 0x22a40000, 0x22a50000) tenured generation total 4096K, used 76K [0x22e40000, 0x23240000, 0x26960000) the space 4096K, 1% used [0x22e40000, 0x22e53060, 0x22e53200, 0x23240000) compacting perm gen total 12288K, used 137K [0x26960000, 0x27560000, 0x2a960000) the space 12288K, 1% used [0x26960000, 0x26982518, 0x26982600, 0x27560000) ro space 8192K, 62% used [0x2a960000, 0x2ae5e4e8, 0x2ae5e600, 0x2b160000) rw space 12288K, 52% used [0x2b160000, 0x2b7a0e78, 0x2b7a1000, 0x2bd60000) Dynamic libraries: 0x00400000 - 0x00423000 C:\Program Files\Java\jre1.6.0_01\bin\javaw.exe 0x7c900000 - 0x7c9b0000 C:\WINDOWS\system32\ntdll.dll 0x7c800000 - 0x7c8f4000 C:\WINDOWS\system32\kernel32.dll 0x77dd0000 - 0x77e6b000 C:\WINDOWS\system32\ADVAPI32.dll 0x77e70000 - 0x77f01000 C:\WINDOWS\system32\RPCRT4.dll 0x7e410000 - 0x7e4a0000 C:\WINDOWS\system32\USER32.dll 0x77f10000 - 0x77f57000 C:\WINDOWS\system32\GDI32.dll 0x76390000 - 0x763ad000 C:\WINDOWS\system32\IMM32.DLL 0x7c340000 - 0x7c396000 C:\Program Files\Java\jre1.6.0_01\bin\msvcr71.dll 0x6d7c0000 - 0x6da07000 C:\Program Files\Java\jre1.6.0_01\bin\client\jvm.dll 0x76b40000 - 0x76b6d000 C:\WINDOWS\system32\WINMM.dll 0x5cd70000 - 0x5cd77000 C:\WINDOWS\system32\serwvdrv.dll 0x5b0a0000 - 0x5b0a7000 C:\WINDOWS\system32\umdmxfrm.dll 0x6d310000 - 0x6d318000 C:\Program Files\Java\jre1.6.0_01\bin\hpi.dll 0x76bf0000 - 0x76bfb000 C:\WINDOWS\system32\PSAPI.DLL 0x6d770000 - 0x6d77c000 C:\Program Files\Java\jre1.6.0_01\bin\verify.dll 0x6d3b0000 - 0x6d3cf000 C:\Program Files\Java\jre1.6.0_01\bin\java.dll 0x6d7b0000 - 0x6d7bf000 C:\Program Files\Java\jre1.6.0_01\bin\zip.dll 0x10000000 - 0x10012000 C:\Documents and Settings\Alex\workspace\MediaServer\rxtxSerial.dll 0x73d90000 - 0x73db7000 C:\WINDOWS\system32\crtdll.dll VM Arguments: jvm_args: -Djava.library.path=C:\Documents and Settings\Alex\workspace\MediaServer java_command: com.bjt.media.server.DigitoolConnection Launcher Type: SUN_STANDARD Environment Variables: CLASSPATH=.;C:\Program Files\Java\j2re1.4.2_07\lib\ext\QTJava.zip PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\wbem;c:\applications\php;C:\Program Files\MATLAB\R2006a\bin\win32;C:\Roger\Projects\UAV\Bin\Debug;C:\Program Files\Microsoft SQL Server\80\Tools\Binn\;c:\Program Files\Microsoft SQL Server\90\Tools\binn\;C:\Program Files\QuickTime\QTSystem\;C:\Pfps\system;C:\Program Files\Java\jdk1.6.0_01\bin;C:\Program Files\Java\jdk1.6.0_01\jre\bin USERNAME=Alex OS=Windows_NT PROCESSOR_IDENTIFIER=x86 Family 15 Model 4 Stepping 1, GenuineIntel --------------- S Y S T E M --------------- OS: Windows XP Build 2600 Service Pack 2 CPU:total 1 family 15, cmov, cx8, fxsr, mmx, sse, sse2 Memory: 4k page, physical 1046508k(275288k free), swap 2522816k(1909176k free) vm_info: Java HotSpot(TM) Client VM (1.6.0_01-b06) for windows-x86, built on Mar 14 2007 00:24:02 by "java_re" with unknown MS VC++:1310 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070604/c87ae1f0/attachment-0008.html From alwyn.schoeman at gmail.com Tue Jun 5 00:10:19 2007 From: alwyn.schoeman at gmail.com (Alwyn Schoeman) Date: Tue, 5 Jun 2007 08:10:19 +0200 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Hi, I'm using a similar modem. By default rxtx doesn't look for devices that start with ACM, so you need to modify the source code and recompile. Look in RXTXCommDriver and add values for ACM in the registerScannedPorts method in the Linux specific parts. Look for osName.equals("Linux")... On 6/4/07, soop soop wrote: > > Hi Guys, > > Looked through the archives but still cannot figure this out. I have a > Motorola G24 GPRS/GSM modem that I am connecting to my server running > Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not > detecting the port, CommPortIdentifier.getPortIdentifiers(). > > I have added the line to RXTXCommDriver: > > "ttyACM" // for USB Modems > > Rxtx still does not seem to find the port. Is there something I am missing > to make this port visable? > > [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver > [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device > [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control > Model > driver for USB modems and ISDN adapters > > I really need your help as I have moved my server from windows to Linux > and > have been down for a few days because of this .. Thanks so much! > > _________________________________________________________________ > PC Magazine's 2007 editors' choice for best Web mail?award-winning Windows > Live Hotmail. > > http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -- Alwyn Schoeman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/b6cb3053/attachment-0008.html From naranjo.manuel at gmail.com Tue Jun 5 06:48:45 2007 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Tue, 05 Jun 2007 09:48:45 -0300 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> References: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Message-ID: <46655BAD.7010501@gmail.com> That's right, an easier solution is creating symlinks to acm. For example make ttyS70 to 79 point to ACM0 to 9 and that will help you a lot, and doesn't even require compile. > Hi, > > I'm using a similar modem. By default rxtx doesn't look for devices > that start with ACM, so you need to modify the > source code and recompile. > > Look in RXTXCommDriver and add values for ACM in the > registerScannedPorts method in the Linux specific parts. Look for > osName.equals("Linux")... > From juanemc2 at gmail.com Tue Jun 5 07:02:43 2007 From: juanemc2 at gmail.com (Juan) Date: Tue, 5 Jun 2007 10:02:43 -0300 Subject: [Rxtx] Problems with Epson TMU220B POSPrinter using XON/XOFF Flow Control and rxtx jar and dll's with the serial port. Message-ID: Hi!, I?m having trouble printing to the serial port using the latest version of rxtx jar and dll's with an Epson POSPrinter. I`ve switched the printer to work with XON/XOFF Flow Control and have watched the serial port to be sure the printer is sending the XON XOFF stop and go characters. I`ve setted the port like this: CommPortIdentifier commPortIdentifier = CommPortIdentifier.* getPortIdentifier*(_portName); SerialPort serialPort = (SerialPort)commPortIdentifier.open(*this*.getClass().getName(), 2000); serialPort.setSerialPortParams(_baudRate, _dataBits, _stopBits, _parity); serialPort.setFlowControlMode( SerialPort.*FLOWCONTROL_XONXOFF_IN* | SerialPort.*FLOWCONTROL_XONXOFF_OUT*); where the baudRate is 9600 the dataBits is 8 the stopBits is 1 and the parity is 0 It seems as the library isn`t taking into account the XON XOFF setting. I would like to know if I`m setting correctly the Flow Control and if you had had any experiences using XON XOFF flow control and could give me some help to solve my problem. I`m very thankful in advance, Yours, Juan Polero -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/b080995a/attachment-0008.html From ehdez.correo at gmail.com Tue Jun 5 07:12:53 2007 From: ehdez.correo at gmail.com (=?ISO-8859-1?Q?Enrique_Hern=E1ndez?=) Date: Tue, 5 Jun 2007 09:12:53 -0400 Subject: [Rxtx] problem with rxtx Message-ID: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Hello: I doing a simple test to show the serial ports. This is the code: import java.util.Enumeration; import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; public class Show { private Enumeration portList; private CommPortIdentifier portId; private SerialPort port; /** Creates a new instance of Show */ public Show() { } public static void main(String args[]){ Show show = new Show(); show.portList = CommPortIdentifier.getPortIdentifiers(); String tPort = ""; System.out.println("========================================="); while(show.portList.hasMoreElements()){ show.portId = (CommPortIdentifier)show.portList.nextElement(); if(show.portId.getPortType() == CommPortIdentifier.PORT_SERIAL) tPort = "Serial"; else tPort = "Parallel"; System.out.println(show.portId.getName() + " " + tPort); } } } whit The problem is that this code not show the serial ports, this show the no use serial ports. I want to connect whit the modem but when windows open and connect the modem my application don't see the port(COMM3) when it is connect. what I can do? Is that the correct way to know the ports? thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/eedd744b/attachment-0008.html From ehdez.correo at gmail.com Tue Jun 5 07:42:13 2007 From: ehdez.correo at gmail.com (=?ISO-8859-1?Q?Enrique_Hern=E1ndez?=) Date: Tue, 5 Jun 2007 09:42:13 -0400 Subject: [Rxtx] serial port Message-ID: <4a814e1f0706050642p4ce9ac7bka80f9479c524c5ea@mail.gmail.com> Hello: How I can ask to the port what device is connect and information about this device. thanks. bye. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/4d10d26a/attachment-0008.html From supsoop at hotmail.com Tue Jun 5 09:29:00 2007 From: supsoop at hotmail.com (soop soop) Date: Tue, 05 Jun 2007 15:29:00 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Message-ID: Hi Guys, Thanks for all your help. I found the problem. I created a user, Tomcat55, for my tomcat but it did not belong to any group. I then added this user to dialout group to have access to the device ttyACM0. Works perfectly! Again permissions was the issue. This also seems to be persistent as a server reboot does not effect the access. Cheers! >From: "Alwyn Schoeman" >Reply-To: RXTX Developers and Users >To: "RXTX Developers and Users" >Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >Date: Tue, 5 Jun 2007 08:10:19 +0200 > >Hi, > >I'm using a similar modem. By default rxtx doesn't look for devices that >start with ACM, so you need to modify the >source code and recompile. > >Look in RXTXCommDriver and add values for ACM in the registerScannedPorts >method in the Linux specific parts. Look for osName.equals("Linux")... > >On 6/4/07, soop soop wrote: >> >>Hi Guys, >> >>Looked through the archives but still cannot figure this out. I have a >>Motorola G24 GPRS/GSM modem that I am connecting to my server running >>Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not >>detecting the port, CommPortIdentifier.getPortIdentifiers(). >> >>I have added the line to RXTXCommDriver: >> >>"ttyACM" // for USB Modems >> >>Rxtx still does not seem to find the port. Is there something I am missing >>to make this port visable? >> >>[ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver >>[ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device >>[ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control >>Model >>driver for USB modems and ISDN adapters >> >>I really need your help as I have moved my server from windows to Linux >>and >>have been down for a few days because of this .. Thanks so much! >> >>_________________________________________________________________ >>PC Magazine's 2007 editors' choice for best Web mail—award-winning Windows >>Live Hotmail. >> >>http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 >> >> >>_______________________________________________ >>Rxtx mailing list >>Rxtx at qbang.org >>http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > >-- >Alwyn Schoeman >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ Need a break? Find your escape route with Live Search Maps. http://maps.live.com/default.aspx?ss=Restaurants~Hotels~Amusement%20Park&cp=33.832922~-117.915659&style=r&lvl=13&tilt=-90&dir=0&alt=-1000&scene=1118863&encType=1&FORM=MGAC01 From netbeans at gatworks.com Tue Jun 5 09:42:31 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 11:42:31 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <46658467.20101@gatworks.com> soop soop wrote: > > Hi Guys, > > Thanks for all your help. I found the problem. I created a user, > Tomcat55, for my tomcat but it did not belong to any group. I then added Look at man pages for the program udev. From tjarvi at qbang.org Tue Jun 5 18:18:17 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Jun 2007 18:18:17 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Message-ID: On Tue, 5 Jun 2007, Enrique Hern?ndez wrote: > The problem is that this code not show the serial ports, this show the no > use serial ports. I want to connect whit the modem but when windows open and > connect the modem my application don't see the port(COMM3) when it is > connect. > what I can do? > Is that the correct way to know the ports? > Hello, We may have problems understanding each other. On windows, the port will not be an available serial port if another application has the port open. That is just how the library behaves. If you can not see the port in the enumerated list, you could not open it. Also note that enumeration only happens once. If you add a port such as a new USB dongle, the port will not be visible until the next time your application runs. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Tue Jun 5 18:45:01 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 20:45:01 -0400 Subject: [Rxtx] problem with rxtx In-Reply-To: References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Message-ID: <4666038D.8090700@gatworks.com> Trent Jarvi wrote: > > > Also note that enumeration only happens once. If you add a port such as > a new USB dongle, the port will not be visible until the next time your > application runs. Is this written in stone ? somewhere? From tjarvi at qbang.org Tue Jun 5 18:54:36 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Jun 2007 18:54:36 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <4666038D.8090700@gatworks.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> Message-ID: On Tue, 5 Jun 2007, Uncle George wrote: > Trent Jarvi wrote: >> >> >> Also note that enumeration only happens once. If you add a port such as >> a new USB dongle, the port will not be visible until the next time your >> application runs. > > Is this written in stone ? somewhere? It is just the current behavior. There is nothing preventing a fix that allows reenumeration. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Tue Jun 5 19:55:19 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 21:55:19 -0400 Subject: [Rxtx] problem with rxtx In-Reply-To: References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> Message-ID: <46661407.4020308@gatworks.com> >> Is this written in stone ? somewhere? > > It is just the current behavior. There is nothing preventing a fix that > allows reenumeration. With usb, ..... , things come and go. Seems a shame that you have to kill application to get at the device u just plugged in. From joachim at buechse.ch Wed Jun 6 01:50:06 2007 From: joachim at buechse.ch (Joachim Buechse) Date: Wed, 6 Jun 2007 09:50:06 +0200 Subject: [Rxtx] problem with rxtx In-Reply-To: <46661407.4020308@gatworks.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> <46661407.4020308@gatworks.com> Message-ID: <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> On MacOS RXTX's enumeration handling is more flexible. It will find new ports that are added during the lifetime of the application. But this is inherently incompatible with suns javax.comm implementation... Regards, Joachim On 06.06.2007, at 03:55, Uncle George wrote: > >>> Is this written in stone ? somewhere? >> >> It is just the current behavior. There is nothing preventing a >> fix that >> allows reenumeration. > > With usb, ..... , things come and go. Seems a shame that you have to > kill application to get at the device u just plugged in. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Jun 6 06:06:48 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Jun 2007 06:06:48 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> <46661407.4020308@gatworks.com> <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> Message-ID: Sun's javax.comm is not a major concern going forward. As long as we do not break old applications using rxtx, I see no reason to limit rxtx to that convention. We have already rejected version 3 from Sun as a dead end and limited our compatability to version 2. That does not mean we will not try to work with Sun and others but the current javax.comm convention (v3) is not a well conceived path. There has been discussion about doing a JSR which is one valid option. On Wed, 6 Jun 2007, Joachim Buechse wrote: > On MacOS RXTX's enumeration handling is more flexible. It will find > new ports that are added during the lifetime of the application. But > this is inherently incompatible with suns javax.comm implementation... > > Regards, > Joachim > > On 06.06.2007, at 03:55, Uncle George wrote: > >> >>>> Is this written in stone ? somewhere? >>> >>> It is just the current behavior. There is nothing preventing a >>> fix that >>> allows reenumeration. >> >> With usb, ..... , things come and go. Seems a shame that you have to >> kill application to get at the device u just plugged in. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From yvespielusenet at free.fr Wed Jun 6 08:46:35 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 16:46:35 +0200 Subject: [Rxtx] [PARALLEL] resource in use Message-ID: <1181141195.3407.20.camel@localhost.localdomain> Hello, I want to use rxtx in my application. I haveto send data to a very old printer (which have a drum and hammers http://perso.orange.fr/tiie/page00010017.html) This is printer is connecter with centronics. It works well but, while it's writting and I putthe printer off-line, after about 45 seconds, I have this error : ------------------------------------- java.io.IOException: La ressource demand?e est en cours d'utilisation. in writeArray at gnu.io.LPRPort.writeArray(Native Method) at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:292) at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:161) at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:156) at mce.buffer.bufferManager.BufferManager$PrintBuffer.run(BufferManager.java:141) The IOexception means "The wanted resource is in use" ------------------------------------- Here is the line 141 of BufferManager : ------------------------------------- while(send){ try{ fos.write(bb); <=== line 141 send = false; } catch(Exception e){ javax.swing.JOptionPane.showMessageDialog(null, "Erreur d'envoie. Veuillez cliquer sur OK pour relancer l'impression de la vignette.\nV?rifiez votre impression !", "Erreur d'envoie", javax.swing.JOptionPane.WARNING_MESSAGE); e.printStackTrace(System.err); System.err.flush(); System.out.println(e); send = true; } } -------------------------------- 'fos' is an outputstream which contains the rxtx stream (this.os is the rxtx outputstream) : -------------------------------- public void write(byte[] bb) throws IOException{ this.write(bb, 0, bb.length); } public void write(byte[] bb, int off, int len) throws IOException{ while(!imp1.isPrinterSelected() || !imp2.isPrinterSelected()){ } this.os.write(bb, off, len); } -------------------------------- Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( can you help me ? thank you :) -- yves piel From yvespielusenet at free.fr Wed Jun 6 09:11:15 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 17:11:15 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181141195.3407.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> Message-ID: <1181142675.3407.23.camel@localhost.localdomain> I forgot to tell that It's under windows XP and java 1.5. Le mercredi 06 juin 2007 ? 16:46 +0200, yves pielusenet a ?crit : > Hello, > I want to use rxtx in my application. I haveto send data to a very old > printer (which have a drum and hammers > http://perso.orange.fr/tiie/page00010017.html) > This is printer is connecter with centronics. It works well but, while > it's writting and I putthe printer off-line, after about 45 seconds, I > have this error : > ------------------------------------- > java.io.IOException: La ressource demand?e est en cours d'utilisation. > in writeArray > at gnu.io.LPRPort.writeArray(Native Method) > at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:292) > at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:161) > at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:156) > at mce.buffer.bufferManager.BufferManager$PrintBuffer.run(BufferManager.java:141) > > The IOexception means "The wanted resource is in use" > ------------------------------------- > > Here is the line 141 of BufferManager : > > ------------------------------------- > while(send){ > try{ > fos.write(bb); <=== line 141 > send = false; > } > catch(Exception e){ > javax.swing.JOptionPane.showMessageDialog(null, "Erreur d'envoie. Veuillez cliquer sur OK pour relancer l'impression de la vignette.\nV?rifiez votre impression !", "Erreur d'envoie", javax.swing.JOptionPane.WARNING_MESSAGE); > e.printStackTrace(System.err); > System.err.flush(); > System.out.println(e); > send = true; > } > } > -------------------------------- > 'fos' is an outputstream which contains the rxtx stream (this.os is the rxtx outputstream) : > > -------------------------------- > public void write(byte[] bb) throws IOException{ > this.write(bb, 0, bb.length); > } > public void write(byte[] bb, int off, int len) throws IOException{ > while(!imp1.isPrinterSelected() || !imp2.isPrinterSelected()){ > } > this.os.write(bb, off, len); > } > -------------------------------- > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > can you help me ? > > thank you :) > From netbeans at gatworks.com Wed Jun 6 09:21:46 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 11:21:46 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181141195.3407.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> Message-ID: <4666D10A.8000507@gatworks.com> } > -------------------------------- > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > can you help me ? > > thank you :) > windoz or linux? ( I guess windoz ) for windoz, there appears to be a timeout ( as Comments suggest ) of about 40seconds. > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } for linux, there is no implied timeout. > if( write( fd, bytes, count ) < 0 ) > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); From netbeans at gatworks.com Wed Jun 6 09:39:41 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 11:39:41 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666D10A.8000507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> Message-ID: <4666D53D.90000@gatworks.com> Uncle George wrote: > } >> -------------------------------- >> >> Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( >> >> can you help me ? From reading the code, I can see your concern. And it appears you are correct, because some of the data will be sent to the OS printer buffers, and then it will refuse to accept anymore. Unfortunately, writeArray does not return the num of characters written :{ So application has no idea to how many characters were accepted by the OS. I dont do windoz, so I cant say with absolute certainty what windoz will do with an off-line condition. If you have the source, and can compile, then maybe u can increase the loop count to hit 4hours? From yvespielusenet at free.fr Wed Jun 6 09:53:25 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 17:53:25 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666D10A.8000507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> Message-ID: <1181145205.3407.35.camel@localhost.localdomain> Thank you for your explanation :) This timeout comes when no data has been send to the printer after 40seconds if I well understand. But why there is such a timeout ? If I setthe printer offline while it's printing I mustn't have an exception. I don't understand why the "printer should solv all problems like buffer full" in 40 seconds. If I pause the printer the buffer will not be emptied, isn't it ? I not very familiar with C/C++, but it seem that the exception is thrown only when countWritten == 0, that means no data at all has been sent. So Is my code is good since when I intercept this exception I send all my buffer again. There is no way that the printer receive two times same bytes ? thanks ps: yes the application is running on windows XP since I developpe under Debian Le mercredi 06 juin 2007 ? 11:21 -0400, Uncle George a ?crit : > } > > -------------------------------- > > > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > > > can you help me ? > > > > thank you :) > > > > windoz or linux? ( I guess windoz ) > > for windoz, there appears to be a timeout ( as Comments suggest ) of > about 40seconds. > > while( count > 0 ){ > > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > > /* > > this are 20 * 2 seconds, in this time a printer (or other parallel device) > > should solv all problems like buffer full, etc > > */ > > if(errorCount++ < 20){ > > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > > continue; > > } > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > for linux, there is no implied timeout. > > if( write( fd, bytes, count ) < 0 ) > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Wed Jun 6 10:34:24 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 12:34:24 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181145205.3407.35.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> Message-ID: <4666E210.30507@gatworks.com> yves pielusenet wrote: > Thank you for your explanation :) > This timeout comes when no data has been send to the printer after > 40seconds if I well understand. But why there is such a timeout ? If I > setthe printer offline while it's printing I mustn't have an exception. > I don't understand why the "printer should solv all problems like buffer > full" in 40 seconds. If I pause the printer the buffer will not be > emptied, isn't it ? > > I not very familiar with C/C++, but it seem that the exception is thrown > only when countWritten == 0, that means no data at all has been sent. So > Is my code is good since when I intercept this exception I send all my > buffer again. There is no way that the printer receive two times same > bytes ? More technically, the function call returns and reports that 0 characters was written in this call. when 0 characters are written, it will check how many times 0 characters was written. If it has tried LESS than 20 times(errorCount), it will sleep() and try to write again. After 20 times, it wont sleep, but throw you the exception. Now suppose you are writing a 120 character line. you off-lined/paused your printer. The OS has room for 80 more characters in it's printer buffer. The WriteFile() will have a char count of 120, but on return the countWritten = 80. You still have 40 more characters to print. Since countWritten != 0, the counters: bytes += countWritten; count -= countWritten; get updated, and the Writefile now has a count of 40 characters. Since the printer is off-line, the countwritten is 0. And so the loop continues, till 40 seconds is up. As to why it is this way, i dont know ( not a windoz maven ); Also the sleep(20) in the loop is not so intuitive to suggest 2 seconds of sleep. I would have guessed 20seconds, or 20milliseconds. But go figure. BTW: Since your computer sends you error messages in French, does it curse in English? :)))) From yvespielusenet at free.fr Thu Jun 7 02:27:44 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Thu, 07 Jun 2007 10:27:44 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666E210.30507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> Message-ID: <1181204864.3501.10.camel@localhost.localdomain> Maybe in my case I should re-compile rxtx and change the code. Instead of send an exception I should display a dialog box to ask if it's printer problem or if it should trie to send bytes. Something like : while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } if(displayDialogBox("Try again to send datas ??")){ errorCount = 0; } else{ throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } } Le mercredi 06 juin 2007 ? 12:34 -0400, Uncle George a ?crit : > yves pielusenet wrote: > > Thank you for your explanation :) > > This timeout comes when no data has been send to the printer after > > 40seconds if I well understand. But why there is such a timeout ? If I > > setthe printer offline while it's printing I mustn't have an exception. > > I don't understand why the "printer should solv all problems like buffer > > full" in 40 seconds. If I pause the printer the buffer will not be > > emptied, isn't it ? > > > > I not very familiar with C/C++, but it seem that the exception is thrown > > only when countWritten == 0, that means no data at all has been sent. So > > Is my code is good since when I intercept this exception I send all my > > buffer again. There is no way that the printer receive two times same > > bytes ? > More technically, the function call returns and reports that 0 > characters was written in this call. > when 0 characters are written, it will check how many times 0 characters > was written. If it has tried LESS than 20 times(errorCount), it will > sleep() and try to write again. > After 20 times, it wont sleep, but throw you the exception. > > Now suppose you are writing a 120 character line. you off-lined/paused > your printer. The OS has room for 80 more characters in it's printer > buffer. The WriteFile() will have a char count of 120, but on return the > countWritten = 80. You still have 40 more characters to print. > Since countWritten != 0, the counters: > bytes += countWritten; > count -= countWritten; > get updated, and the Writefile now has a count of 40 characters. Since > the printer is off-line, the countwritten is 0. And so the loop > continues, till 40 seconds is up. > > As to why it is this way, i dont know ( not a windoz maven ); > Also the sleep(20) in the loop is not so intuitive to suggest 2 seconds > of sleep. I would have guessed 20seconds, or 20milliseconds. But go figure. > > BTW: Since your computer sends you error messages in French, does it > curse in English? :)))) > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 06:11:43 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 08:11:43 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181204864.3501.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> Message-ID: <4667F5FF.8070903@gatworks.com> your suggestion appears good. I dont know what displayDialogBox exactly will do, so all I can say it that it looks good. But I'd like to wait 10min before first dialog box And a 5 min wait for every dialog box there after. And since these are custom solution/choices, maybe a more exact explanation of what the issue is. if(errorCount++ < 300){ // wait 10min ( 10min * 60sec / 2 ) Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } if(displayDialogBox("Printer has Paused. Retry sending data?")){ errorCount = 150; // Wait for 5 min thereafter continue; } > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } yves pielusenet wrote: > Maybe in my case I should re-compile rxtx and change the code. Instead > of send an exception I should display a dialog box to ask if it's > printer problem or if it should trie to send bytes. Something like : > > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > > if(displayDialogBox("Try again to send datas ??")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > } > From yvespielusenet at free.fr Thu Jun 7 07:17:21 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Thu, 07 Jun 2007 15:17:21 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4667F5FF.8070903@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <4667F5FF.8070903@gatworks.com> Message-ID: <1181222241.3501.20.camel@localhost.localdomain> thank you :) 'displayDialogBox()' I think doesn't exist. It was just for the example :) But I think It should not be so complicated to display a dialog box under windows with YES/NO buttons. When yes is clicked it return 0 other it returns 1. Le jeudi 07 juin 2007 ? 08:11 -0400, Uncle George a ?crit : > your suggestion appears good. I dont know what displayDialogBox exactly > will do, so all I can say it that it looks good. > > But I'd like to wait 10min before first dialog box And a 5 min wait for > every dialog box there after. And since these are custom > solution/choices, maybe a more exact explanation of what the issue is. > > if(errorCount++ < 300){ // wait 10min ( 10min * 60sec / 2 ) > Sleep( 20 ); /* make a small pause to execute all other requests > in all other threads */ > continue; > } > > if(displayDialogBox("Printer has Paused. Retry sending data?")){ > errorCount = 150; // Wait for 5 min thereafter > continue; > } > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > > yves pielusenet wrote: > > Maybe in my case I should re-compile rxtx and change the code. Instead > > of send an exception I should display a dialog box to ask if it's > > printer problem or if it should trie to send bytes. Something like : > > > > while( count > 0 ){ > > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > > /* > > this are 20 * 2 seconds, in this time a printer (or other parallel device) > > should solv all problems like buffer full, etc > > */ > > if(errorCount++ < 20){ > > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > > continue; > > } > > > > if(displayDialogBox("Try again to send datas ??")){ > > errorCount = 0; > > } > > else{ > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > } > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 07:41:43 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 09:41:43 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181222241.3501.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <4667F5FF.8070903@gatworks.com> <1181222241.3501.20.camel@localhost.localdomain> Message-ID: <46680B17.8050109@gatworks.com> yves pielusenet wrote: > thank you :) > 'displayDialogBox()' I think doesn't exist. It was just for the > example :) too bad. Good luck. From rtrout at webbresearch.com Thu Jun 7 11:23:04 2007 From: rtrout at webbresearch.com (Robert Trout) Date: Thu, 07 Jun 2007 13:23:04 -0400 Subject: [Rxtx] Disconnected PortServer TS causes Java to hang Message-ID: <1181236984.14186.33.camel@sisyphus.DinkumSoftware.com> I'm running Linux with sun's Java 1.4.2, Java comm API 2.0, RXTX 2.0-7pre1, and the RealPort digi driver. "/dev/ttyrp00" is a RealPort device. My Java application never returns from a ComPortIdentifier.getPortIdentifier("/dev/ttyrp00") call while the Digi PortServer TS 4 is disconnected from the network. If I later re-connect the PortServer, the call returns about 30 seconds later (it's like a serial port read or write is blocking until the PortServer is re- connected). With the PortServer disconnected, minicom immediately responds with "cannot open /dev/ttyrp00: No such file or directory". I would like my Java application to behave similarly. That is, respond with an error condition instead of hanging when the PortServer is not connected. Since minicom and Java behave differently, I think this "hanging" behavior may be due to RXTX or Java? Has anyone had a similar issue? Solutions? Suggestions? Thanks, Robert From vicnevicne at gmail.com Thu Jun 7 12:16:02 2007 From: vicnevicne at gmail.com (Vicne) Date: Thu, 07 Jun 2007 20:16:02 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181204864.3501.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> Message-ID: <46684B62.7080802@gmail.com> yves pielusenet wrote: > Maybe in my case I should re-compile rxtx and change the code. Instead > of send an exception I should display a dialog box to ask if it's > printer problem or if it should trie to send bytes. Something like : > > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > > if(displayDialogBox("Try again to send datas ??")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > } > Sorry to step in without a specific solution to your problem, but I wanted to share my feeling regarding this proposal. AFAIK, it's generally considered bad practice to pop-up a prompt from a library. The main reason is that in general use, you can't guarantee that someone is actually present behind the console. Imagine a print server in a machine room, connected to a park of printers. In that case, when one printer fails, the logical behaviour would be to use an other one. If you change RxTx the way you propose, the printer queue will simply be stuck with a useless "Try again to send data ?" prompt until an administrator opens a remote connection to the print server's console and clicks "no". Second, it would create a dependency upon the existence of a graphical console (if you go the graphical "dialogBox" way). On many applications (typically server or embedded ones), the JVM is "headless" and if you try to pop-up a dialog, your app would throw an exception (at best) or just wouldn't display the prompt anywhere... Going the "text console" way is not more reliable, because on graphical environments, the text console is hidden unless explicitly requested. My advice would be to think again and find another solution. Ideas are : - make the number of retries a parameter so that you can tune it to what you think is reasonable - throw a more specific exception when the number of retries has been reached, so that a specific prompt can be shown at a higher level Anyway, if you feel that the prompt is the way to go in your case, I would at least make that prompt conditional. The least intrusive way would probably be using a system property, like if("true".equals(System.getProperty("org.rxtx.usePrompt")) && displayDialogBox("Retry sending data ?")){ errorCount = 0; } else{ throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } By default, the behaviour would remain as it is now, but you could force the prompts by defining the property at VM launch if desired. (for example : java.exe -Dorg.rxtx.usePrompt=true myApp) Also, you seemed to say you wanted the printer to start again exactly where is stopped. It would indeed be the best way when the printer is put offline for a few seconds. On the other hand, if the printer is turned off (or the printer runs out of paper, or someone steps on the mains cable), then the only way to go back to a "stable" situation would be by printing the item (page, label, etc.) again from scratch... Just my two cents. Vicne PS : By the way, the dialog box thing is very platform dependant on the C-side, and I think the simplest way would probably be to bridge it to a Java call where you can implement it like you proposed : public boolean displayDialogBox(prompt) { return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); } From netbeans at gatworks.com Thu Jun 7 14:08:24 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 16:08:24 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46684B62.7080802@gmail.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> Message-ID: <466865B8.4060004@gatworks.com> My feeling is that the code that was suggested was for his environs ( his shop ). The issue here is that after a 40+ second wait, an exception will be thrown. But you really dont have a way of 'cancelling' all the WriteFiles() that have already occured before the exception so that your writeArray and the Commapi can backtrack to a position in which they are in sync. The main ( really mine ) concern is not to lose data, or replicate data. After 40seconds, 300 seconds, 55min, no matter how long, data should not be lost or duplicated. But as soon as the exception is thrown, that possibility exists. Maybe an event should be thrown instead? Vicne wrote: > yves pielusenet wrote: >> Maybe in my case I should re-compile rxtx and change the code. Instead >> of send an exception I should display a dialog box to ask if it's >> printer problem or if it should trie to send bytes. Something like : >> >> while( count > 0 ){ >> if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ >> /* >> this are 20 * 2 seconds, in this time a printer (or other parallel device) >> should solv all problems like buffer full, etc >> */ >> if(errorCount++ < 20){ >> Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ >> continue; >> } >> >> if(displayDialogBox("Try again to send datas ??")){ >> errorCount = 0; >> } >> else{ >> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >> break; >> } >> } >> > > Sorry to step in without a specific solution to your problem, but I > wanted to share my feeling regarding this proposal. AFAIK, it's > generally considered bad practice to pop-up a prompt from a library. > The main reason is that in general use, you can't guarantee that > someone is actually present behind the console. Imagine a print server > in a machine room, connected to a park of printers. In that case, when > one printer fails, the logical behaviour would be to use an other one. > If you change RxTx the way you propose, the printer queue will simply be > stuck with a useless "Try again to send data ?" prompt until an > administrator opens a remote connection to the print server's console > and clicks "no". > Second, it would create a dependency upon the existence of a > graphical console (if you go the graphical "dialogBox" way). On many > applications (typically server or embedded ones), the JVM is "headless" > and if you try to pop-up a dialog, your app would throw an exception (at > best) or just wouldn't display the prompt anywhere... Going the "text > console" way is not more reliable, because on graphical environments, > the text console is hidden unless explicitly requested. > > My advice would be to think again and find another solution. Ideas are : > - make the number of retries a parameter so that you can tune it to what > you think is reasonable > - throw a more specific exception when the number of retries has been > reached, so that a specific prompt can be shown at a higher level > > Anyway, if you feel that the prompt is the way to go in your case, I > would at least make that prompt conditional. The least intrusive way > would probably be using a system property, like > > if("true".equals(System.getProperty("org.rxtx.usePrompt")) > && displayDialogBox("Retry sending data ?")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > > > By default, the behaviour would remain as it is now, but you could > force the prompts by defining the property at VM launch if desired. (for > example : java.exe -Dorg.rxtx.usePrompt=true myApp) > > > Also, you seemed to say you wanted the printer to start again > exactly where is stopped. It would indeed be the best way when the > printer is put offline for a few seconds. On the other hand, if the > printer is turned off (or the printer runs out of paper, or someone > steps on the mains cable), then the only way to go back to a "stable" > situation would be by printing the item (page, label, etc.) again from > scratch... > > > Just my two cents. > > > Vicne > > PS : By the way, the dialog box thing is very platform dependant on the > C-side, and I think the simplest way would probably be to bridge it to a > Java call where you can implement it like you proposed : > > public boolean displayDialogBox(prompt) { > return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", > JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); > } > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Thu Jun 7 17:48:11 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 Jun 2007 17:48:11 -0600 (MDT) Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <466865B8.4060004@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> Message-ID: An event is possible. I'm amazed this is the largest problem encountered while using the parallel code. How would the write ever exit if we throw events? Isn't this going to lead to hung applications? On Thu, 7 Jun 2007, Uncle George wrote: > My feeling is that the code that was suggested was for his environs ( > his shop ). > > The issue here is that after a 40+ second wait, an exception will be > thrown. But you really dont have a way of 'cancelling' all the > WriteFiles() that have already occured before the exception so that your > writeArray and the Commapi can backtrack to a position in which they are > in sync. > > The main ( really mine ) concern is not to lose data, or replicate data. > After 40seconds, 300 seconds, 55min, no matter how long, data should > not be lost or duplicated. But as soon as the exception is thrown, that > possibility exists. > > Maybe an event should be thrown instead? > > Vicne wrote: >> yves pielusenet wrote: >>> Maybe in my case I should re-compile rxtx and change the code. Instead >>> of send an exception I should display a dialog box to ask if it's >>> printer problem or if it should trie to send bytes. Something like : >>> >>> while( count > 0 ){ >>> if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ >>> /* >>> this are 20 * 2 seconds, in this time a printer (or other parallel device) >>> should solv all problems like buffer full, etc >>> */ >>> if(errorCount++ < 20){ >>> Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ >>> continue; >>> } >>> >>> if(displayDialogBox("Try again to send datas ??")){ >>> errorCount = 0; >>> } >>> else{ >>> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >>> break; >>> } >>> } >>> >> >> Sorry to step in without a specific solution to your problem, but I >> wanted to share my feeling regarding this proposal. AFAIK, it's >> generally considered bad practice to pop-up a prompt from a library. >> The main reason is that in general use, you can't guarantee that >> someone is actually present behind the console. Imagine a print server >> in a machine room, connected to a park of printers. In that case, when >> one printer fails, the logical behaviour would be to use an other one. >> If you change RxTx the way you propose, the printer queue will simply be >> stuck with a useless "Try again to send data ?" prompt until an >> administrator opens a remote connection to the print server's console >> and clicks "no". >> Second, it would create a dependency upon the existence of a >> graphical console (if you go the graphical "dialogBox" way). On many >> applications (typically server or embedded ones), the JVM is "headless" >> and if you try to pop-up a dialog, your app would throw an exception (at >> best) or just wouldn't display the prompt anywhere... Going the "text >> console" way is not more reliable, because on graphical environments, >> the text console is hidden unless explicitly requested. >> >> My advice would be to think again and find another solution. Ideas are : >> - make the number of retries a parameter so that you can tune it to what >> you think is reasonable >> - throw a more specific exception when the number of retries has been >> reached, so that a specific prompt can be shown at a higher level >> >> Anyway, if you feel that the prompt is the way to go in your case, I >> would at least make that prompt conditional. The least intrusive way >> would probably be using a system property, like >> >> if("true".equals(System.getProperty("org.rxtx.usePrompt")) >> && displayDialogBox("Retry sending data ?")){ >> errorCount = 0; >> } >> else{ >> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >> break; >> } >> >> >> By default, the behaviour would remain as it is now, but you could >> force the prompts by defining the property at VM launch if desired. (for >> example : java.exe -Dorg.rxtx.usePrompt=true myApp) >> >> >> Also, you seemed to say you wanted the printer to start again >> exactly where is stopped. It would indeed be the best way when the >> printer is put offline for a few seconds. On the other hand, if the >> printer is turned off (or the printer runs out of paper, or someone >> steps on the mains cable), then the only way to go back to a "stable" >> situation would be by printing the item (page, label, etc.) again from >> scratch... >> >> >> Just my two cents. >> >> >> Vicne >> >> PS : By the way, the dialog box thing is very platform dependant on the >> C-side, and I think the simplest way would probably be to bridge it to a >> Java call where you can implement it like you proposed : >> >> public boolean displayDialogBox(prompt) { >> return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", >> JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); >> } >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 19:18:51 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 21:18:51 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> Message-ID: <4668AE7B.3060409@gatworks.com> The UNIX version of writeArray is not too great either. It is possible that the write will only process some of the bytes. #else if( write( fd, bytes, count ) < 0 ) throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); #endif -------------------------------- Maybe it might be better to have the native function inform the caller of the # of characters written, then the commapi/output-buffer can be modified to reflect the #of chars written. If an exception is to be thrown, for too many loops of chars written == 0, then exception wont affect the state of the output buffer. Then a ParallelPort.restart() can be called to resume printing whats in the buffer. Trent Jarvi wrote: > An event is possible. I'm amazed this is the largest problem encountered > while using the parallel code. > > How would the write ever exit if we throw events? Isn't this going to > lead to hung applications? Sure. If you dont time out, then there is nothing that will force an EXIT from the write(). Issue is what has the OS done with the write. > > On Thu, 7 Jun 2007, Uncle George wrote: > >> My feeling is that the code that was suggested was for his environs ( >> his shop ). From yvespielusenet at free.fr Fri Jun 8 01:09:01 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Fri, 08 Jun 2007 09:09:01 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4668AE7B.3060409@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> Message-ID: <1181286541.3674.10.camel@localhost.localdomain> It is not possible that the rxtx java method write(byte[], int offset, int length) return anint which contains the number of byte really send to the printer instead of an exception ? So this is the programm which will see if all bytes have been sent. If not it can retry to send the unsended bytes. -------------------------------------------------------- int sended = 0; while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ sended += countWritten; /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } return sended; /*throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break;*/ } ... ... return countWritten; ------------------------------------------------ Le jeudi 07 juin 2007 ? 21:18 -0400, Uncle George a ?crit : > The UNIX version of writeArray is not too great either. It is possible > that the write will only process some of the bytes. > > #else > if( write( fd, bytes, count ) < 0 ) > throw_java_exception_system_msg( env, IO_EXCEPTION, > "writeArray" ); > #endif > -------------------------------- > > Maybe it might be better to have the native function inform the caller > of the # of characters written, then the commapi/output-buffer can be > modified to reflect the #of chars written. If an exception is to be > thrown, for too many loops of chars written == 0, then exception wont > affect the state of the output buffer. Then a ParallelPort.restart() can > be called to resume printing whats in the buffer. > > > Trent Jarvi wrote: > > An event is possible. I'm amazed this is the largest problem encountered > > while using the parallel code. > > > > How would the write ever exit if we throw events? Isn't this going to > > lead to hung applications? > Sure. If you dont time out, then there is nothing that will force an > EXIT from the write(). Issue is what has the OS done with the write. > > > > On Thu, 7 Jun 2007, Uncle George wrote: > > > >> My feeling is that the code that was suggested was for his environs ( > >> his shop ). > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Fri Jun 8 03:45:00 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 11:45:00 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181286541.3674.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> Message-ID: <20070608094500.GC21069@elberon.bln.de.ingenico.com> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > It is not possible that the rxtx java method write(byte[], int offset, > int length) return anint which contains the number of byte really send > to the printer instead of an exception ? > So this is the programm which will see if all bytes have been sent. If > not it can retry to send the unsended bytes. I think write() is void because in Java people love to do this since OutputStream :-) Of course on such interfaces you cannot implement something nice. If you would have a int write, you would not implement the interface and no applications expecting this interface would link/work/compile. oki, Steffen P.S.: (OT) If you propose not to implement the Java interfaces (especially not on JNI level), maybe optionally offering a wrapper that removes e.g. the write return value and so on to downgrade the powerful classic old POSIX read/write style to the modern limited Java style, then I agree :-) Same for read. Instead of things like "int avialable()" it is more powerful to have an approach as select(2) offers (to guarante the caller that read/write will not block [nothing else make sense anyway IMHO] but may read/write less bytes then requested). The caller gets full control and the higher level protocols can care about timeouts, invoking read in some loops and/or implement retransmission. On top of such an implementation, where everything is controlled, defined, guaranteed and reliable, someone could use an InputStream or OutputStream style interface. Or even better: don't use them at all :) just BTW :-) St. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From yvespielusenet at free.fr Fri Jun 8 05:52:45 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Fri, 08 Jun 2007 13:52:45 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <20070608094500.GC21069@elberon.bln.de.ingenico.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> Message-ID: <1181303565.11203.3.camel@localhost.localdomain> So maybe a better way should be to create a new Exception class which has a method "int getWrittenByte()". So the Exception should be use to send again bytes which are not printed yet. yves Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : > * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > > It is not possible that the rxtx java method write(byte[], int offset, > > int length) return anint which contains the number of byte really send > > to the printer instead of an exception ? > > So this is the programm which will see if all bytes have been sent. If > > not it can retry to send the unsended bytes. > > I think write() is void because in Java people love to do this > since OutputStream :-) Of course on such interfaces you cannot > implement something nice. If you would have a int write, you > would not implement the interface and no applications expecting > this interface would link/work/compile. > > oki, > > Steffen > > P.S.: (OT) > If you propose not to implement the Java interfaces (especially > not on JNI level), maybe optionally offering a wrapper that > removes e.g. the write return value and so on to downgrade the > powerful classic old POSIX read/write style to the modern limited > Java style, then I agree :-) Same for read. Instead of things > like "int avialable()" it is more powerful to have an approach as > select(2) offers (to guarante the caller that read/write will not > block [nothing else make sense anyway IMHO] but may read/write > less bytes then requested). The caller gets full control and the > higher level protocols can care about timeouts, invoking read in > some loops and/or implement retransmission. On top of such an > implementation, where everything is controlled, defined, > guaranteed and reliable, someone could use an InputStream or > OutputStream style interface. Or even better: don't use them at > all :) just BTW :-) > St. > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > 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. > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > 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. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Fri Jun 8 06:46:21 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 08:46:21 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181303565.11203.3.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> Message-ID: <46694F9D.5080501@gatworks.com> It seems that with outputstream.write(b[]), you become terribly uncoordinated as soon as an exception is thrown. Docs do not say what happens to the data. Yet from a practicable point of view, one would like to know if the write was accepted in-full, or rejected before any writes. There are no in betweens, as partial writes are not reportable. So for an outputstream.write(), in order for it to return, the full write request has to be taken, and stored in an internal output buffer. If there is no room, the write() is suspended, till there is room. Or throw's an IOException( "no room in buffer") ; As the select() loop for write reports buffer room avail, then more of the internal buffer is sent to the printer. yves pielusenet wrote: > So maybe a better way should be to create a new Exception class which > has a method "int getWrittenByte()". So the Exception should be use to > send again bytes which are not printed yet. > > yves > > Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : >> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: >>> It is not possible that the rxtx java method write(byte[], int offset, >>> int length) return anint which contains the number of byte really send >>> to the printer instead of an exception ? >>> So this is the programm which will see if all bytes have been sent. If >>> not it can retry to send the unsended bytes. >> I think write() is void because in Java people love to do this >> since OutputStream :-) Of course on such interfaces you cannot >> implement something nice. If you would have a int write, you >> would not implement the interface and no applications expecting >> this interface would link/work/compile. >> >> oki, >> >> Steffen >> >> P.S.: (OT) >> If you propose not to implement the Java interfaces (especially >> not on JNI level), maybe optionally offering a wrapper that >> removes e.g. the write return value and so on to downgrade the >> powerful classic old POSIX read/write style to the modern limited >> Java style, then I agree :-) Same for read. Instead of things >> like "int avialable()" it is more powerful to have an approach as >> select(2) offers (to guarante the caller that read/write will not >> block [nothing else make sense anyway IMHO] but may read/write >> less bytes then requested). The caller gets full control and the >> higher level protocols can care about timeouts, invoking read in >> some loops and/or implement retransmission. On top of such an >> implementation, where everything is controlled, defined, >> guaranteed and reliable, someone could use an InputStream or >> OutputStream style interface. Or even better: don't use them at >> all :) just BTW :-) >> St. >> >> About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. >> 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. >> >> About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. >> 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. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From Steffen.DETTMER at ingenico.com Fri Jun 8 08:12:18 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 16:12:18 +0200 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <46694F9D.5080501@gatworks.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: <20070608141218.GE21069@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 08:46 -0400: > It seems that with outputstream.write(b[]), you become terribly > uncoordinated as soon as an exception is thrown. Docs do not say what > happens to the data. (yes, so avoiding it seems to be good :)) > Yet from a practicable point of view, one would like to know if the > write was accepted in-full, or rejected before any writes. There are no > in betweens, as partial writes are not reportable. (which is an artificial API limitation. I never understood how this happend when they invented JDK because the well-known BSD socket API and thus [probably] WinSock does this correct, but anyway) > So for an outputstream.write(), in order for it to return, the full > write request has to be taken, and stored in an internal output buffer. > If there is no room, the write() is suspended, till there is room. Or > throw's an IOException( "no room in buffer") ; As the select() loop for > write reports buffer room avail, then more of the internal buffer is > sent to the printer. yes, might be good in case of a printer. May be horrible in case of PPP/TCP or some other transmission control protocol which may e.g. repeat data or even omit parts of it (e.g. internet realtime radio station broadcasting)... So I think the idea of "int write" (e.g. BSD sockets, linux files and so on) still is the best. A clean API / implementation should guarantee and allow implementations (users) to rely on that; assumptions and automatic background-sending and so on may look pragmatic and may even work on the first look, but may fail in other situations. BTW, if e.g. BSD socket API is known, why not simply copy it (until something better is invented :)) instead of fiddling around with JDK APIs? anyway, have a nice weekend everyone :-) oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Fri Jun 8 08:55:56 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 10:55:56 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070608141218.GE21069@elberon.bln.de.ingenico.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> Message-ID: <46696DFC.7000801@gatworks.com> >> write reports buffer room avail, then more of the internal buffer is >> sent to the printer. > > yes, might be good in case of a printer. May be horrible in case > of PPP/TCP or some other transmission control protocol which > may e.g. repeat data or even omit parts of it (e.g. internet > realtime radio station broadcasting)... So I think the idea of > "int write" (e.g. BSD sockets, linux files and so on) still is > the best. A clean API / implementation should guarantee and allow > implementations (users) to rely on that; assumptions and > automatic background-sending and so on may look pragmatic and may > even work on the first look, but may fail in other situations. > BTW, if e.g. BSD socket API is known, why not simply copy it > (until something better is invented :)) instead of fiddling > around with JDK APIs? But we were talking about the Parallel Port, and the transmission of data over the commapi/parallel-port schema. There isn't much in bi-directional software communication. Its a simple write one byte at a time interface. I'm not looking to change the comm-api. I'm just looking to alter the interaction between the Native ParallelPort functions, and the java ParallelPort functions that call them. This might be more readily doable than to get a committee to re-specify java-API specs. BTW: Whats is off-topic? ( help: not looking for def of off-topic ) From j.kenneth.gentle at acm.org Fri Jun 8 08:58:59 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Fri, 08 Jun 2007 10:58:59 -0400 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <20070608141218.GE21069@elberon.bln.de.ingenico.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> Message-ID: <200706081459.l58Ex5rA019991@qbang.org> Perhaps it is a bit late to jump in on this one, but here goes anyway. If the solutions all seem to "break" the contract with "java.io.outputstream", then, as noted, that may not be the appropriate contract. At the risk of being heretical, JDK1.4 introduced the "nio" package to address some of the compatibility issues with C apis mentioned in previous posts. The interface "java.nio.channels.WriteableByteChannel" defines the following single method: int write(ByteBuffer source); int, strangely enough, is the actual number of bytes written. So, if RXTX as written, against the JavaCOMM api and OutputStream, doesn't do what we want, how about writing a different set of bindings using the java.nio classes and as much of the underlying native code as possible. Note that just because the java.nio.channels.WriteableByteChannel sends back a result, OutputStream.write doesn't have to - and they could both call the same underlying native code. My 2 cents - maybe not worth even that... Ken From netbeans at gatworks.com Fri Jun 8 10:37:28 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 12:37:28 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <200706081459.l58Ex5rA019991@qbang.org> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> Message-ID: <466985C8.8000505@gatworks.com> Ken Gentle wrote: > Perhaps it is a bit late to jump in on this one, but here goes anyway. Common in, the waters fine. > > If the solutions all seem to "break" the contract with > "java.io.outputstream", then, as noted, that may not be the > appropriate contract. > How would the contract be broken? The machinery underneath is handling the contract. From j.kenneth.gentle at acm.org Fri Jun 8 10:48:01 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Fri, 08 Jun 2007 12:48:01 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466985C8.8000505@gatworks.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> Message-ID: <200706081648.l58Gm7YA022904@qbang.org> At 12:37 2007-06-08, you wrote: >Ken Gentle wrote: > > > > If the solutions all seem to "break" the contract with > > "java.io.outputstream", then, as noted, that may not be the > > appropriate contract. > > >How would the contract be broken? The machinery underneath is handling >the contract. It seems that a lot of the discussion has been about not only the timeout and being able to adjust it in the "machinery layer", but also about knowing in the Java layer, in the event of a timeout or exception, how many characters have been written to the device. An OutputStream won't ever do this with out an extension and including a return value "breaks" the contract, right? So, go with a Java IO api that *does* return the number of bytes written, out of the NIO package. I know it doesn't allow for a strict implementation of the JavaCOMM API - however, using NIO classes in place of the IO classes isn't that big a break and would allow those applications that need such information a way to get it. Maybe I'm misunderstanding the problem... Ken From netbeans at gatworks.com Fri Jun 8 11:24:14 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 13:24:14 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <200706081648.l58Gm7YA022904@qbang.org> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> Message-ID: <466990BE.7040100@gatworks.com> Ken Gentle wrote: An > OutputStream won't ever do this with out an extension and including a > return value "breaks" the contract, right? > i was not thinking of change the API to OutputSream. Are there specs for how output stream should work internally? for instance: String data = "Hello this is a line of data"; Outputstream.write( data.getbytes() ); ParallelPort.suspend(); int free = ParallelPort.getoutputbufferfree(); There is a symbiotic relationship between outputstream and the functionality of ParallelPort. From Steffen.DETTMER at ingenico.com Fri Jun 8 11:15:39 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 19:15:39 +0200 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <200706081459.l58Ex5rA019991@qbang.org> References: <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> Message-ID: <20070608171539.GK21069@elberon.bln.de.ingenico.com> * Ken Gentle wrote on Fri, Jun 08, 2007 at 10:58 -0400: > If the solutions all seem to "break" the contract with > "java.io.outputstream", then, as noted, that may not be the > appropriate contract. > > At the risk of being heretical, JDK1.4 introduced the "nio" package > to address some of the compatibility issues with C apis mentioned in > previous posts. The interface > "java.nio.channels.WriteableByteChannel" defines the following single method: > > int write(ByteBuffer source); > > int, strangely enough, is the actual number of bytes written. Yes, AFAIK one of the motivations for the NIO interface was, that the JDK-1.3 APIs (InputStream, e.g.) were not powerfull enough, especially for multi-connection-TCP servers or so. I don't know much about it but I've heard of a project where NIO usage was removed because of stability issues in multi-threaded environments and performance limitations under some circumstances. IIRC the "nio.ByteBuffer" is something very special (namely something you cannot implement in Java, it is "magic" or part of the language itself). Not sure if this is such a great idea (but for performance in the end sometimes heavy prices must be paid) :) > So, if RXTX as written, against the JavaCOMM api and OutputStream, > doesn't do what we want, how about writing a different set of > bindings using the java.nio classes and as much of the underlying > native code as possible. Yes, this would be an idea: use a full-featured interface on JNI, and, if wanted, deliver some wrappers converting this to a less-featured Java-compliant interface. However, powerful things as e.g. "select" are difficult to "emulate" if you are e.g. on some (older?) windows. But if you expose the full-featured APIs, you need to emulate them full-featured, theoretically. In the end it depends what you do on the serial line. If you just want to talk to a modem, then you may not need precise timeouts. But if you need to implement complexer protocols which define response times and timeouts, you may quickly get into difficulties. For instance, AFAIK, rxtx 1.7.2 (?) for windows is very messy with timeouts (there is a maximum, higher values are truncated; resolution is 100ms only; the function may take up to twice the timeout because internally it may be called twice). Probably for most people this is OK, but probably not for all. But having precise timeouts should be OK for all :-) Well, in the end it is nice to wish but somewhat hard to implement (many platforms, connections, USB, BlueTooth, whatever). oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Steffen.DETTMER at ingenico.com Fri Jun 8 11:04:22 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 19:04:22 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <46696DFC.7000801@gatworks.com> References: <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <46696DFC.7000801@gatworks.com> Message-ID: <20070608170422.GJ21069@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 10:55 -0400: > > BTW, if e.g. BSD socket API is known, why not simply copy it > > (until something better is invented :)) instead of fiddling > > around with JDK APIs? > > But we were talking about the Parallel Port, and the > transmission of data over the commapi/parallel-port schema. > There isn't much in bi-directional software communication. Its > a simple write one byte at a time interface. First, there are things like PLIP (http://en.wikipedia.org/wiki/Plip) - well, probably not widely used, sure ;) Second, I think if there is a good simple API known to support all that (with known "best practices") or so and there is no forcing need to invent a new one, why not simply using it? > I'm not looking to change the comm-api. I'm just looking to > alter the interaction between the Native ParallelPort > functions, and the java ParallelPort functions that call them. Ahh, yes. I think this is what I tried to ask. Having an usable JNI interface and on top (in pure java) some wrapper to InputStream or whatever could be done (e.g. by ignoring the return value of write or throwing if != length). Developers could then use the full-featured (non-JAVA-standard) API or select among various wrappers (as InputStream). > This might be more readily doable than to get a committee to > re-specify java-API specs. Yes, of course. I'm afraid that the Java APIs change regularily, but still yet with limited success it seems, so maybe they get it in one of the next iterations; who knows, maybe Java-9 has a BSD-like socket API :) SCNR. > BTW: Whats is off-topic? ( help: not looking for def of > off-topic ) I think I started some "re-specify java-API specs" which was OT probably. oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From lists at iDIAcomputing.com Fri Jun 8 18:48:54 2007 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Fri, 08 Jun 2007 20:48:54 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46684B62.7080802@gmail.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> Message-ID: <4669F8F6.3040101@iDIAcomputing.com> Vicne wrote: > Sorry to step in without a specific solution to your problem, but I > wanted to share my feeling regarding this proposal. AFAIK, it's > generally considered bad practice to pop-up a prompt from a library. ... > > My advice would be to think again and find another solution. Ideas are : > - make the number of retries a parameter so that you can tune it to what > you think is reasonable > - throw a more specific exception when the number of retries has been > reached, so that a specific prompt can be shown at a higher level You could also allow the client code to register a callback class which returns a boolean indicating whether to retry or cancel. This callback class could pop up a dialog, if appropriate, or follow some preset policy, or.... - George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From joachim at buechse.ch Sat Jun 9 09:43:16 2007 From: joachim at buechse.ch (Joachim Buechse) Date: Sat, 9 Jun 2007 17:43:16 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46694F9D.5080501@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: You should not forget, that in the case of an exception it may not even be known what happened to the data. You have a kernel buffer, outgoing chip buffer, incoming chip buffer, etc. So of course, it would be nice to know up to which point data was correctly processed, but this feedback does not exist on the hardware or protocol level and hence can in general not be magicly created on the software level... Regards, Joachim On 08.06.2007, at 14:46, Uncle George wrote: > It seems that with outputstream.write(b[]), you become terribly > uncoordinated as soon as an exception is thrown. Docs do not say what > happens to the data. > > Yet from a practicable point of view, one would like to know if the > write was accepted in-full, or rejected before any writes. There > are no > in betweens, as partial writes are not reportable. > > So for an outputstream.write(), in order for it to return, the full > write request has to be taken, and stored in an internal output > buffer. > If there is no room, the write() is suspended, till there is room. Or > throw's an IOException( "no room in buffer") ; As the select() loop > for > write reports buffer room avail, then more of the internal buffer is > sent to the printer. > > > > yves pielusenet wrote: >> So maybe a better way should be to create a new Exception class which >> has a method "int getWrittenByte()". So the Exception should be >> use to >> send again bytes which are not printed yet. >> >> yves >> >> Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : >>> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: >>>> It is not possible that the rxtx java method write(byte[], int >>>> offset, >>>> int length) return anint which contains the number of byte >>>> really send >>>> to the printer instead of an exception ? >>>> So this is the programm which will see if all bytes have been >>>> sent. If >>>> not it can retry to send the unsended bytes. >>> I think write() is void because in Java people love to do this >>> since OutputStream :-) Of course on such interfaces you cannot >>> implement something nice. If you would have a int write, you >>> would not implement the interface and no applications expecting >>> this interface would link/work/compile. >>> >>> oki, >>> >>> Steffen >>> >>> P.S.: (OT) >>> If you propose not to implement the Java interfaces (especially >>> not on JNI level), maybe optionally offering a wrapper that >>> removes e.g. the write return value and so on to downgrade the >>> powerful classic old POSIX read/write style to the modern limited >>> Java style, then I agree :-) Same for read. Instead of things >>> like "int avialable()" it is more powerful to have an approach as >>> select(2) offers (to guarante the caller that read/write will not >>> block [nothing else make sense anyway IMHO] but may read/write >>> less bytes then requested). The caller gets full control and the >>> higher level protocols can care about timeouts, invoking read in >>> some loops and/or implement retransmission. On top of such an >>> implementation, where everything is controlled, defined, >>> guaranteed and reliable, someone could use an InputStream or >>> OutputStream style interface. Or even better: don't use them at >>> all :) just BTW :-) >>> St. >>> >>> About Ingenico Throughout the world businesses rely on Ingenico >>> for secure and expedient electronic transaction acceptance. >>> Ingenico products leverage proven technology, established >>> standards and unparalleled ergonomics to provide optimal >>> reliability, versatility and usability. This comprehensive range >>> of products is complemented by a global array of services and >>> partnerships, enabling businesses in a number of vertical sectors >>> to accept transactions anywhere their business takes them. >>> 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. >>> >>> About Ingenico Throughout the world businesses rely on Ingenico >>> for secure and expedient electronic transaction acceptance. >>> Ingenico products leverage proven technology, established >>> standards and unparalleled ergonomics to provide optimal >>> reliability, versatility and usability. This comprehensive range >>> of products is complemented by a global array of services and >>> partnerships, enabling businesses in a number of vertical sectors >>> to accept transactions anywhere their business takes them. >>> 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. >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx 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 yvespielusenet at free.fr Mon Jun 11 03:15:12 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Mon, 11 Jun 2007 11:15:12 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: <1181553312.8335.14.camel@localhost.localdomain> So can someone tell a solution for my problem :( Must I say to the user to not put the printer off-line ? I can't since he has to do some pauses, verify print, paper conditioning etc... How do other people ? Before I use the parport librarry to read port status : http://www.geocities.com/Juanga69/parport/ (which doesn't work on windows XP) And I send data into the file LPT1 I use to have no problem when printer was disabled. thanks -- yves piel Le samedi 09 juin 2007 ? 17:43 +0200, Joachim Buechse a ?crit : > You should not forget, that in the case of an exception it may not > even be known what happened to the data. > > You have a kernel buffer, outgoing chip buffer, incoming chip buffer, > etc. So of course, it would be nice to know up to which point data > was correctly processed, but this feedback does not exist on the > hardware or protocol level and hence can in general not be magicly > created on the software level... > > Regards, > Joachim > > On 08.06.2007, at 14:46, Uncle George wrote: > > > It seems that with outputstream.write(b[]), you become terribly > > uncoordinated as soon as an exception is thrown. Docs do not say what > > happens to the data. > > > > Yet from a practicable point of view, one would like to know if the > > write was accepted in-full, or rejected before any writes. There > > are no > > in betweens, as partial writes are not reportable. > > > > So for an outputstream.write(), in order for it to return, the full > > write request has to be taken, and stored in an internal output > > buffer. > > If there is no room, the write() is suspended, till there is room. Or > > throw's an IOException( "no room in buffer") ; As the select() loop > > for > > write reports buffer room avail, then more of the internal buffer is > > sent to the printer. > > > > > > > > yves pielusenet wrote: > >> So maybe a better way should be to create a new Exception class which > >> has a method "int getWrittenByte()". So the Exception should be > >> use to > >> send again bytes which are not printed yet. > >> > >> yves > >> > >> Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : > >>> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > >>>> It is not possible that the rxtx java method write(byte[], int > >>>> offset, > >>>> int length) return anint which contains the number of byte > >>>> really send > >>>> to the printer instead of an exception ? > >>>> So this is the programm which will see if all bytes have been > >>>> sent. If > >>>> not it can retry to send the unsended bytes. > >>> I think write() is void because in Java people love to do this > >>> since OutputStream :-) Of course on such interfaces you cannot > >>> implement something nice. If you would have a int write, you > >>> would not implement the interface and no applications expecting > >>> this interface would link/work/compile. > >>> > >>> oki, > >>> > >>> Steffen > >>> > >>> P.S.: (OT) > >>> If you propose not to implement the Java interfaces (especially > >>> not on JNI level), maybe optionally offering a wrapper that > >>> removes e.g. the write return value and so on to downgrade the > >>> powerful classic old POSIX read/write style to the modern limited > >>> Java style, then I agree :-) Same for read. Instead of things > >>> like "int avialable()" it is more powerful to have an approach as > >>> select(2) offers (to guarante the caller that read/write will not > >>> block [nothing else make sense anyway IMHO] but may read/write > >>> less bytes then requested). The caller gets full control and the > >>> higher level protocols can care about timeouts, invoking read in > >>> some loops and/or implement retransmission. On top of such an > >>> implementation, where everything is controlled, defined, > >>> guaranteed and reliable, someone could use an InputStream or > >>> OutputStream style interface. Or even better: don't use them at > >>> all :) just BTW :-) > >>> St. > >>> > >>> About Ingenico Throughout the world businesses rely on Ingenico > >>> for secure and expedient electronic transaction acceptance. > >>> Ingenico products leverage proven technology, established > >>> standards and unparalleled ergonomics to provide optimal > >>> reliability, versatility and usability. This comprehensive range > >>> of products is complemented by a global array of services and > >>> partnerships, enabling businesses in a number of vertical sectors > >>> to accept transactions anywhere their business takes them. > >>> 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. > >>> > >>> About Ingenico Throughout the world businesses rely on Ingenico > >>> for secure and expedient electronic transaction acceptance. > >>> Ingenico products leverage proven technology, established > >>> standards and unparalleled ergonomics to provide optimal > >>> reliability, versatility and usability. This comprehensive range > >>> of products is complemented by a global array of services and > >>> partnerships, enabling businesses in a number of vertical sectors > >>> to accept transactions anywhere their business takes them. > >>> 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. > >>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx 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 > From Steffen.DETTMER at ingenico.com Mon Jun 11 03:56:18 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 11:56:18 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466990BE.7040100@gatworks.com> References: <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> Message-ID: <20070611095618.GA10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 13:24 -0400: > i was not thinking of change the API to OutputSream. Then I think either someone uses OutputStream (and has no reliable information about incomplete writes) or someone uses somethink else. > Are there specs for how output stream should work internally? > > for instance: > String data = "Hello this is a line of data"; > Outputstream.write( data.getbytes() ); > ParallelPort.suspend(); > int free = ParallelPort.getoutputbufferfree(); > > There is a symbiotic relationship between outputstream and the > functionality of ParallelPort. If you need OutputStream "plus something else", in short you're needing "something else". Personally I dislike the code above a lot. The stream "looks" like if it would be an OutputStream, but in fact it isn't. You need to call getoutputbufferfree later to check if write succeeded (but OutputStream promises that write succeedes synchronous, blocking, or throws an exception). So it is not an OutputStream. No application written for OutputStreams would work without change (because it won't know getoutputbufferfree at all). It is not abstracted from ParallelPort. I think this would be wrong. Then I think an alternative interface instead is better. Let's assume we had some "connection" (to distinguish between OutputStreams and Channels). Then why not working as on a file handle in POSIX: do { // ... select maybe using timer ... readyForWrite = ... if (readyForWrite) { int writtenBytes = connection.write(toWrite); toWrite.remove(0, writtenBytes); } while(readyForWrite && toWrite.length > 0); I think, having such a write isn't the big problem. I think, the difficult thing is around "select" - however this would look like. It should be OO, typesafe, performant, supporting multiple connections/channels/streams in various modes and should be orthogonal to other functionalities. Of course, this heavily depends on what the application is doing; for a simple situation (like reading a small, mandatory file from a local disk) this would be to uncomfortable (and offering unneeded features only). just BTW :) oki, Steffen -- // Modeline for VIM. Please don't remove. // (Help: autoindent, expandtab, shiftwidth=4, tabstop=4, textwidth=75) // vi: set ai et sw=4 ts=4 tw=75 ft=java: About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Mon Jun 11 05:38:33 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 07:38:33 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611095618.GA10821@elberon.bln.de.ingenico.com> References: <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> Message-ID: <466D3439.4020805@gatworks.com> Steffen DETTMER wrote: > (but OutputStream promises that write > succeedes synchronous, blocking, or throws an exception). Where is it so written? From Steffen.DETTMER at ingenico.com Mon Jun 11 06:36:50 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 14:36:50 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466D3439.4020805@gatworks.com> References: <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> <466D3439.4020805@gatworks.com> Message-ID: <20070611123650.GI10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Mon, Jun 11, 2007 at 07:38 -0400: > Steffen DETTMER wrote: > > > (but OutputStream promises that write > > succeedes synchronous, blocking, or throws an exception). > > Where is it so written? Now, as you ask, I think it is not written that clearly but follows from specification. mmm... Am I wrong? I understand the API doc in this way: * http://java.sun.com/j2se/1.4.2/docs/api/java/io/OutputStream.html#write(byte[]) > public void write(byte[] b) > throws IOException > > Writes b.length bytes from the specified byte array to this > output stream. The general contract for write(b) is that > it should have exactly the same effect as the call write(b, > 0, b.length). > > Parameters: > b - the data. > Throws: > IOException - if an I/O error occurs. > See Also: > write(byte[], int, int) and there is: > public void write(byte[] b, > int off, > int len) > throws IOException > > Writes len bytes from the specified byte array starting at > offset off to this output stream. The general contract for > write(b, off, len) is that some of the bytes in the array b > are written to the output stream in order; element b[off] > is the first byte written and b[off+len-1] is the last byte > written by this operation. > > The write method of OutputStream calls the write method of > one argument on each of the bytes to be written out. > Subclasses are encouraged to override this method and > provide a more efficient implementation. > > If b is null, a NullPointerException is thrown. > > If off is negative, or len is negative, or off+len is > greater than the length of the array b, then an > IndexOutOfBoundsException is thrown. > > Parameters: > b - the data. > off - the start offset in the data. > len - the number of bytes to write. > Throws: > IOException - if an I/O error occurs. In particular, an > IOException is thrown if the output stream is closed. In general, any specialisation (derived child class) must comform to this. So write in the end is specified (!) as "The write method ... calls the write method ... on each of the bytes to be written out". This is what must be implemented by ANY OutputStream. Of course, there is: "Subclasses are encouraged to override this method and provide a more efficient implementation." which IMHO does not contradict - the more efficient must behave in exactly the same way of course (just wasting less resources than a simple byte-by-byte write). So it does not matter here I think. The write that finally defines the behavior tells basically: > "Writes the specified byte to this output stream. The general > contract for write is that one byte is written to the output > stream. " > > Throws: > IOException - if an I/O error occurs. which IMHO is another way of saying "write writes the byte immediately and returns on success (only), otherwise an exception is thrown". Especially it cannot happen that zero bytes are written (i.e. the specified byte is NOT written) without an exception. So by this write must be synchronous and blocking, because otherwise it could not reliably know if an asynchronous operation will succeede or not (some getAsyncResult or so would be needed). Since write(byte[]) does this for each byte (or with a behavior beeing exactly the same as if it would do), I think this means that the write(byte[]) succeedes synchronous/blocking or throws an exception. Did I an error in reasoning or confused something or so? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From j.kenneth.gentle at acm.org Mon Jun 11 06:51:25 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 11 Jun 2007 08:51:25 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611123650.GI10821@elberon.bln.de.ingenico.com> References: <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> <466D3439.4020805@gatworks.com> <20070611123650.GI10821@elberon.bln.de.ingenico.com> Message-ID: <200706111251.l5BCpS9T017831@qbang.org> It is as Steffen describes. "InputStream" and "OutputStream" are inherently synchronous (which is why so many java programs resort to threads to use them). Anything outside of this "contract" is *not* an InputStream or OutputStream. That is why there is a new package for things that don't behave like the old *Stream classes - the NIO package. If you look carefully at the IO package, you'll note that almost all the classes are _Decorator_ pattern implementations of the *Stream classes - and the interface presents the _same_ behavior to the calling code in all cases - a synchronous operation that completes successfully or throws an exception (with the one exception of "read" that returns a "-1" on end-of-stream. I know I've read this numerous times - I'd suggest checking the Language Spec or one of the books by Bloch or Gosling. Ken At 08:36 2007-06-11, you wrote: >* Uncle George wrote on Mon, Jun 11, 2007 at 07:38 -0400: > > Steffen DETTMER wrote: > > > > > (but OutputStream promises that write > > > succeedes synchronous, blocking, or throws an exception). > > > > Where is it so written? > >Now, as you ask, I think it is not written that clearly but >follows from specification. mmm... > >Am I wrong? > >I understand the API doc in this way: > >* >http://java.sun.com/j2se/1.4.2/docs/api/java/io/OutputStream.html#write(byte[]) > > public void write(byte[] b) > > throws IOException > > > > Writes b.length bytes from the specified byte array to this > > output stream. The general contract for write(b) is that > > it should have exactly the same effect as the call write(b, > > 0, b.length). > > > > Parameters: > > b - the data. > > Throws: > > IOException - if an I/O error occurs. > > See Also: > > write(byte[], int, int) > > >and there is: > > > > public void write(byte[] b, > > int off, > > int len) > > throws IOException > > > > Writes len bytes from the specified byte array starting at > > offset off to this output stream. The general contract for > > write(b, off, len) is that some of the bytes in the array b > > are written to the output stream in order; element b[off] > > is the first byte written and b[off+len-1] is the last byte > > written by this operation. > > > > The write method of OutputStream calls the write method of > > one argument on each of the bytes to be written out. > > Subclasses are encouraged to override this method and > > provide a more efficient implementation. > > > > If b is null, a NullPointerException is thrown. > > > > If off is negative, or len is negative, or off+len is > > greater than the length of the array b, then an > > IndexOutOfBoundsException is thrown. > > > > Parameters: > > b - the data. > > off - the start offset in the data. > > len - the number of bytes to write. > > Throws: > > IOException - if an I/O error occurs. In particular, an > > IOException is thrown if the output stream is closed. > > >In general, any specialisation (derived child class) must comform >to this. So write in the end is specified (!) as "The write >method ... calls the write method ... on each of the bytes to be >written out". This is what must be implemented by ANY >OutputStream. > >Of course, there is: "Subclasses are encouraged to override this >method and provide a more efficient implementation." which IMHO >does not contradict - the more efficient must behave in exactly >the same way of course (just wasting less resources than a simple >byte-by-byte write). So it does not matter here I think. > > > >The write that finally defines the behavior tells basically: > > > "Writes the specified byte to this output stream. The general > > contract for write is that one byte is written to the output > > stream. " > > > > Throws: > > IOException - if an I/O error occurs. > > >which IMHO is another way of saying "write writes the byte >immediately and returns on success (only), otherwise an exception >is thrown". Especially it cannot happen that zero bytes are >written (i.e. the specified byte is NOT written) without an >exception. So by this write must be synchronous and blocking, >because otherwise it could not reliably know if an asynchronous >operation will succeede or not (some getAsyncResult or so would >be needed). > >Since write(byte[]) does this for each byte (or with a behavior >beeing exactly the same as if it would do), I think this means >that the write(byte[]) succeedes synchronous/blocking or throws >an exception. > >Did I an error in reasoning or confused something or so? > >oki, > >Steffen > >About Ingenico Throughout the world businesses rely on Ingenico for >secure and expedient electronic transaction acceptance. Ingenico >products leverage proven technology, established standards and >unparalleled ergonomics to provide optimal reliability, versatility >and usability. This comprehensive range of products is complemented >by a global array of services and partnerships, enabling businesses >in a number of vertical sectors to accept transactions anywhere >their business takes them. >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. > >About Ingenico Throughout the world businesses rely on Ingenico for >secure and expedient electronic transaction acceptance. Ingenico >products leverage proven technology, established standards and >unparalleled ergonomics to provide optimal reliability, versatility >and usability. This comprehensive range of products is complemented >by a global array of services and partnerships, enabling businesses >in a number of vertical sectors to accept transactions anywhere >their business takes them. >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. > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From alesinskyy at googlemail.com Mon Jun 11 07:25:33 2007 From: alesinskyy at googlemail.com (Oleksandr Alesinskyy) Date: Mon, 11 Jun 2007 15:25:33 +0200 Subject: [Rxtx] [OT] select :-) Message-ID: Sorry, but I have to disagree with following statement: "So write in the end is specified (!) as "The write method ... calls the write method ... on each of the bytes to be written out". This is what must be implemented by ANY OutputStream.". This is not part of the specification or contract, it is just revealed implementation detail of the OutputStream. It is not stated anywhere that behavoiur of derived classes shall conform with this one. Statement concerning "synchronous" nature of the output stream is invalid as well. Really synchronous stream does not require flush() but OutputStream has it. From Steffen.DETTMER at ingenico.com Mon Jun 11 08:21:16 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 16:21:16 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: Message-ID: <20070611142116.GN10821@elberon.bln.de.ingenico.com> * Oleksandr Alesinskyy wrote on Mon, Jun 11, 2007 at 15:25 +0200: > Sorry, but I have to disagree with following statement: > "So write in the end is specified (!) as "The write > method ... calls the write method ... on each of the bytes to be > written out". This is what must be implemented by ANY > OutputStream.". > > This is not part of the specification or contract, it is just > revealed implementation detail of the OutputStream. It is not > stated anywhere that behavoiur of derived classes shall conform > with this one. (I didn't meant that the implementation must really write byte by byte, but that it must "look as if it would do" - because all implementations of OutputStream must "look" in the same way [which is another way of saying "do abstract" I think]) I think the API doc is not "revealing implementation details" but it is the *specification* of that interface and derivations must (should) conform to this specification. Isn't this the idea of interfaces? A function that expects an OutputStream should work on ANY OutputStream, shouldn't it? just kidding: I mean, what would be the point in implementing a checksum function as OutputStream.write which throws its result as IOException? Or which requires to call close() as very first operation to tell that the application is about to transmit confidential data? :-) > Statement concerning "synchronous" nature of the output stream > is invalid as well. Really synchronous stream does not require > flush() but OutputStream has it. ahh, interesting point! I think this is another bug in the API. flush() is wrong. Because write specifies "The general contract for write is that one byte is written to the output stream." but not "a byte may be written or buffered". Actually, an application would need to call flush() after each write (or bunch of write calls) to ensure that write really did something otherwise I think. I didn't found in the spec of OutputStream that it would be required to call flush(). This should mean that calling flush is not required which in turn leads to the conclusion that write must be synchrous (private threads are forbidden because not specified :)) which in turn leads to the conclusion that flush() is not needed at all... I mean, what if someone would only store in write and do the "real write" in flush() and never else? An application could write in one stream and read on another one (e.g. in bidirectional communication) and would never get anything back, because nothing was actually written because no flush was called? Then someone could even think that on error in some write the data could remain buffered AND throw an exception, retrying to send the data in the next write. Ohh, and if there would be some message number inside, and underlaying write (e.g. a protocol offering InputStream/OutputStream) would check this and throw "DuplicatedMessageNumber" the stream would only throw it again and again beeing unusable... In short: I have no clue how someone could be able to implement an asynchrounos write (which is realiable and correct) without beeing specific to anything which is not specified by OutputStream. Well, I think in the end OutputStream was not intended for such communication or protocol implementations - but to read a local disk file or so. In case of I/O errors usually you can abort your application and change the hard disk :-) oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Bob_Jacobsen at lbl.gov Mon Jun 11 09:32:23 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Mon, 11 Jun 2007 08:32:23 -0700 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611142116.GN10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> Message-ID: At 4:21 PM +0200 6/11/07, Steffen DETTMER wrote: > > Statement concerning "synchronous" nature of the output stream >> is invalid as well. Really synchronous stream does not require >> flush() but OutputStream has it. > >ahh, interesting point! > >I think this is another bug in the API. flush() is wrong. Because >write specifies "The general contract for write is that one byte >is written to the output stream." but not "a byte may be written >or buffered". > >Actually, an application would need to call flush() after each >write (or bunch of write calls) to ensure that write really did >something otherwise I think. OutputStreams don't _have_ to be synchronous or asynchronous, but the OutputStream API was be arranged so that subclasses _can_ be synchronous or asynchronous. Such generality is the hardest part of getting an API right. Hence, if at some point a program using an OutputStream wants to be sure that the data has been pushed all the way out, flush() is available. For some subclasses, e.g. the buffered ones, this has important behavior. Others write the data from each call, and flush() doesn't do anything. You _can_ omit it in programs that are known to use this second type, but there's no requirement that you do so; the interface is general in that way. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From Steffen.DETTMER at ingenico.com Mon Jun 11 12:32:39 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 20:32:39 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> Message-ID: <20070611183239.GT10821@elberon.bln.de.ingenico.com> * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: > >Actually, an application would need to call flush() after each > >write (or bunch of write calls) to ensure that write really did > >something otherwise I think. > OutputStreams don't _have_ to be synchronous or asynchronous, > but the OutputStream API was be arranged so that subclasses > _can_ be synchronous or asynchronous. Ahh, oki. Thanks for the clarificaion. So in short, flush() MUST be called on OutputStream, this is just not documented correctly or so clearly (right?). So the overall usage semantics would be: 1. call write (multiple times if desired) 2. call flush only if both succeeded, write was successful. If flush fails it remains unknown if a part of the data was written and/or will be repeated. So the spec (API doc) is wrong. Correct would be to tell that write behaves as told as long as it is followed by a call to flush, otherwise data may or may not get lost (depending wheter close() is called and calls flush(), which seems not to be guaranteed/required). BTW, I think it is a little bit... erm... interesting to find the specification (java API doc reference) wrong, having a need to conclude it from the presence of some methods with "it would make no sense if they behave exactly as specified, so specification must be wrong (incomplete)". > Such generality is the hardest part of getting an API right. Yes, seems to be proven ;) > Hence, if at some point a program using an OutputStream wants > to be sure that the data has been pushed all the way out, > flush() is available. For some subclasses, e.g. the buffered > ones, this has important behavior. Others write the data from > each call, and flush() doesn't do anything. > You _can_ omit it in programs that are known to use this second > type, but there's no requirement that you do so; the interface > is general in that way. I think, it still it must be called always, otherwise the application could break if passing a different runtime type as OutputStream. I think, if the application/method needs a special "type of OutputStream" then the parameter type must be a subclass but not OutputStream, maybe a PrintStream or so - otherwise the compiler could not detect this error (passing wrong type). Is this correct? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Bob_Jacobsen at lbl.gov Mon Jun 11 13:00:52 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Mon, 11 Jun 2007 12:00:52 -0700 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611183239.GT10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> Message-ID: At 8:32 PM +0200 6/11/07, Steffen DETTMER wrote: >So the spec (API doc) is wrong. Correct would be to tell that >write behaves as told as long as it is followed by a call to >flush, otherwise data may or may not get lost (depending wheter >close() is called and calls flush(), which seems not to be >guaranteed/required). I'm not entirely sure that the spec is wrong, but reasonable people can differ on this. In the 1.5 JavaDocs, all that the docs say for the write methods is that they write to the _output_ _stream_; there is no guarantee of anything beyond that. Only the flush method has any guarantee about the data, which is >Flushes this output stream and forces any buffered output bytes to >be written out. The general contract of flush is that calling it is >an indication that, if any bytes previously written have been >buffered by the implementation of the output stream, such bytes >should immediately be written to their intended destination. People commonly use various OutputStreams without using flush(), and it often works, but it's a bad practice and will eventually bite them. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From netbeans at gatworks.com Mon Jun 11 13:31:57 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 15:31:57 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611183239.GT10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> Message-ID: <466DA32D.1010602@gatworks.com> Steffen DETTMER wrote: > * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: >>> Actually, an application would need to call flush() after each >>> write (or bunch of write calls) to ensure that write really did >>> something otherwise I think. > >> OutputStreams don't _have_ to be synchronous or asynchronous, >> but the OutputStream API was be arranged so that subclasses >> _can_ be synchronous or asynchronous. > > Ahh, oki. Thanks for the clarificaion. > > So in short, flush() MUST be called on OutputStream, this is just > not documented correctly or so clearly (right?). No. Flush can be called to force all current data in java buffer's to be written to the kernel - NOW. A flush() can also *imply* that, besides writing out the buffer's that java employs, may also imply/ask the kernel to write all data thusfar written to the kernel, to be physically placed on the destination device - NOW. For some OS's there is no need to do a kernel flush(), as the I/O is synchronized already. Since this is java, you never know what OS your on. From tjarvi at qbang.org Mon Jun 11 19:28:27 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Jun 2007 19:28:27 -0600 (MDT) Subject: [Rxtx] [OT] select :-) In-Reply-To: <466DA32D.1010602@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: On Mon, 11 Jun 2007, Uncle George wrote: > Steffen DETTMER wrote: >> * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: >>>> Actually, an application would need to call flush() after each >>>> write (or bunch of write calls) to ensure that write really did >>>> something otherwise I think. >> >>> OutputStreams don't _have_ to be synchronous or asynchronous, >>> but the OutputStream API was be arranged so that subclasses >>> _can_ be synchronous or asynchronous. >> >> Ahh, oki. Thanks for the clarificaion. >> >> So in short, flush() MUST be called on OutputStream, this is just >> not documented correctly or so clearly (right?). > No. > Flush can be called to force all current data in java buffer's to be > written to the kernel - NOW. > > A flush() can also *imply* that, besides writing out the buffer's that > java employs, may also imply/ask the kernel to write all data thusfar > written to the kernel, to be physically placed on the destination device > - NOW. > For some OS's there is no need to do a kernel flush(), as the I/O is > synchronized already. Since this is java, you never know what OS your on. To add to the confusion, flush on the C side throws away data. drain makes sure it is written. Looking at the ParallelImp.c we can probably do better. /* we set a timeout because all calls are sequentiell (also with asynchron) this means that the default timeout of unlimited blocks all calls (also close and status request) if the device is down */ GetCommTimeouts( (HANDLE)fd, &timeouts ); timeouts.WriteTotalTimeoutMultiplier = 0; timeouts.WriteTotalTimeoutConstant = 2000; /* 2000 is the min value for the default Windows NT and Windows 2000 driver */ SetCommTimeouts( (HANDLE)fd, &timeouts ); while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } errorCount = 0; bytes += countWritten; count -= countWritten; } LPRPort has some timeout code that appears to be doing nothing but flipping bits back and forth right now. The commapi rxtx follows allows for timeout control from javax.comm.CommPort. The above is a solution that worked in one specific use case. With timeouts in place, the original 'old printer going offline' problem could be solved. That printer code isn't written in stone. In fact it was ajusted from being able to print 'asdf' to a daisy wheel printer to working for one person. BTW, I've finished teaching after hours tonight and will be moving forward with a new rxtx release in my free time. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Jun 11 21:28:04 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 23:28:04 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: <466E12C4.1010305@gatworks.com> > Looking at the ParallelImp.c we can probably do better. > The problem stemmed from the possibility that the writev routine could have written some of the buffer, in chunks, printer pauses, refuses any more chunks, and a timeout occurs. Do you or do you not cause an exception to be thrown? Is there a way to set timeout for a ParallelPort data output stream? I cant find it. From tjarvi at qbang.org Mon Jun 11 22:17:23 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Jun 2007 22:17:23 -0600 (MDT) Subject: [Rxtx] [OT] select :-) In-Reply-To: <466E12C4.1010305@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> <466E12C4.1010305@gatworks.com> Message-ID: On Mon, 11 Jun 2007, Uncle George wrote: >> Looking at the ParallelImp.c we can probably do better. >> > The problem stemmed from the possibility that the writev routine could > have written some of the buffer, in chunks, printer pauses, refuses any > more chunks, and a timeout occurs. Do you or do you not cause an > exception to be thrown? > > Is there a way to set timeout for a ParallelPort data output stream? I > cant find it. hmm I looked again after you asked. The timeouts are only controllable on the receive side. This comes from CommPort; the parent. So what we are talking about is some bytes in memory that rxtx has and is supposed to write. A buffer perhaps? The approach with rxtx in the past has been to ignore output buffer sizes. The assumption is that the library does not know how to best handle buffers. There are buffered output streams that can do buffering on top of rxtx for instance. There is also a question regarding what was actually ment when the API was put together. My suspicion is that it was put together while looking at one OS API and was never ment to be anything more than a hook into that API. The comments are fairly telling combined with reading the w32 API. So looking at the problem again.. The current timeout behavior appears fairly arbitrary. Presumably this is to prevent a program from hanging instead of using a helper thread to write - heavy handed for new programmers. Even so, I don't think the write should timeout at all if it is not configurable. >From the API perspective, "What Timeout?" -- Trent Jarvi tjarvi at qbang.org From Steffen.DETTMER at ingenico.com Tue Jun 12 02:14:48 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 12 Jun 2007 10:14:48 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466DA32D.1010602@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: <20070612081447.GU10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Mon, Jun 11, 2007 at 15:31 -0400: > Steffen DETTMER wrote: > > Ahh, oki. Thanks for the clarificaion. > > > > So in short, flush() MUST be called on OutputStream, this is just > > not documented correctly or so clearly (right?). > No. hum (though now I got it, but...). > Flush can be called to force all current data in java buffer's to be > written to the kernel - NOW. > > A flush() can also *imply* that, besides writing out the > buffer's that java employs, may also imply/ask the kernel to > write all data thusfar written to the kernel, to be physically > placed on the destination device - NOW. > > For some OS's there is no need to do a kernel flush(), as the I/O is > synchronized already. Since this is java, you never know what OS your on. (well, but if you're going to kernel level, even flush cannot guarantee that data will "be physically placed". Maybe you're flushing to a file via NFS (and the client "thinks" that it was written, but maybe it was just buffered by the NFS server) or so... but of course such exceptions of the rules are constructable always.) Well, you tell that depending on the OS it can be that flush is needed or it can be that flush is not needed (beacuse the I/O is synchronized already), right? Also, applications should work on any OS, which includes the OSes that do need flush. Since the application cannot know whether flush is needed or not because it doesn't know what the OS is doing, it has to call flush, hasn't it? I mean, if it would not call flush then it would not work on such OSes (except the written data would not be needed at all, but in this would be an artificial example :)). Since applications are supposed to work this would be wrong, wouldn't it? So would it be correct to say: "Applications, that should work under all OSes (including the OSes where the I/O is not synchronised already), have to call flush on OutputStream to ensure the data is transfered to the kernel." or is this wrong? If so, then I'm afraid I missed the point again :( oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Tue Jun 12 04:46:52 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 12 Jun 2007 06:46:52 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070612081447.GU10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> <20070612081447.GU10821@elberon.bln.de.ingenico.com> Message-ID: <466E799C.7060700@gatworks.com> S > (well, but if you're going to kernel level, even flush cannot > guarantee that data will "be physically placed". Thats true now-a-days because ( from "man 2 sync" ) : > According to the standard specification (e.g., SVID), sync() schedules > the writes, but may return before the actual writing is done. However, > since version 1.3.20 Linux does actually wait. (This still does not > guarantee data integrity: modern disks have large caches.) My disk drive has 8mb cache. Maybe you're > flushing to a file via NFS (and the client "thinks" that it was > written, but maybe it was just buffered by the NFS server) or > so... but of course such exceptions of the rules are > constructable always.) > > Well, you tell that depending on the OS it can be that flush is > needed or it can be that flush is not needed (beacuse the I/O is > synchronized already), right? Also, applications should work on > any OS, which includes the OSes that do need flush. Its not OS's that need flush, its applications that want to have some assurance that data is written to the device that really needs to use flush. If your program ( or thread ) dies then it is in your best interest to write out the critical data as soon as possible, as economical as possible. These are trade-off's that the application programmer makes. A big buffer may mean big loss of data, a small buffer may mean spending too much time writing out data. > > > So would it be correct to say: > > "Applications, that should work under all OSes (including the > OSes where the I/O is not synchronised already), have to call > flush on OutputStream to ensure the data is transfered to the > kernel." > > or is this wrong? If so, then I'm afraid I missed the point again > :( > No that is not wrong. Ensuring that data is transfered to the OS is just about what any application can do. From tjarvi at qbang.org Thu Jun 14 08:16:47 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 14 Jun 2007 08:16:47 -0600 (MDT) Subject: [Rxtx] rxtx and usb-serial solution In-Reply-To: References: Message-ID: On Thu, 14 Jun 2007, Vladimir Kirtchev wrote: > Hi Trent, > > I develop a Java application which communicates with devices which have > USB-to-Serial bridge in them. The target OS is Linux. So for this purpose I > use RXTX. > > But I encountered a strange problem - when reading from the InputStream, I > receive series of zeros. I have this problem under Linux only. Under Windows > it is fine. > Actually this problem is the same as the one described here: > http://marc.info/?l=rxtx&m=109703190731748&w=2. > > > So I searched for the problem in the native code. And found that the root of > the problem is in SerialImp.c, > int configure_port( int fd ) > { > ... > ttyset.c_iflag = INPCK; > ... > } > > This line enables input parity checking, and the data sent from the device > is processed by the OS driver before being read with read(). > In this case the driver detects some problem and sets the received bytes to > zero. > > On the other hand in the Java part a set the serial port parameters with > SerialPort.PARITY_NONE. According to me, except all other things, this > should also disable INPCK in c_iflag. > > So I refactored the method translate_parity(...) to the following: > > int translate_parity( JNIEnv *env, struct termios *ttyset, jint parity ) > { > ENTER( "translate_parity" ); > #ifdef CMSPAR > ttyset->c_cflag &= ~(PARENB | PARODD | CMSPAR ); > #endif /* CMSPAR */ > switch( parity ) { > case JPARITY_NONE: > ttyset->c_iflag &= ~INPCK; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_EVEN: > ttyset->c_cflag |= PARENB; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_ODD: > ttyset->c_cflag |= PARENB | PARODD; > LEAVE( "translate_parity" ); > return 0; > #ifdef CMSPAR > case JPARITY_MARK: > ttyset->c_cflag |= PARENB | PARODD | CMSPAR; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_SPACE: > ttyset->c_cflag |= PARENB | CMSPAR; > LEAVE( "translate_parity" ); > return 0; > #endif /* CMSPAR */ > default: > printf("Parity missed %i\n", (int) parity ); > } > > LEAVE( "translate_parity" ); > /* > For some reason the native exceptions are not being caught. Moving this > to the Java side fixed the issue. taj. > throw_java_exception( env, UNSUPPORTED_COMM_OPERATION, > "", "parity value not supported" ); > */ > return 1; > } > > This modification solved the problem and now it works correctly under Linux. > > I think I will be a nice if this is idea is included in a future release of > RXTX. > > Thanks Vadim, I'll try that out. Forwarding to the rxtx mail-list too. This is probably not going to help USB drivers on windows which I'm sure some are looking for. As far as I can tell, windows USB bluetooth and serial dongles are limited by driver functionality. Some are good and others lack key features. -- Trent Jarvi tjarvi at qbang.org From dan.sandberg.lists at gmail.com Mon Jun 18 14:43:39 2007 From: dan.sandberg.lists at gmail.com (Dan Sandberg) Date: Mon, 18 Jun 2007 13:43:39 -0700 Subject: [Rxtx] Fix for JNI Get/Set Field Errors Message-ID: <4676EE7B.7060800@gmail.com> Hi, I've fixed the problems that cause the following JNI error when extra JNI checking ( -Xjni:check ) is turned on. FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) The problem was basically that GetLong was being used to get ints, and SetInt was used for longs. The patch below fixes this. Please let me know if there are any questions / problems. Cheers, -Dan diff -aur old/SerialImp.c src/SerialImp.c --- old/SerialImp.c 2007-06-18 13:24:33.000000000 -0700 +++ src/SerialImp.c 2007-06-18 06:26:26.000000000 -0700 @@ -1337,7 +1337,7 @@ report("init_threads: get eis\n"); jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); report("init_threads: set eis\n"); - (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); + (*eis->env)->SetLongField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); report("init_threads: stop\n"); report_time_end( ); return( 1 ); @@ -1530,7 +1530,7 @@ jobject jobj, jboolean interrupted ) { int fd = get_java_var( env, jobj,"fd","I" ); - struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var( env, jobj, "eis", "J" ); + struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var_long( env, jobj, "eis", "J" ); int result, count=0; char message[80]; @@ -2939,7 +2939,7 @@ /* TRENT */ int flag, count = 0; struct event_info_struct *eis = ( struct event_info_struct * ) - get_java_var( env, *jobj,"eis","J" ); + get_java_var_long( env, *jobj,"eis","J" ); report_time_start(); flag = eis->eventflags[SPE_DATA_AVAILABLE]; @@ -4873,9 +4873,9 @@ exceptions: none comments: ----------------------------------------------------------*/ -size_t get_java_var( JNIEnv *env, jobject jobj, char *id, char *type ) +long get_java_var_long( JNIEnv *env, jobject jobj, char *id, char *type ) { - int result = 0; + long result = 0; jclass jclazz = (*env)->GetObjectClass( env, jobj ); jfieldID jfd = (*env)->GetFieldID( env, jclazz, id, type ); @@ -4889,7 +4889,11 @@ LEAVE( "get_java_var" ); return result; } - result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); + if ( !strcmp( type, "J" ) ) { + result = (long)( (*env)->GetLongField( env, jobj, jfd ) ); + } else { + result = (int) ( (*env)->GetIntField( env, jobj, jfd ) ); + } /* ct7 & gel * Added DeleteLocalRef */ (*env)->DeleteLocalRef( env, jclazz ); if(!strncmp( "fd",id,2) && result == 0) @@ -4900,6 +4904,10 @@ return result; } +int get_java_var( JNIEnv *env, jobject jobj, char *id, char *type ) { + return (int) get_java_var_long( env, jobj, id, type ); +} + /*---------------------------------------------------------- throw_java_exception diff -aur old/SerialImp.h src/SerialImp.h --- old/SerialImp.h 2007-06-18 13:24:39.000000000 -0700 +++ src/SerialImp.h 2007-06-18 06:23:43.000000000 -0700 @@ -413,7 +413,8 @@ void system_wait(); void finalize_event_info_struct( struct event_info_struct * ); int read_byte_array( JNIEnv *, jobject *, int, unsigned char *, int, int ); -size_t get_java_var( JNIEnv *, jobject, char *, char * ); +int get_java_var( JNIEnv *, jobject, char *, char * ); +long get_java_var_long( JNIEnv *, jobject, char *, char * ); jboolean is_interrupted( struct event_info_struct * ); int send_event(struct event_info_struct *, jint, int ); void dump_termios(char *,struct termios *); From yvespielusenet at free.fr Tue Jun 26 03:41:58 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 11:41:58 +0200 Subject: [Rxtx] [PARALLEL] resource in use Message-ID: <1182850918.3483.10.camel@localhost.localdomain> Hello, So now I want to modify the timeout of the library for parallel port. I have downloaded source code. There is a makefile for migw. SO I have installed mingw on ubuntu and modified the makefile.mingw32 to set it for my system. I have no error but some warnings. The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But When I want to use it the jvm crash :( How can I know what is wrong ? How rxtx windows release has been done ? thanks -- yves piel From yvespielusenet at free.fr Tue Jun 26 07:17:02 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 15:17:02 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182850918.3483.10.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> Message-ID: <1182863822.3483.17.camel@localhost.localdomain> Here is the Makefile I use, the output of the 'make' and the log of the jvm when it crashed : - The Makefile : http://yvespiel.free.fr/rxtx/Makefile - The make output : http://yvespiel.free.fr/rxtx/compile.txt - The crash log : http://yvespiel.free.fr/rxtx/hs_err_pid2100.log I have compiled rxtx under Debian testing with mingw : narma at linimi:/tmp/err$ dpkg -l | grep mingw ii mingw32 3.4.5.20060117.1.dfsg-3 ii mingw32-binutils 2.17.50-20070129.1-1 ii mingw32-runtime 3.12-1 thanks fort help :) Le mardi 26 juin 2007 ? 11:41 +0200, yves pielusenet a ?crit : > Hello, > So now I want to modify the timeout of the library for parallel port. I > have downloaded source code. There is a makefile for migw. SO I have > installed mingw on ubuntu and modified the makefile.mingw32 to set it > for my system. > I have no error but some warnings. > The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But > When I want to use it the jvm crash :( > > How can I know what is wrong ? > > How rxtx windows release has been done ? > > thanks > From yvespielusenet at free.fr Tue Jun 26 07:40:11 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 15:40:11 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182863822.3483.17.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> <1182863822.3483.17.camel@localhost.localdomain> Message-ID: <1182865211.3483.21.camel@localhost.localdomain> I have add the options '--enable-stdcall-fixup' to the 'i586-mingw32msvc-ld' commande. Now I have no warning. But the JVM always crashes :( The output seems more detailled, but I don't understand anything... Here is files : http://yvespiel.free.fr/rxtx/2/ -- yves piel Le mardi 26 juin 2007 ? 15:17 +0200, yves pielusenet a ?crit : > Here is the Makefile I use, the output of the 'make' and the log of the > jvm when it crashed : > > - The Makefile : http://yvespiel.free.fr/rxtx/Makefile > - The make output : http://yvespiel.free.fr/rxtx/compile.txt > - The crash log : http://yvespiel.free.fr/rxtx/hs_err_pid2100.log > > I have compiled rxtx under Debian testing with mingw : > narma at linimi:/tmp/err$ dpkg -l | grep mingw > ii mingw32 3.4.5.20060117.1.dfsg-3 > ii mingw32-binutils 2.17.50-20070129.1-1 > ii mingw32-runtime 3.12-1 > > thanks fort help :) > > > Le mardi 26 juin 2007 ? 11:41 +0200, yves pielusenet a ?crit : > > Hello, > > So now I want to modify the timeout of the library for parallel port. I > > have downloaded source code. There is a makefile for migw. SO I have > > installed mingw on ubuntu and modified the makefile.mingw32 to set it > > for my system. > > I have no error but some warnings. > > The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But > > When I want to use it the jvm crash :( > > > > How can I know what is wrong ? > > > > How rxtx windows release has been done ? > > > > thanks > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From yvespielusenet at free.fr Tue Jun 26 08:27:42 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 16:27:42 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182865211.3483.21.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> <1182863822.3483.17.camel@localhost.localdomain> <1182865211.3483.21.camel@localhost.localdomain> Message-ID: <1182868062.3483.24.camel@localhost.localdomain> I think thant the include files of jdk were not for windows but for linux. So I have copied include/ folder from windows to linux and I modified the Makefile to use those file. It compile fine but the JVM always crash :( http://yvespiel.free.fr/rxtx/3/ Le mardi 26 juin 2007 ? 15:40 +0200, yves pielusenet a ?crit : > I have add the options '--enable-stdcall-fixup' to the > 'i586-mingw32msvc-ld' commande. Now I have no warning. But the JVM > always crashes :( The output seems more detailled, but I don't > understand anything... > Here is files : > http://yvespiel.free.fr/rxtx/2/ > From netbeans at gatworks.com Fri Jun 1 05:38:50 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 07:38:50 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <465F7ADD.1010501@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> Message-ID: <4660054A.2040202@gatworks.com> Manuel Naranjo wrote: In the case of my module, you can > unplug the device but it will not delete the symlink until those apps > that had opened the port has closed it. This is done this way to avoid > kernel panics. What does this mean to user code ? I have tried the alternate route ( other than closing ) which is sleep inbetween the I/O errors ( an unplugged USB device). When the device is plugged back in, The writes to the device still get an I/O error. This would seem to be a lost cause for the application. From netbeans at gatworks.com Fri Jun 1 06:35:48 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 08:35:48 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <465F7ADD.1010501@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> Message-ID: <466012A4.90608@gatworks.com> Manuel Naranjo wrote: In the case of my module, you can > unplug the device but it will not delete the symlink until those apps > that had opened the port has closed it. T Did u also mean for this to happen? USB0 was not closed by application. Apparently USB1 got created when USB device was plugged back in. There is only one USB device on a 4 port USB hub. This also seems to suggest that application recovery to be impossible. > Jun 1 07:10:08 mylaptop kernel: garmin_gps 1-1.4:1.0: Garmin GPS usb/tty converter detected > Jun 1 07:10:08 mylaptop kernel: usb 1-1.4: Garmin GPS usb/tty converter now attached to ttyUSB0 > Jun 1 07:15:17 mylaptop kernel: usb 1-1: USB disconnect, address 4 > Jun 1 07:15:17 mylaptop kernel: usb 1-1.4: USB disconnect, address 5 > Jun 1 07:15:17 mylaptop kernel: garmin_gps 1-1.4:1.0: device disconnected > Jun 1 07:15:26 mylaptop kernel: usb 1-1: new full speed USB device using uhci_hcd and address 6 > Jun 1 07:15:26 mylaptop kernel: hub 1-1:1.0: USB hub found > Jun 1 07:15:26 mylaptop kernel: hub 1-1:1.0: 4 ports detected > Jun 1 07:15:27 mylaptop kernel: usb 1-1.4: new full speed USB device using uhci_hcd and address 7 > Jun 1 07:15:27 mylaptop kernel: garmin_gps 1-1.4:1.0: Garmin GPS usb/tty converter detected > Jun 1 07:15:27 mylaptop kernel: usb 1-1.4: Garmin GPS usb/tty converter now attached to ttyUSB1 From naranjo.manuel at gmail.com Fri Jun 1 09:17:22 2007 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Fri, 01 Jun 2007 12:17:22 -0300 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <466012A4.90608@gatworks.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> <466012A4.90608@gatworks.com> Message-ID: <46603882.5050701@gmail.com> Uncle George escribi?: > Manuel Naranjo wrote: > In the case of my module, you can > >> unplug the device but it will not delete the symlink until those apps >> that had opened the port has closed it. T >> > > Did u also mean for this to happen? USB0 was not closed by application. > > Apparently USB1 got created when USB device was plugged back in. There > is only one USB device on a 4 port USB hub. > > This also seems to suggest that application recovery to be impossible. > Exactly there's a dead symlink (you can read and write to it and nothing will happen) and a new port will be created when a new device is connencted. From netbeans at gatworks.com Fri Jun 1 10:20:46 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 12:20:46 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <46603882.5050701@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> <466012A4.90608@gatworks.com> <46603882.5050701@gmail.com> Message-ID: <4660475E.5090202@gatworks.com> Not sure what u mean by "symlink". U cant read/write to it anymore. U get I/O error. In this scenario the device effectively went dead, and only solution is to close the channel. reconnecting the USB device, although dead, but not closed, will create a second device. This does not seem to be a desirable side-effect. The user will now have ttyUSB1, wondering where did ttyUSB0 go to. The application will also be in a confused state, as well as RXTX, because RXTX wont know about ttyUSB1. Manuel Naranjo wrote: > Uncle George escribi?: >> Manuel Naranjo wrote: >> In the case of my module, you can >> >>> unplug the device but it will not delete the symlink until those apps >>> that had opened the port has closed it. T >>> >> Did u also mean for this to happen? USB0 was not closed by application. >> >> Apparently USB1 got created when USB device was plugged back in. There >> is only one USB device on a 4 port USB hub. >> >> This also seems to suggest that application recovery to be impossible. >> > Exactly there's a dead symlink (you can read and write to it and nothing > will happen) and a new port will be created when a new device is connencted. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From arnab.bhaumik at gmail.com Mon Jun 4 01:40:16 2007 From: arnab.bhaumik at gmail.com (arnab bhaumik) Date: Mon, 4 Jun 2007 13:10:16 +0530 Subject: [Rxtx] full duplex com port with rxtx Message-ID: hi , till now i did half duplex communication with rxtx package on com package. my question is : is it possible to use com port with full duplex mode with rxtx package . ther is example of SimpleRead class and SimpleWrite class. it is clear that if i can use both the class simultaneously then full duplex is possible......... arnab/vu2bpw -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070604/6edb0453/attachment-0009.html From lists at iDIAcomputing.com Mon Jun 4 07:53:17 2007 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Mon, 04 Jun 2007 09:53:17 -0400 Subject: [Rxtx] full duplex com port with rxtx In-Reply-To: References: Message-ID: <4664194D.90301@iDIAcomputing.com> arnab bhaumik wrote: > hi , > > till now i did half duplex communication with rxtx package on com > package. > > my question is : is it possible to use com port with full duplex mode > with rxtx package . > > > ther is example of SimpleRead class and SimpleWrite class. it is > clear that if i can use both the class simultaneously then full duplex > is possible......... I haven't looked at the SimpleRead and SimpleWrite classes (I originally wrote my code for the javax.comm api), but full duplex is certainly possible. My CommReader class requires an object analogous to a OutputStream or Writer. When started, it spawns a thread that reads the comm port and writes to that output device. In this way the input is asynchronous and dependent on the actual input data. For full duplex, I extend that class with CommReaderWriter, which adds synchronous output methods. Hope that helps, George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From supsoop at hotmail.com Mon Jun 4 15:21:06 2007 From: supsoop at hotmail.com (soop soop) Date: Mon, 04 Jun 2007 21:21:06 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- Message-ID: Hi Guys, Looked through the archives but still cannot figure this out. I have a Motorola G24 GPRS/GSM modem that I am connecting to my server running Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not detecting the port, CommPortIdentifier.getPortIdentifiers(). I have added the line to RXTXCommDriver: "ttyACM" // for USB Modems Rxtx still does not seem to find the port. Is there something I am missing to make this port visable? [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control Model driver for USB modems and ISDN adapters I really need your help as I have moved my server from windows to Linux and have been down for a few days because of this .. Thanks so much! _________________________________________________________________ PC Magazine’s 2007 editors’ choice for best Web mail—award-winning Windows Live Hotmail. http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 From tjarvi at qbang.org Mon Jun 4 16:17:35 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Jun 2007 16:17:35 -0600 (MDT) Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: On Mon, 4 Jun 2007, soop soop wrote: > Hi Guys, > > Looked through the archives but still cannot figure this out. I have a > Motorola G24 GPRS/GSM modem that I am connecting to my server running Ubuntu. > I can see my modem as is shows up as ttyACM0, but RXTX is not detecting the > port, CommPortIdentifier.getPortIdentifiers(). > > I have added the line to RXTXCommDriver: > > "ttyACM" // for USB Modems > > Rxtx still does not seem to find the port. Is there something I am missing to > make this port visable? > > [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver > [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device > [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control Model > driver for USB modems and ISDN adapters > > I really need your help as I have moved my server from windows to Linux and > have been down for a few days because of this .. Thanks so much! > You could try the INSTALL documentation that comes with the source for possible solutions. Those usually involve lockfile creation, permissions on the device file or the device is in use by another application (even another session of your application). The usual commands: ls -l /dev/ttyACM0 fuser /dev/ttyACM0 touch /var/lock/LCK.testfile && rm -f /var/lock/LCK.testfile whoami To disable lockfiles: ../configure --disable-lockfiles && make install -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Jun 4 16:22:52 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 04 Jun 2007 18:22:52 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <466490BC.3090801@gatworks.com> soop soop wrote: > I really need your help as I have moved my server from windows to Linux > and have been down for a few days because of this .. Thanks so much! can u open the device ? ie is the file protection/permissions keeping you out? From supsoop at hotmail.com Mon Jun 4 16:44:40 2007 From: supsoop at hotmail.com (soop soop) Date: Mon, 04 Jun 2007 22:44:40 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <466490BC.3090801@gatworks.com> Message-ID: Thanks for the reply, I see no exceptions being thrown, just no detection of the port whats so ever. I will run rxtx in debug mode and log. If this were a permissions issue would I not see some exceptions being thrown? >From: Uncle George >Reply-To: RXTX Developers and Users >To: RXTX Developers and Users >Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >Date: Mon, 04 Jun 2007 18:22:52 -0400 > >soop soop wrote: > > > I really need your help as I have moved my server from windows to Linux > > and have been down for a few days because of this .. Thanks so much! > >can u open the device ? ie is the file protection/permissions keeping >you out? >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ Get a preview of Live Earth, the hottest event this summer - only on MSN http://liveearth.msn.com?source=msntaglineliveearthhm From netbeans at gatworks.com Mon Jun 4 17:06:15 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 04 Jun 2007 19:06:15 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <46649AE7.10405@gatworks.com> Exceptions on what? On startup it wants to lookup all devices in /dev that it is capable of opening ( within the list of specific 'comm' devices ). If it cannot open, then does not get onto list. Part of this process, if configured, will also test if the "LOCK" schema can also be opened for the device. then it gets on the list of avail comm port. soop soop wrote: > Thanks for the reply, > > I see no exceptions being thrown, just no detection of the port whats so > ever. I will run rxtx in debug mode and log. If this were a permissions > issue would I not see some exceptions being thrown? > > >> From: Uncle George >> Reply-To: RXTX Developers and Users >> To: RXTX Developers and Users >> Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >> Date: Mon, 04 Jun 2007 18:22:52 -0400 >> >> soop soop wrote: >> >>> I really need your help as I have moved my server from windows to Linux >>> and have been down for a few days because of this .. Thanks so much! >> can u open the device ? ie is the file protection/permissions keeping >> you out? >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _________________________________________________________________ > Get a preview of Live Earth, the hottest event this summer - only on MSN > http://liveearth.msn.com?source=msntaglineliveearthhm > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From alex.flint at gmail.com Mon Jun 4 21:31:49 2007 From: alex.flint at gmail.com (Alex Flint) Date: Tue, 5 Jun 2007 13:01:49 +0930 Subject: [Rxtx] random EXCEPTION_ACCESS_VIOLATION errors Message-ID: Hi All, I'm running winXP and RXTX 2.1-7r2 (the latest from the webpage as of June 2007). I'm sending sequences of 64 lines (each line has about 15 chars) at various intervals. The strings are sent fine, until I get the following error (from hs_err_pid3316.log, at the end of this email). What can I do to avoid the error? Obviously this is a low-level memory exception, but is there any way I can keep the JVM running after such an error? I noticed the exact same problem here: http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20070129/1180520.html Cheers, Alex # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x100034fb, pid=3316, tid=2400 # # Java VM: Java HotSpot(TM) Client VM (1.6.0_01-b06 mixed mode, sharing) # Problematic frame: # C [rxtxSerial.dll+0x34fb] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # --------------- T H R E A D --------------- Current thread (0x00386400): JavaThread "main" [_thread_in_native, id=2400] siginfo: ExceptionCode=0xc0000005, reading address 0x20726f78 Registers: EAX=0x20726f20, EBX=0x6d8922c0, ECX=0x00000005, EDX=0x20726f20 ESP=0x003efa30, EBP=0x003efb68, ESI=0x269728a0, EDI=0x00386400 EIP=0x100034fb, EFLAGS=0x00010212 Top of Stack: (sp=0x003efa30) 0x003efa30: 003efa3c 003efa64 0000000f ffffffff 0x003efa40: 003efa40 2a97f808 003efa6c 2b190ca8 0x003efa50: 00000000 2b190ec0 003efa90 008e2dd7 0x003efa60: 003efa90 008e2dd7 26977f88 6d815e72 0x003efa70: 00000004 2696eae0 0000008a 003efb0c 0x003efa80: 6d852b4a 2696eae0 00000003 26970930 0x003efa90: 000000cb 2696eae0 6d86b264 00385d40 0x003efaa0: 0000003f 003efb0c 26977f90 2ace65d8 Instructions: (pc=0x100034fb) 0x100034eb: ff ff 8d 76 00 eb 02 89 f6 90 8b 45 f8 8b 55 f8 0x100034fb: 8b 4a 58 83 c9 04 89 48 58 83 c4 f8 8b 45 f8 8b Stack: [0x003a0000,0x003f0000), sp=0x003efa30, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x34fb] Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j gnu.io.RXTXPort.writeArray([BIIZ)V+0 j gnu.io.RXTXPort$SerialOutputStream.write([B)V+76 j com.bjt.media.server.CommLink.send(Ljava/lang/String;)V+48 j com.bjt.media.server.DigitoolConnection.select(I)V+73 j com.bjt.media.server.DigitoolConnection.main([Ljava/lang/String;)V+74 v ~StubRoutines::call_stub --------------- P R O C E S S --------------- Java Threads: ( => current thread ) 0x02a69400 JavaThread "Thread-0" [_thread_in_native, id=3052] 0x02a4d000 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=3920] 0x02a48400 JavaThread "CompilerThread0" daemon [_thread_blocked, id=1968] 0x02a47400 JavaThread "Attach Listener" daemon [_thread_blocked, id=2984] 0x02a46400 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=2660] 0x02a41c00 JavaThread "Finalizer" daemon [_thread_blocked, id=3924] 0x02a3d800 JavaThread "Reference Handler" daemon [_thread_blocked, id=4008] =>0x00386400 JavaThread "main" [_thread_in_native, id=2400] Other Threads: 0x02a34400 VMThread [id=3708] 0x02a4e800 WatcherThread [id=3964] VM state:not at safepoint (normal execution) VM Mutex/Monitor currently owned by a thread: None Heap def new generation total 960K, used 131K [0x22960000, 0x22a60000, 0x22e40000) eden space 896K, 7% used [0x22960000, 0x22970ea8, 0x22a40000) from space 64K, 99% used [0x22a50000, 0x22a5fff8, 0x22a60000) to space 64K, 0% used [0x22a40000, 0x22a40000, 0x22a50000) tenured generation total 4096K, used 76K [0x22e40000, 0x23240000, 0x26960000) the space 4096K, 1% used [0x22e40000, 0x22e53060, 0x22e53200, 0x23240000) compacting perm gen total 12288K, used 137K [0x26960000, 0x27560000, 0x2a960000) the space 12288K, 1% used [0x26960000, 0x26982518, 0x26982600, 0x27560000) ro space 8192K, 62% used [0x2a960000, 0x2ae5e4e8, 0x2ae5e600, 0x2b160000) rw space 12288K, 52% used [0x2b160000, 0x2b7a0e78, 0x2b7a1000, 0x2bd60000) Dynamic libraries: 0x00400000 - 0x00423000 C:\Program Files\Java\jre1.6.0_01\bin\javaw.exe 0x7c900000 - 0x7c9b0000 C:\WINDOWS\system32\ntdll.dll 0x7c800000 - 0x7c8f4000 C:\WINDOWS\system32\kernel32.dll 0x77dd0000 - 0x77e6b000 C:\WINDOWS\system32\ADVAPI32.dll 0x77e70000 - 0x77f01000 C:\WINDOWS\system32\RPCRT4.dll 0x7e410000 - 0x7e4a0000 C:\WINDOWS\system32\USER32.dll 0x77f10000 - 0x77f57000 C:\WINDOWS\system32\GDI32.dll 0x76390000 - 0x763ad000 C:\WINDOWS\system32\IMM32.DLL 0x7c340000 - 0x7c396000 C:\Program Files\Java\jre1.6.0_01\bin\msvcr71.dll 0x6d7c0000 - 0x6da07000 C:\Program Files\Java\jre1.6.0_01\bin\client\jvm.dll 0x76b40000 - 0x76b6d000 C:\WINDOWS\system32\WINMM.dll 0x5cd70000 - 0x5cd77000 C:\WINDOWS\system32\serwvdrv.dll 0x5b0a0000 - 0x5b0a7000 C:\WINDOWS\system32\umdmxfrm.dll 0x6d310000 - 0x6d318000 C:\Program Files\Java\jre1.6.0_01\bin\hpi.dll 0x76bf0000 - 0x76bfb000 C:\WINDOWS\system32\PSAPI.DLL 0x6d770000 - 0x6d77c000 C:\Program Files\Java\jre1.6.0_01\bin\verify.dll 0x6d3b0000 - 0x6d3cf000 C:\Program Files\Java\jre1.6.0_01\bin\java.dll 0x6d7b0000 - 0x6d7bf000 C:\Program Files\Java\jre1.6.0_01\bin\zip.dll 0x10000000 - 0x10012000 C:\Documents and Settings\Alex\workspace\MediaServer\rxtxSerial.dll 0x73d90000 - 0x73db7000 C:\WINDOWS\system32\crtdll.dll VM Arguments: jvm_args: -Djava.library.path=C:\Documents and Settings\Alex\workspace\MediaServer java_command: com.bjt.media.server.DigitoolConnection Launcher Type: SUN_STANDARD Environment Variables: CLASSPATH=.;C:\Program Files\Java\j2re1.4.2_07\lib\ext\QTJava.zip PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\wbem;c:\applications\php;C:\Program Files\MATLAB\R2006a\bin\win32;C:\Roger\Projects\UAV\Bin\Debug;C:\Program Files\Microsoft SQL Server\80\Tools\Binn\;c:\Program Files\Microsoft SQL Server\90\Tools\binn\;C:\Program Files\QuickTime\QTSystem\;C:\Pfps\system;C:\Program Files\Java\jdk1.6.0_01\bin;C:\Program Files\Java\jdk1.6.0_01\jre\bin USERNAME=Alex OS=Windows_NT PROCESSOR_IDENTIFIER=x86 Family 15 Model 4 Stepping 1, GenuineIntel --------------- S Y S T E M --------------- OS: Windows XP Build 2600 Service Pack 2 CPU:total 1 family 15, cmov, cx8, fxsr, mmx, sse, sse2 Memory: 4k page, physical 1046508k(275288k free), swap 2522816k(1909176k free) vm_info: Java HotSpot(TM) Client VM (1.6.0_01-b06) for windows-x86, built on Mar 14 2007 00:24:02 by "java_re" with unknown MS VC++:1310 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070604/c87ae1f0/attachment-0009.html From alwyn.schoeman at gmail.com Tue Jun 5 00:10:19 2007 From: alwyn.schoeman at gmail.com (Alwyn Schoeman) Date: Tue, 5 Jun 2007 08:10:19 +0200 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Hi, I'm using a similar modem. By default rxtx doesn't look for devices that start with ACM, so you need to modify the source code and recompile. Look in RXTXCommDriver and add values for ACM in the registerScannedPorts method in the Linux specific parts. Look for osName.equals("Linux")... On 6/4/07, soop soop wrote: > > Hi Guys, > > Looked through the archives but still cannot figure this out. I have a > Motorola G24 GPRS/GSM modem that I am connecting to my server running > Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not > detecting the port, CommPortIdentifier.getPortIdentifiers(). > > I have added the line to RXTXCommDriver: > > "ttyACM" // for USB Modems > > Rxtx still does not seem to find the port. Is there something I am missing > to make this port visable? > > [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver > [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device > [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control > Model > driver for USB modems and ISDN adapters > > I really need your help as I have moved my server from windows to Linux > and > have been down for a few days because of this .. Thanks so much! > > _________________________________________________________________ > PC Magazine's 2007 editors' choice for best Web mail?award-winning Windows > Live Hotmail. > > http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -- Alwyn Schoeman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/b6cb3053/attachment-0009.html From naranjo.manuel at gmail.com Tue Jun 5 06:48:45 2007 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Tue, 05 Jun 2007 09:48:45 -0300 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> References: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Message-ID: <46655BAD.7010501@gmail.com> That's right, an easier solution is creating symlinks to acm. For example make ttyS70 to 79 point to ACM0 to 9 and that will help you a lot, and doesn't even require compile. > Hi, > > I'm using a similar modem. By default rxtx doesn't look for devices > that start with ACM, so you need to modify the > source code and recompile. > > Look in RXTXCommDriver and add values for ACM in the > registerScannedPorts method in the Linux specific parts. Look for > osName.equals("Linux")... > From juanemc2 at gmail.com Tue Jun 5 07:02:43 2007 From: juanemc2 at gmail.com (Juan) Date: Tue, 5 Jun 2007 10:02:43 -0300 Subject: [Rxtx] Problems with Epson TMU220B POSPrinter using XON/XOFF Flow Control and rxtx jar and dll's with the serial port. Message-ID: Hi!, I?m having trouble printing to the serial port using the latest version of rxtx jar and dll's with an Epson POSPrinter. I`ve switched the printer to work with XON/XOFF Flow Control and have watched the serial port to be sure the printer is sending the XON XOFF stop and go characters. I`ve setted the port like this: CommPortIdentifier commPortIdentifier = CommPortIdentifier.* getPortIdentifier*(_portName); SerialPort serialPort = (SerialPort)commPortIdentifier.open(*this*.getClass().getName(), 2000); serialPort.setSerialPortParams(_baudRate, _dataBits, _stopBits, _parity); serialPort.setFlowControlMode( SerialPort.*FLOWCONTROL_XONXOFF_IN* | SerialPort.*FLOWCONTROL_XONXOFF_OUT*); where the baudRate is 9600 the dataBits is 8 the stopBits is 1 and the parity is 0 It seems as the library isn`t taking into account the XON XOFF setting. I would like to know if I`m setting correctly the Flow Control and if you had had any experiences using XON XOFF flow control and could give me some help to solve my problem. I`m very thankful in advance, Yours, Juan Polero -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/b080995a/attachment-0009.html From ehdez.correo at gmail.com Tue Jun 5 07:12:53 2007 From: ehdez.correo at gmail.com (=?ISO-8859-1?Q?Enrique_Hern=E1ndez?=) Date: Tue, 5 Jun 2007 09:12:53 -0400 Subject: [Rxtx] problem with rxtx Message-ID: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Hello: I doing a simple test to show the serial ports. This is the code: import java.util.Enumeration; import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; public class Show { private Enumeration portList; private CommPortIdentifier portId; private SerialPort port; /** Creates a new instance of Show */ public Show() { } public static void main(String args[]){ Show show = new Show(); show.portList = CommPortIdentifier.getPortIdentifiers(); String tPort = ""; System.out.println("========================================="); while(show.portList.hasMoreElements()){ show.portId = (CommPortIdentifier)show.portList.nextElement(); if(show.portId.getPortType() == CommPortIdentifier.PORT_SERIAL) tPort = "Serial"; else tPort = "Parallel"; System.out.println(show.portId.getName() + " " + tPort); } } } whit The problem is that this code not show the serial ports, this show the no use serial ports. I want to connect whit the modem but when windows open and connect the modem my application don't see the port(COMM3) when it is connect. what I can do? Is that the correct way to know the ports? thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/eedd744b/attachment-0009.html From ehdez.correo at gmail.com Tue Jun 5 07:42:13 2007 From: ehdez.correo at gmail.com (=?ISO-8859-1?Q?Enrique_Hern=E1ndez?=) Date: Tue, 5 Jun 2007 09:42:13 -0400 Subject: [Rxtx] serial port Message-ID: <4a814e1f0706050642p4ce9ac7bka80f9479c524c5ea@mail.gmail.com> Hello: How I can ask to the port what device is connect and information about this device. thanks. bye. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/4d10d26a/attachment-0009.html From supsoop at hotmail.com Tue Jun 5 09:29:00 2007 From: supsoop at hotmail.com (soop soop) Date: Tue, 05 Jun 2007 15:29:00 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Message-ID: Hi Guys, Thanks for all your help. I found the problem. I created a user, Tomcat55, for my tomcat but it did not belong to any group. I then added this user to dialout group to have access to the device ttyACM0. Works perfectly! Again permissions was the issue. This also seems to be persistent as a server reboot does not effect the access. Cheers! >From: "Alwyn Schoeman" >Reply-To: RXTX Developers and Users >To: "RXTX Developers and Users" >Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >Date: Tue, 5 Jun 2007 08:10:19 +0200 > >Hi, > >I'm using a similar modem. By default rxtx doesn't look for devices that >start with ACM, so you need to modify the >source code and recompile. > >Look in RXTXCommDriver and add values for ACM in the registerScannedPorts >method in the Linux specific parts. Look for osName.equals("Linux")... > >On 6/4/07, soop soop wrote: >> >>Hi Guys, >> >>Looked through the archives but still cannot figure this out. I have a >>Motorola G24 GPRS/GSM modem that I am connecting to my server running >>Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not >>detecting the port, CommPortIdentifier.getPortIdentifiers(). >> >>I have added the line to RXTXCommDriver: >> >>"ttyACM" // for USB Modems >> >>Rxtx still does not seem to find the port. Is there something I am missing >>to make this port visable? >> >>[ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver >>[ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device >>[ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control >>Model >>driver for USB modems and ISDN adapters >> >>I really need your help as I have moved my server from windows to Linux >>and >>have been down for a few days because of this .. Thanks so much! >> >>_________________________________________________________________ >>PC Magazine's 2007 editors' choice for best Web mail—award-winning Windows >>Live Hotmail. >> >>http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 >> >> >>_______________________________________________ >>Rxtx mailing list >>Rxtx at qbang.org >>http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > >-- >Alwyn Schoeman >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ Need a break? Find your escape route with Live Search Maps. http://maps.live.com/default.aspx?ss=Restaurants~Hotels~Amusement%20Park&cp=33.832922~-117.915659&style=r&lvl=13&tilt=-90&dir=0&alt=-1000&scene=1118863&encType=1&FORM=MGAC01 From netbeans at gatworks.com Tue Jun 5 09:42:31 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 11:42:31 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <46658467.20101@gatworks.com> soop soop wrote: > > Hi Guys, > > Thanks for all your help. I found the problem. I created a user, > Tomcat55, for my tomcat but it did not belong to any group. I then added Look at man pages for the program udev. From tjarvi at qbang.org Tue Jun 5 18:18:17 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Jun 2007 18:18:17 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Message-ID: On Tue, 5 Jun 2007, Enrique Hern?ndez wrote: > The problem is that this code not show the serial ports, this show the no > use serial ports. I want to connect whit the modem but when windows open and > connect the modem my application don't see the port(COMM3) when it is > connect. > what I can do? > Is that the correct way to know the ports? > Hello, We may have problems understanding each other. On windows, the port will not be an available serial port if another application has the port open. That is just how the library behaves. If you can not see the port in the enumerated list, you could not open it. Also note that enumeration only happens once. If you add a port such as a new USB dongle, the port will not be visible until the next time your application runs. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Tue Jun 5 18:45:01 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 20:45:01 -0400 Subject: [Rxtx] problem with rxtx In-Reply-To: References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Message-ID: <4666038D.8090700@gatworks.com> Trent Jarvi wrote: > > > Also note that enumeration only happens once. If you add a port such as > a new USB dongle, the port will not be visible until the next time your > application runs. Is this written in stone ? somewhere? From tjarvi at qbang.org Tue Jun 5 18:54:36 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Jun 2007 18:54:36 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <4666038D.8090700@gatworks.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> Message-ID: On Tue, 5 Jun 2007, Uncle George wrote: > Trent Jarvi wrote: >> >> >> Also note that enumeration only happens once. If you add a port such as >> a new USB dongle, the port will not be visible until the next time your >> application runs. > > Is this written in stone ? somewhere? It is just the current behavior. There is nothing preventing a fix that allows reenumeration. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Tue Jun 5 19:55:19 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 21:55:19 -0400 Subject: [Rxtx] problem with rxtx In-Reply-To: References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> Message-ID: <46661407.4020308@gatworks.com> >> Is this written in stone ? somewhere? > > It is just the current behavior. There is nothing preventing a fix that > allows reenumeration. With usb, ..... , things come and go. Seems a shame that you have to kill application to get at the device u just plugged in. From joachim at buechse.ch Wed Jun 6 01:50:06 2007 From: joachim at buechse.ch (Joachim Buechse) Date: Wed, 6 Jun 2007 09:50:06 +0200 Subject: [Rxtx] problem with rxtx In-Reply-To: <46661407.4020308@gatworks.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> <46661407.4020308@gatworks.com> Message-ID: <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> On MacOS RXTX's enumeration handling is more flexible. It will find new ports that are added during the lifetime of the application. But this is inherently incompatible with suns javax.comm implementation... Regards, Joachim On 06.06.2007, at 03:55, Uncle George wrote: > >>> Is this written in stone ? somewhere? >> >> It is just the current behavior. There is nothing preventing a >> fix that >> allows reenumeration. > > With usb, ..... , things come and go. Seems a shame that you have to > kill application to get at the device u just plugged in. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Jun 6 06:06:48 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Jun 2007 06:06:48 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> <46661407.4020308@gatworks.com> <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> Message-ID: Sun's javax.comm is not a major concern going forward. As long as we do not break old applications using rxtx, I see no reason to limit rxtx to that convention. We have already rejected version 3 from Sun as a dead end and limited our compatability to version 2. That does not mean we will not try to work with Sun and others but the current javax.comm convention (v3) is not a well conceived path. There has been discussion about doing a JSR which is one valid option. On Wed, 6 Jun 2007, Joachim Buechse wrote: > On MacOS RXTX's enumeration handling is more flexible. It will find > new ports that are added during the lifetime of the application. But > this is inherently incompatible with suns javax.comm implementation... > > Regards, > Joachim > > On 06.06.2007, at 03:55, Uncle George wrote: > >> >>>> Is this written in stone ? somewhere? >>> >>> It is just the current behavior. There is nothing preventing a >>> fix that >>> allows reenumeration. >> >> With usb, ..... , things come and go. Seems a shame that you have to >> kill application to get at the device u just plugged in. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From yvespielusenet at free.fr Wed Jun 6 08:46:35 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 16:46:35 +0200 Subject: [Rxtx] [PARALLEL] resource in use Message-ID: <1181141195.3407.20.camel@localhost.localdomain> Hello, I want to use rxtx in my application. I haveto send data to a very old printer (which have a drum and hammers http://perso.orange.fr/tiie/page00010017.html) This is printer is connecter with centronics. It works well but, while it's writting and I putthe printer off-line, after about 45 seconds, I have this error : ------------------------------------- java.io.IOException: La ressource demand?e est en cours d'utilisation. in writeArray at gnu.io.LPRPort.writeArray(Native Method) at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:292) at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:161) at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:156) at mce.buffer.bufferManager.BufferManager$PrintBuffer.run(BufferManager.java:141) The IOexception means "The wanted resource is in use" ------------------------------------- Here is the line 141 of BufferManager : ------------------------------------- while(send){ try{ fos.write(bb); <=== line 141 send = false; } catch(Exception e){ javax.swing.JOptionPane.showMessageDialog(null, "Erreur d'envoie. Veuillez cliquer sur OK pour relancer l'impression de la vignette.\nV?rifiez votre impression !", "Erreur d'envoie", javax.swing.JOptionPane.WARNING_MESSAGE); e.printStackTrace(System.err); System.err.flush(); System.out.println(e); send = true; } } -------------------------------- 'fos' is an outputstream which contains the rxtx stream (this.os is the rxtx outputstream) : -------------------------------- public void write(byte[] bb) throws IOException{ this.write(bb, 0, bb.length); } public void write(byte[] bb, int off, int len) throws IOException{ while(!imp1.isPrinterSelected() || !imp2.isPrinterSelected()){ } this.os.write(bb, off, len); } -------------------------------- Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( can you help me ? thank you :) -- yves piel From yvespielusenet at free.fr Wed Jun 6 09:11:15 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 17:11:15 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181141195.3407.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> Message-ID: <1181142675.3407.23.camel@localhost.localdomain> I forgot to tell that It's under windows XP and java 1.5. Le mercredi 06 juin 2007 ? 16:46 +0200, yves pielusenet a ?crit : > Hello, > I want to use rxtx in my application. I haveto send data to a very old > printer (which have a drum and hammers > http://perso.orange.fr/tiie/page00010017.html) > This is printer is connecter with centronics. It works well but, while > it's writting and I putthe printer off-line, after about 45 seconds, I > have this error : > ------------------------------------- > java.io.IOException: La ressource demand?e est en cours d'utilisation. > in writeArray > at gnu.io.LPRPort.writeArray(Native Method) > at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:292) > at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:161) > at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:156) > at mce.buffer.bufferManager.BufferManager$PrintBuffer.run(BufferManager.java:141) > > The IOexception means "The wanted resource is in use" > ------------------------------------- > > Here is the line 141 of BufferManager : > > ------------------------------------- > while(send){ > try{ > fos.write(bb); <=== line 141 > send = false; > } > catch(Exception e){ > javax.swing.JOptionPane.showMessageDialog(null, "Erreur d'envoie. Veuillez cliquer sur OK pour relancer l'impression de la vignette.\nV?rifiez votre impression !", "Erreur d'envoie", javax.swing.JOptionPane.WARNING_MESSAGE); > e.printStackTrace(System.err); > System.err.flush(); > System.out.println(e); > send = true; > } > } > -------------------------------- > 'fos' is an outputstream which contains the rxtx stream (this.os is the rxtx outputstream) : > > -------------------------------- > public void write(byte[] bb) throws IOException{ > this.write(bb, 0, bb.length); > } > public void write(byte[] bb, int off, int len) throws IOException{ > while(!imp1.isPrinterSelected() || !imp2.isPrinterSelected()){ > } > this.os.write(bb, off, len); > } > -------------------------------- > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > can you help me ? > > thank you :) > From netbeans at gatworks.com Wed Jun 6 09:21:46 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 11:21:46 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181141195.3407.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> Message-ID: <4666D10A.8000507@gatworks.com> } > -------------------------------- > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > can you help me ? > > thank you :) > windoz or linux? ( I guess windoz ) for windoz, there appears to be a timeout ( as Comments suggest ) of about 40seconds. > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } for linux, there is no implied timeout. > if( write( fd, bytes, count ) < 0 ) > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); From netbeans at gatworks.com Wed Jun 6 09:39:41 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 11:39:41 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666D10A.8000507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> Message-ID: <4666D53D.90000@gatworks.com> Uncle George wrote: > } >> -------------------------------- >> >> Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( >> >> can you help me ? From reading the code, I can see your concern. And it appears you are correct, because some of the data will be sent to the OS printer buffers, and then it will refuse to accept anymore. Unfortunately, writeArray does not return the num of characters written :{ So application has no idea to how many characters were accepted by the OS. I dont do windoz, so I cant say with absolute certainty what windoz will do with an off-line condition. If you have the source, and can compile, then maybe u can increase the loop count to hit 4hours? From yvespielusenet at free.fr Wed Jun 6 09:53:25 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 17:53:25 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666D10A.8000507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> Message-ID: <1181145205.3407.35.camel@localhost.localdomain> Thank you for your explanation :) This timeout comes when no data has been send to the printer after 40seconds if I well understand. But why there is such a timeout ? If I setthe printer offline while it's printing I mustn't have an exception. I don't understand why the "printer should solv all problems like buffer full" in 40 seconds. If I pause the printer the buffer will not be emptied, isn't it ? I not very familiar with C/C++, but it seem that the exception is thrown only when countWritten == 0, that means no data at all has been sent. So Is my code is good since when I intercept this exception I send all my buffer again. There is no way that the printer receive two times same bytes ? thanks ps: yes the application is running on windows XP since I developpe under Debian Le mercredi 06 juin 2007 ? 11:21 -0400, Uncle George a ?crit : > } > > -------------------------------- > > > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > > > can you help me ? > > > > thank you :) > > > > windoz or linux? ( I guess windoz ) > > for windoz, there appears to be a timeout ( as Comments suggest ) of > about 40seconds. > > while( count > 0 ){ > > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > > /* > > this are 20 * 2 seconds, in this time a printer (or other parallel device) > > should solv all problems like buffer full, etc > > */ > > if(errorCount++ < 20){ > > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > > continue; > > } > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > for linux, there is no implied timeout. > > if( write( fd, bytes, count ) < 0 ) > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Wed Jun 6 10:34:24 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 12:34:24 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181145205.3407.35.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> Message-ID: <4666E210.30507@gatworks.com> yves pielusenet wrote: > Thank you for your explanation :) > This timeout comes when no data has been send to the printer after > 40seconds if I well understand. But why there is such a timeout ? If I > setthe printer offline while it's printing I mustn't have an exception. > I don't understand why the "printer should solv all problems like buffer > full" in 40 seconds. If I pause the printer the buffer will not be > emptied, isn't it ? > > I not very familiar with C/C++, but it seem that the exception is thrown > only when countWritten == 0, that means no data at all has been sent. So > Is my code is good since when I intercept this exception I send all my > buffer again. There is no way that the printer receive two times same > bytes ? More technically, the function call returns and reports that 0 characters was written in this call. when 0 characters are written, it will check how many times 0 characters was written. If it has tried LESS than 20 times(errorCount), it will sleep() and try to write again. After 20 times, it wont sleep, but throw you the exception. Now suppose you are writing a 120 character line. you off-lined/paused your printer. The OS has room for 80 more characters in it's printer buffer. The WriteFile() will have a char count of 120, but on return the countWritten = 80. You still have 40 more characters to print. Since countWritten != 0, the counters: bytes += countWritten; count -= countWritten; get updated, and the Writefile now has a count of 40 characters. Since the printer is off-line, the countwritten is 0. And so the loop continues, till 40 seconds is up. As to why it is this way, i dont know ( not a windoz maven ); Also the sleep(20) in the loop is not so intuitive to suggest 2 seconds of sleep. I would have guessed 20seconds, or 20milliseconds. But go figure. BTW: Since your computer sends you error messages in French, does it curse in English? :)))) From yvespielusenet at free.fr Thu Jun 7 02:27:44 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Thu, 07 Jun 2007 10:27:44 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666E210.30507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> Message-ID: <1181204864.3501.10.camel@localhost.localdomain> Maybe in my case I should re-compile rxtx and change the code. Instead of send an exception I should display a dialog box to ask if it's printer problem or if it should trie to send bytes. Something like : while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } if(displayDialogBox("Try again to send datas ??")){ errorCount = 0; } else{ throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } } Le mercredi 06 juin 2007 ? 12:34 -0400, Uncle George a ?crit : > yves pielusenet wrote: > > Thank you for your explanation :) > > This timeout comes when no data has been send to the printer after > > 40seconds if I well understand. But why there is such a timeout ? If I > > setthe printer offline while it's printing I mustn't have an exception. > > I don't understand why the "printer should solv all problems like buffer > > full" in 40 seconds. If I pause the printer the buffer will not be > > emptied, isn't it ? > > > > I not very familiar with C/C++, but it seem that the exception is thrown > > only when countWritten == 0, that means no data at all has been sent. So > > Is my code is good since when I intercept this exception I send all my > > buffer again. There is no way that the printer receive two times same > > bytes ? > More technically, the function call returns and reports that 0 > characters was written in this call. > when 0 characters are written, it will check how many times 0 characters > was written. If it has tried LESS than 20 times(errorCount), it will > sleep() and try to write again. > After 20 times, it wont sleep, but throw you the exception. > > Now suppose you are writing a 120 character line. you off-lined/paused > your printer. The OS has room for 80 more characters in it's printer > buffer. The WriteFile() will have a char count of 120, but on return the > countWritten = 80. You still have 40 more characters to print. > Since countWritten != 0, the counters: > bytes += countWritten; > count -= countWritten; > get updated, and the Writefile now has a count of 40 characters. Since > the printer is off-line, the countwritten is 0. And so the loop > continues, till 40 seconds is up. > > As to why it is this way, i dont know ( not a windoz maven ); > Also the sleep(20) in the loop is not so intuitive to suggest 2 seconds > of sleep. I would have guessed 20seconds, or 20milliseconds. But go figure. > > BTW: Since your computer sends you error messages in French, does it > curse in English? :)))) > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 06:11:43 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 08:11:43 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181204864.3501.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> Message-ID: <4667F5FF.8070903@gatworks.com> your suggestion appears good. I dont know what displayDialogBox exactly will do, so all I can say it that it looks good. But I'd like to wait 10min before first dialog box And a 5 min wait for every dialog box there after. And since these are custom solution/choices, maybe a more exact explanation of what the issue is. if(errorCount++ < 300){ // wait 10min ( 10min * 60sec / 2 ) Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } if(displayDialogBox("Printer has Paused. Retry sending data?")){ errorCount = 150; // Wait for 5 min thereafter continue; } > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } yves pielusenet wrote: > Maybe in my case I should re-compile rxtx and change the code. Instead > of send an exception I should display a dialog box to ask if it's > printer problem or if it should trie to send bytes. Something like : > > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > > if(displayDialogBox("Try again to send datas ??")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > } > From yvespielusenet at free.fr Thu Jun 7 07:17:21 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Thu, 07 Jun 2007 15:17:21 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4667F5FF.8070903@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <4667F5FF.8070903@gatworks.com> Message-ID: <1181222241.3501.20.camel@localhost.localdomain> thank you :) 'displayDialogBox()' I think doesn't exist. It was just for the example :) But I think It should not be so complicated to display a dialog box under windows with YES/NO buttons. When yes is clicked it return 0 other it returns 1. Le jeudi 07 juin 2007 ? 08:11 -0400, Uncle George a ?crit : > your suggestion appears good. I dont know what displayDialogBox exactly > will do, so all I can say it that it looks good. > > But I'd like to wait 10min before first dialog box And a 5 min wait for > every dialog box there after. And since these are custom > solution/choices, maybe a more exact explanation of what the issue is. > > if(errorCount++ < 300){ // wait 10min ( 10min * 60sec / 2 ) > Sleep( 20 ); /* make a small pause to execute all other requests > in all other threads */ > continue; > } > > if(displayDialogBox("Printer has Paused. Retry sending data?")){ > errorCount = 150; // Wait for 5 min thereafter > continue; > } > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > > yves pielusenet wrote: > > Maybe in my case I should re-compile rxtx and change the code. Instead > > of send an exception I should display a dialog box to ask if it's > > printer problem or if it should trie to send bytes. Something like : > > > > while( count > 0 ){ > > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > > /* > > this are 20 * 2 seconds, in this time a printer (or other parallel device) > > should solv all problems like buffer full, etc > > */ > > if(errorCount++ < 20){ > > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > > continue; > > } > > > > if(displayDialogBox("Try again to send datas ??")){ > > errorCount = 0; > > } > > else{ > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > } > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 07:41:43 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 09:41:43 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181222241.3501.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <4667F5FF.8070903@gatworks.com> <1181222241.3501.20.camel@localhost.localdomain> Message-ID: <46680B17.8050109@gatworks.com> yves pielusenet wrote: > thank you :) > 'displayDialogBox()' I think doesn't exist. It was just for the > example :) too bad. Good luck. From rtrout at webbresearch.com Thu Jun 7 11:23:04 2007 From: rtrout at webbresearch.com (Robert Trout) Date: Thu, 07 Jun 2007 13:23:04 -0400 Subject: [Rxtx] Disconnected PortServer TS causes Java to hang Message-ID: <1181236984.14186.33.camel@sisyphus.DinkumSoftware.com> I'm running Linux with sun's Java 1.4.2, Java comm API 2.0, RXTX 2.0-7pre1, and the RealPort digi driver. "/dev/ttyrp00" is a RealPort device. My Java application never returns from a ComPortIdentifier.getPortIdentifier("/dev/ttyrp00") call while the Digi PortServer TS 4 is disconnected from the network. If I later re-connect the PortServer, the call returns about 30 seconds later (it's like a serial port read or write is blocking until the PortServer is re- connected). With the PortServer disconnected, minicom immediately responds with "cannot open /dev/ttyrp00: No such file or directory". I would like my Java application to behave similarly. That is, respond with an error condition instead of hanging when the PortServer is not connected. Since minicom and Java behave differently, I think this "hanging" behavior may be due to RXTX or Java? Has anyone had a similar issue? Solutions? Suggestions? Thanks, Robert From vicnevicne at gmail.com Thu Jun 7 12:16:02 2007 From: vicnevicne at gmail.com (Vicne) Date: Thu, 07 Jun 2007 20:16:02 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181204864.3501.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> Message-ID: <46684B62.7080802@gmail.com> yves pielusenet wrote: > Maybe in my case I should re-compile rxtx and change the code. Instead > of send an exception I should display a dialog box to ask if it's > printer problem or if it should trie to send bytes. Something like : > > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > > if(displayDialogBox("Try again to send datas ??")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > } > Sorry to step in without a specific solution to your problem, but I wanted to share my feeling regarding this proposal. AFAIK, it's generally considered bad practice to pop-up a prompt from a library. The main reason is that in general use, you can't guarantee that someone is actually present behind the console. Imagine a print server in a machine room, connected to a park of printers. In that case, when one printer fails, the logical behaviour would be to use an other one. If you change RxTx the way you propose, the printer queue will simply be stuck with a useless "Try again to send data ?" prompt until an administrator opens a remote connection to the print server's console and clicks "no". Second, it would create a dependency upon the existence of a graphical console (if you go the graphical "dialogBox" way). On many applications (typically server or embedded ones), the JVM is "headless" and if you try to pop-up a dialog, your app would throw an exception (at best) or just wouldn't display the prompt anywhere... Going the "text console" way is not more reliable, because on graphical environments, the text console is hidden unless explicitly requested. My advice would be to think again and find another solution. Ideas are : - make the number of retries a parameter so that you can tune it to what you think is reasonable - throw a more specific exception when the number of retries has been reached, so that a specific prompt can be shown at a higher level Anyway, if you feel that the prompt is the way to go in your case, I would at least make that prompt conditional. The least intrusive way would probably be using a system property, like if("true".equals(System.getProperty("org.rxtx.usePrompt")) && displayDialogBox("Retry sending data ?")){ errorCount = 0; } else{ throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } By default, the behaviour would remain as it is now, but you could force the prompts by defining the property at VM launch if desired. (for example : java.exe -Dorg.rxtx.usePrompt=true myApp) Also, you seemed to say you wanted the printer to start again exactly where is stopped. It would indeed be the best way when the printer is put offline for a few seconds. On the other hand, if the printer is turned off (or the printer runs out of paper, or someone steps on the mains cable), then the only way to go back to a "stable" situation would be by printing the item (page, label, etc.) again from scratch... Just my two cents. Vicne PS : By the way, the dialog box thing is very platform dependant on the C-side, and I think the simplest way would probably be to bridge it to a Java call where you can implement it like you proposed : public boolean displayDialogBox(prompt) { return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); } From netbeans at gatworks.com Thu Jun 7 14:08:24 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 16:08:24 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46684B62.7080802@gmail.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> Message-ID: <466865B8.4060004@gatworks.com> My feeling is that the code that was suggested was for his environs ( his shop ). The issue here is that after a 40+ second wait, an exception will be thrown. But you really dont have a way of 'cancelling' all the WriteFiles() that have already occured before the exception so that your writeArray and the Commapi can backtrack to a position in which they are in sync. The main ( really mine ) concern is not to lose data, or replicate data. After 40seconds, 300 seconds, 55min, no matter how long, data should not be lost or duplicated. But as soon as the exception is thrown, that possibility exists. Maybe an event should be thrown instead? Vicne wrote: > yves pielusenet wrote: >> Maybe in my case I should re-compile rxtx and change the code. Instead >> of send an exception I should display a dialog box to ask if it's >> printer problem or if it should trie to send bytes. Something like : >> >> while( count > 0 ){ >> if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ >> /* >> this are 20 * 2 seconds, in this time a printer (or other parallel device) >> should solv all problems like buffer full, etc >> */ >> if(errorCount++ < 20){ >> Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ >> continue; >> } >> >> if(displayDialogBox("Try again to send datas ??")){ >> errorCount = 0; >> } >> else{ >> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >> break; >> } >> } >> > > Sorry to step in without a specific solution to your problem, but I > wanted to share my feeling regarding this proposal. AFAIK, it's > generally considered bad practice to pop-up a prompt from a library. > The main reason is that in general use, you can't guarantee that > someone is actually present behind the console. Imagine a print server > in a machine room, connected to a park of printers. In that case, when > one printer fails, the logical behaviour would be to use an other one. > If you change RxTx the way you propose, the printer queue will simply be > stuck with a useless "Try again to send data ?" prompt until an > administrator opens a remote connection to the print server's console > and clicks "no". > Second, it would create a dependency upon the existence of a > graphical console (if you go the graphical "dialogBox" way). On many > applications (typically server or embedded ones), the JVM is "headless" > and if you try to pop-up a dialog, your app would throw an exception (at > best) or just wouldn't display the prompt anywhere... Going the "text > console" way is not more reliable, because on graphical environments, > the text console is hidden unless explicitly requested. > > My advice would be to think again and find another solution. Ideas are : > - make the number of retries a parameter so that you can tune it to what > you think is reasonable > - throw a more specific exception when the number of retries has been > reached, so that a specific prompt can be shown at a higher level > > Anyway, if you feel that the prompt is the way to go in your case, I > would at least make that prompt conditional. The least intrusive way > would probably be using a system property, like > > if("true".equals(System.getProperty("org.rxtx.usePrompt")) > && displayDialogBox("Retry sending data ?")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > > > By default, the behaviour would remain as it is now, but you could > force the prompts by defining the property at VM launch if desired. (for > example : java.exe -Dorg.rxtx.usePrompt=true myApp) > > > Also, you seemed to say you wanted the printer to start again > exactly where is stopped. It would indeed be the best way when the > printer is put offline for a few seconds. On the other hand, if the > printer is turned off (or the printer runs out of paper, or someone > steps on the mains cable), then the only way to go back to a "stable" > situation would be by printing the item (page, label, etc.) again from > scratch... > > > Just my two cents. > > > Vicne > > PS : By the way, the dialog box thing is very platform dependant on the > C-side, and I think the simplest way would probably be to bridge it to a > Java call where you can implement it like you proposed : > > public boolean displayDialogBox(prompt) { > return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", > JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); > } > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Thu Jun 7 17:48:11 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 Jun 2007 17:48:11 -0600 (MDT) Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <466865B8.4060004@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> Message-ID: An event is possible. I'm amazed this is the largest problem encountered while using the parallel code. How would the write ever exit if we throw events? Isn't this going to lead to hung applications? On Thu, 7 Jun 2007, Uncle George wrote: > My feeling is that the code that was suggested was for his environs ( > his shop ). > > The issue here is that after a 40+ second wait, an exception will be > thrown. But you really dont have a way of 'cancelling' all the > WriteFiles() that have already occured before the exception so that your > writeArray and the Commapi can backtrack to a position in which they are > in sync. > > The main ( really mine ) concern is not to lose data, or replicate data. > After 40seconds, 300 seconds, 55min, no matter how long, data should > not be lost or duplicated. But as soon as the exception is thrown, that > possibility exists. > > Maybe an event should be thrown instead? > > Vicne wrote: >> yves pielusenet wrote: >>> Maybe in my case I should re-compile rxtx and change the code. Instead >>> of send an exception I should display a dialog box to ask if it's >>> printer problem or if it should trie to send bytes. Something like : >>> >>> while( count > 0 ){ >>> if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ >>> /* >>> this are 20 * 2 seconds, in this time a printer (or other parallel device) >>> should solv all problems like buffer full, etc >>> */ >>> if(errorCount++ < 20){ >>> Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ >>> continue; >>> } >>> >>> if(displayDialogBox("Try again to send datas ??")){ >>> errorCount = 0; >>> } >>> else{ >>> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >>> break; >>> } >>> } >>> >> >> Sorry to step in without a specific solution to your problem, but I >> wanted to share my feeling regarding this proposal. AFAIK, it's >> generally considered bad practice to pop-up a prompt from a library. >> The main reason is that in general use, you can't guarantee that >> someone is actually present behind the console. Imagine a print server >> in a machine room, connected to a park of printers. In that case, when >> one printer fails, the logical behaviour would be to use an other one. >> If you change RxTx the way you propose, the printer queue will simply be >> stuck with a useless "Try again to send data ?" prompt until an >> administrator opens a remote connection to the print server's console >> and clicks "no". >> Second, it would create a dependency upon the existence of a >> graphical console (if you go the graphical "dialogBox" way). On many >> applications (typically server or embedded ones), the JVM is "headless" >> and if you try to pop-up a dialog, your app would throw an exception (at >> best) or just wouldn't display the prompt anywhere... Going the "text >> console" way is not more reliable, because on graphical environments, >> the text console is hidden unless explicitly requested. >> >> My advice would be to think again and find another solution. Ideas are : >> - make the number of retries a parameter so that you can tune it to what >> you think is reasonable >> - throw a more specific exception when the number of retries has been >> reached, so that a specific prompt can be shown at a higher level >> >> Anyway, if you feel that the prompt is the way to go in your case, I >> would at least make that prompt conditional. The least intrusive way >> would probably be using a system property, like >> >> if("true".equals(System.getProperty("org.rxtx.usePrompt")) >> && displayDialogBox("Retry sending data ?")){ >> errorCount = 0; >> } >> else{ >> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >> break; >> } >> >> >> By default, the behaviour would remain as it is now, but you could >> force the prompts by defining the property at VM launch if desired. (for >> example : java.exe -Dorg.rxtx.usePrompt=true myApp) >> >> >> Also, you seemed to say you wanted the printer to start again >> exactly where is stopped. It would indeed be the best way when the >> printer is put offline for a few seconds. On the other hand, if the >> printer is turned off (or the printer runs out of paper, or someone >> steps on the mains cable), then the only way to go back to a "stable" >> situation would be by printing the item (page, label, etc.) again from >> scratch... >> >> >> Just my two cents. >> >> >> Vicne >> >> PS : By the way, the dialog box thing is very platform dependant on the >> C-side, and I think the simplest way would probably be to bridge it to a >> Java call where you can implement it like you proposed : >> >> public boolean displayDialogBox(prompt) { >> return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", >> JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); >> } >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 19:18:51 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 21:18:51 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> Message-ID: <4668AE7B.3060409@gatworks.com> The UNIX version of writeArray is not too great either. It is possible that the write will only process some of the bytes. #else if( write( fd, bytes, count ) < 0 ) throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); #endif -------------------------------- Maybe it might be better to have the native function inform the caller of the # of characters written, then the commapi/output-buffer can be modified to reflect the #of chars written. If an exception is to be thrown, for too many loops of chars written == 0, then exception wont affect the state of the output buffer. Then a ParallelPort.restart() can be called to resume printing whats in the buffer. Trent Jarvi wrote: > An event is possible. I'm amazed this is the largest problem encountered > while using the parallel code. > > How would the write ever exit if we throw events? Isn't this going to > lead to hung applications? Sure. If you dont time out, then there is nothing that will force an EXIT from the write(). Issue is what has the OS done with the write. > > On Thu, 7 Jun 2007, Uncle George wrote: > >> My feeling is that the code that was suggested was for his environs ( >> his shop ). From yvespielusenet at free.fr Fri Jun 8 01:09:01 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Fri, 08 Jun 2007 09:09:01 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4668AE7B.3060409@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> Message-ID: <1181286541.3674.10.camel@localhost.localdomain> It is not possible that the rxtx java method write(byte[], int offset, int length) return anint which contains the number of byte really send to the printer instead of an exception ? So this is the programm which will see if all bytes have been sent. If not it can retry to send the unsended bytes. -------------------------------------------------------- int sended = 0; while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ sended += countWritten; /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } return sended; /*throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break;*/ } ... ... return countWritten; ------------------------------------------------ Le jeudi 07 juin 2007 ? 21:18 -0400, Uncle George a ?crit : > The UNIX version of writeArray is not too great either. It is possible > that the write will only process some of the bytes. > > #else > if( write( fd, bytes, count ) < 0 ) > throw_java_exception_system_msg( env, IO_EXCEPTION, > "writeArray" ); > #endif > -------------------------------- > > Maybe it might be better to have the native function inform the caller > of the # of characters written, then the commapi/output-buffer can be > modified to reflect the #of chars written. If an exception is to be > thrown, for too many loops of chars written == 0, then exception wont > affect the state of the output buffer. Then a ParallelPort.restart() can > be called to resume printing whats in the buffer. > > > Trent Jarvi wrote: > > An event is possible. I'm amazed this is the largest problem encountered > > while using the parallel code. > > > > How would the write ever exit if we throw events? Isn't this going to > > lead to hung applications? > Sure. If you dont time out, then there is nothing that will force an > EXIT from the write(). Issue is what has the OS done with the write. > > > > On Thu, 7 Jun 2007, Uncle George wrote: > > > >> My feeling is that the code that was suggested was for his environs ( > >> his shop ). > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Fri Jun 8 03:45:00 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 11:45:00 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181286541.3674.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> Message-ID: <20070608094500.GC21069@elberon.bln.de.ingenico.com> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > It is not possible that the rxtx java method write(byte[], int offset, > int length) return anint which contains the number of byte really send > to the printer instead of an exception ? > So this is the programm which will see if all bytes have been sent. If > not it can retry to send the unsended bytes. I think write() is void because in Java people love to do this since OutputStream :-) Of course on such interfaces you cannot implement something nice. If you would have a int write, you would not implement the interface and no applications expecting this interface would link/work/compile. oki, Steffen P.S.: (OT) If you propose not to implement the Java interfaces (especially not on JNI level), maybe optionally offering a wrapper that removes e.g. the write return value and so on to downgrade the powerful classic old POSIX read/write style to the modern limited Java style, then I agree :-) Same for read. Instead of things like "int avialable()" it is more powerful to have an approach as select(2) offers (to guarante the caller that read/write will not block [nothing else make sense anyway IMHO] but may read/write less bytes then requested). The caller gets full control and the higher level protocols can care about timeouts, invoking read in some loops and/or implement retransmission. On top of such an implementation, where everything is controlled, defined, guaranteed and reliable, someone could use an InputStream or OutputStream style interface. Or even better: don't use them at all :) just BTW :-) St. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From yvespielusenet at free.fr Fri Jun 8 05:52:45 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Fri, 08 Jun 2007 13:52:45 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <20070608094500.GC21069@elberon.bln.de.ingenico.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> Message-ID: <1181303565.11203.3.camel@localhost.localdomain> So maybe a better way should be to create a new Exception class which has a method "int getWrittenByte()". So the Exception should be use to send again bytes which are not printed yet. yves Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : > * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > > It is not possible that the rxtx java method write(byte[], int offset, > > int length) return anint which contains the number of byte really send > > to the printer instead of an exception ? > > So this is the programm which will see if all bytes have been sent. If > > not it can retry to send the unsended bytes. > > I think write() is void because in Java people love to do this > since OutputStream :-) Of course on such interfaces you cannot > implement something nice. If you would have a int write, you > would not implement the interface and no applications expecting > this interface would link/work/compile. > > oki, > > Steffen > > P.S.: (OT) > If you propose not to implement the Java interfaces (especially > not on JNI level), maybe optionally offering a wrapper that > removes e.g. the write return value and so on to downgrade the > powerful classic old POSIX read/write style to the modern limited > Java style, then I agree :-) Same for read. Instead of things > like "int avialable()" it is more powerful to have an approach as > select(2) offers (to guarante the caller that read/write will not > block [nothing else make sense anyway IMHO] but may read/write > less bytes then requested). The caller gets full control and the > higher level protocols can care about timeouts, invoking read in > some loops and/or implement retransmission. On top of such an > implementation, where everything is controlled, defined, > guaranteed and reliable, someone could use an InputStream or > OutputStream style interface. Or even better: don't use them at > all :) just BTW :-) > St. > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > 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. > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > 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. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Fri Jun 8 06:46:21 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 08:46:21 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181303565.11203.3.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> Message-ID: <46694F9D.5080501@gatworks.com> It seems that with outputstream.write(b[]), you become terribly uncoordinated as soon as an exception is thrown. Docs do not say what happens to the data. Yet from a practicable point of view, one would like to know if the write was accepted in-full, or rejected before any writes. There are no in betweens, as partial writes are not reportable. So for an outputstream.write(), in order for it to return, the full write request has to be taken, and stored in an internal output buffer. If there is no room, the write() is suspended, till there is room. Or throw's an IOException( "no room in buffer") ; As the select() loop for write reports buffer room avail, then more of the internal buffer is sent to the printer. yves pielusenet wrote: > So maybe a better way should be to create a new Exception class which > has a method "int getWrittenByte()". So the Exception should be use to > send again bytes which are not printed yet. > > yves > > Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : >> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: >>> It is not possible that the rxtx java method write(byte[], int offset, >>> int length) return anint which contains the number of byte really send >>> to the printer instead of an exception ? >>> So this is the programm which will see if all bytes have been sent. If >>> not it can retry to send the unsended bytes. >> I think write() is void because in Java people love to do this >> since OutputStream :-) Of course on such interfaces you cannot >> implement something nice. If you would have a int write, you >> would not implement the interface and no applications expecting >> this interface would link/work/compile. >> >> oki, >> >> Steffen >> >> P.S.: (OT) >> If you propose not to implement the Java interfaces (especially >> not on JNI level), maybe optionally offering a wrapper that >> removes e.g. the write return value and so on to downgrade the >> powerful classic old POSIX read/write style to the modern limited >> Java style, then I agree :-) Same for read. Instead of things >> like "int avialable()" it is more powerful to have an approach as >> select(2) offers (to guarante the caller that read/write will not >> block [nothing else make sense anyway IMHO] but may read/write >> less bytes then requested). The caller gets full control and the >> higher level protocols can care about timeouts, invoking read in >> some loops and/or implement retransmission. On top of such an >> implementation, where everything is controlled, defined, >> guaranteed and reliable, someone could use an InputStream or >> OutputStream style interface. Or even better: don't use them at >> all :) just BTW :-) >> St. >> >> About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. >> 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. >> >> About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. >> 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. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From Steffen.DETTMER at ingenico.com Fri Jun 8 08:12:18 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 16:12:18 +0200 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <46694F9D.5080501@gatworks.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: <20070608141218.GE21069@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 08:46 -0400: > It seems that with outputstream.write(b[]), you become terribly > uncoordinated as soon as an exception is thrown. Docs do not say what > happens to the data. (yes, so avoiding it seems to be good :)) > Yet from a practicable point of view, one would like to know if the > write was accepted in-full, or rejected before any writes. There are no > in betweens, as partial writes are not reportable. (which is an artificial API limitation. I never understood how this happend when they invented JDK because the well-known BSD socket API and thus [probably] WinSock does this correct, but anyway) > So for an outputstream.write(), in order for it to return, the full > write request has to be taken, and stored in an internal output buffer. > If there is no room, the write() is suspended, till there is room. Or > throw's an IOException( "no room in buffer") ; As the select() loop for > write reports buffer room avail, then more of the internal buffer is > sent to the printer. yes, might be good in case of a printer. May be horrible in case of PPP/TCP or some other transmission control protocol which may e.g. repeat data or even omit parts of it (e.g. internet realtime radio station broadcasting)... So I think the idea of "int write" (e.g. BSD sockets, linux files and so on) still is the best. A clean API / implementation should guarantee and allow implementations (users) to rely on that; assumptions and automatic background-sending and so on may look pragmatic and may even work on the first look, but may fail in other situations. BTW, if e.g. BSD socket API is known, why not simply copy it (until something better is invented :)) instead of fiddling around with JDK APIs? anyway, have a nice weekend everyone :-) oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Fri Jun 8 08:55:56 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 10:55:56 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070608141218.GE21069@elberon.bln.de.ingenico.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> Message-ID: <46696DFC.7000801@gatworks.com> >> write reports buffer room avail, then more of the internal buffer is >> sent to the printer. > > yes, might be good in case of a printer. May be horrible in case > of PPP/TCP or some other transmission control protocol which > may e.g. repeat data or even omit parts of it (e.g. internet > realtime radio station broadcasting)... So I think the idea of > "int write" (e.g. BSD sockets, linux files and so on) still is > the best. A clean API / implementation should guarantee and allow > implementations (users) to rely on that; assumptions and > automatic background-sending and so on may look pragmatic and may > even work on the first look, but may fail in other situations. > BTW, if e.g. BSD socket API is known, why not simply copy it > (until something better is invented :)) instead of fiddling > around with JDK APIs? But we were talking about the Parallel Port, and the transmission of data over the commapi/parallel-port schema. There isn't much in bi-directional software communication. Its a simple write one byte at a time interface. I'm not looking to change the comm-api. I'm just looking to alter the interaction between the Native ParallelPort functions, and the java ParallelPort functions that call them. This might be more readily doable than to get a committee to re-specify java-API specs. BTW: Whats is off-topic? ( help: not looking for def of off-topic ) From j.kenneth.gentle at acm.org Fri Jun 8 08:58:59 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Fri, 08 Jun 2007 10:58:59 -0400 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <20070608141218.GE21069@elberon.bln.de.ingenico.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> Message-ID: <200706081459.l58Ex5rA019991@qbang.org> Perhaps it is a bit late to jump in on this one, but here goes anyway. If the solutions all seem to "break" the contract with "java.io.outputstream", then, as noted, that may not be the appropriate contract. At the risk of being heretical, JDK1.4 introduced the "nio" package to address some of the compatibility issues with C apis mentioned in previous posts. The interface "java.nio.channels.WriteableByteChannel" defines the following single method: int write(ByteBuffer source); int, strangely enough, is the actual number of bytes written. So, if RXTX as written, against the JavaCOMM api and OutputStream, doesn't do what we want, how about writing a different set of bindings using the java.nio classes and as much of the underlying native code as possible. Note that just because the java.nio.channels.WriteableByteChannel sends back a result, OutputStream.write doesn't have to - and they could both call the same underlying native code. My 2 cents - maybe not worth even that... Ken From netbeans at gatworks.com Fri Jun 8 10:37:28 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 12:37:28 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <200706081459.l58Ex5rA019991@qbang.org> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> Message-ID: <466985C8.8000505@gatworks.com> Ken Gentle wrote: > Perhaps it is a bit late to jump in on this one, but here goes anyway. Common in, the waters fine. > > If the solutions all seem to "break" the contract with > "java.io.outputstream", then, as noted, that may not be the > appropriate contract. > How would the contract be broken? The machinery underneath is handling the contract. From j.kenneth.gentle at acm.org Fri Jun 8 10:48:01 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Fri, 08 Jun 2007 12:48:01 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466985C8.8000505@gatworks.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> Message-ID: <200706081648.l58Gm7YA022904@qbang.org> At 12:37 2007-06-08, you wrote: >Ken Gentle wrote: > > > > If the solutions all seem to "break" the contract with > > "java.io.outputstream", then, as noted, that may not be the > > appropriate contract. > > >How would the contract be broken? The machinery underneath is handling >the contract. It seems that a lot of the discussion has been about not only the timeout and being able to adjust it in the "machinery layer", but also about knowing in the Java layer, in the event of a timeout or exception, how many characters have been written to the device. An OutputStream won't ever do this with out an extension and including a return value "breaks" the contract, right? So, go with a Java IO api that *does* return the number of bytes written, out of the NIO package. I know it doesn't allow for a strict implementation of the JavaCOMM API - however, using NIO classes in place of the IO classes isn't that big a break and would allow those applications that need such information a way to get it. Maybe I'm misunderstanding the problem... Ken From netbeans at gatworks.com Fri Jun 8 11:24:14 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 13:24:14 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <200706081648.l58Gm7YA022904@qbang.org> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> Message-ID: <466990BE.7040100@gatworks.com> Ken Gentle wrote: An > OutputStream won't ever do this with out an extension and including a > return value "breaks" the contract, right? > i was not thinking of change the API to OutputSream. Are there specs for how output stream should work internally? for instance: String data = "Hello this is a line of data"; Outputstream.write( data.getbytes() ); ParallelPort.suspend(); int free = ParallelPort.getoutputbufferfree(); There is a symbiotic relationship between outputstream and the functionality of ParallelPort. From Steffen.DETTMER at ingenico.com Fri Jun 8 11:15:39 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 19:15:39 +0200 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <200706081459.l58Ex5rA019991@qbang.org> References: <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> Message-ID: <20070608171539.GK21069@elberon.bln.de.ingenico.com> * Ken Gentle wrote on Fri, Jun 08, 2007 at 10:58 -0400: > If the solutions all seem to "break" the contract with > "java.io.outputstream", then, as noted, that may not be the > appropriate contract. > > At the risk of being heretical, JDK1.4 introduced the "nio" package > to address some of the compatibility issues with C apis mentioned in > previous posts. The interface > "java.nio.channels.WriteableByteChannel" defines the following single method: > > int write(ByteBuffer source); > > int, strangely enough, is the actual number of bytes written. Yes, AFAIK one of the motivations for the NIO interface was, that the JDK-1.3 APIs (InputStream, e.g.) were not powerfull enough, especially for multi-connection-TCP servers or so. I don't know much about it but I've heard of a project where NIO usage was removed because of stability issues in multi-threaded environments and performance limitations under some circumstances. IIRC the "nio.ByteBuffer" is something very special (namely something you cannot implement in Java, it is "magic" or part of the language itself). Not sure if this is such a great idea (but for performance in the end sometimes heavy prices must be paid) :) > So, if RXTX as written, against the JavaCOMM api and OutputStream, > doesn't do what we want, how about writing a different set of > bindings using the java.nio classes and as much of the underlying > native code as possible. Yes, this would be an idea: use a full-featured interface on JNI, and, if wanted, deliver some wrappers converting this to a less-featured Java-compliant interface. However, powerful things as e.g. "select" are difficult to "emulate" if you are e.g. on some (older?) windows. But if you expose the full-featured APIs, you need to emulate them full-featured, theoretically. In the end it depends what you do on the serial line. If you just want to talk to a modem, then you may not need precise timeouts. But if you need to implement complexer protocols which define response times and timeouts, you may quickly get into difficulties. For instance, AFAIK, rxtx 1.7.2 (?) for windows is very messy with timeouts (there is a maximum, higher values are truncated; resolution is 100ms only; the function may take up to twice the timeout because internally it may be called twice). Probably for most people this is OK, but probably not for all. But having precise timeouts should be OK for all :-) Well, in the end it is nice to wish but somewhat hard to implement (many platforms, connections, USB, BlueTooth, whatever). oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Steffen.DETTMER at ingenico.com Fri Jun 8 11:04:22 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 19:04:22 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <46696DFC.7000801@gatworks.com> References: <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <46696DFC.7000801@gatworks.com> Message-ID: <20070608170422.GJ21069@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 10:55 -0400: > > BTW, if e.g. BSD socket API is known, why not simply copy it > > (until something better is invented :)) instead of fiddling > > around with JDK APIs? > > But we were talking about the Parallel Port, and the > transmission of data over the commapi/parallel-port schema. > There isn't much in bi-directional software communication. Its > a simple write one byte at a time interface. First, there are things like PLIP (http://en.wikipedia.org/wiki/Plip) - well, probably not widely used, sure ;) Second, I think if there is a good simple API known to support all that (with known "best practices") or so and there is no forcing need to invent a new one, why not simply using it? > I'm not looking to change the comm-api. I'm just looking to > alter the interaction between the Native ParallelPort > functions, and the java ParallelPort functions that call them. Ahh, yes. I think this is what I tried to ask. Having an usable JNI interface and on top (in pure java) some wrapper to InputStream or whatever could be done (e.g. by ignoring the return value of write or throwing if != length). Developers could then use the full-featured (non-JAVA-standard) API or select among various wrappers (as InputStream). > This might be more readily doable than to get a committee to > re-specify java-API specs. Yes, of course. I'm afraid that the Java APIs change regularily, but still yet with limited success it seems, so maybe they get it in one of the next iterations; who knows, maybe Java-9 has a BSD-like socket API :) SCNR. > BTW: Whats is off-topic? ( help: not looking for def of > off-topic ) I think I started some "re-specify java-API specs" which was OT probably. oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From lists at iDIAcomputing.com Fri Jun 8 18:48:54 2007 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Fri, 08 Jun 2007 20:48:54 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46684B62.7080802@gmail.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> Message-ID: <4669F8F6.3040101@iDIAcomputing.com> Vicne wrote: > Sorry to step in without a specific solution to your problem, but I > wanted to share my feeling regarding this proposal. AFAIK, it's > generally considered bad practice to pop-up a prompt from a library. ... > > My advice would be to think again and find another solution. Ideas are : > - make the number of retries a parameter so that you can tune it to what > you think is reasonable > - throw a more specific exception when the number of retries has been > reached, so that a specific prompt can be shown at a higher level You could also allow the client code to register a callback class which returns a boolean indicating whether to retry or cancel. This callback class could pop up a dialog, if appropriate, or follow some preset policy, or.... - George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From joachim at buechse.ch Sat Jun 9 09:43:16 2007 From: joachim at buechse.ch (Joachim Buechse) Date: Sat, 9 Jun 2007 17:43:16 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46694F9D.5080501@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: You should not forget, that in the case of an exception it may not even be known what happened to the data. You have a kernel buffer, outgoing chip buffer, incoming chip buffer, etc. So of course, it would be nice to know up to which point data was correctly processed, but this feedback does not exist on the hardware or protocol level and hence can in general not be magicly created on the software level... Regards, Joachim On 08.06.2007, at 14:46, Uncle George wrote: > It seems that with outputstream.write(b[]), you become terribly > uncoordinated as soon as an exception is thrown. Docs do not say what > happens to the data. > > Yet from a practicable point of view, one would like to know if the > write was accepted in-full, or rejected before any writes. There > are no > in betweens, as partial writes are not reportable. > > So for an outputstream.write(), in order for it to return, the full > write request has to be taken, and stored in an internal output > buffer. > If there is no room, the write() is suspended, till there is room. Or > throw's an IOException( "no room in buffer") ; As the select() loop > for > write reports buffer room avail, then more of the internal buffer is > sent to the printer. > > > > yves pielusenet wrote: >> So maybe a better way should be to create a new Exception class which >> has a method "int getWrittenByte()". So the Exception should be >> use to >> send again bytes which are not printed yet. >> >> yves >> >> Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : >>> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: >>>> It is not possible that the rxtx java method write(byte[], int >>>> offset, >>>> int length) return anint which contains the number of byte >>>> really send >>>> to the printer instead of an exception ? >>>> So this is the programm which will see if all bytes have been >>>> sent. If >>>> not it can retry to send the unsended bytes. >>> I think write() is void because in Java people love to do this >>> since OutputStream :-) Of course on such interfaces you cannot >>> implement something nice. If you would have a int write, you >>> would not implement the interface and no applications expecting >>> this interface would link/work/compile. >>> >>> oki, >>> >>> Steffen >>> >>> P.S.: (OT) >>> If you propose not to implement the Java interfaces (especially >>> not on JNI level), maybe optionally offering a wrapper that >>> removes e.g. the write return value and so on to downgrade the >>> powerful classic old POSIX read/write style to the modern limited >>> Java style, then I agree :-) Same for read. Instead of things >>> like "int avialable()" it is more powerful to have an approach as >>> select(2) offers (to guarante the caller that read/write will not >>> block [nothing else make sense anyway IMHO] but may read/write >>> less bytes then requested). The caller gets full control and the >>> higher level protocols can care about timeouts, invoking read in >>> some loops and/or implement retransmission. On top of such an >>> implementation, where everything is controlled, defined, >>> guaranteed and reliable, someone could use an InputStream or >>> OutputStream style interface. Or even better: don't use them at >>> all :) just BTW :-) >>> St. >>> >>> About Ingenico Throughout the world businesses rely on Ingenico >>> for secure and expedient electronic transaction acceptance. >>> Ingenico products leverage proven technology, established >>> standards and unparalleled ergonomics to provide optimal >>> reliability, versatility and usability. This comprehensive range >>> of products is complemented by a global array of services and >>> partnerships, enabling businesses in a number of vertical sectors >>> to accept transactions anywhere their business takes them. >>> 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. >>> >>> About Ingenico Throughout the world businesses rely on Ingenico >>> for secure and expedient electronic transaction acceptance. >>> Ingenico products leverage proven technology, established >>> standards and unparalleled ergonomics to provide optimal >>> reliability, versatility and usability. This comprehensive range >>> of products is complemented by a global array of services and >>> partnerships, enabling businesses in a number of vertical sectors >>> to accept transactions anywhere their business takes them. >>> 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. >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx 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 yvespielusenet at free.fr Mon Jun 11 03:15:12 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Mon, 11 Jun 2007 11:15:12 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: <1181553312.8335.14.camel@localhost.localdomain> So can someone tell a solution for my problem :( Must I say to the user to not put the printer off-line ? I can't since he has to do some pauses, verify print, paper conditioning etc... How do other people ? Before I use the parport librarry to read port status : http://www.geocities.com/Juanga69/parport/ (which doesn't work on windows XP) And I send data into the file LPT1 I use to have no problem when printer was disabled. thanks -- yves piel Le samedi 09 juin 2007 ? 17:43 +0200, Joachim Buechse a ?crit : > You should not forget, that in the case of an exception it may not > even be known what happened to the data. > > You have a kernel buffer, outgoing chip buffer, incoming chip buffer, > etc. So of course, it would be nice to know up to which point data > was correctly processed, but this feedback does not exist on the > hardware or protocol level and hence can in general not be magicly > created on the software level... > > Regards, > Joachim > > On 08.06.2007, at 14:46, Uncle George wrote: > > > It seems that with outputstream.write(b[]), you become terribly > > uncoordinated as soon as an exception is thrown. Docs do not say what > > happens to the data. > > > > Yet from a practicable point of view, one would like to know if the > > write was accepted in-full, or rejected before any writes. There > > are no > > in betweens, as partial writes are not reportable. > > > > So for an outputstream.write(), in order for it to return, the full > > write request has to be taken, and stored in an internal output > > buffer. > > If there is no room, the write() is suspended, till there is room. Or > > throw's an IOException( "no room in buffer") ; As the select() loop > > for > > write reports buffer room avail, then more of the internal buffer is > > sent to the printer. > > > > > > > > yves pielusenet wrote: > >> So maybe a better way should be to create a new Exception class which > >> has a method "int getWrittenByte()". So the Exception should be > >> use to > >> send again bytes which are not printed yet. > >> > >> yves > >> > >> Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : > >>> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > >>>> It is not possible that the rxtx java method write(byte[], int > >>>> offset, > >>>> int length) return anint which contains the number of byte > >>>> really send > >>>> to the printer instead of an exception ? > >>>> So this is the programm which will see if all bytes have been > >>>> sent. If > >>>> not it can retry to send the unsended bytes. > >>> I think write() is void because in Java people love to do this > >>> since OutputStream :-) Of course on such interfaces you cannot > >>> implement something nice. If you would have a int write, you > >>> would not implement the interface and no applications expecting > >>> this interface would link/work/compile. > >>> > >>> oki, > >>> > >>> Steffen > >>> > >>> P.S.: (OT) > >>> If you propose not to implement the Java interfaces (especially > >>> not on JNI level), maybe optionally offering a wrapper that > >>> removes e.g. the write return value and so on to downgrade the > >>> powerful classic old POSIX read/write style to the modern limited > >>> Java style, then I agree :-) Same for read. Instead of things > >>> like "int avialable()" it is more powerful to have an approach as > >>> select(2) offers (to guarante the caller that read/write will not > >>> block [nothing else make sense anyway IMHO] but may read/write > >>> less bytes then requested). The caller gets full control and the > >>> higher level protocols can care about timeouts, invoking read in > >>> some loops and/or implement retransmission. On top of such an > >>> implementation, where everything is controlled, defined, > >>> guaranteed and reliable, someone could use an InputStream or > >>> OutputStream style interface. Or even better: don't use them at > >>> all :) just BTW :-) > >>> St. > >>> > >>> About Ingenico Throughout the world businesses rely on Ingenico > >>> for secure and expedient electronic transaction acceptance. > >>> Ingenico products leverage proven technology, established > >>> standards and unparalleled ergonomics to provide optimal > >>> reliability, versatility and usability. This comprehensive range > >>> of products is complemented by a global array of services and > >>> partnerships, enabling businesses in a number of vertical sectors > >>> to accept transactions anywhere their business takes them. > >>> 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. > >>> > >>> About Ingenico Throughout the world businesses rely on Ingenico > >>> for secure and expedient electronic transaction acceptance. > >>> Ingenico products leverage proven technology, established > >>> standards and unparalleled ergonomics to provide optimal > >>> reliability, versatility and usability. This comprehensive range > >>> of products is complemented by a global array of services and > >>> partnerships, enabling businesses in a number of vertical sectors > >>> to accept transactions anywhere their business takes them. > >>> 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. > >>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx 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 > From Steffen.DETTMER at ingenico.com Mon Jun 11 03:56:18 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 11:56:18 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466990BE.7040100@gatworks.com> References: <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> Message-ID: <20070611095618.GA10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 13:24 -0400: > i was not thinking of change the API to OutputSream. Then I think either someone uses OutputStream (and has no reliable information about incomplete writes) or someone uses somethink else. > Are there specs for how output stream should work internally? > > for instance: > String data = "Hello this is a line of data"; > Outputstream.write( data.getbytes() ); > ParallelPort.suspend(); > int free = ParallelPort.getoutputbufferfree(); > > There is a symbiotic relationship between outputstream and the > functionality of ParallelPort. If you need OutputStream "plus something else", in short you're needing "something else". Personally I dislike the code above a lot. The stream "looks" like if it would be an OutputStream, but in fact it isn't. You need to call getoutputbufferfree later to check if write succeeded (but OutputStream promises that write succeedes synchronous, blocking, or throws an exception). So it is not an OutputStream. No application written for OutputStreams would work without change (because it won't know getoutputbufferfree at all). It is not abstracted from ParallelPort. I think this would be wrong. Then I think an alternative interface instead is better. Let's assume we had some "connection" (to distinguish between OutputStreams and Channels). Then why not working as on a file handle in POSIX: do { // ... select maybe using timer ... readyForWrite = ... if (readyForWrite) { int writtenBytes = connection.write(toWrite); toWrite.remove(0, writtenBytes); } while(readyForWrite && toWrite.length > 0); I think, having such a write isn't the big problem. I think, the difficult thing is around "select" - however this would look like. It should be OO, typesafe, performant, supporting multiple connections/channels/streams in various modes and should be orthogonal to other functionalities. Of course, this heavily depends on what the application is doing; for a simple situation (like reading a small, mandatory file from a local disk) this would be to uncomfortable (and offering unneeded features only). just BTW :) oki, Steffen -- // Modeline for VIM. Please don't remove. // (Help: autoindent, expandtab, shiftwidth=4, tabstop=4, textwidth=75) // vi: set ai et sw=4 ts=4 tw=75 ft=java: About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Mon Jun 11 05:38:33 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 07:38:33 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611095618.GA10821@elberon.bln.de.ingenico.com> References: <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> Message-ID: <466D3439.4020805@gatworks.com> Steffen DETTMER wrote: > (but OutputStream promises that write > succeedes synchronous, blocking, or throws an exception). Where is it so written? From Steffen.DETTMER at ingenico.com Mon Jun 11 06:36:50 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 14:36:50 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466D3439.4020805@gatworks.com> References: <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> <466D3439.4020805@gatworks.com> Message-ID: <20070611123650.GI10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Mon, Jun 11, 2007 at 07:38 -0400: > Steffen DETTMER wrote: > > > (but OutputStream promises that write > > succeedes synchronous, blocking, or throws an exception). > > Where is it so written? Now, as you ask, I think it is not written that clearly but follows from specification. mmm... Am I wrong? I understand the API doc in this way: * http://java.sun.com/j2se/1.4.2/docs/api/java/io/OutputStream.html#write(byte[]) > public void write(byte[] b) > throws IOException > > Writes b.length bytes from the specified byte array to this > output stream. The general contract for write(b) is that > it should have exactly the same effect as the call write(b, > 0, b.length). > > Parameters: > b - the data. > Throws: > IOException - if an I/O error occurs. > See Also: > write(byte[], int, int) and there is: > public void write(byte[] b, > int off, > int len) > throws IOException > > Writes len bytes from the specified byte array starting at > offset off to this output stream. The general contract for > write(b, off, len) is that some of the bytes in the array b > are written to the output stream in order; element b[off] > is the first byte written and b[off+len-1] is the last byte > written by this operation. > > The write method of OutputStream calls the write method of > one argument on each of the bytes to be written out. > Subclasses are encouraged to override this method and > provide a more efficient implementation. > > If b is null, a NullPointerException is thrown. > > If off is negative, or len is negative, or off+len is > greater than the length of the array b, then an > IndexOutOfBoundsException is thrown. > > Parameters: > b - the data. > off - the start offset in the data. > len - the number of bytes to write. > Throws: > IOException - if an I/O error occurs. In particular, an > IOException is thrown if the output stream is closed. In general, any specialisation (derived child class) must comform to this. So write in the end is specified (!) as "The write method ... calls the write method ... on each of the bytes to be written out". This is what must be implemented by ANY OutputStream. Of course, there is: "Subclasses are encouraged to override this method and provide a more efficient implementation." which IMHO does not contradict - the more efficient must behave in exactly the same way of course (just wasting less resources than a simple byte-by-byte write). So it does not matter here I think. The write that finally defines the behavior tells basically: > "Writes the specified byte to this output stream. The general > contract for write is that one byte is written to the output > stream. " > > Throws: > IOException - if an I/O error occurs. which IMHO is another way of saying "write writes the byte immediately and returns on success (only), otherwise an exception is thrown". Especially it cannot happen that zero bytes are written (i.e. the specified byte is NOT written) without an exception. So by this write must be synchronous and blocking, because otherwise it could not reliably know if an asynchronous operation will succeede or not (some getAsyncResult or so would be needed). Since write(byte[]) does this for each byte (or with a behavior beeing exactly the same as if it would do), I think this means that the write(byte[]) succeedes synchronous/blocking or throws an exception. Did I an error in reasoning or confused something or so? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From j.kenneth.gentle at acm.org Mon Jun 11 06:51:25 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 11 Jun 2007 08:51:25 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611123650.GI10821@elberon.bln.de.ingenico.com> References: <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> <466D3439.4020805@gatworks.com> <20070611123650.GI10821@elberon.bln.de.ingenico.com> Message-ID: <200706111251.l5BCpS9T017831@qbang.org> It is as Steffen describes. "InputStream" and "OutputStream" are inherently synchronous (which is why so many java programs resort to threads to use them). Anything outside of this "contract" is *not* an InputStream or OutputStream. That is why there is a new package for things that don't behave like the old *Stream classes - the NIO package. If you look carefully at the IO package, you'll note that almost all the classes are _Decorator_ pattern implementations of the *Stream classes - and the interface presents the _same_ behavior to the calling code in all cases - a synchronous operation that completes successfully or throws an exception (with the one exception of "read" that returns a "-1" on end-of-stream. I know I've read this numerous times - I'd suggest checking the Language Spec or one of the books by Bloch or Gosling. Ken At 08:36 2007-06-11, you wrote: >* Uncle George wrote on Mon, Jun 11, 2007 at 07:38 -0400: > > Steffen DETTMER wrote: > > > > > (but OutputStream promises that write > > > succeedes synchronous, blocking, or throws an exception). > > > > Where is it so written? > >Now, as you ask, I think it is not written that clearly but >follows from specification. mmm... > >Am I wrong? > >I understand the API doc in this way: > >* >http://java.sun.com/j2se/1.4.2/docs/api/java/io/OutputStream.html#write(byte[]) > > public void write(byte[] b) > > throws IOException > > > > Writes b.length bytes from the specified byte array to this > > output stream. The general contract for write(b) is that > > it should have exactly the same effect as the call write(b, > > 0, b.length). > > > > Parameters: > > b - the data. > > Throws: > > IOException - if an I/O error occurs. > > See Also: > > write(byte[], int, int) > > >and there is: > > > > public void write(byte[] b, > > int off, > > int len) > > throws IOException > > > > Writes len bytes from the specified byte array starting at > > offset off to this output stream. The general contract for > > write(b, off, len) is that some of the bytes in the array b > > are written to the output stream in order; element b[off] > > is the first byte written and b[off+len-1] is the last byte > > written by this operation. > > > > The write method of OutputStream calls the write method of > > one argument on each of the bytes to be written out. > > Subclasses are encouraged to override this method and > > provide a more efficient implementation. > > > > If b is null, a NullPointerException is thrown. > > > > If off is negative, or len is negative, or off+len is > > greater than the length of the array b, then an > > IndexOutOfBoundsException is thrown. > > > > Parameters: > > b - the data. > > off - the start offset in the data. > > len - the number of bytes to write. > > Throws: > > IOException - if an I/O error occurs. In particular, an > > IOException is thrown if the output stream is closed. > > >In general, any specialisation (derived child class) must comform >to this. So write in the end is specified (!) as "The write >method ... calls the write method ... on each of the bytes to be >written out". This is what must be implemented by ANY >OutputStream. > >Of course, there is: "Subclasses are encouraged to override this >method and provide a more efficient implementation." which IMHO >does not contradict - the more efficient must behave in exactly >the same way of course (just wasting less resources than a simple >byte-by-byte write). So it does not matter here I think. > > > >The write that finally defines the behavior tells basically: > > > "Writes the specified byte to this output stream. The general > > contract for write is that one byte is written to the output > > stream. " > > > > Throws: > > IOException - if an I/O error occurs. > > >which IMHO is another way of saying "write writes the byte >immediately and returns on success (only), otherwise an exception >is thrown". Especially it cannot happen that zero bytes are >written (i.e. the specified byte is NOT written) without an >exception. So by this write must be synchronous and blocking, >because otherwise it could not reliably know if an asynchronous >operation will succeede or not (some getAsyncResult or so would >be needed). > >Since write(byte[]) does this for each byte (or with a behavior >beeing exactly the same as if it would do), I think this means >that the write(byte[]) succeedes synchronous/blocking or throws >an exception. > >Did I an error in reasoning or confused something or so? > >oki, > >Steffen > >About Ingenico Throughout the world businesses rely on Ingenico for >secure and expedient electronic transaction acceptance. Ingenico >products leverage proven technology, established standards and >unparalleled ergonomics to provide optimal reliability, versatility >and usability. This comprehensive range of products is complemented >by a global array of services and partnerships, enabling businesses >in a number of vertical sectors to accept transactions anywhere >their business takes them. >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. > >About Ingenico Throughout the world businesses rely on Ingenico for >secure and expedient electronic transaction acceptance. Ingenico >products leverage proven technology, established standards and >unparalleled ergonomics to provide optimal reliability, versatility >and usability. This comprehensive range of products is complemented >by a global array of services and partnerships, enabling businesses >in a number of vertical sectors to accept transactions anywhere >their business takes them. >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. > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From alesinskyy at googlemail.com Mon Jun 11 07:25:33 2007 From: alesinskyy at googlemail.com (Oleksandr Alesinskyy) Date: Mon, 11 Jun 2007 15:25:33 +0200 Subject: [Rxtx] [OT] select :-) Message-ID: Sorry, but I have to disagree with following statement: "So write in the end is specified (!) as "The write method ... calls the write method ... on each of the bytes to be written out". This is what must be implemented by ANY OutputStream.". This is not part of the specification or contract, it is just revealed implementation detail of the OutputStream. It is not stated anywhere that behavoiur of derived classes shall conform with this one. Statement concerning "synchronous" nature of the output stream is invalid as well. Really synchronous stream does not require flush() but OutputStream has it. From Steffen.DETTMER at ingenico.com Mon Jun 11 08:21:16 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 16:21:16 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: Message-ID: <20070611142116.GN10821@elberon.bln.de.ingenico.com> * Oleksandr Alesinskyy wrote on Mon, Jun 11, 2007 at 15:25 +0200: > Sorry, but I have to disagree with following statement: > "So write in the end is specified (!) as "The write > method ... calls the write method ... on each of the bytes to be > written out". This is what must be implemented by ANY > OutputStream.". > > This is not part of the specification or contract, it is just > revealed implementation detail of the OutputStream. It is not > stated anywhere that behavoiur of derived classes shall conform > with this one. (I didn't meant that the implementation must really write byte by byte, but that it must "look as if it would do" - because all implementations of OutputStream must "look" in the same way [which is another way of saying "do abstract" I think]) I think the API doc is not "revealing implementation details" but it is the *specification* of that interface and derivations must (should) conform to this specification. Isn't this the idea of interfaces? A function that expects an OutputStream should work on ANY OutputStream, shouldn't it? just kidding: I mean, what would be the point in implementing a checksum function as OutputStream.write which throws its result as IOException? Or which requires to call close() as very first operation to tell that the application is about to transmit confidential data? :-) > Statement concerning "synchronous" nature of the output stream > is invalid as well. Really synchronous stream does not require > flush() but OutputStream has it. ahh, interesting point! I think this is another bug in the API. flush() is wrong. Because write specifies "The general contract for write is that one byte is written to the output stream." but not "a byte may be written or buffered". Actually, an application would need to call flush() after each write (or bunch of write calls) to ensure that write really did something otherwise I think. I didn't found in the spec of OutputStream that it would be required to call flush(). This should mean that calling flush is not required which in turn leads to the conclusion that write must be synchrous (private threads are forbidden because not specified :)) which in turn leads to the conclusion that flush() is not needed at all... I mean, what if someone would only store in write and do the "real write" in flush() and never else? An application could write in one stream and read on another one (e.g. in bidirectional communication) and would never get anything back, because nothing was actually written because no flush was called? Then someone could even think that on error in some write the data could remain buffered AND throw an exception, retrying to send the data in the next write. Ohh, and if there would be some message number inside, and underlaying write (e.g. a protocol offering InputStream/OutputStream) would check this and throw "DuplicatedMessageNumber" the stream would only throw it again and again beeing unusable... In short: I have no clue how someone could be able to implement an asynchrounos write (which is realiable and correct) without beeing specific to anything which is not specified by OutputStream. Well, I think in the end OutputStream was not intended for such communication or protocol implementations - but to read a local disk file or so. In case of I/O errors usually you can abort your application and change the hard disk :-) oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Bob_Jacobsen at lbl.gov Mon Jun 11 09:32:23 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Mon, 11 Jun 2007 08:32:23 -0700 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611142116.GN10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> Message-ID: At 4:21 PM +0200 6/11/07, Steffen DETTMER wrote: > > Statement concerning "synchronous" nature of the output stream >> is invalid as well. Really synchronous stream does not require >> flush() but OutputStream has it. > >ahh, interesting point! > >I think this is another bug in the API. flush() is wrong. Because >write specifies "The general contract for write is that one byte >is written to the output stream." but not "a byte may be written >or buffered". > >Actually, an application would need to call flush() after each >write (or bunch of write calls) to ensure that write really did >something otherwise I think. OutputStreams don't _have_ to be synchronous or asynchronous, but the OutputStream API was be arranged so that subclasses _can_ be synchronous or asynchronous. Such generality is the hardest part of getting an API right. Hence, if at some point a program using an OutputStream wants to be sure that the data has been pushed all the way out, flush() is available. For some subclasses, e.g. the buffered ones, this has important behavior. Others write the data from each call, and flush() doesn't do anything. You _can_ omit it in programs that are known to use this second type, but there's no requirement that you do so; the interface is general in that way. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From Steffen.DETTMER at ingenico.com Mon Jun 11 12:32:39 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 20:32:39 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> Message-ID: <20070611183239.GT10821@elberon.bln.de.ingenico.com> * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: > >Actually, an application would need to call flush() after each > >write (or bunch of write calls) to ensure that write really did > >something otherwise I think. > OutputStreams don't _have_ to be synchronous or asynchronous, > but the OutputStream API was be arranged so that subclasses > _can_ be synchronous or asynchronous. Ahh, oki. Thanks for the clarificaion. So in short, flush() MUST be called on OutputStream, this is just not documented correctly or so clearly (right?). So the overall usage semantics would be: 1. call write (multiple times if desired) 2. call flush only if both succeeded, write was successful. If flush fails it remains unknown if a part of the data was written and/or will be repeated. So the spec (API doc) is wrong. Correct would be to tell that write behaves as told as long as it is followed by a call to flush, otherwise data may or may not get lost (depending wheter close() is called and calls flush(), which seems not to be guaranteed/required). BTW, I think it is a little bit... erm... interesting to find the specification (java API doc reference) wrong, having a need to conclude it from the presence of some methods with "it would make no sense if they behave exactly as specified, so specification must be wrong (incomplete)". > Such generality is the hardest part of getting an API right. Yes, seems to be proven ;) > Hence, if at some point a program using an OutputStream wants > to be sure that the data has been pushed all the way out, > flush() is available. For some subclasses, e.g. the buffered > ones, this has important behavior. Others write the data from > each call, and flush() doesn't do anything. > You _can_ omit it in programs that are known to use this second > type, but there's no requirement that you do so; the interface > is general in that way. I think, it still it must be called always, otherwise the application could break if passing a different runtime type as OutputStream. I think, if the application/method needs a special "type of OutputStream" then the parameter type must be a subclass but not OutputStream, maybe a PrintStream or so - otherwise the compiler could not detect this error (passing wrong type). Is this correct? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Bob_Jacobsen at lbl.gov Mon Jun 11 13:00:52 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Mon, 11 Jun 2007 12:00:52 -0700 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611183239.GT10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> Message-ID: At 8:32 PM +0200 6/11/07, Steffen DETTMER wrote: >So the spec (API doc) is wrong. Correct would be to tell that >write behaves as told as long as it is followed by a call to >flush, otherwise data may or may not get lost (depending wheter >close() is called and calls flush(), which seems not to be >guaranteed/required). I'm not entirely sure that the spec is wrong, but reasonable people can differ on this. In the 1.5 JavaDocs, all that the docs say for the write methods is that they write to the _output_ _stream_; there is no guarantee of anything beyond that. Only the flush method has any guarantee about the data, which is >Flushes this output stream and forces any buffered output bytes to >be written out. The general contract of flush is that calling it is >an indication that, if any bytes previously written have been >buffered by the implementation of the output stream, such bytes >should immediately be written to their intended destination. People commonly use various OutputStreams without using flush(), and it often works, but it's a bad practice and will eventually bite them. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From netbeans at gatworks.com Mon Jun 11 13:31:57 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 15:31:57 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611183239.GT10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> Message-ID: <466DA32D.1010602@gatworks.com> Steffen DETTMER wrote: > * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: >>> Actually, an application would need to call flush() after each >>> write (or bunch of write calls) to ensure that write really did >>> something otherwise I think. > >> OutputStreams don't _have_ to be synchronous or asynchronous, >> but the OutputStream API was be arranged so that subclasses >> _can_ be synchronous or asynchronous. > > Ahh, oki. Thanks for the clarificaion. > > So in short, flush() MUST be called on OutputStream, this is just > not documented correctly or so clearly (right?). No. Flush can be called to force all current data in java buffer's to be written to the kernel - NOW. A flush() can also *imply* that, besides writing out the buffer's that java employs, may also imply/ask the kernel to write all data thusfar written to the kernel, to be physically placed on the destination device - NOW. For some OS's there is no need to do a kernel flush(), as the I/O is synchronized already. Since this is java, you never know what OS your on. From tjarvi at qbang.org Mon Jun 11 19:28:27 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Jun 2007 19:28:27 -0600 (MDT) Subject: [Rxtx] [OT] select :-) In-Reply-To: <466DA32D.1010602@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: On Mon, 11 Jun 2007, Uncle George wrote: > Steffen DETTMER wrote: >> * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: >>>> Actually, an application would need to call flush() after each >>>> write (or bunch of write calls) to ensure that write really did >>>> something otherwise I think. >> >>> OutputStreams don't _have_ to be synchronous or asynchronous, >>> but the OutputStream API was be arranged so that subclasses >>> _can_ be synchronous or asynchronous. >> >> Ahh, oki. Thanks for the clarificaion. >> >> So in short, flush() MUST be called on OutputStream, this is just >> not documented correctly or so clearly (right?). > No. > Flush can be called to force all current data in java buffer's to be > written to the kernel - NOW. > > A flush() can also *imply* that, besides writing out the buffer's that > java employs, may also imply/ask the kernel to write all data thusfar > written to the kernel, to be physically placed on the destination device > - NOW. > For some OS's there is no need to do a kernel flush(), as the I/O is > synchronized already. Since this is java, you never know what OS your on. To add to the confusion, flush on the C side throws away data. drain makes sure it is written. Looking at the ParallelImp.c we can probably do better. /* we set a timeout because all calls are sequentiell (also with asynchron) this means that the default timeout of unlimited blocks all calls (also close and status request) if the device is down */ GetCommTimeouts( (HANDLE)fd, &timeouts ); timeouts.WriteTotalTimeoutMultiplier = 0; timeouts.WriteTotalTimeoutConstant = 2000; /* 2000 is the min value for the default Windows NT and Windows 2000 driver */ SetCommTimeouts( (HANDLE)fd, &timeouts ); while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } errorCount = 0; bytes += countWritten; count -= countWritten; } LPRPort has some timeout code that appears to be doing nothing but flipping bits back and forth right now. The commapi rxtx follows allows for timeout control from javax.comm.CommPort. The above is a solution that worked in one specific use case. With timeouts in place, the original 'old printer going offline' problem could be solved. That printer code isn't written in stone. In fact it was ajusted from being able to print 'asdf' to a daisy wheel printer to working for one person. BTW, I've finished teaching after hours tonight and will be moving forward with a new rxtx release in my free time. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Jun 11 21:28:04 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 23:28:04 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: <466E12C4.1010305@gatworks.com> > Looking at the ParallelImp.c we can probably do better. > The problem stemmed from the possibility that the writev routine could have written some of the buffer, in chunks, printer pauses, refuses any more chunks, and a timeout occurs. Do you or do you not cause an exception to be thrown? Is there a way to set timeout for a ParallelPort data output stream? I cant find it. From tjarvi at qbang.org Mon Jun 11 22:17:23 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Jun 2007 22:17:23 -0600 (MDT) Subject: [Rxtx] [OT] select :-) In-Reply-To: <466E12C4.1010305@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> <466E12C4.1010305@gatworks.com> Message-ID: On Mon, 11 Jun 2007, Uncle George wrote: >> Looking at the ParallelImp.c we can probably do better. >> > The problem stemmed from the possibility that the writev routine could > have written some of the buffer, in chunks, printer pauses, refuses any > more chunks, and a timeout occurs. Do you or do you not cause an > exception to be thrown? > > Is there a way to set timeout for a ParallelPort data output stream? I > cant find it. hmm I looked again after you asked. The timeouts are only controllable on the receive side. This comes from CommPort; the parent. So what we are talking about is some bytes in memory that rxtx has and is supposed to write. A buffer perhaps? The approach with rxtx in the past has been to ignore output buffer sizes. The assumption is that the library does not know how to best handle buffers. There are buffered output streams that can do buffering on top of rxtx for instance. There is also a question regarding what was actually ment when the API was put together. My suspicion is that it was put together while looking at one OS API and was never ment to be anything more than a hook into that API. The comments are fairly telling combined with reading the w32 API. So looking at the problem again.. The current timeout behavior appears fairly arbitrary. Presumably this is to prevent a program from hanging instead of using a helper thread to write - heavy handed for new programmers. Even so, I don't think the write should timeout at all if it is not configurable. >From the API perspective, "What Timeout?" -- Trent Jarvi tjarvi at qbang.org From Steffen.DETTMER at ingenico.com Tue Jun 12 02:14:48 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 12 Jun 2007 10:14:48 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466DA32D.1010602@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: <20070612081447.GU10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Mon, Jun 11, 2007 at 15:31 -0400: > Steffen DETTMER wrote: > > Ahh, oki. Thanks for the clarificaion. > > > > So in short, flush() MUST be called on OutputStream, this is just > > not documented correctly or so clearly (right?). > No. hum (though now I got it, but...). > Flush can be called to force all current data in java buffer's to be > written to the kernel - NOW. > > A flush() can also *imply* that, besides writing out the > buffer's that java employs, may also imply/ask the kernel to > write all data thusfar written to the kernel, to be physically > placed on the destination device - NOW. > > For some OS's there is no need to do a kernel flush(), as the I/O is > synchronized already. Since this is java, you never know what OS your on. (well, but if you're going to kernel level, even flush cannot guarantee that data will "be physically placed". Maybe you're flushing to a file via NFS (and the client "thinks" that it was written, but maybe it was just buffered by the NFS server) or so... but of course such exceptions of the rules are constructable always.) Well, you tell that depending on the OS it can be that flush is needed or it can be that flush is not needed (beacuse the I/O is synchronized already), right? Also, applications should work on any OS, which includes the OSes that do need flush. Since the application cannot know whether flush is needed or not because it doesn't know what the OS is doing, it has to call flush, hasn't it? I mean, if it would not call flush then it would not work on such OSes (except the written data would not be needed at all, but in this would be an artificial example :)). Since applications are supposed to work this would be wrong, wouldn't it? So would it be correct to say: "Applications, that should work under all OSes (including the OSes where the I/O is not synchronised already), have to call flush on OutputStream to ensure the data is transfered to the kernel." or is this wrong? If so, then I'm afraid I missed the point again :( oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Tue Jun 12 04:46:52 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 12 Jun 2007 06:46:52 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070612081447.GU10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> <20070612081447.GU10821@elberon.bln.de.ingenico.com> Message-ID: <466E799C.7060700@gatworks.com> S > (well, but if you're going to kernel level, even flush cannot > guarantee that data will "be physically placed". Thats true now-a-days because ( from "man 2 sync" ) : > According to the standard specification (e.g., SVID), sync() schedules > the writes, but may return before the actual writing is done. However, > since version 1.3.20 Linux does actually wait. (This still does not > guarantee data integrity: modern disks have large caches.) My disk drive has 8mb cache. Maybe you're > flushing to a file via NFS (and the client "thinks" that it was > written, but maybe it was just buffered by the NFS server) or > so... but of course such exceptions of the rules are > constructable always.) > > Well, you tell that depending on the OS it can be that flush is > needed or it can be that flush is not needed (beacuse the I/O is > synchronized already), right? Also, applications should work on > any OS, which includes the OSes that do need flush. Its not OS's that need flush, its applications that want to have some assurance that data is written to the device that really needs to use flush. If your program ( or thread ) dies then it is in your best interest to write out the critical data as soon as possible, as economical as possible. These are trade-off's that the application programmer makes. A big buffer may mean big loss of data, a small buffer may mean spending too much time writing out data. > > > So would it be correct to say: > > "Applications, that should work under all OSes (including the > OSes where the I/O is not synchronised already), have to call > flush on OutputStream to ensure the data is transfered to the > kernel." > > or is this wrong? If so, then I'm afraid I missed the point again > :( > No that is not wrong. Ensuring that data is transfered to the OS is just about what any application can do. From tjarvi at qbang.org Thu Jun 14 08:16:47 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 14 Jun 2007 08:16:47 -0600 (MDT) Subject: [Rxtx] rxtx and usb-serial solution In-Reply-To: References: Message-ID: On Thu, 14 Jun 2007, Vladimir Kirtchev wrote: > Hi Trent, > > I develop a Java application which communicates with devices which have > USB-to-Serial bridge in them. The target OS is Linux. So for this purpose I > use RXTX. > > But I encountered a strange problem - when reading from the InputStream, I > receive series of zeros. I have this problem under Linux only. Under Windows > it is fine. > Actually this problem is the same as the one described here: > http://marc.info/?l=rxtx&m=109703190731748&w=2. > > > So I searched for the problem in the native code. And found that the root of > the problem is in SerialImp.c, > int configure_port( int fd ) > { > ... > ttyset.c_iflag = INPCK; > ... > } > > This line enables input parity checking, and the data sent from the device > is processed by the OS driver before being read with read(). > In this case the driver detects some problem and sets the received bytes to > zero. > > On the other hand in the Java part a set the serial port parameters with > SerialPort.PARITY_NONE. According to me, except all other things, this > should also disable INPCK in c_iflag. > > So I refactored the method translate_parity(...) to the following: > > int translate_parity( JNIEnv *env, struct termios *ttyset, jint parity ) > { > ENTER( "translate_parity" ); > #ifdef CMSPAR > ttyset->c_cflag &= ~(PARENB | PARODD | CMSPAR ); > #endif /* CMSPAR */ > switch( parity ) { > case JPARITY_NONE: > ttyset->c_iflag &= ~INPCK; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_EVEN: > ttyset->c_cflag |= PARENB; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_ODD: > ttyset->c_cflag |= PARENB | PARODD; > LEAVE( "translate_parity" ); > return 0; > #ifdef CMSPAR > case JPARITY_MARK: > ttyset->c_cflag |= PARENB | PARODD | CMSPAR; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_SPACE: > ttyset->c_cflag |= PARENB | CMSPAR; > LEAVE( "translate_parity" ); > return 0; > #endif /* CMSPAR */ > default: > printf("Parity missed %i\n", (int) parity ); > } > > LEAVE( "translate_parity" ); > /* > For some reason the native exceptions are not being caught. Moving this > to the Java side fixed the issue. taj. > throw_java_exception( env, UNSUPPORTED_COMM_OPERATION, > "", "parity value not supported" ); > */ > return 1; > } > > This modification solved the problem and now it works correctly under Linux. > > I think I will be a nice if this is idea is included in a future release of > RXTX. > > Thanks Vadim, I'll try that out. Forwarding to the rxtx mail-list too. This is probably not going to help USB drivers on windows which I'm sure some are looking for. As far as I can tell, windows USB bluetooth and serial dongles are limited by driver functionality. Some are good and others lack key features. -- Trent Jarvi tjarvi at qbang.org From dan.sandberg.lists at gmail.com Mon Jun 18 14:43:39 2007 From: dan.sandberg.lists at gmail.com (Dan Sandberg) Date: Mon, 18 Jun 2007 13:43:39 -0700 Subject: [Rxtx] Fix for JNI Get/Set Field Errors Message-ID: <4676EE7B.7060800@gmail.com> Hi, I've fixed the problems that cause the following JNI error when extra JNI checking ( -Xjni:check ) is turned on. FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) The problem was basically that GetLong was being used to get ints, and SetInt was used for longs. The patch below fixes this. Please let me know if there are any questions / problems. Cheers, -Dan diff -aur old/SerialImp.c src/SerialImp.c --- old/SerialImp.c 2007-06-18 13:24:33.000000000 -0700 +++ src/SerialImp.c 2007-06-18 06:26:26.000000000 -0700 @@ -1337,7 +1337,7 @@ report("init_threads: get eis\n"); jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); report("init_threads: set eis\n"); - (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); + (*eis->env)->SetLongField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); report("init_threads: stop\n"); report_time_end( ); return( 1 ); @@ -1530,7 +1530,7 @@ jobject jobj, jboolean interrupted ) { int fd = get_java_var( env, jobj,"fd","I" ); - struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var( env, jobj, "eis", "J" ); + struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var_long( env, jobj, "eis", "J" ); int result, count=0; char message[80]; @@ -2939,7 +2939,7 @@ /* TRENT */ int flag, count = 0; struct event_info_struct *eis = ( struct event_info_struct * ) - get_java_var( env, *jobj,"eis","J" ); + get_java_var_long( env, *jobj,"eis","J" ); report_time_start(); flag = eis->eventflags[SPE_DATA_AVAILABLE]; @@ -4873,9 +4873,9 @@ exceptions: none comments: ----------------------------------------------------------*/ -size_t get_java_var( JNIEnv *env, jobject jobj, char *id, char *type ) +long get_java_var_long( JNIEnv *env, jobject jobj, char *id, char *type ) { - int result = 0; + long result = 0; jclass jclazz = (*env)->GetObjectClass( env, jobj ); jfieldID jfd = (*env)->GetFieldID( env, jclazz, id, type ); @@ -4889,7 +4889,11 @@ LEAVE( "get_java_var" ); return result; } - result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); + if ( !strcmp( type, "J" ) ) { + result = (long)( (*env)->GetLongField( env, jobj, jfd ) ); + } else { + result = (int) ( (*env)->GetIntField( env, jobj, jfd ) ); + } /* ct7 & gel * Added DeleteLocalRef */ (*env)->DeleteLocalRef( env, jclazz ); if(!strncmp( "fd",id,2) && result == 0) @@ -4900,6 +4904,10 @@ return result; } +int get_java_var( JNIEnv *env, jobject jobj, char *id, char *type ) { + return (int) get_java_var_long( env, jobj, id, type ); +} + /*---------------------------------------------------------- throw_java_exception diff -aur old/SerialImp.h src/SerialImp.h --- old/SerialImp.h 2007-06-18 13:24:39.000000000 -0700 +++ src/SerialImp.h 2007-06-18 06:23:43.000000000 -0700 @@ -413,7 +413,8 @@ void system_wait(); void finalize_event_info_struct( struct event_info_struct * ); int read_byte_array( JNIEnv *, jobject *, int, unsigned char *, int, int ); -size_t get_java_var( JNIEnv *, jobject, char *, char * ); +int get_java_var( JNIEnv *, jobject, char *, char * ); +long get_java_var_long( JNIEnv *, jobject, char *, char * ); jboolean is_interrupted( struct event_info_struct * ); int send_event(struct event_info_struct *, jint, int ); void dump_termios(char *,struct termios *); From yvespielusenet at free.fr Tue Jun 26 03:41:58 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 11:41:58 +0200 Subject: [Rxtx] [PARALLEL] resource in use Message-ID: <1182850918.3483.10.camel@localhost.localdomain> Hello, So now I want to modify the timeout of the library for parallel port. I have downloaded source code. There is a makefile for migw. SO I have installed mingw on ubuntu and modified the makefile.mingw32 to set it for my system. I have no error but some warnings. The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But When I want to use it the jvm crash :( How can I know what is wrong ? How rxtx windows release has been done ? thanks -- yves piel From yvespielusenet at free.fr Tue Jun 26 07:17:02 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 15:17:02 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182850918.3483.10.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> Message-ID: <1182863822.3483.17.camel@localhost.localdomain> Here is the Makefile I use, the output of the 'make' and the log of the jvm when it crashed : - The Makefile : http://yvespiel.free.fr/rxtx/Makefile - The make output : http://yvespiel.free.fr/rxtx/compile.txt - The crash log : http://yvespiel.free.fr/rxtx/hs_err_pid2100.log I have compiled rxtx under Debian testing with mingw : narma at linimi:/tmp/err$ dpkg -l | grep mingw ii mingw32 3.4.5.20060117.1.dfsg-3 ii mingw32-binutils 2.17.50-20070129.1-1 ii mingw32-runtime 3.12-1 thanks fort help :) Le mardi 26 juin 2007 ? 11:41 +0200, yves pielusenet a ?crit : > Hello, > So now I want to modify the timeout of the library for parallel port. I > have downloaded source code. There is a makefile for migw. SO I have > installed mingw on ubuntu and modified the makefile.mingw32 to set it > for my system. > I have no error but some warnings. > The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But > When I want to use it the jvm crash :( > > How can I know what is wrong ? > > How rxtx windows release has been done ? > > thanks > From yvespielusenet at free.fr Tue Jun 26 07:40:11 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 15:40:11 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182863822.3483.17.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> <1182863822.3483.17.camel@localhost.localdomain> Message-ID: <1182865211.3483.21.camel@localhost.localdomain> I have add the options '--enable-stdcall-fixup' to the 'i586-mingw32msvc-ld' commande. Now I have no warning. But the JVM always crashes :( The output seems more detailled, but I don't understand anything... Here is files : http://yvespiel.free.fr/rxtx/2/ -- yves piel Le mardi 26 juin 2007 ? 15:17 +0200, yves pielusenet a ?crit : > Here is the Makefile I use, the output of the 'make' and the log of the > jvm when it crashed : > > - The Makefile : http://yvespiel.free.fr/rxtx/Makefile > - The make output : http://yvespiel.free.fr/rxtx/compile.txt > - The crash log : http://yvespiel.free.fr/rxtx/hs_err_pid2100.log > > I have compiled rxtx under Debian testing with mingw : > narma at linimi:/tmp/err$ dpkg -l | grep mingw > ii mingw32 3.4.5.20060117.1.dfsg-3 > ii mingw32-binutils 2.17.50-20070129.1-1 > ii mingw32-runtime 3.12-1 > > thanks fort help :) > > > Le mardi 26 juin 2007 ? 11:41 +0200, yves pielusenet a ?crit : > > Hello, > > So now I want to modify the timeout of the library for parallel port. I > > have downloaded source code. There is a makefile for migw. SO I have > > installed mingw on ubuntu and modified the makefile.mingw32 to set it > > for my system. > > I have no error but some warnings. > > The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But > > When I want to use it the jvm crash :( > > > > How can I know what is wrong ? > > > > How rxtx windows release has been done ? > > > > thanks > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From yvespielusenet at free.fr Tue Jun 26 08:27:42 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 16:27:42 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182865211.3483.21.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> <1182863822.3483.17.camel@localhost.localdomain> <1182865211.3483.21.camel@localhost.localdomain> Message-ID: <1182868062.3483.24.camel@localhost.localdomain> I think thant the include files of jdk were not for windows but for linux. So I have copied include/ folder from windows to linux and I modified the Makefile to use those file. It compile fine but the JVM always crash :( http://yvespiel.free.fr/rxtx/3/ Le mardi 26 juin 2007 ? 15:40 +0200, yves pielusenet a ?crit : > I have add the options '--enable-stdcall-fixup' to the > 'i586-mingw32msvc-ld' commande. Now I have no warning. But the JVM > always crashes :( The output seems more detailled, but I don't > understand anything... > Here is files : > http://yvespiel.free.fr/rxtx/2/ > From netbeans at gatworks.com Fri Jun 1 05:38:50 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 07:38:50 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <465F7ADD.1010501@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> Message-ID: <4660054A.2040202@gatworks.com> Manuel Naranjo wrote: In the case of my module, you can > unplug the device but it will not delete the symlink until those apps > that had opened the port has closed it. This is done this way to avoid > kernel panics. What does this mean to user code ? I have tried the alternate route ( other than closing ) which is sleep inbetween the I/O errors ( an unplugged USB device). When the device is plugged back in, The writes to the device still get an I/O error. This would seem to be a lost cause for the application. From netbeans at gatworks.com Fri Jun 1 06:35:48 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 08:35:48 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <465F7ADD.1010501@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> Message-ID: <466012A4.90608@gatworks.com> Manuel Naranjo wrote: In the case of my module, you can > unplug the device but it will not delete the symlink until those apps > that had opened the port has closed it. T Did u also mean for this to happen? USB0 was not closed by application. Apparently USB1 got created when USB device was plugged back in. There is only one USB device on a 4 port USB hub. This also seems to suggest that application recovery to be impossible. > Jun 1 07:10:08 mylaptop kernel: garmin_gps 1-1.4:1.0: Garmin GPS usb/tty converter detected > Jun 1 07:10:08 mylaptop kernel: usb 1-1.4: Garmin GPS usb/tty converter now attached to ttyUSB0 > Jun 1 07:15:17 mylaptop kernel: usb 1-1: USB disconnect, address 4 > Jun 1 07:15:17 mylaptop kernel: usb 1-1.4: USB disconnect, address 5 > Jun 1 07:15:17 mylaptop kernel: garmin_gps 1-1.4:1.0: device disconnected > Jun 1 07:15:26 mylaptop kernel: usb 1-1: new full speed USB device using uhci_hcd and address 6 > Jun 1 07:15:26 mylaptop kernel: hub 1-1:1.0: USB hub found > Jun 1 07:15:26 mylaptop kernel: hub 1-1:1.0: 4 ports detected > Jun 1 07:15:27 mylaptop kernel: usb 1-1.4: new full speed USB device using uhci_hcd and address 7 > Jun 1 07:15:27 mylaptop kernel: garmin_gps 1-1.4:1.0: Garmin GPS usb/tty converter detected > Jun 1 07:15:27 mylaptop kernel: usb 1-1.4: Garmin GPS usb/tty converter now attached to ttyUSB1 From naranjo.manuel at gmail.com Fri Jun 1 09:17:22 2007 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Fri, 01 Jun 2007 12:17:22 -0300 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <466012A4.90608@gatworks.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> <466012A4.90608@gatworks.com> Message-ID: <46603882.5050701@gmail.com> Uncle George escribi?: > Manuel Naranjo wrote: > In the case of my module, you can > >> unplug the device but it will not delete the symlink until those apps >> that had opened the port has closed it. T >> > > Did u also mean for this to happen? USB0 was not closed by application. > > Apparently USB1 got created when USB device was plugged back in. There > is only one USB device on a 4 port USB hub. > > This also seems to suggest that application recovery to be impossible. > Exactly there's a dead symlink (you can read and write to it and nothing will happen) and a new port will be created when a new device is connencted. From netbeans at gatworks.com Fri Jun 1 10:20:46 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 12:20:46 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <46603882.5050701@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> <466012A4.90608@gatworks.com> <46603882.5050701@gmail.com> Message-ID: <4660475E.5090202@gatworks.com> Not sure what u mean by "symlink". U cant read/write to it anymore. U get I/O error. In this scenario the device effectively went dead, and only solution is to close the channel. reconnecting the USB device, although dead, but not closed, will create a second device. This does not seem to be a desirable side-effect. The user will now have ttyUSB1, wondering where did ttyUSB0 go to. The application will also be in a confused state, as well as RXTX, because RXTX wont know about ttyUSB1. Manuel Naranjo wrote: > Uncle George escribi?: >> Manuel Naranjo wrote: >> In the case of my module, you can >> >>> unplug the device but it will not delete the symlink until those apps >>> that had opened the port has closed it. T >>> >> Did u also mean for this to happen? USB0 was not closed by application. >> >> Apparently USB1 got created when USB device was plugged back in. There >> is only one USB device on a 4 port USB hub. >> >> This also seems to suggest that application recovery to be impossible. >> > Exactly there's a dead symlink (you can read and write to it and nothing > will happen) and a new port will be created when a new device is connencted. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From arnab.bhaumik at gmail.com Mon Jun 4 01:40:16 2007 From: arnab.bhaumik at gmail.com (arnab bhaumik) Date: Mon, 4 Jun 2007 13:10:16 +0530 Subject: [Rxtx] full duplex com port with rxtx Message-ID: hi , till now i did half duplex communication with rxtx package on com package. my question is : is it possible to use com port with full duplex mode with rxtx package . ther is example of SimpleRead class and SimpleWrite class. it is clear that if i can use both the class simultaneously then full duplex is possible......... arnab/vu2bpw -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070604/6edb0453/attachment-0010.html From lists at iDIAcomputing.com Mon Jun 4 07:53:17 2007 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Mon, 04 Jun 2007 09:53:17 -0400 Subject: [Rxtx] full duplex com port with rxtx In-Reply-To: References: Message-ID: <4664194D.90301@iDIAcomputing.com> arnab bhaumik wrote: > hi , > > till now i did half duplex communication with rxtx package on com > package. > > my question is : is it possible to use com port with full duplex mode > with rxtx package . > > > ther is example of SimpleRead class and SimpleWrite class. it is > clear that if i can use both the class simultaneously then full duplex > is possible......... I haven't looked at the SimpleRead and SimpleWrite classes (I originally wrote my code for the javax.comm api), but full duplex is certainly possible. My CommReader class requires an object analogous to a OutputStream or Writer. When started, it spawns a thread that reads the comm port and writes to that output device. In this way the input is asynchronous and dependent on the actual input data. For full duplex, I extend that class with CommReaderWriter, which adds synchronous output methods. Hope that helps, George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From supsoop at hotmail.com Mon Jun 4 15:21:06 2007 From: supsoop at hotmail.com (soop soop) Date: Mon, 04 Jun 2007 21:21:06 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- Message-ID: Hi Guys, Looked through the archives but still cannot figure this out. I have a Motorola G24 GPRS/GSM modem that I am connecting to my server running Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not detecting the port, CommPortIdentifier.getPortIdentifiers(). I have added the line to RXTXCommDriver: "ttyACM" // for USB Modems Rxtx still does not seem to find the port. Is there something I am missing to make this port visable? [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control Model driver for USB modems and ISDN adapters I really need your help as I have moved my server from windows to Linux and have been down for a few days because of this .. Thanks so much! _________________________________________________________________ PC Magazine’s 2007 editors’ choice for best Web mail—award-winning Windows Live Hotmail. http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 From tjarvi at qbang.org Mon Jun 4 16:17:35 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Jun 2007 16:17:35 -0600 (MDT) Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: On Mon, 4 Jun 2007, soop soop wrote: > Hi Guys, > > Looked through the archives but still cannot figure this out. I have a > Motorola G24 GPRS/GSM modem that I am connecting to my server running Ubuntu. > I can see my modem as is shows up as ttyACM0, but RXTX is not detecting the > port, CommPortIdentifier.getPortIdentifiers(). > > I have added the line to RXTXCommDriver: > > "ttyACM" // for USB Modems > > Rxtx still does not seem to find the port. Is there something I am missing to > make this port visable? > > [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver > [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device > [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control Model > driver for USB modems and ISDN adapters > > I really need your help as I have moved my server from windows to Linux and > have been down for a few days because of this .. Thanks so much! > You could try the INSTALL documentation that comes with the source for possible solutions. Those usually involve lockfile creation, permissions on the device file or the device is in use by another application (even another session of your application). The usual commands: ls -l /dev/ttyACM0 fuser /dev/ttyACM0 touch /var/lock/LCK.testfile && rm -f /var/lock/LCK.testfile whoami To disable lockfiles: ../configure --disable-lockfiles && make install -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Jun 4 16:22:52 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 04 Jun 2007 18:22:52 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <466490BC.3090801@gatworks.com> soop soop wrote: > I really need your help as I have moved my server from windows to Linux > and have been down for a few days because of this .. Thanks so much! can u open the device ? ie is the file protection/permissions keeping you out? From supsoop at hotmail.com Mon Jun 4 16:44:40 2007 From: supsoop at hotmail.com (soop soop) Date: Mon, 04 Jun 2007 22:44:40 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <466490BC.3090801@gatworks.com> Message-ID: Thanks for the reply, I see no exceptions being thrown, just no detection of the port whats so ever. I will run rxtx in debug mode and log. If this were a permissions issue would I not see some exceptions being thrown? >From: Uncle George >Reply-To: RXTX Developers and Users >To: RXTX Developers and Users >Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >Date: Mon, 04 Jun 2007 18:22:52 -0400 > >soop soop wrote: > > > I really need your help as I have moved my server from windows to Linux > > and have been down for a few days because of this .. Thanks so much! > >can u open the device ? ie is the file protection/permissions keeping >you out? >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ Get a preview of Live Earth, the hottest event this summer - only on MSN http://liveearth.msn.com?source=msntaglineliveearthhm From netbeans at gatworks.com Mon Jun 4 17:06:15 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 04 Jun 2007 19:06:15 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <46649AE7.10405@gatworks.com> Exceptions on what? On startup it wants to lookup all devices in /dev that it is capable of opening ( within the list of specific 'comm' devices ). If it cannot open, then does not get onto list. Part of this process, if configured, will also test if the "LOCK" schema can also be opened for the device. then it gets on the list of avail comm port. soop soop wrote: > Thanks for the reply, > > I see no exceptions being thrown, just no detection of the port whats so > ever. I will run rxtx in debug mode and log. If this were a permissions > issue would I not see some exceptions being thrown? > > >> From: Uncle George >> Reply-To: RXTX Developers and Users >> To: RXTX Developers and Users >> Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >> Date: Mon, 04 Jun 2007 18:22:52 -0400 >> >> soop soop wrote: >> >>> I really need your help as I have moved my server from windows to Linux >>> and have been down for a few days because of this .. Thanks so much! >> can u open the device ? ie is the file protection/permissions keeping >> you out? >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _________________________________________________________________ > Get a preview of Live Earth, the hottest event this summer - only on MSN > http://liveearth.msn.com?source=msntaglineliveearthhm > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From alex.flint at gmail.com Mon Jun 4 21:31:49 2007 From: alex.flint at gmail.com (Alex Flint) Date: Tue, 5 Jun 2007 13:01:49 +0930 Subject: [Rxtx] random EXCEPTION_ACCESS_VIOLATION errors Message-ID: Hi All, I'm running winXP and RXTX 2.1-7r2 (the latest from the webpage as of June 2007). I'm sending sequences of 64 lines (each line has about 15 chars) at various intervals. The strings are sent fine, until I get the following error (from hs_err_pid3316.log, at the end of this email). What can I do to avoid the error? Obviously this is a low-level memory exception, but is there any way I can keep the JVM running after such an error? I noticed the exact same problem here: http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20070129/1180520.html Cheers, Alex # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x100034fb, pid=3316, tid=2400 # # Java VM: Java HotSpot(TM) Client VM (1.6.0_01-b06 mixed mode, sharing) # Problematic frame: # C [rxtxSerial.dll+0x34fb] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # --------------- T H R E A D --------------- Current thread (0x00386400): JavaThread "main" [_thread_in_native, id=2400] siginfo: ExceptionCode=0xc0000005, reading address 0x20726f78 Registers: EAX=0x20726f20, EBX=0x6d8922c0, ECX=0x00000005, EDX=0x20726f20 ESP=0x003efa30, EBP=0x003efb68, ESI=0x269728a0, EDI=0x00386400 EIP=0x100034fb, EFLAGS=0x00010212 Top of Stack: (sp=0x003efa30) 0x003efa30: 003efa3c 003efa64 0000000f ffffffff 0x003efa40: 003efa40 2a97f808 003efa6c 2b190ca8 0x003efa50: 00000000 2b190ec0 003efa90 008e2dd7 0x003efa60: 003efa90 008e2dd7 26977f88 6d815e72 0x003efa70: 00000004 2696eae0 0000008a 003efb0c 0x003efa80: 6d852b4a 2696eae0 00000003 26970930 0x003efa90: 000000cb 2696eae0 6d86b264 00385d40 0x003efaa0: 0000003f 003efb0c 26977f90 2ace65d8 Instructions: (pc=0x100034fb) 0x100034eb: ff ff 8d 76 00 eb 02 89 f6 90 8b 45 f8 8b 55 f8 0x100034fb: 8b 4a 58 83 c9 04 89 48 58 83 c4 f8 8b 45 f8 8b Stack: [0x003a0000,0x003f0000), sp=0x003efa30, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x34fb] Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j gnu.io.RXTXPort.writeArray([BIIZ)V+0 j gnu.io.RXTXPort$SerialOutputStream.write([B)V+76 j com.bjt.media.server.CommLink.send(Ljava/lang/String;)V+48 j com.bjt.media.server.DigitoolConnection.select(I)V+73 j com.bjt.media.server.DigitoolConnection.main([Ljava/lang/String;)V+74 v ~StubRoutines::call_stub --------------- P R O C E S S --------------- Java Threads: ( => current thread ) 0x02a69400 JavaThread "Thread-0" [_thread_in_native, id=3052] 0x02a4d000 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=3920] 0x02a48400 JavaThread "CompilerThread0" daemon [_thread_blocked, id=1968] 0x02a47400 JavaThread "Attach Listener" daemon [_thread_blocked, id=2984] 0x02a46400 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=2660] 0x02a41c00 JavaThread "Finalizer" daemon [_thread_blocked, id=3924] 0x02a3d800 JavaThread "Reference Handler" daemon [_thread_blocked, id=4008] =>0x00386400 JavaThread "main" [_thread_in_native, id=2400] Other Threads: 0x02a34400 VMThread [id=3708] 0x02a4e800 WatcherThread [id=3964] VM state:not at safepoint (normal execution) VM Mutex/Monitor currently owned by a thread: None Heap def new generation total 960K, used 131K [0x22960000, 0x22a60000, 0x22e40000) eden space 896K, 7% used [0x22960000, 0x22970ea8, 0x22a40000) from space 64K, 99% used [0x22a50000, 0x22a5fff8, 0x22a60000) to space 64K, 0% used [0x22a40000, 0x22a40000, 0x22a50000) tenured generation total 4096K, used 76K [0x22e40000, 0x23240000, 0x26960000) the space 4096K, 1% used [0x22e40000, 0x22e53060, 0x22e53200, 0x23240000) compacting perm gen total 12288K, used 137K [0x26960000, 0x27560000, 0x2a960000) the space 12288K, 1% used [0x26960000, 0x26982518, 0x26982600, 0x27560000) ro space 8192K, 62% used [0x2a960000, 0x2ae5e4e8, 0x2ae5e600, 0x2b160000) rw space 12288K, 52% used [0x2b160000, 0x2b7a0e78, 0x2b7a1000, 0x2bd60000) Dynamic libraries: 0x00400000 - 0x00423000 C:\Program Files\Java\jre1.6.0_01\bin\javaw.exe 0x7c900000 - 0x7c9b0000 C:\WINDOWS\system32\ntdll.dll 0x7c800000 - 0x7c8f4000 C:\WINDOWS\system32\kernel32.dll 0x77dd0000 - 0x77e6b000 C:\WINDOWS\system32\ADVAPI32.dll 0x77e70000 - 0x77f01000 C:\WINDOWS\system32\RPCRT4.dll 0x7e410000 - 0x7e4a0000 C:\WINDOWS\system32\USER32.dll 0x77f10000 - 0x77f57000 C:\WINDOWS\system32\GDI32.dll 0x76390000 - 0x763ad000 C:\WINDOWS\system32\IMM32.DLL 0x7c340000 - 0x7c396000 C:\Program Files\Java\jre1.6.0_01\bin\msvcr71.dll 0x6d7c0000 - 0x6da07000 C:\Program Files\Java\jre1.6.0_01\bin\client\jvm.dll 0x76b40000 - 0x76b6d000 C:\WINDOWS\system32\WINMM.dll 0x5cd70000 - 0x5cd77000 C:\WINDOWS\system32\serwvdrv.dll 0x5b0a0000 - 0x5b0a7000 C:\WINDOWS\system32\umdmxfrm.dll 0x6d310000 - 0x6d318000 C:\Program Files\Java\jre1.6.0_01\bin\hpi.dll 0x76bf0000 - 0x76bfb000 C:\WINDOWS\system32\PSAPI.DLL 0x6d770000 - 0x6d77c000 C:\Program Files\Java\jre1.6.0_01\bin\verify.dll 0x6d3b0000 - 0x6d3cf000 C:\Program Files\Java\jre1.6.0_01\bin\java.dll 0x6d7b0000 - 0x6d7bf000 C:\Program Files\Java\jre1.6.0_01\bin\zip.dll 0x10000000 - 0x10012000 C:\Documents and Settings\Alex\workspace\MediaServer\rxtxSerial.dll 0x73d90000 - 0x73db7000 C:\WINDOWS\system32\crtdll.dll VM Arguments: jvm_args: -Djava.library.path=C:\Documents and Settings\Alex\workspace\MediaServer java_command: com.bjt.media.server.DigitoolConnection Launcher Type: SUN_STANDARD Environment Variables: CLASSPATH=.;C:\Program Files\Java\j2re1.4.2_07\lib\ext\QTJava.zip PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\wbem;c:\applications\php;C:\Program Files\MATLAB\R2006a\bin\win32;C:\Roger\Projects\UAV\Bin\Debug;C:\Program Files\Microsoft SQL Server\80\Tools\Binn\;c:\Program Files\Microsoft SQL Server\90\Tools\binn\;C:\Program Files\QuickTime\QTSystem\;C:\Pfps\system;C:\Program Files\Java\jdk1.6.0_01\bin;C:\Program Files\Java\jdk1.6.0_01\jre\bin USERNAME=Alex OS=Windows_NT PROCESSOR_IDENTIFIER=x86 Family 15 Model 4 Stepping 1, GenuineIntel --------------- S Y S T E M --------------- OS: Windows XP Build 2600 Service Pack 2 CPU:total 1 family 15, cmov, cx8, fxsr, mmx, sse, sse2 Memory: 4k page, physical 1046508k(275288k free), swap 2522816k(1909176k free) vm_info: Java HotSpot(TM) Client VM (1.6.0_01-b06) for windows-x86, built on Mar 14 2007 00:24:02 by "java_re" with unknown MS VC++:1310 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070604/c87ae1f0/attachment-0010.html From alwyn.schoeman at gmail.com Tue Jun 5 00:10:19 2007 From: alwyn.schoeman at gmail.com (Alwyn Schoeman) Date: Tue, 5 Jun 2007 08:10:19 +0200 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Hi, I'm using a similar modem. By default rxtx doesn't look for devices that start with ACM, so you need to modify the source code and recompile. Look in RXTXCommDriver and add values for ACM in the registerScannedPorts method in the Linux specific parts. Look for osName.equals("Linux")... On 6/4/07, soop soop wrote: > > Hi Guys, > > Looked through the archives but still cannot figure this out. I have a > Motorola G24 GPRS/GSM modem that I am connecting to my server running > Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not > detecting the port, CommPortIdentifier.getPortIdentifiers(). > > I have added the line to RXTXCommDriver: > > "ttyACM" // for USB Modems > > Rxtx still does not seem to find the port. Is there something I am missing > to make this port visable? > > [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver > [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device > [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control > Model > driver for USB modems and ISDN adapters > > I really need your help as I have moved my server from windows to Linux > and > have been down for a few days because of this .. Thanks so much! > > _________________________________________________________________ > PC Magazine's 2007 editors' choice for best Web mail?award-winning Windows > Live Hotmail. > > http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -- Alwyn Schoeman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/b6cb3053/attachment-0010.html From naranjo.manuel at gmail.com Tue Jun 5 06:48:45 2007 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Tue, 05 Jun 2007 09:48:45 -0300 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> References: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Message-ID: <46655BAD.7010501@gmail.com> That's right, an easier solution is creating symlinks to acm. For example make ttyS70 to 79 point to ACM0 to 9 and that will help you a lot, and doesn't even require compile. > Hi, > > I'm using a similar modem. By default rxtx doesn't look for devices > that start with ACM, so you need to modify the > source code and recompile. > > Look in RXTXCommDriver and add values for ACM in the > registerScannedPorts method in the Linux specific parts. Look for > osName.equals("Linux")... > From juanemc2 at gmail.com Tue Jun 5 07:02:43 2007 From: juanemc2 at gmail.com (Juan) Date: Tue, 5 Jun 2007 10:02:43 -0300 Subject: [Rxtx] Problems with Epson TMU220B POSPrinter using XON/XOFF Flow Control and rxtx jar and dll's with the serial port. Message-ID: Hi!, I?m having trouble printing to the serial port using the latest version of rxtx jar and dll's with an Epson POSPrinter. I`ve switched the printer to work with XON/XOFF Flow Control and have watched the serial port to be sure the printer is sending the XON XOFF stop and go characters. I`ve setted the port like this: CommPortIdentifier commPortIdentifier = CommPortIdentifier.* getPortIdentifier*(_portName); SerialPort serialPort = (SerialPort)commPortIdentifier.open(*this*.getClass().getName(), 2000); serialPort.setSerialPortParams(_baudRate, _dataBits, _stopBits, _parity); serialPort.setFlowControlMode( SerialPort.*FLOWCONTROL_XONXOFF_IN* | SerialPort.*FLOWCONTROL_XONXOFF_OUT*); where the baudRate is 9600 the dataBits is 8 the stopBits is 1 and the parity is 0 It seems as the library isn`t taking into account the XON XOFF setting. I would like to know if I`m setting correctly the Flow Control and if you had had any experiences using XON XOFF flow control and could give me some help to solve my problem. I`m very thankful in advance, Yours, Juan Polero -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/b080995a/attachment-0010.html From ehdez.correo at gmail.com Tue Jun 5 07:12:53 2007 From: ehdez.correo at gmail.com (=?ISO-8859-1?Q?Enrique_Hern=E1ndez?=) Date: Tue, 5 Jun 2007 09:12:53 -0400 Subject: [Rxtx] problem with rxtx Message-ID: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Hello: I doing a simple test to show the serial ports. This is the code: import java.util.Enumeration; import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; public class Show { private Enumeration portList; private CommPortIdentifier portId; private SerialPort port; /** Creates a new instance of Show */ public Show() { } public static void main(String args[]){ Show show = new Show(); show.portList = CommPortIdentifier.getPortIdentifiers(); String tPort = ""; System.out.println("========================================="); while(show.portList.hasMoreElements()){ show.portId = (CommPortIdentifier)show.portList.nextElement(); if(show.portId.getPortType() == CommPortIdentifier.PORT_SERIAL) tPort = "Serial"; else tPort = "Parallel"; System.out.println(show.portId.getName() + " " + tPort); } } } whit The problem is that this code not show the serial ports, this show the no use serial ports. I want to connect whit the modem but when windows open and connect the modem my application don't see the port(COMM3) when it is connect. what I can do? Is that the correct way to know the ports? thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/eedd744b/attachment-0010.html From ehdez.correo at gmail.com Tue Jun 5 07:42:13 2007 From: ehdez.correo at gmail.com (=?ISO-8859-1?Q?Enrique_Hern=E1ndez?=) Date: Tue, 5 Jun 2007 09:42:13 -0400 Subject: [Rxtx] serial port Message-ID: <4a814e1f0706050642p4ce9ac7bka80f9479c524c5ea@mail.gmail.com> Hello: How I can ask to the port what device is connect and information about this device. thanks. bye. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/4d10d26a/attachment-0010.html From supsoop at hotmail.com Tue Jun 5 09:29:00 2007 From: supsoop at hotmail.com (soop soop) Date: Tue, 05 Jun 2007 15:29:00 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Message-ID: Hi Guys, Thanks for all your help. I found the problem. I created a user, Tomcat55, for my tomcat but it did not belong to any group. I then added this user to dialout group to have access to the device ttyACM0. Works perfectly! Again permissions was the issue. This also seems to be persistent as a server reboot does not effect the access. Cheers! >From: "Alwyn Schoeman" >Reply-To: RXTX Developers and Users >To: "RXTX Developers and Users" >Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >Date: Tue, 5 Jun 2007 08:10:19 +0200 > >Hi, > >I'm using a similar modem. By default rxtx doesn't look for devices that >start with ACM, so you need to modify the >source code and recompile. > >Look in RXTXCommDriver and add values for ACM in the registerScannedPorts >method in the Linux specific parts. Look for osName.equals("Linux")... > >On 6/4/07, soop soop wrote: >> >>Hi Guys, >> >>Looked through the archives but still cannot figure this out. I have a >>Motorola G24 GPRS/GSM modem that I am connecting to my server running >>Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not >>detecting the port, CommPortIdentifier.getPortIdentifiers(). >> >>I have added the line to RXTXCommDriver: >> >>"ttyACM" // for USB Modems >> >>Rxtx still does not seem to find the port. Is there something I am missing >>to make this port visable? >> >>[ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver >>[ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device >>[ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control >>Model >>driver for USB modems and ISDN adapters >> >>I really need your help as I have moved my server from windows to Linux >>and >>have been down for a few days because of this .. Thanks so much! >> >>_________________________________________________________________ >>PC Magazine's 2007 editors' choice for best Web mail—award-winning Windows >>Live Hotmail. >> >>http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 >> >> >>_______________________________________________ >>Rxtx mailing list >>Rxtx at qbang.org >>http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > >-- >Alwyn Schoeman >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ Need a break? Find your escape route with Live Search Maps. http://maps.live.com/default.aspx?ss=Restaurants~Hotels~Amusement%20Park&cp=33.832922~-117.915659&style=r&lvl=13&tilt=-90&dir=0&alt=-1000&scene=1118863&encType=1&FORM=MGAC01 From netbeans at gatworks.com Tue Jun 5 09:42:31 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 11:42:31 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <46658467.20101@gatworks.com> soop soop wrote: > > Hi Guys, > > Thanks for all your help. I found the problem. I created a user, > Tomcat55, for my tomcat but it did not belong to any group. I then added Look at man pages for the program udev. From tjarvi at qbang.org Tue Jun 5 18:18:17 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Jun 2007 18:18:17 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Message-ID: On Tue, 5 Jun 2007, Enrique Hern?ndez wrote: > The problem is that this code not show the serial ports, this show the no > use serial ports. I want to connect whit the modem but when windows open and > connect the modem my application don't see the port(COMM3) when it is > connect. > what I can do? > Is that the correct way to know the ports? > Hello, We may have problems understanding each other. On windows, the port will not be an available serial port if another application has the port open. That is just how the library behaves. If you can not see the port in the enumerated list, you could not open it. Also note that enumeration only happens once. If you add a port such as a new USB dongle, the port will not be visible until the next time your application runs. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Tue Jun 5 18:45:01 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 20:45:01 -0400 Subject: [Rxtx] problem with rxtx In-Reply-To: References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Message-ID: <4666038D.8090700@gatworks.com> Trent Jarvi wrote: > > > Also note that enumeration only happens once. If you add a port such as > a new USB dongle, the port will not be visible until the next time your > application runs. Is this written in stone ? somewhere? From tjarvi at qbang.org Tue Jun 5 18:54:36 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Jun 2007 18:54:36 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <4666038D.8090700@gatworks.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> Message-ID: On Tue, 5 Jun 2007, Uncle George wrote: > Trent Jarvi wrote: >> >> >> Also note that enumeration only happens once. If you add a port such as >> a new USB dongle, the port will not be visible until the next time your >> application runs. > > Is this written in stone ? somewhere? It is just the current behavior. There is nothing preventing a fix that allows reenumeration. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Tue Jun 5 19:55:19 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 21:55:19 -0400 Subject: [Rxtx] problem with rxtx In-Reply-To: References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> Message-ID: <46661407.4020308@gatworks.com> >> Is this written in stone ? somewhere? > > It is just the current behavior. There is nothing preventing a fix that > allows reenumeration. With usb, ..... , things come and go. Seems a shame that you have to kill application to get at the device u just plugged in. From joachim at buechse.ch Wed Jun 6 01:50:06 2007 From: joachim at buechse.ch (Joachim Buechse) Date: Wed, 6 Jun 2007 09:50:06 +0200 Subject: [Rxtx] problem with rxtx In-Reply-To: <46661407.4020308@gatworks.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> <46661407.4020308@gatworks.com> Message-ID: <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> On MacOS RXTX's enumeration handling is more flexible. It will find new ports that are added during the lifetime of the application. But this is inherently incompatible with suns javax.comm implementation... Regards, Joachim On 06.06.2007, at 03:55, Uncle George wrote: > >>> Is this written in stone ? somewhere? >> >> It is just the current behavior. There is nothing preventing a >> fix that >> allows reenumeration. > > With usb, ..... , things come and go. Seems a shame that you have to > kill application to get at the device u just plugged in. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Jun 6 06:06:48 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Jun 2007 06:06:48 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> <46661407.4020308@gatworks.com> <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> Message-ID: Sun's javax.comm is not a major concern going forward. As long as we do not break old applications using rxtx, I see no reason to limit rxtx to that convention. We have already rejected version 3 from Sun as a dead end and limited our compatability to version 2. That does not mean we will not try to work with Sun and others but the current javax.comm convention (v3) is not a well conceived path. There has been discussion about doing a JSR which is one valid option. On Wed, 6 Jun 2007, Joachim Buechse wrote: > On MacOS RXTX's enumeration handling is more flexible. It will find > new ports that are added during the lifetime of the application. But > this is inherently incompatible with suns javax.comm implementation... > > Regards, > Joachim > > On 06.06.2007, at 03:55, Uncle George wrote: > >> >>>> Is this written in stone ? somewhere? >>> >>> It is just the current behavior. There is nothing preventing a >>> fix that >>> allows reenumeration. >> >> With usb, ..... , things come and go. Seems a shame that you have to >> kill application to get at the device u just plugged in. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From yvespielusenet at free.fr Wed Jun 6 08:46:35 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 16:46:35 +0200 Subject: [Rxtx] [PARALLEL] resource in use Message-ID: <1181141195.3407.20.camel@localhost.localdomain> Hello, I want to use rxtx in my application. I haveto send data to a very old printer (which have a drum and hammers http://perso.orange.fr/tiie/page00010017.html) This is printer is connecter with centronics. It works well but, while it's writting and I putthe printer off-line, after about 45 seconds, I have this error : ------------------------------------- java.io.IOException: La ressource demand?e est en cours d'utilisation. in writeArray at gnu.io.LPRPort.writeArray(Native Method) at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:292) at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:161) at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:156) at mce.buffer.bufferManager.BufferManager$PrintBuffer.run(BufferManager.java:141) The IOexception means "The wanted resource is in use" ------------------------------------- Here is the line 141 of BufferManager : ------------------------------------- while(send){ try{ fos.write(bb); <=== line 141 send = false; } catch(Exception e){ javax.swing.JOptionPane.showMessageDialog(null, "Erreur d'envoie. Veuillez cliquer sur OK pour relancer l'impression de la vignette.\nV?rifiez votre impression !", "Erreur d'envoie", javax.swing.JOptionPane.WARNING_MESSAGE); e.printStackTrace(System.err); System.err.flush(); System.out.println(e); send = true; } } -------------------------------- 'fos' is an outputstream which contains the rxtx stream (this.os is the rxtx outputstream) : -------------------------------- public void write(byte[] bb) throws IOException{ this.write(bb, 0, bb.length); } public void write(byte[] bb, int off, int len) throws IOException{ while(!imp1.isPrinterSelected() || !imp2.isPrinterSelected()){ } this.os.write(bb, off, len); } -------------------------------- Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( can you help me ? thank you :) -- yves piel From yvespielusenet at free.fr Wed Jun 6 09:11:15 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 17:11:15 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181141195.3407.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> Message-ID: <1181142675.3407.23.camel@localhost.localdomain> I forgot to tell that It's under windows XP and java 1.5. Le mercredi 06 juin 2007 ? 16:46 +0200, yves pielusenet a ?crit : > Hello, > I want to use rxtx in my application. I haveto send data to a very old > printer (which have a drum and hammers > http://perso.orange.fr/tiie/page00010017.html) > This is printer is connecter with centronics. It works well but, while > it's writting and I putthe printer off-line, after about 45 seconds, I > have this error : > ------------------------------------- > java.io.IOException: La ressource demand?e est en cours d'utilisation. > in writeArray > at gnu.io.LPRPort.writeArray(Native Method) > at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:292) > at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:161) > at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:156) > at mce.buffer.bufferManager.BufferManager$PrintBuffer.run(BufferManager.java:141) > > The IOexception means "The wanted resource is in use" > ------------------------------------- > > Here is the line 141 of BufferManager : > > ------------------------------------- > while(send){ > try{ > fos.write(bb); <=== line 141 > send = false; > } > catch(Exception e){ > javax.swing.JOptionPane.showMessageDialog(null, "Erreur d'envoie. Veuillez cliquer sur OK pour relancer l'impression de la vignette.\nV?rifiez votre impression !", "Erreur d'envoie", javax.swing.JOptionPane.WARNING_MESSAGE); > e.printStackTrace(System.err); > System.err.flush(); > System.out.println(e); > send = true; > } > } > -------------------------------- > 'fos' is an outputstream which contains the rxtx stream (this.os is the rxtx outputstream) : > > -------------------------------- > public void write(byte[] bb) throws IOException{ > this.write(bb, 0, bb.length); > } > public void write(byte[] bb, int off, int len) throws IOException{ > while(!imp1.isPrinterSelected() || !imp2.isPrinterSelected()){ > } > this.os.write(bb, off, len); > } > -------------------------------- > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > can you help me ? > > thank you :) > From netbeans at gatworks.com Wed Jun 6 09:21:46 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 11:21:46 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181141195.3407.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> Message-ID: <4666D10A.8000507@gatworks.com> } > -------------------------------- > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > can you help me ? > > thank you :) > windoz or linux? ( I guess windoz ) for windoz, there appears to be a timeout ( as Comments suggest ) of about 40seconds. > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } for linux, there is no implied timeout. > if( write( fd, bytes, count ) < 0 ) > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); From netbeans at gatworks.com Wed Jun 6 09:39:41 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 11:39:41 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666D10A.8000507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> Message-ID: <4666D53D.90000@gatworks.com> Uncle George wrote: > } >> -------------------------------- >> >> Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( >> >> can you help me ? From reading the code, I can see your concern. And it appears you are correct, because some of the data will be sent to the OS printer buffers, and then it will refuse to accept anymore. Unfortunately, writeArray does not return the num of characters written :{ So application has no idea to how many characters were accepted by the OS. I dont do windoz, so I cant say with absolute certainty what windoz will do with an off-line condition. If you have the source, and can compile, then maybe u can increase the loop count to hit 4hours? From yvespielusenet at free.fr Wed Jun 6 09:53:25 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 17:53:25 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666D10A.8000507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> Message-ID: <1181145205.3407.35.camel@localhost.localdomain> Thank you for your explanation :) This timeout comes when no data has been send to the printer after 40seconds if I well understand. But why there is such a timeout ? If I setthe printer offline while it's printing I mustn't have an exception. I don't understand why the "printer should solv all problems like buffer full" in 40 seconds. If I pause the printer the buffer will not be emptied, isn't it ? I not very familiar with C/C++, but it seem that the exception is thrown only when countWritten == 0, that means no data at all has been sent. So Is my code is good since when I intercept this exception I send all my buffer again. There is no way that the printer receive two times same bytes ? thanks ps: yes the application is running on windows XP since I developpe under Debian Le mercredi 06 juin 2007 ? 11:21 -0400, Uncle George a ?crit : > } > > -------------------------------- > > > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > > > can you help me ? > > > > thank you :) > > > > windoz or linux? ( I guess windoz ) > > for windoz, there appears to be a timeout ( as Comments suggest ) of > about 40seconds. > > while( count > 0 ){ > > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > > /* > > this are 20 * 2 seconds, in this time a printer (or other parallel device) > > should solv all problems like buffer full, etc > > */ > > if(errorCount++ < 20){ > > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > > continue; > > } > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > for linux, there is no implied timeout. > > if( write( fd, bytes, count ) < 0 ) > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Wed Jun 6 10:34:24 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 12:34:24 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181145205.3407.35.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> Message-ID: <4666E210.30507@gatworks.com> yves pielusenet wrote: > Thank you for your explanation :) > This timeout comes when no data has been send to the printer after > 40seconds if I well understand. But why there is such a timeout ? If I > setthe printer offline while it's printing I mustn't have an exception. > I don't understand why the "printer should solv all problems like buffer > full" in 40 seconds. If I pause the printer the buffer will not be > emptied, isn't it ? > > I not very familiar with C/C++, but it seem that the exception is thrown > only when countWritten == 0, that means no data at all has been sent. So > Is my code is good since when I intercept this exception I send all my > buffer again. There is no way that the printer receive two times same > bytes ? More technically, the function call returns and reports that 0 characters was written in this call. when 0 characters are written, it will check how many times 0 characters was written. If it has tried LESS than 20 times(errorCount), it will sleep() and try to write again. After 20 times, it wont sleep, but throw you the exception. Now suppose you are writing a 120 character line. you off-lined/paused your printer. The OS has room for 80 more characters in it's printer buffer. The WriteFile() will have a char count of 120, but on return the countWritten = 80. You still have 40 more characters to print. Since countWritten != 0, the counters: bytes += countWritten; count -= countWritten; get updated, and the Writefile now has a count of 40 characters. Since the printer is off-line, the countwritten is 0. And so the loop continues, till 40 seconds is up. As to why it is this way, i dont know ( not a windoz maven ); Also the sleep(20) in the loop is not so intuitive to suggest 2 seconds of sleep. I would have guessed 20seconds, or 20milliseconds. But go figure. BTW: Since your computer sends you error messages in French, does it curse in English? :)))) From yvespielusenet at free.fr Thu Jun 7 02:27:44 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Thu, 07 Jun 2007 10:27:44 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666E210.30507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> Message-ID: <1181204864.3501.10.camel@localhost.localdomain> Maybe in my case I should re-compile rxtx and change the code. Instead of send an exception I should display a dialog box to ask if it's printer problem or if it should trie to send bytes. Something like : while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } if(displayDialogBox("Try again to send datas ??")){ errorCount = 0; } else{ throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } } Le mercredi 06 juin 2007 ? 12:34 -0400, Uncle George a ?crit : > yves pielusenet wrote: > > Thank you for your explanation :) > > This timeout comes when no data has been send to the printer after > > 40seconds if I well understand. But why there is such a timeout ? If I > > setthe printer offline while it's printing I mustn't have an exception. > > I don't understand why the "printer should solv all problems like buffer > > full" in 40 seconds. If I pause the printer the buffer will not be > > emptied, isn't it ? > > > > I not very familiar with C/C++, but it seem that the exception is thrown > > only when countWritten == 0, that means no data at all has been sent. So > > Is my code is good since when I intercept this exception I send all my > > buffer again. There is no way that the printer receive two times same > > bytes ? > More technically, the function call returns and reports that 0 > characters was written in this call. > when 0 characters are written, it will check how many times 0 characters > was written. If it has tried LESS than 20 times(errorCount), it will > sleep() and try to write again. > After 20 times, it wont sleep, but throw you the exception. > > Now suppose you are writing a 120 character line. you off-lined/paused > your printer. The OS has room for 80 more characters in it's printer > buffer. The WriteFile() will have a char count of 120, but on return the > countWritten = 80. You still have 40 more characters to print. > Since countWritten != 0, the counters: > bytes += countWritten; > count -= countWritten; > get updated, and the Writefile now has a count of 40 characters. Since > the printer is off-line, the countwritten is 0. And so the loop > continues, till 40 seconds is up. > > As to why it is this way, i dont know ( not a windoz maven ); > Also the sleep(20) in the loop is not so intuitive to suggest 2 seconds > of sleep. I would have guessed 20seconds, or 20milliseconds. But go figure. > > BTW: Since your computer sends you error messages in French, does it > curse in English? :)))) > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 06:11:43 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 08:11:43 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181204864.3501.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> Message-ID: <4667F5FF.8070903@gatworks.com> your suggestion appears good. I dont know what displayDialogBox exactly will do, so all I can say it that it looks good. But I'd like to wait 10min before first dialog box And a 5 min wait for every dialog box there after. And since these are custom solution/choices, maybe a more exact explanation of what the issue is. if(errorCount++ < 300){ // wait 10min ( 10min * 60sec / 2 ) Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } if(displayDialogBox("Printer has Paused. Retry sending data?")){ errorCount = 150; // Wait for 5 min thereafter continue; } > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } yves pielusenet wrote: > Maybe in my case I should re-compile rxtx and change the code. Instead > of send an exception I should display a dialog box to ask if it's > printer problem or if it should trie to send bytes. Something like : > > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > > if(displayDialogBox("Try again to send datas ??")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > } > From yvespielusenet at free.fr Thu Jun 7 07:17:21 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Thu, 07 Jun 2007 15:17:21 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4667F5FF.8070903@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <4667F5FF.8070903@gatworks.com> Message-ID: <1181222241.3501.20.camel@localhost.localdomain> thank you :) 'displayDialogBox()' I think doesn't exist. It was just for the example :) But I think It should not be so complicated to display a dialog box under windows with YES/NO buttons. When yes is clicked it return 0 other it returns 1. Le jeudi 07 juin 2007 ? 08:11 -0400, Uncle George a ?crit : > your suggestion appears good. I dont know what displayDialogBox exactly > will do, so all I can say it that it looks good. > > But I'd like to wait 10min before first dialog box And a 5 min wait for > every dialog box there after. And since these are custom > solution/choices, maybe a more exact explanation of what the issue is. > > if(errorCount++ < 300){ // wait 10min ( 10min * 60sec / 2 ) > Sleep( 20 ); /* make a small pause to execute all other requests > in all other threads */ > continue; > } > > if(displayDialogBox("Printer has Paused. Retry sending data?")){ > errorCount = 150; // Wait for 5 min thereafter > continue; > } > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > > yves pielusenet wrote: > > Maybe in my case I should re-compile rxtx and change the code. Instead > > of send an exception I should display a dialog box to ask if it's > > printer problem or if it should trie to send bytes. Something like : > > > > while( count > 0 ){ > > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > > /* > > this are 20 * 2 seconds, in this time a printer (or other parallel device) > > should solv all problems like buffer full, etc > > */ > > if(errorCount++ < 20){ > > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > > continue; > > } > > > > if(displayDialogBox("Try again to send datas ??")){ > > errorCount = 0; > > } > > else{ > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > } > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 07:41:43 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 09:41:43 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181222241.3501.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <4667F5FF.8070903@gatworks.com> <1181222241.3501.20.camel@localhost.localdomain> Message-ID: <46680B17.8050109@gatworks.com> yves pielusenet wrote: > thank you :) > 'displayDialogBox()' I think doesn't exist. It was just for the > example :) too bad. Good luck. From rtrout at webbresearch.com Thu Jun 7 11:23:04 2007 From: rtrout at webbresearch.com (Robert Trout) Date: Thu, 07 Jun 2007 13:23:04 -0400 Subject: [Rxtx] Disconnected PortServer TS causes Java to hang Message-ID: <1181236984.14186.33.camel@sisyphus.DinkumSoftware.com> I'm running Linux with sun's Java 1.4.2, Java comm API 2.0, RXTX 2.0-7pre1, and the RealPort digi driver. "/dev/ttyrp00" is a RealPort device. My Java application never returns from a ComPortIdentifier.getPortIdentifier("/dev/ttyrp00") call while the Digi PortServer TS 4 is disconnected from the network. If I later re-connect the PortServer, the call returns about 30 seconds later (it's like a serial port read or write is blocking until the PortServer is re- connected). With the PortServer disconnected, minicom immediately responds with "cannot open /dev/ttyrp00: No such file or directory". I would like my Java application to behave similarly. That is, respond with an error condition instead of hanging when the PortServer is not connected. Since minicom and Java behave differently, I think this "hanging" behavior may be due to RXTX or Java? Has anyone had a similar issue? Solutions? Suggestions? Thanks, Robert From vicnevicne at gmail.com Thu Jun 7 12:16:02 2007 From: vicnevicne at gmail.com (Vicne) Date: Thu, 07 Jun 2007 20:16:02 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181204864.3501.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> Message-ID: <46684B62.7080802@gmail.com> yves pielusenet wrote: > Maybe in my case I should re-compile rxtx and change the code. Instead > of send an exception I should display a dialog box to ask if it's > printer problem or if it should trie to send bytes. Something like : > > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > > if(displayDialogBox("Try again to send datas ??")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > } > Sorry to step in without a specific solution to your problem, but I wanted to share my feeling regarding this proposal. AFAIK, it's generally considered bad practice to pop-up a prompt from a library. The main reason is that in general use, you can't guarantee that someone is actually present behind the console. Imagine a print server in a machine room, connected to a park of printers. In that case, when one printer fails, the logical behaviour would be to use an other one. If you change RxTx the way you propose, the printer queue will simply be stuck with a useless "Try again to send data ?" prompt until an administrator opens a remote connection to the print server's console and clicks "no". Second, it would create a dependency upon the existence of a graphical console (if you go the graphical "dialogBox" way). On many applications (typically server or embedded ones), the JVM is "headless" and if you try to pop-up a dialog, your app would throw an exception (at best) or just wouldn't display the prompt anywhere... Going the "text console" way is not more reliable, because on graphical environments, the text console is hidden unless explicitly requested. My advice would be to think again and find another solution. Ideas are : - make the number of retries a parameter so that you can tune it to what you think is reasonable - throw a more specific exception when the number of retries has been reached, so that a specific prompt can be shown at a higher level Anyway, if you feel that the prompt is the way to go in your case, I would at least make that prompt conditional. The least intrusive way would probably be using a system property, like if("true".equals(System.getProperty("org.rxtx.usePrompt")) && displayDialogBox("Retry sending data ?")){ errorCount = 0; } else{ throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } By default, the behaviour would remain as it is now, but you could force the prompts by defining the property at VM launch if desired. (for example : java.exe -Dorg.rxtx.usePrompt=true myApp) Also, you seemed to say you wanted the printer to start again exactly where is stopped. It would indeed be the best way when the printer is put offline for a few seconds. On the other hand, if the printer is turned off (or the printer runs out of paper, or someone steps on the mains cable), then the only way to go back to a "stable" situation would be by printing the item (page, label, etc.) again from scratch... Just my two cents. Vicne PS : By the way, the dialog box thing is very platform dependant on the C-side, and I think the simplest way would probably be to bridge it to a Java call where you can implement it like you proposed : public boolean displayDialogBox(prompt) { return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); } From netbeans at gatworks.com Thu Jun 7 14:08:24 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 16:08:24 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46684B62.7080802@gmail.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> Message-ID: <466865B8.4060004@gatworks.com> My feeling is that the code that was suggested was for his environs ( his shop ). The issue here is that after a 40+ second wait, an exception will be thrown. But you really dont have a way of 'cancelling' all the WriteFiles() that have already occured before the exception so that your writeArray and the Commapi can backtrack to a position in which they are in sync. The main ( really mine ) concern is not to lose data, or replicate data. After 40seconds, 300 seconds, 55min, no matter how long, data should not be lost or duplicated. But as soon as the exception is thrown, that possibility exists. Maybe an event should be thrown instead? Vicne wrote: > yves pielusenet wrote: >> Maybe in my case I should re-compile rxtx and change the code. Instead >> of send an exception I should display a dialog box to ask if it's >> printer problem or if it should trie to send bytes. Something like : >> >> while( count > 0 ){ >> if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ >> /* >> this are 20 * 2 seconds, in this time a printer (or other parallel device) >> should solv all problems like buffer full, etc >> */ >> if(errorCount++ < 20){ >> Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ >> continue; >> } >> >> if(displayDialogBox("Try again to send datas ??")){ >> errorCount = 0; >> } >> else{ >> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >> break; >> } >> } >> > > Sorry to step in without a specific solution to your problem, but I > wanted to share my feeling regarding this proposal. AFAIK, it's > generally considered bad practice to pop-up a prompt from a library. > The main reason is that in general use, you can't guarantee that > someone is actually present behind the console. Imagine a print server > in a machine room, connected to a park of printers. In that case, when > one printer fails, the logical behaviour would be to use an other one. > If you change RxTx the way you propose, the printer queue will simply be > stuck with a useless "Try again to send data ?" prompt until an > administrator opens a remote connection to the print server's console > and clicks "no". > Second, it would create a dependency upon the existence of a > graphical console (if you go the graphical "dialogBox" way). On many > applications (typically server or embedded ones), the JVM is "headless" > and if you try to pop-up a dialog, your app would throw an exception (at > best) or just wouldn't display the prompt anywhere... Going the "text > console" way is not more reliable, because on graphical environments, > the text console is hidden unless explicitly requested. > > My advice would be to think again and find another solution. Ideas are : > - make the number of retries a parameter so that you can tune it to what > you think is reasonable > - throw a more specific exception when the number of retries has been > reached, so that a specific prompt can be shown at a higher level > > Anyway, if you feel that the prompt is the way to go in your case, I > would at least make that prompt conditional. The least intrusive way > would probably be using a system property, like > > if("true".equals(System.getProperty("org.rxtx.usePrompt")) > && displayDialogBox("Retry sending data ?")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > > > By default, the behaviour would remain as it is now, but you could > force the prompts by defining the property at VM launch if desired. (for > example : java.exe -Dorg.rxtx.usePrompt=true myApp) > > > Also, you seemed to say you wanted the printer to start again > exactly where is stopped. It would indeed be the best way when the > printer is put offline for a few seconds. On the other hand, if the > printer is turned off (or the printer runs out of paper, or someone > steps on the mains cable), then the only way to go back to a "stable" > situation would be by printing the item (page, label, etc.) again from > scratch... > > > Just my two cents. > > > Vicne > > PS : By the way, the dialog box thing is very platform dependant on the > C-side, and I think the simplest way would probably be to bridge it to a > Java call where you can implement it like you proposed : > > public boolean displayDialogBox(prompt) { > return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", > JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); > } > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Thu Jun 7 17:48:11 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 Jun 2007 17:48:11 -0600 (MDT) Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <466865B8.4060004@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> Message-ID: An event is possible. I'm amazed this is the largest problem encountered while using the parallel code. How would the write ever exit if we throw events? Isn't this going to lead to hung applications? On Thu, 7 Jun 2007, Uncle George wrote: > My feeling is that the code that was suggested was for his environs ( > his shop ). > > The issue here is that after a 40+ second wait, an exception will be > thrown. But you really dont have a way of 'cancelling' all the > WriteFiles() that have already occured before the exception so that your > writeArray and the Commapi can backtrack to a position in which they are > in sync. > > The main ( really mine ) concern is not to lose data, or replicate data. > After 40seconds, 300 seconds, 55min, no matter how long, data should > not be lost or duplicated. But as soon as the exception is thrown, that > possibility exists. > > Maybe an event should be thrown instead? > > Vicne wrote: >> yves pielusenet wrote: >>> Maybe in my case I should re-compile rxtx and change the code. Instead >>> of send an exception I should display a dialog box to ask if it's >>> printer problem or if it should trie to send bytes. Something like : >>> >>> while( count > 0 ){ >>> if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ >>> /* >>> this are 20 * 2 seconds, in this time a printer (or other parallel device) >>> should solv all problems like buffer full, etc >>> */ >>> if(errorCount++ < 20){ >>> Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ >>> continue; >>> } >>> >>> if(displayDialogBox("Try again to send datas ??")){ >>> errorCount = 0; >>> } >>> else{ >>> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >>> break; >>> } >>> } >>> >> >> Sorry to step in without a specific solution to your problem, but I >> wanted to share my feeling regarding this proposal. AFAIK, it's >> generally considered bad practice to pop-up a prompt from a library. >> The main reason is that in general use, you can't guarantee that >> someone is actually present behind the console. Imagine a print server >> in a machine room, connected to a park of printers. In that case, when >> one printer fails, the logical behaviour would be to use an other one. >> If you change RxTx the way you propose, the printer queue will simply be >> stuck with a useless "Try again to send data ?" prompt until an >> administrator opens a remote connection to the print server's console >> and clicks "no". >> Second, it would create a dependency upon the existence of a >> graphical console (if you go the graphical "dialogBox" way). On many >> applications (typically server or embedded ones), the JVM is "headless" >> and if you try to pop-up a dialog, your app would throw an exception (at >> best) or just wouldn't display the prompt anywhere... Going the "text >> console" way is not more reliable, because on graphical environments, >> the text console is hidden unless explicitly requested. >> >> My advice would be to think again and find another solution. Ideas are : >> - make the number of retries a parameter so that you can tune it to what >> you think is reasonable >> - throw a more specific exception when the number of retries has been >> reached, so that a specific prompt can be shown at a higher level >> >> Anyway, if you feel that the prompt is the way to go in your case, I >> would at least make that prompt conditional. The least intrusive way >> would probably be using a system property, like >> >> if("true".equals(System.getProperty("org.rxtx.usePrompt")) >> && displayDialogBox("Retry sending data ?")){ >> errorCount = 0; >> } >> else{ >> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >> break; >> } >> >> >> By default, the behaviour would remain as it is now, but you could >> force the prompts by defining the property at VM launch if desired. (for >> example : java.exe -Dorg.rxtx.usePrompt=true myApp) >> >> >> Also, you seemed to say you wanted the printer to start again >> exactly where is stopped. It would indeed be the best way when the >> printer is put offline for a few seconds. On the other hand, if the >> printer is turned off (or the printer runs out of paper, or someone >> steps on the mains cable), then the only way to go back to a "stable" >> situation would be by printing the item (page, label, etc.) again from >> scratch... >> >> >> Just my two cents. >> >> >> Vicne >> >> PS : By the way, the dialog box thing is very platform dependant on the >> C-side, and I think the simplest way would probably be to bridge it to a >> Java call where you can implement it like you proposed : >> >> public boolean displayDialogBox(prompt) { >> return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", >> JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); >> } >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 19:18:51 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 21:18:51 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> Message-ID: <4668AE7B.3060409@gatworks.com> The UNIX version of writeArray is not too great either. It is possible that the write will only process some of the bytes. #else if( write( fd, bytes, count ) < 0 ) throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); #endif -------------------------------- Maybe it might be better to have the native function inform the caller of the # of characters written, then the commapi/output-buffer can be modified to reflect the #of chars written. If an exception is to be thrown, for too many loops of chars written == 0, then exception wont affect the state of the output buffer. Then a ParallelPort.restart() can be called to resume printing whats in the buffer. Trent Jarvi wrote: > An event is possible. I'm amazed this is the largest problem encountered > while using the parallel code. > > How would the write ever exit if we throw events? Isn't this going to > lead to hung applications? Sure. If you dont time out, then there is nothing that will force an EXIT from the write(). Issue is what has the OS done with the write. > > On Thu, 7 Jun 2007, Uncle George wrote: > >> My feeling is that the code that was suggested was for his environs ( >> his shop ). From yvespielusenet at free.fr Fri Jun 8 01:09:01 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Fri, 08 Jun 2007 09:09:01 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4668AE7B.3060409@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> Message-ID: <1181286541.3674.10.camel@localhost.localdomain> It is not possible that the rxtx java method write(byte[], int offset, int length) return anint which contains the number of byte really send to the printer instead of an exception ? So this is the programm which will see if all bytes have been sent. If not it can retry to send the unsended bytes. -------------------------------------------------------- int sended = 0; while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ sended += countWritten; /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } return sended; /*throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break;*/ } ... ... return countWritten; ------------------------------------------------ Le jeudi 07 juin 2007 ? 21:18 -0400, Uncle George a ?crit : > The UNIX version of writeArray is not too great either. It is possible > that the write will only process some of the bytes. > > #else > if( write( fd, bytes, count ) < 0 ) > throw_java_exception_system_msg( env, IO_EXCEPTION, > "writeArray" ); > #endif > -------------------------------- > > Maybe it might be better to have the native function inform the caller > of the # of characters written, then the commapi/output-buffer can be > modified to reflect the #of chars written. If an exception is to be > thrown, for too many loops of chars written == 0, then exception wont > affect the state of the output buffer. Then a ParallelPort.restart() can > be called to resume printing whats in the buffer. > > > Trent Jarvi wrote: > > An event is possible. I'm amazed this is the largest problem encountered > > while using the parallel code. > > > > How would the write ever exit if we throw events? Isn't this going to > > lead to hung applications? > Sure. If you dont time out, then there is nothing that will force an > EXIT from the write(). Issue is what has the OS done with the write. > > > > On Thu, 7 Jun 2007, Uncle George wrote: > > > >> My feeling is that the code that was suggested was for his environs ( > >> his shop ). > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Fri Jun 8 03:45:00 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 11:45:00 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181286541.3674.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> Message-ID: <20070608094500.GC21069@elberon.bln.de.ingenico.com> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > It is not possible that the rxtx java method write(byte[], int offset, > int length) return anint which contains the number of byte really send > to the printer instead of an exception ? > So this is the programm which will see if all bytes have been sent. If > not it can retry to send the unsended bytes. I think write() is void because in Java people love to do this since OutputStream :-) Of course on such interfaces you cannot implement something nice. If you would have a int write, you would not implement the interface and no applications expecting this interface would link/work/compile. oki, Steffen P.S.: (OT) If you propose not to implement the Java interfaces (especially not on JNI level), maybe optionally offering a wrapper that removes e.g. the write return value and so on to downgrade the powerful classic old POSIX read/write style to the modern limited Java style, then I agree :-) Same for read. Instead of things like "int avialable()" it is more powerful to have an approach as select(2) offers (to guarante the caller that read/write will not block [nothing else make sense anyway IMHO] but may read/write less bytes then requested). The caller gets full control and the higher level protocols can care about timeouts, invoking read in some loops and/or implement retransmission. On top of such an implementation, where everything is controlled, defined, guaranteed and reliable, someone could use an InputStream or OutputStream style interface. Or even better: don't use them at all :) just BTW :-) St. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From yvespielusenet at free.fr Fri Jun 8 05:52:45 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Fri, 08 Jun 2007 13:52:45 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <20070608094500.GC21069@elberon.bln.de.ingenico.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> Message-ID: <1181303565.11203.3.camel@localhost.localdomain> So maybe a better way should be to create a new Exception class which has a method "int getWrittenByte()". So the Exception should be use to send again bytes which are not printed yet. yves Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : > * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > > It is not possible that the rxtx java method write(byte[], int offset, > > int length) return anint which contains the number of byte really send > > to the printer instead of an exception ? > > So this is the programm which will see if all bytes have been sent. If > > not it can retry to send the unsended bytes. > > I think write() is void because in Java people love to do this > since OutputStream :-) Of course on such interfaces you cannot > implement something nice. If you would have a int write, you > would not implement the interface and no applications expecting > this interface would link/work/compile. > > oki, > > Steffen > > P.S.: (OT) > If you propose not to implement the Java interfaces (especially > not on JNI level), maybe optionally offering a wrapper that > removes e.g. the write return value and so on to downgrade the > powerful classic old POSIX read/write style to the modern limited > Java style, then I agree :-) Same for read. Instead of things > like "int avialable()" it is more powerful to have an approach as > select(2) offers (to guarante the caller that read/write will not > block [nothing else make sense anyway IMHO] but may read/write > less bytes then requested). The caller gets full control and the > higher level protocols can care about timeouts, invoking read in > some loops and/or implement retransmission. On top of such an > implementation, where everything is controlled, defined, > guaranteed and reliable, someone could use an InputStream or > OutputStream style interface. Or even better: don't use them at > all :) just BTW :-) > St. > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > 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. > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > 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. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Fri Jun 8 06:46:21 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 08:46:21 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181303565.11203.3.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> Message-ID: <46694F9D.5080501@gatworks.com> It seems that with outputstream.write(b[]), you become terribly uncoordinated as soon as an exception is thrown. Docs do not say what happens to the data. Yet from a practicable point of view, one would like to know if the write was accepted in-full, or rejected before any writes. There are no in betweens, as partial writes are not reportable. So for an outputstream.write(), in order for it to return, the full write request has to be taken, and stored in an internal output buffer. If there is no room, the write() is suspended, till there is room. Or throw's an IOException( "no room in buffer") ; As the select() loop for write reports buffer room avail, then more of the internal buffer is sent to the printer. yves pielusenet wrote: > So maybe a better way should be to create a new Exception class which > has a method "int getWrittenByte()". So the Exception should be use to > send again bytes which are not printed yet. > > yves > > Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : >> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: >>> It is not possible that the rxtx java method write(byte[], int offset, >>> int length) return anint which contains the number of byte really send >>> to the printer instead of an exception ? >>> So this is the programm which will see if all bytes have been sent. If >>> not it can retry to send the unsended bytes. >> I think write() is void because in Java people love to do this >> since OutputStream :-) Of course on such interfaces you cannot >> implement something nice. If you would have a int write, you >> would not implement the interface and no applications expecting >> this interface would link/work/compile. >> >> oki, >> >> Steffen >> >> P.S.: (OT) >> If you propose not to implement the Java interfaces (especially >> not on JNI level), maybe optionally offering a wrapper that >> removes e.g. the write return value and so on to downgrade the >> powerful classic old POSIX read/write style to the modern limited >> Java style, then I agree :-) Same for read. Instead of things >> like "int avialable()" it is more powerful to have an approach as >> select(2) offers (to guarante the caller that read/write will not >> block [nothing else make sense anyway IMHO] but may read/write >> less bytes then requested). The caller gets full control and the >> higher level protocols can care about timeouts, invoking read in >> some loops and/or implement retransmission. On top of such an >> implementation, where everything is controlled, defined, >> guaranteed and reliable, someone could use an InputStream or >> OutputStream style interface. Or even better: don't use them at >> all :) just BTW :-) >> St. >> >> About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. >> 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. >> >> About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. >> 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. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From Steffen.DETTMER at ingenico.com Fri Jun 8 08:12:18 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 16:12:18 +0200 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <46694F9D.5080501@gatworks.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: <20070608141218.GE21069@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 08:46 -0400: > It seems that with outputstream.write(b[]), you become terribly > uncoordinated as soon as an exception is thrown. Docs do not say what > happens to the data. (yes, so avoiding it seems to be good :)) > Yet from a practicable point of view, one would like to know if the > write was accepted in-full, or rejected before any writes. There are no > in betweens, as partial writes are not reportable. (which is an artificial API limitation. I never understood how this happend when they invented JDK because the well-known BSD socket API and thus [probably] WinSock does this correct, but anyway) > So for an outputstream.write(), in order for it to return, the full > write request has to be taken, and stored in an internal output buffer. > If there is no room, the write() is suspended, till there is room. Or > throw's an IOException( "no room in buffer") ; As the select() loop for > write reports buffer room avail, then more of the internal buffer is > sent to the printer. yes, might be good in case of a printer. May be horrible in case of PPP/TCP or some other transmission control protocol which may e.g. repeat data or even omit parts of it (e.g. internet realtime radio station broadcasting)... So I think the idea of "int write" (e.g. BSD sockets, linux files and so on) still is the best. A clean API / implementation should guarantee and allow implementations (users) to rely on that; assumptions and automatic background-sending and so on may look pragmatic and may even work on the first look, but may fail in other situations. BTW, if e.g. BSD socket API is known, why not simply copy it (until something better is invented :)) instead of fiddling around with JDK APIs? anyway, have a nice weekend everyone :-) oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Fri Jun 8 08:55:56 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 10:55:56 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070608141218.GE21069@elberon.bln.de.ingenico.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> Message-ID: <46696DFC.7000801@gatworks.com> >> write reports buffer room avail, then more of the internal buffer is >> sent to the printer. > > yes, might be good in case of a printer. May be horrible in case > of PPP/TCP or some other transmission control protocol which > may e.g. repeat data or even omit parts of it (e.g. internet > realtime radio station broadcasting)... So I think the idea of > "int write" (e.g. BSD sockets, linux files and so on) still is > the best. A clean API / implementation should guarantee and allow > implementations (users) to rely on that; assumptions and > automatic background-sending and so on may look pragmatic and may > even work on the first look, but may fail in other situations. > BTW, if e.g. BSD socket API is known, why not simply copy it > (until something better is invented :)) instead of fiddling > around with JDK APIs? But we were talking about the Parallel Port, and the transmission of data over the commapi/parallel-port schema. There isn't much in bi-directional software communication. Its a simple write one byte at a time interface. I'm not looking to change the comm-api. I'm just looking to alter the interaction between the Native ParallelPort functions, and the java ParallelPort functions that call them. This might be more readily doable than to get a committee to re-specify java-API specs. BTW: Whats is off-topic? ( help: not looking for def of off-topic ) From j.kenneth.gentle at acm.org Fri Jun 8 08:58:59 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Fri, 08 Jun 2007 10:58:59 -0400 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <20070608141218.GE21069@elberon.bln.de.ingenico.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> Message-ID: <200706081459.l58Ex5rA019991@qbang.org> Perhaps it is a bit late to jump in on this one, but here goes anyway. If the solutions all seem to "break" the contract with "java.io.outputstream", then, as noted, that may not be the appropriate contract. At the risk of being heretical, JDK1.4 introduced the "nio" package to address some of the compatibility issues with C apis mentioned in previous posts. The interface "java.nio.channels.WriteableByteChannel" defines the following single method: int write(ByteBuffer source); int, strangely enough, is the actual number of bytes written. So, if RXTX as written, against the JavaCOMM api and OutputStream, doesn't do what we want, how about writing a different set of bindings using the java.nio classes and as much of the underlying native code as possible. Note that just because the java.nio.channels.WriteableByteChannel sends back a result, OutputStream.write doesn't have to - and they could both call the same underlying native code. My 2 cents - maybe not worth even that... Ken From netbeans at gatworks.com Fri Jun 8 10:37:28 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 12:37:28 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <200706081459.l58Ex5rA019991@qbang.org> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> Message-ID: <466985C8.8000505@gatworks.com> Ken Gentle wrote: > Perhaps it is a bit late to jump in on this one, but here goes anyway. Common in, the waters fine. > > If the solutions all seem to "break" the contract with > "java.io.outputstream", then, as noted, that may not be the > appropriate contract. > How would the contract be broken? The machinery underneath is handling the contract. From j.kenneth.gentle at acm.org Fri Jun 8 10:48:01 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Fri, 08 Jun 2007 12:48:01 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466985C8.8000505@gatworks.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> Message-ID: <200706081648.l58Gm7YA022904@qbang.org> At 12:37 2007-06-08, you wrote: >Ken Gentle wrote: > > > > If the solutions all seem to "break" the contract with > > "java.io.outputstream", then, as noted, that may not be the > > appropriate contract. > > >How would the contract be broken? The machinery underneath is handling >the contract. It seems that a lot of the discussion has been about not only the timeout and being able to adjust it in the "machinery layer", but also about knowing in the Java layer, in the event of a timeout or exception, how many characters have been written to the device. An OutputStream won't ever do this with out an extension and including a return value "breaks" the contract, right? So, go with a Java IO api that *does* return the number of bytes written, out of the NIO package. I know it doesn't allow for a strict implementation of the JavaCOMM API - however, using NIO classes in place of the IO classes isn't that big a break and would allow those applications that need such information a way to get it. Maybe I'm misunderstanding the problem... Ken From netbeans at gatworks.com Fri Jun 8 11:24:14 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 13:24:14 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <200706081648.l58Gm7YA022904@qbang.org> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> Message-ID: <466990BE.7040100@gatworks.com> Ken Gentle wrote: An > OutputStream won't ever do this with out an extension and including a > return value "breaks" the contract, right? > i was not thinking of change the API to OutputSream. Are there specs for how output stream should work internally? for instance: String data = "Hello this is a line of data"; Outputstream.write( data.getbytes() ); ParallelPort.suspend(); int free = ParallelPort.getoutputbufferfree(); There is a symbiotic relationship between outputstream and the functionality of ParallelPort. From Steffen.DETTMER at ingenico.com Fri Jun 8 11:15:39 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 19:15:39 +0200 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <200706081459.l58Ex5rA019991@qbang.org> References: <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> Message-ID: <20070608171539.GK21069@elberon.bln.de.ingenico.com> * Ken Gentle wrote on Fri, Jun 08, 2007 at 10:58 -0400: > If the solutions all seem to "break" the contract with > "java.io.outputstream", then, as noted, that may not be the > appropriate contract. > > At the risk of being heretical, JDK1.4 introduced the "nio" package > to address some of the compatibility issues with C apis mentioned in > previous posts. The interface > "java.nio.channels.WriteableByteChannel" defines the following single method: > > int write(ByteBuffer source); > > int, strangely enough, is the actual number of bytes written. Yes, AFAIK one of the motivations for the NIO interface was, that the JDK-1.3 APIs (InputStream, e.g.) were not powerfull enough, especially for multi-connection-TCP servers or so. I don't know much about it but I've heard of a project where NIO usage was removed because of stability issues in multi-threaded environments and performance limitations under some circumstances. IIRC the "nio.ByteBuffer" is something very special (namely something you cannot implement in Java, it is "magic" or part of the language itself). Not sure if this is such a great idea (but for performance in the end sometimes heavy prices must be paid) :) > So, if RXTX as written, against the JavaCOMM api and OutputStream, > doesn't do what we want, how about writing a different set of > bindings using the java.nio classes and as much of the underlying > native code as possible. Yes, this would be an idea: use a full-featured interface on JNI, and, if wanted, deliver some wrappers converting this to a less-featured Java-compliant interface. However, powerful things as e.g. "select" are difficult to "emulate" if you are e.g. on some (older?) windows. But if you expose the full-featured APIs, you need to emulate them full-featured, theoretically. In the end it depends what you do on the serial line. If you just want to talk to a modem, then you may not need precise timeouts. But if you need to implement complexer protocols which define response times and timeouts, you may quickly get into difficulties. For instance, AFAIK, rxtx 1.7.2 (?) for windows is very messy with timeouts (there is a maximum, higher values are truncated; resolution is 100ms only; the function may take up to twice the timeout because internally it may be called twice). Probably for most people this is OK, but probably not for all. But having precise timeouts should be OK for all :-) Well, in the end it is nice to wish but somewhat hard to implement (many platforms, connections, USB, BlueTooth, whatever). oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Steffen.DETTMER at ingenico.com Fri Jun 8 11:04:22 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 19:04:22 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <46696DFC.7000801@gatworks.com> References: <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <46696DFC.7000801@gatworks.com> Message-ID: <20070608170422.GJ21069@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 10:55 -0400: > > BTW, if e.g. BSD socket API is known, why not simply copy it > > (until something better is invented :)) instead of fiddling > > around with JDK APIs? > > But we were talking about the Parallel Port, and the > transmission of data over the commapi/parallel-port schema. > There isn't much in bi-directional software communication. Its > a simple write one byte at a time interface. First, there are things like PLIP (http://en.wikipedia.org/wiki/Plip) - well, probably not widely used, sure ;) Second, I think if there is a good simple API known to support all that (with known "best practices") or so and there is no forcing need to invent a new one, why not simply using it? > I'm not looking to change the comm-api. I'm just looking to > alter the interaction between the Native ParallelPort > functions, and the java ParallelPort functions that call them. Ahh, yes. I think this is what I tried to ask. Having an usable JNI interface and on top (in pure java) some wrapper to InputStream or whatever could be done (e.g. by ignoring the return value of write or throwing if != length). Developers could then use the full-featured (non-JAVA-standard) API or select among various wrappers (as InputStream). > This might be more readily doable than to get a committee to > re-specify java-API specs. Yes, of course. I'm afraid that the Java APIs change regularily, but still yet with limited success it seems, so maybe they get it in one of the next iterations; who knows, maybe Java-9 has a BSD-like socket API :) SCNR. > BTW: Whats is off-topic? ( help: not looking for def of > off-topic ) I think I started some "re-specify java-API specs" which was OT probably. oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From lists at iDIAcomputing.com Fri Jun 8 18:48:54 2007 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Fri, 08 Jun 2007 20:48:54 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46684B62.7080802@gmail.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> Message-ID: <4669F8F6.3040101@iDIAcomputing.com> Vicne wrote: > Sorry to step in without a specific solution to your problem, but I > wanted to share my feeling regarding this proposal. AFAIK, it's > generally considered bad practice to pop-up a prompt from a library. ... > > My advice would be to think again and find another solution. Ideas are : > - make the number of retries a parameter so that you can tune it to what > you think is reasonable > - throw a more specific exception when the number of retries has been > reached, so that a specific prompt can be shown at a higher level You could also allow the client code to register a callback class which returns a boolean indicating whether to retry or cancel. This callback class could pop up a dialog, if appropriate, or follow some preset policy, or.... - George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From joachim at buechse.ch Sat Jun 9 09:43:16 2007 From: joachim at buechse.ch (Joachim Buechse) Date: Sat, 9 Jun 2007 17:43:16 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46694F9D.5080501@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: You should not forget, that in the case of an exception it may not even be known what happened to the data. You have a kernel buffer, outgoing chip buffer, incoming chip buffer, etc. So of course, it would be nice to know up to which point data was correctly processed, but this feedback does not exist on the hardware or protocol level and hence can in general not be magicly created on the software level... Regards, Joachim On 08.06.2007, at 14:46, Uncle George wrote: > It seems that with outputstream.write(b[]), you become terribly > uncoordinated as soon as an exception is thrown. Docs do not say what > happens to the data. > > Yet from a practicable point of view, one would like to know if the > write was accepted in-full, or rejected before any writes. There > are no > in betweens, as partial writes are not reportable. > > So for an outputstream.write(), in order for it to return, the full > write request has to be taken, and stored in an internal output > buffer. > If there is no room, the write() is suspended, till there is room. Or > throw's an IOException( "no room in buffer") ; As the select() loop > for > write reports buffer room avail, then more of the internal buffer is > sent to the printer. > > > > yves pielusenet wrote: >> So maybe a better way should be to create a new Exception class which >> has a method "int getWrittenByte()". So the Exception should be >> use to >> send again bytes which are not printed yet. >> >> yves >> >> Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : >>> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: >>>> It is not possible that the rxtx java method write(byte[], int >>>> offset, >>>> int length) return anint which contains the number of byte >>>> really send >>>> to the printer instead of an exception ? >>>> So this is the programm which will see if all bytes have been >>>> sent. If >>>> not it can retry to send the unsended bytes. >>> I think write() is void because in Java people love to do this >>> since OutputStream :-) Of course on such interfaces you cannot >>> implement something nice. If you would have a int write, you >>> would not implement the interface and no applications expecting >>> this interface would link/work/compile. >>> >>> oki, >>> >>> Steffen >>> >>> P.S.: (OT) >>> If you propose not to implement the Java interfaces (especially >>> not on JNI level), maybe optionally offering a wrapper that >>> removes e.g. the write return value and so on to downgrade the >>> powerful classic old POSIX read/write style to the modern limited >>> Java style, then I agree :-) Same for read. Instead of things >>> like "int avialable()" it is more powerful to have an approach as >>> select(2) offers (to guarante the caller that read/write will not >>> block [nothing else make sense anyway IMHO] but may read/write >>> less bytes then requested). The caller gets full control and the >>> higher level protocols can care about timeouts, invoking read in >>> some loops and/or implement retransmission. On top of such an >>> implementation, where everything is controlled, defined, >>> guaranteed and reliable, someone could use an InputStream or >>> OutputStream style interface. Or even better: don't use them at >>> all :) just BTW :-) >>> St. >>> >>> About Ingenico Throughout the world businesses rely on Ingenico >>> for secure and expedient electronic transaction acceptance. >>> Ingenico products leverage proven technology, established >>> standards and unparalleled ergonomics to provide optimal >>> reliability, versatility and usability. This comprehensive range >>> of products is complemented by a global array of services and >>> partnerships, enabling businesses in a number of vertical sectors >>> to accept transactions anywhere their business takes them. >>> 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. >>> >>> About Ingenico Throughout the world businesses rely on Ingenico >>> for secure and expedient electronic transaction acceptance. >>> Ingenico products leverage proven technology, established >>> standards and unparalleled ergonomics to provide optimal >>> reliability, versatility and usability. This comprehensive range >>> of products is complemented by a global array of services and >>> partnerships, enabling businesses in a number of vertical sectors >>> to accept transactions anywhere their business takes them. >>> 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. >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx 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 yvespielusenet at free.fr Mon Jun 11 03:15:12 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Mon, 11 Jun 2007 11:15:12 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: <1181553312.8335.14.camel@localhost.localdomain> So can someone tell a solution for my problem :( Must I say to the user to not put the printer off-line ? I can't since he has to do some pauses, verify print, paper conditioning etc... How do other people ? Before I use the parport librarry to read port status : http://www.geocities.com/Juanga69/parport/ (which doesn't work on windows XP) And I send data into the file LPT1 I use to have no problem when printer was disabled. thanks -- yves piel Le samedi 09 juin 2007 ? 17:43 +0200, Joachim Buechse a ?crit : > You should not forget, that in the case of an exception it may not > even be known what happened to the data. > > You have a kernel buffer, outgoing chip buffer, incoming chip buffer, > etc. So of course, it would be nice to know up to which point data > was correctly processed, but this feedback does not exist on the > hardware or protocol level and hence can in general not be magicly > created on the software level... > > Regards, > Joachim > > On 08.06.2007, at 14:46, Uncle George wrote: > > > It seems that with outputstream.write(b[]), you become terribly > > uncoordinated as soon as an exception is thrown. Docs do not say what > > happens to the data. > > > > Yet from a practicable point of view, one would like to know if the > > write was accepted in-full, or rejected before any writes. There > > are no > > in betweens, as partial writes are not reportable. > > > > So for an outputstream.write(), in order for it to return, the full > > write request has to be taken, and stored in an internal output > > buffer. > > If there is no room, the write() is suspended, till there is room. Or > > throw's an IOException( "no room in buffer") ; As the select() loop > > for > > write reports buffer room avail, then more of the internal buffer is > > sent to the printer. > > > > > > > > yves pielusenet wrote: > >> So maybe a better way should be to create a new Exception class which > >> has a method "int getWrittenByte()". So the Exception should be > >> use to > >> send again bytes which are not printed yet. > >> > >> yves > >> > >> Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : > >>> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > >>>> It is not possible that the rxtx java method write(byte[], int > >>>> offset, > >>>> int length) return anint which contains the number of byte > >>>> really send > >>>> to the printer instead of an exception ? > >>>> So this is the programm which will see if all bytes have been > >>>> sent. If > >>>> not it can retry to send the unsended bytes. > >>> I think write() is void because in Java people love to do this > >>> since OutputStream :-) Of course on such interfaces you cannot > >>> implement something nice. If you would have a int write, you > >>> would not implement the interface and no applications expecting > >>> this interface would link/work/compile. > >>> > >>> oki, > >>> > >>> Steffen > >>> > >>> P.S.: (OT) > >>> If you propose not to implement the Java interfaces (especially > >>> not on JNI level), maybe optionally offering a wrapper that > >>> removes e.g. the write return value and so on to downgrade the > >>> powerful classic old POSIX read/write style to the modern limited > >>> Java style, then I agree :-) Same for read. Instead of things > >>> like "int avialable()" it is more powerful to have an approach as > >>> select(2) offers (to guarante the caller that read/write will not > >>> block [nothing else make sense anyway IMHO] but may read/write > >>> less bytes then requested). The caller gets full control and the > >>> higher level protocols can care about timeouts, invoking read in > >>> some loops and/or implement retransmission. On top of such an > >>> implementation, where everything is controlled, defined, > >>> guaranteed and reliable, someone could use an InputStream or > >>> OutputStream style interface. Or even better: don't use them at > >>> all :) just BTW :-) > >>> St. > >>> > >>> About Ingenico Throughout the world businesses rely on Ingenico > >>> for secure and expedient electronic transaction acceptance. > >>> Ingenico products leverage proven technology, established > >>> standards and unparalleled ergonomics to provide optimal > >>> reliability, versatility and usability. This comprehensive range > >>> of products is complemented by a global array of services and > >>> partnerships, enabling businesses in a number of vertical sectors > >>> to accept transactions anywhere their business takes them. > >>> 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. > >>> > >>> About Ingenico Throughout the world businesses rely on Ingenico > >>> for secure and expedient electronic transaction acceptance. > >>> Ingenico products leverage proven technology, established > >>> standards and unparalleled ergonomics to provide optimal > >>> reliability, versatility and usability. This comprehensive range > >>> of products is complemented by a global array of services and > >>> partnerships, enabling businesses in a number of vertical sectors > >>> to accept transactions anywhere their business takes them. > >>> 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. > >>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx 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 > From Steffen.DETTMER at ingenico.com Mon Jun 11 03:56:18 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 11:56:18 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466990BE.7040100@gatworks.com> References: <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> Message-ID: <20070611095618.GA10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 13:24 -0400: > i was not thinking of change the API to OutputSream. Then I think either someone uses OutputStream (and has no reliable information about incomplete writes) or someone uses somethink else. > Are there specs for how output stream should work internally? > > for instance: > String data = "Hello this is a line of data"; > Outputstream.write( data.getbytes() ); > ParallelPort.suspend(); > int free = ParallelPort.getoutputbufferfree(); > > There is a symbiotic relationship between outputstream and the > functionality of ParallelPort. If you need OutputStream "plus something else", in short you're needing "something else". Personally I dislike the code above a lot. The stream "looks" like if it would be an OutputStream, but in fact it isn't. You need to call getoutputbufferfree later to check if write succeeded (but OutputStream promises that write succeedes synchronous, blocking, or throws an exception). So it is not an OutputStream. No application written for OutputStreams would work without change (because it won't know getoutputbufferfree at all). It is not abstracted from ParallelPort. I think this would be wrong. Then I think an alternative interface instead is better. Let's assume we had some "connection" (to distinguish between OutputStreams and Channels). Then why not working as on a file handle in POSIX: do { // ... select maybe using timer ... readyForWrite = ... if (readyForWrite) { int writtenBytes = connection.write(toWrite); toWrite.remove(0, writtenBytes); } while(readyForWrite && toWrite.length > 0); I think, having such a write isn't the big problem. I think, the difficult thing is around "select" - however this would look like. It should be OO, typesafe, performant, supporting multiple connections/channels/streams in various modes and should be orthogonal to other functionalities. Of course, this heavily depends on what the application is doing; for a simple situation (like reading a small, mandatory file from a local disk) this would be to uncomfortable (and offering unneeded features only). just BTW :) oki, Steffen -- // Modeline for VIM. Please don't remove. // (Help: autoindent, expandtab, shiftwidth=4, tabstop=4, textwidth=75) // vi: set ai et sw=4 ts=4 tw=75 ft=java: About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Mon Jun 11 05:38:33 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 07:38:33 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611095618.GA10821@elberon.bln.de.ingenico.com> References: <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> Message-ID: <466D3439.4020805@gatworks.com> Steffen DETTMER wrote: > (but OutputStream promises that write > succeedes synchronous, blocking, or throws an exception). Where is it so written? From Steffen.DETTMER at ingenico.com Mon Jun 11 06:36:50 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 14:36:50 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466D3439.4020805@gatworks.com> References: <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> <466D3439.4020805@gatworks.com> Message-ID: <20070611123650.GI10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Mon, Jun 11, 2007 at 07:38 -0400: > Steffen DETTMER wrote: > > > (but OutputStream promises that write > > succeedes synchronous, blocking, or throws an exception). > > Where is it so written? Now, as you ask, I think it is not written that clearly but follows from specification. mmm... Am I wrong? I understand the API doc in this way: * http://java.sun.com/j2se/1.4.2/docs/api/java/io/OutputStream.html#write(byte[]) > public void write(byte[] b) > throws IOException > > Writes b.length bytes from the specified byte array to this > output stream. The general contract for write(b) is that > it should have exactly the same effect as the call write(b, > 0, b.length). > > Parameters: > b - the data. > Throws: > IOException - if an I/O error occurs. > See Also: > write(byte[], int, int) and there is: > public void write(byte[] b, > int off, > int len) > throws IOException > > Writes len bytes from the specified byte array starting at > offset off to this output stream. The general contract for > write(b, off, len) is that some of the bytes in the array b > are written to the output stream in order; element b[off] > is the first byte written and b[off+len-1] is the last byte > written by this operation. > > The write method of OutputStream calls the write method of > one argument on each of the bytes to be written out. > Subclasses are encouraged to override this method and > provide a more efficient implementation. > > If b is null, a NullPointerException is thrown. > > If off is negative, or len is negative, or off+len is > greater than the length of the array b, then an > IndexOutOfBoundsException is thrown. > > Parameters: > b - the data. > off - the start offset in the data. > len - the number of bytes to write. > Throws: > IOException - if an I/O error occurs. In particular, an > IOException is thrown if the output stream is closed. In general, any specialisation (derived child class) must comform to this. So write in the end is specified (!) as "The write method ... calls the write method ... on each of the bytes to be written out". This is what must be implemented by ANY OutputStream. Of course, there is: "Subclasses are encouraged to override this method and provide a more efficient implementation." which IMHO does not contradict - the more efficient must behave in exactly the same way of course (just wasting less resources than a simple byte-by-byte write). So it does not matter here I think. The write that finally defines the behavior tells basically: > "Writes the specified byte to this output stream. The general > contract for write is that one byte is written to the output > stream. " > > Throws: > IOException - if an I/O error occurs. which IMHO is another way of saying "write writes the byte immediately and returns on success (only), otherwise an exception is thrown". Especially it cannot happen that zero bytes are written (i.e. the specified byte is NOT written) without an exception. So by this write must be synchronous and blocking, because otherwise it could not reliably know if an asynchronous operation will succeede or not (some getAsyncResult or so would be needed). Since write(byte[]) does this for each byte (or with a behavior beeing exactly the same as if it would do), I think this means that the write(byte[]) succeedes synchronous/blocking or throws an exception. Did I an error in reasoning or confused something or so? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From j.kenneth.gentle at acm.org Mon Jun 11 06:51:25 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 11 Jun 2007 08:51:25 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611123650.GI10821@elberon.bln.de.ingenico.com> References: <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> <466D3439.4020805@gatworks.com> <20070611123650.GI10821@elberon.bln.de.ingenico.com> Message-ID: <200706111251.l5BCpS9T017831@qbang.org> It is as Steffen describes. "InputStream" and "OutputStream" are inherently synchronous (which is why so many java programs resort to threads to use them). Anything outside of this "contract" is *not* an InputStream or OutputStream. That is why there is a new package for things that don't behave like the old *Stream classes - the NIO package. If you look carefully at the IO package, you'll note that almost all the classes are _Decorator_ pattern implementations of the *Stream classes - and the interface presents the _same_ behavior to the calling code in all cases - a synchronous operation that completes successfully or throws an exception (with the one exception of "read" that returns a "-1" on end-of-stream. I know I've read this numerous times - I'd suggest checking the Language Spec or one of the books by Bloch or Gosling. Ken At 08:36 2007-06-11, you wrote: >* Uncle George wrote on Mon, Jun 11, 2007 at 07:38 -0400: > > Steffen DETTMER wrote: > > > > > (but OutputStream promises that write > > > succeedes synchronous, blocking, or throws an exception). > > > > Where is it so written? > >Now, as you ask, I think it is not written that clearly but >follows from specification. mmm... > >Am I wrong? > >I understand the API doc in this way: > >* >http://java.sun.com/j2se/1.4.2/docs/api/java/io/OutputStream.html#write(byte[]) > > public void write(byte[] b) > > throws IOException > > > > Writes b.length bytes from the specified byte array to this > > output stream. The general contract for write(b) is that > > it should have exactly the same effect as the call write(b, > > 0, b.length). > > > > Parameters: > > b - the data. > > Throws: > > IOException - if an I/O error occurs. > > See Also: > > write(byte[], int, int) > > >and there is: > > > > public void write(byte[] b, > > int off, > > int len) > > throws IOException > > > > Writes len bytes from the specified byte array starting at > > offset off to this output stream. The general contract for > > write(b, off, len) is that some of the bytes in the array b > > are written to the output stream in order; element b[off] > > is the first byte written and b[off+len-1] is the last byte > > written by this operation. > > > > The write method of OutputStream calls the write method of > > one argument on each of the bytes to be written out. > > Subclasses are encouraged to override this method and > > provide a more efficient implementation. > > > > If b is null, a NullPointerException is thrown. > > > > If off is negative, or len is negative, or off+len is > > greater than the length of the array b, then an > > IndexOutOfBoundsException is thrown. > > > > Parameters: > > b - the data. > > off - the start offset in the data. > > len - the number of bytes to write. > > Throws: > > IOException - if an I/O error occurs. In particular, an > > IOException is thrown if the output stream is closed. > > >In general, any specialisation (derived child class) must comform >to this. So write in the end is specified (!) as "The write >method ... calls the write method ... on each of the bytes to be >written out". This is what must be implemented by ANY >OutputStream. > >Of course, there is: "Subclasses are encouraged to override this >method and provide a more efficient implementation." which IMHO >does not contradict - the more efficient must behave in exactly >the same way of course (just wasting less resources than a simple >byte-by-byte write). So it does not matter here I think. > > > >The write that finally defines the behavior tells basically: > > > "Writes the specified byte to this output stream. The general > > contract for write is that one byte is written to the output > > stream. " > > > > Throws: > > IOException - if an I/O error occurs. > > >which IMHO is another way of saying "write writes the byte >immediately and returns on success (only), otherwise an exception >is thrown". Especially it cannot happen that zero bytes are >written (i.e. the specified byte is NOT written) without an >exception. So by this write must be synchronous and blocking, >because otherwise it could not reliably know if an asynchronous >operation will succeede or not (some getAsyncResult or so would >be needed). > >Since write(byte[]) does this for each byte (or with a behavior >beeing exactly the same as if it would do), I think this means >that the write(byte[]) succeedes synchronous/blocking or throws >an exception. > >Did I an error in reasoning or confused something or so? > >oki, > >Steffen > >About Ingenico Throughout the world businesses rely on Ingenico for >secure and expedient electronic transaction acceptance. Ingenico >products leverage proven technology, established standards and >unparalleled ergonomics to provide optimal reliability, versatility >and usability. This comprehensive range of products is complemented >by a global array of services and partnerships, enabling businesses >in a number of vertical sectors to accept transactions anywhere >their business takes them. >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. > >About Ingenico Throughout the world businesses rely on Ingenico for >secure and expedient electronic transaction acceptance. Ingenico >products leverage proven technology, established standards and >unparalleled ergonomics to provide optimal reliability, versatility >and usability. This comprehensive range of products is complemented >by a global array of services and partnerships, enabling businesses >in a number of vertical sectors to accept transactions anywhere >their business takes them. >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. > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From alesinskyy at googlemail.com Mon Jun 11 07:25:33 2007 From: alesinskyy at googlemail.com (Oleksandr Alesinskyy) Date: Mon, 11 Jun 2007 15:25:33 +0200 Subject: [Rxtx] [OT] select :-) Message-ID: Sorry, but I have to disagree with following statement: "So write in the end is specified (!) as "The write method ... calls the write method ... on each of the bytes to be written out". This is what must be implemented by ANY OutputStream.". This is not part of the specification or contract, it is just revealed implementation detail of the OutputStream. It is not stated anywhere that behavoiur of derived classes shall conform with this one. Statement concerning "synchronous" nature of the output stream is invalid as well. Really synchronous stream does not require flush() but OutputStream has it. From Steffen.DETTMER at ingenico.com Mon Jun 11 08:21:16 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 16:21:16 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: Message-ID: <20070611142116.GN10821@elberon.bln.de.ingenico.com> * Oleksandr Alesinskyy wrote on Mon, Jun 11, 2007 at 15:25 +0200: > Sorry, but I have to disagree with following statement: > "So write in the end is specified (!) as "The write > method ... calls the write method ... on each of the bytes to be > written out". This is what must be implemented by ANY > OutputStream.". > > This is not part of the specification or contract, it is just > revealed implementation detail of the OutputStream. It is not > stated anywhere that behavoiur of derived classes shall conform > with this one. (I didn't meant that the implementation must really write byte by byte, but that it must "look as if it would do" - because all implementations of OutputStream must "look" in the same way [which is another way of saying "do abstract" I think]) I think the API doc is not "revealing implementation details" but it is the *specification* of that interface and derivations must (should) conform to this specification. Isn't this the idea of interfaces? A function that expects an OutputStream should work on ANY OutputStream, shouldn't it? just kidding: I mean, what would be the point in implementing a checksum function as OutputStream.write which throws its result as IOException? Or which requires to call close() as very first operation to tell that the application is about to transmit confidential data? :-) > Statement concerning "synchronous" nature of the output stream > is invalid as well. Really synchronous stream does not require > flush() but OutputStream has it. ahh, interesting point! I think this is another bug in the API. flush() is wrong. Because write specifies "The general contract for write is that one byte is written to the output stream." but not "a byte may be written or buffered". Actually, an application would need to call flush() after each write (or bunch of write calls) to ensure that write really did something otherwise I think. I didn't found in the spec of OutputStream that it would be required to call flush(). This should mean that calling flush is not required which in turn leads to the conclusion that write must be synchrous (private threads are forbidden because not specified :)) which in turn leads to the conclusion that flush() is not needed at all... I mean, what if someone would only store in write and do the "real write" in flush() and never else? An application could write in one stream and read on another one (e.g. in bidirectional communication) and would never get anything back, because nothing was actually written because no flush was called? Then someone could even think that on error in some write the data could remain buffered AND throw an exception, retrying to send the data in the next write. Ohh, and if there would be some message number inside, and underlaying write (e.g. a protocol offering InputStream/OutputStream) would check this and throw "DuplicatedMessageNumber" the stream would only throw it again and again beeing unusable... In short: I have no clue how someone could be able to implement an asynchrounos write (which is realiable and correct) without beeing specific to anything which is not specified by OutputStream. Well, I think in the end OutputStream was not intended for such communication or protocol implementations - but to read a local disk file or so. In case of I/O errors usually you can abort your application and change the hard disk :-) oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Bob_Jacobsen at lbl.gov Mon Jun 11 09:32:23 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Mon, 11 Jun 2007 08:32:23 -0700 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611142116.GN10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> Message-ID: At 4:21 PM +0200 6/11/07, Steffen DETTMER wrote: > > Statement concerning "synchronous" nature of the output stream >> is invalid as well. Really synchronous stream does not require >> flush() but OutputStream has it. > >ahh, interesting point! > >I think this is another bug in the API. flush() is wrong. Because >write specifies "The general contract for write is that one byte >is written to the output stream." but not "a byte may be written >or buffered". > >Actually, an application would need to call flush() after each >write (or bunch of write calls) to ensure that write really did >something otherwise I think. OutputStreams don't _have_ to be synchronous or asynchronous, but the OutputStream API was be arranged so that subclasses _can_ be synchronous or asynchronous. Such generality is the hardest part of getting an API right. Hence, if at some point a program using an OutputStream wants to be sure that the data has been pushed all the way out, flush() is available. For some subclasses, e.g. the buffered ones, this has important behavior. Others write the data from each call, and flush() doesn't do anything. You _can_ omit it in programs that are known to use this second type, but there's no requirement that you do so; the interface is general in that way. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From Steffen.DETTMER at ingenico.com Mon Jun 11 12:32:39 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 20:32:39 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> Message-ID: <20070611183239.GT10821@elberon.bln.de.ingenico.com> * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: > >Actually, an application would need to call flush() after each > >write (or bunch of write calls) to ensure that write really did > >something otherwise I think. > OutputStreams don't _have_ to be synchronous or asynchronous, > but the OutputStream API was be arranged so that subclasses > _can_ be synchronous or asynchronous. Ahh, oki. Thanks for the clarificaion. So in short, flush() MUST be called on OutputStream, this is just not documented correctly or so clearly (right?). So the overall usage semantics would be: 1. call write (multiple times if desired) 2. call flush only if both succeeded, write was successful. If flush fails it remains unknown if a part of the data was written and/or will be repeated. So the spec (API doc) is wrong. Correct would be to tell that write behaves as told as long as it is followed by a call to flush, otherwise data may or may not get lost (depending wheter close() is called and calls flush(), which seems not to be guaranteed/required). BTW, I think it is a little bit... erm... interesting to find the specification (java API doc reference) wrong, having a need to conclude it from the presence of some methods with "it would make no sense if they behave exactly as specified, so specification must be wrong (incomplete)". > Such generality is the hardest part of getting an API right. Yes, seems to be proven ;) > Hence, if at some point a program using an OutputStream wants > to be sure that the data has been pushed all the way out, > flush() is available. For some subclasses, e.g. the buffered > ones, this has important behavior. Others write the data from > each call, and flush() doesn't do anything. > You _can_ omit it in programs that are known to use this second > type, but there's no requirement that you do so; the interface > is general in that way. I think, it still it must be called always, otherwise the application could break if passing a different runtime type as OutputStream. I think, if the application/method needs a special "type of OutputStream" then the parameter type must be a subclass but not OutputStream, maybe a PrintStream or so - otherwise the compiler could not detect this error (passing wrong type). Is this correct? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Bob_Jacobsen at lbl.gov Mon Jun 11 13:00:52 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Mon, 11 Jun 2007 12:00:52 -0700 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611183239.GT10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> Message-ID: At 8:32 PM +0200 6/11/07, Steffen DETTMER wrote: >So the spec (API doc) is wrong. Correct would be to tell that >write behaves as told as long as it is followed by a call to >flush, otherwise data may or may not get lost (depending wheter >close() is called and calls flush(), which seems not to be >guaranteed/required). I'm not entirely sure that the spec is wrong, but reasonable people can differ on this. In the 1.5 JavaDocs, all that the docs say for the write methods is that they write to the _output_ _stream_; there is no guarantee of anything beyond that. Only the flush method has any guarantee about the data, which is >Flushes this output stream and forces any buffered output bytes to >be written out. The general contract of flush is that calling it is >an indication that, if any bytes previously written have been >buffered by the implementation of the output stream, such bytes >should immediately be written to their intended destination. People commonly use various OutputStreams without using flush(), and it often works, but it's a bad practice and will eventually bite them. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From netbeans at gatworks.com Mon Jun 11 13:31:57 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 15:31:57 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611183239.GT10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> Message-ID: <466DA32D.1010602@gatworks.com> Steffen DETTMER wrote: > * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: >>> Actually, an application would need to call flush() after each >>> write (or bunch of write calls) to ensure that write really did >>> something otherwise I think. > >> OutputStreams don't _have_ to be synchronous or asynchronous, >> but the OutputStream API was be arranged so that subclasses >> _can_ be synchronous or asynchronous. > > Ahh, oki. Thanks for the clarificaion. > > So in short, flush() MUST be called on OutputStream, this is just > not documented correctly or so clearly (right?). No. Flush can be called to force all current data in java buffer's to be written to the kernel - NOW. A flush() can also *imply* that, besides writing out the buffer's that java employs, may also imply/ask the kernel to write all data thusfar written to the kernel, to be physically placed on the destination device - NOW. For some OS's there is no need to do a kernel flush(), as the I/O is synchronized already. Since this is java, you never know what OS your on. From tjarvi at qbang.org Mon Jun 11 19:28:27 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Jun 2007 19:28:27 -0600 (MDT) Subject: [Rxtx] [OT] select :-) In-Reply-To: <466DA32D.1010602@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: On Mon, 11 Jun 2007, Uncle George wrote: > Steffen DETTMER wrote: >> * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: >>>> Actually, an application would need to call flush() after each >>>> write (or bunch of write calls) to ensure that write really did >>>> something otherwise I think. >> >>> OutputStreams don't _have_ to be synchronous or asynchronous, >>> but the OutputStream API was be arranged so that subclasses >>> _can_ be synchronous or asynchronous. >> >> Ahh, oki. Thanks for the clarificaion. >> >> So in short, flush() MUST be called on OutputStream, this is just >> not documented correctly or so clearly (right?). > No. > Flush can be called to force all current data in java buffer's to be > written to the kernel - NOW. > > A flush() can also *imply* that, besides writing out the buffer's that > java employs, may also imply/ask the kernel to write all data thusfar > written to the kernel, to be physically placed on the destination device > - NOW. > For some OS's there is no need to do a kernel flush(), as the I/O is > synchronized already. Since this is java, you never know what OS your on. To add to the confusion, flush on the C side throws away data. drain makes sure it is written. Looking at the ParallelImp.c we can probably do better. /* we set a timeout because all calls are sequentiell (also with asynchron) this means that the default timeout of unlimited blocks all calls (also close and status request) if the device is down */ GetCommTimeouts( (HANDLE)fd, &timeouts ); timeouts.WriteTotalTimeoutMultiplier = 0; timeouts.WriteTotalTimeoutConstant = 2000; /* 2000 is the min value for the default Windows NT and Windows 2000 driver */ SetCommTimeouts( (HANDLE)fd, &timeouts ); while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } errorCount = 0; bytes += countWritten; count -= countWritten; } LPRPort has some timeout code that appears to be doing nothing but flipping bits back and forth right now. The commapi rxtx follows allows for timeout control from javax.comm.CommPort. The above is a solution that worked in one specific use case. With timeouts in place, the original 'old printer going offline' problem could be solved. That printer code isn't written in stone. In fact it was ajusted from being able to print 'asdf' to a daisy wheel printer to working for one person. BTW, I've finished teaching after hours tonight and will be moving forward with a new rxtx release in my free time. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Jun 11 21:28:04 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 23:28:04 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: <466E12C4.1010305@gatworks.com> > Looking at the ParallelImp.c we can probably do better. > The problem stemmed from the possibility that the writev routine could have written some of the buffer, in chunks, printer pauses, refuses any more chunks, and a timeout occurs. Do you or do you not cause an exception to be thrown? Is there a way to set timeout for a ParallelPort data output stream? I cant find it. From tjarvi at qbang.org Mon Jun 11 22:17:23 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Jun 2007 22:17:23 -0600 (MDT) Subject: [Rxtx] [OT] select :-) In-Reply-To: <466E12C4.1010305@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> <466E12C4.1010305@gatworks.com> Message-ID: On Mon, 11 Jun 2007, Uncle George wrote: >> Looking at the ParallelImp.c we can probably do better. >> > The problem stemmed from the possibility that the writev routine could > have written some of the buffer, in chunks, printer pauses, refuses any > more chunks, and a timeout occurs. Do you or do you not cause an > exception to be thrown? > > Is there a way to set timeout for a ParallelPort data output stream? I > cant find it. hmm I looked again after you asked. The timeouts are only controllable on the receive side. This comes from CommPort; the parent. So what we are talking about is some bytes in memory that rxtx has and is supposed to write. A buffer perhaps? The approach with rxtx in the past has been to ignore output buffer sizes. The assumption is that the library does not know how to best handle buffers. There are buffered output streams that can do buffering on top of rxtx for instance. There is also a question regarding what was actually ment when the API was put together. My suspicion is that it was put together while looking at one OS API and was never ment to be anything more than a hook into that API. The comments are fairly telling combined with reading the w32 API. So looking at the problem again.. The current timeout behavior appears fairly arbitrary. Presumably this is to prevent a program from hanging instead of using a helper thread to write - heavy handed for new programmers. Even so, I don't think the write should timeout at all if it is not configurable. >From the API perspective, "What Timeout?" -- Trent Jarvi tjarvi at qbang.org From Steffen.DETTMER at ingenico.com Tue Jun 12 02:14:48 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 12 Jun 2007 10:14:48 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466DA32D.1010602@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: <20070612081447.GU10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Mon, Jun 11, 2007 at 15:31 -0400: > Steffen DETTMER wrote: > > Ahh, oki. Thanks for the clarificaion. > > > > So in short, flush() MUST be called on OutputStream, this is just > > not documented correctly or so clearly (right?). > No. hum (though now I got it, but...). > Flush can be called to force all current data in java buffer's to be > written to the kernel - NOW. > > A flush() can also *imply* that, besides writing out the > buffer's that java employs, may also imply/ask the kernel to > write all data thusfar written to the kernel, to be physically > placed on the destination device - NOW. > > For some OS's there is no need to do a kernel flush(), as the I/O is > synchronized already. Since this is java, you never know what OS your on. (well, but if you're going to kernel level, even flush cannot guarantee that data will "be physically placed". Maybe you're flushing to a file via NFS (and the client "thinks" that it was written, but maybe it was just buffered by the NFS server) or so... but of course such exceptions of the rules are constructable always.) Well, you tell that depending on the OS it can be that flush is needed or it can be that flush is not needed (beacuse the I/O is synchronized already), right? Also, applications should work on any OS, which includes the OSes that do need flush. Since the application cannot know whether flush is needed or not because it doesn't know what the OS is doing, it has to call flush, hasn't it? I mean, if it would not call flush then it would not work on such OSes (except the written data would not be needed at all, but in this would be an artificial example :)). Since applications are supposed to work this would be wrong, wouldn't it? So would it be correct to say: "Applications, that should work under all OSes (including the OSes where the I/O is not synchronised already), have to call flush on OutputStream to ensure the data is transfered to the kernel." or is this wrong? If so, then I'm afraid I missed the point again :( oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Tue Jun 12 04:46:52 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 12 Jun 2007 06:46:52 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070612081447.GU10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> <20070612081447.GU10821@elberon.bln.de.ingenico.com> Message-ID: <466E799C.7060700@gatworks.com> S > (well, but if you're going to kernel level, even flush cannot > guarantee that data will "be physically placed". Thats true now-a-days because ( from "man 2 sync" ) : > According to the standard specification (e.g., SVID), sync() schedules > the writes, but may return before the actual writing is done. However, > since version 1.3.20 Linux does actually wait. (This still does not > guarantee data integrity: modern disks have large caches.) My disk drive has 8mb cache. Maybe you're > flushing to a file via NFS (and the client "thinks" that it was > written, but maybe it was just buffered by the NFS server) or > so... but of course such exceptions of the rules are > constructable always.) > > Well, you tell that depending on the OS it can be that flush is > needed or it can be that flush is not needed (beacuse the I/O is > synchronized already), right? Also, applications should work on > any OS, which includes the OSes that do need flush. Its not OS's that need flush, its applications that want to have some assurance that data is written to the device that really needs to use flush. If your program ( or thread ) dies then it is in your best interest to write out the critical data as soon as possible, as economical as possible. These are trade-off's that the application programmer makes. A big buffer may mean big loss of data, a small buffer may mean spending too much time writing out data. > > > So would it be correct to say: > > "Applications, that should work under all OSes (including the > OSes where the I/O is not synchronised already), have to call > flush on OutputStream to ensure the data is transfered to the > kernel." > > or is this wrong? If so, then I'm afraid I missed the point again > :( > No that is not wrong. Ensuring that data is transfered to the OS is just about what any application can do. From tjarvi at qbang.org Thu Jun 14 08:16:47 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 14 Jun 2007 08:16:47 -0600 (MDT) Subject: [Rxtx] rxtx and usb-serial solution In-Reply-To: References: Message-ID: On Thu, 14 Jun 2007, Vladimir Kirtchev wrote: > Hi Trent, > > I develop a Java application which communicates with devices which have > USB-to-Serial bridge in them. The target OS is Linux. So for this purpose I > use RXTX. > > But I encountered a strange problem - when reading from the InputStream, I > receive series of zeros. I have this problem under Linux only. Under Windows > it is fine. > Actually this problem is the same as the one described here: > http://marc.info/?l=rxtx&m=109703190731748&w=2. > > > So I searched for the problem in the native code. And found that the root of > the problem is in SerialImp.c, > int configure_port( int fd ) > { > ... > ttyset.c_iflag = INPCK; > ... > } > > This line enables input parity checking, and the data sent from the device > is processed by the OS driver before being read with read(). > In this case the driver detects some problem and sets the received bytes to > zero. > > On the other hand in the Java part a set the serial port parameters with > SerialPort.PARITY_NONE. According to me, except all other things, this > should also disable INPCK in c_iflag. > > So I refactored the method translate_parity(...) to the following: > > int translate_parity( JNIEnv *env, struct termios *ttyset, jint parity ) > { > ENTER( "translate_parity" ); > #ifdef CMSPAR > ttyset->c_cflag &= ~(PARENB | PARODD | CMSPAR ); > #endif /* CMSPAR */ > switch( parity ) { > case JPARITY_NONE: > ttyset->c_iflag &= ~INPCK; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_EVEN: > ttyset->c_cflag |= PARENB; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_ODD: > ttyset->c_cflag |= PARENB | PARODD; > LEAVE( "translate_parity" ); > return 0; > #ifdef CMSPAR > case JPARITY_MARK: > ttyset->c_cflag |= PARENB | PARODD | CMSPAR; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_SPACE: > ttyset->c_cflag |= PARENB | CMSPAR; > LEAVE( "translate_parity" ); > return 0; > #endif /* CMSPAR */ > default: > printf("Parity missed %i\n", (int) parity ); > } > > LEAVE( "translate_parity" ); > /* > For some reason the native exceptions are not being caught. Moving this > to the Java side fixed the issue. taj. > throw_java_exception( env, UNSUPPORTED_COMM_OPERATION, > "", "parity value not supported" ); > */ > return 1; > } > > This modification solved the problem and now it works correctly under Linux. > > I think I will be a nice if this is idea is included in a future release of > RXTX. > > Thanks Vadim, I'll try that out. Forwarding to the rxtx mail-list too. This is probably not going to help USB drivers on windows which I'm sure some are looking for. As far as I can tell, windows USB bluetooth and serial dongles are limited by driver functionality. Some are good and others lack key features. -- Trent Jarvi tjarvi at qbang.org From dan.sandberg.lists at gmail.com Mon Jun 18 14:43:39 2007 From: dan.sandberg.lists at gmail.com (Dan Sandberg) Date: Mon, 18 Jun 2007 13:43:39 -0700 Subject: [Rxtx] Fix for JNI Get/Set Field Errors Message-ID: <4676EE7B.7060800@gmail.com> Hi, I've fixed the problems that cause the following JNI error when extra JNI checking ( -Xjni:check ) is turned on. FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) The problem was basically that GetLong was being used to get ints, and SetInt was used for longs. The patch below fixes this. Please let me know if there are any questions / problems. Cheers, -Dan diff -aur old/SerialImp.c src/SerialImp.c --- old/SerialImp.c 2007-06-18 13:24:33.000000000 -0700 +++ src/SerialImp.c 2007-06-18 06:26:26.000000000 -0700 @@ -1337,7 +1337,7 @@ report("init_threads: get eis\n"); jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); report("init_threads: set eis\n"); - (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); + (*eis->env)->SetLongField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); report("init_threads: stop\n"); report_time_end( ); return( 1 ); @@ -1530,7 +1530,7 @@ jobject jobj, jboolean interrupted ) { int fd = get_java_var( env, jobj,"fd","I" ); - struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var( env, jobj, "eis", "J" ); + struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var_long( env, jobj, "eis", "J" ); int result, count=0; char message[80]; @@ -2939,7 +2939,7 @@ /* TRENT */ int flag, count = 0; struct event_info_struct *eis = ( struct event_info_struct * ) - get_java_var( env, *jobj,"eis","J" ); + get_java_var_long( env, *jobj,"eis","J" ); report_time_start(); flag = eis->eventflags[SPE_DATA_AVAILABLE]; @@ -4873,9 +4873,9 @@ exceptions: none comments: ----------------------------------------------------------*/ -size_t get_java_var( JNIEnv *env, jobject jobj, char *id, char *type ) +long get_java_var_long( JNIEnv *env, jobject jobj, char *id, char *type ) { - int result = 0; + long result = 0; jclass jclazz = (*env)->GetObjectClass( env, jobj ); jfieldID jfd = (*env)->GetFieldID( env, jclazz, id, type ); @@ -4889,7 +4889,11 @@ LEAVE( "get_java_var" ); return result; } - result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); + if ( !strcmp( type, "J" ) ) { + result = (long)( (*env)->GetLongField( env, jobj, jfd ) ); + } else { + result = (int) ( (*env)->GetIntField( env, jobj, jfd ) ); + } /* ct7 & gel * Added DeleteLocalRef */ (*env)->DeleteLocalRef( env, jclazz ); if(!strncmp( "fd",id,2) && result == 0) @@ -4900,6 +4904,10 @@ return result; } +int get_java_var( JNIEnv *env, jobject jobj, char *id, char *type ) { + return (int) get_java_var_long( env, jobj, id, type ); +} + /*---------------------------------------------------------- throw_java_exception diff -aur old/SerialImp.h src/SerialImp.h --- old/SerialImp.h 2007-06-18 13:24:39.000000000 -0700 +++ src/SerialImp.h 2007-06-18 06:23:43.000000000 -0700 @@ -413,7 +413,8 @@ void system_wait(); void finalize_event_info_struct( struct event_info_struct * ); int read_byte_array( JNIEnv *, jobject *, int, unsigned char *, int, int ); -size_t get_java_var( JNIEnv *, jobject, char *, char * ); +int get_java_var( JNIEnv *, jobject, char *, char * ); +long get_java_var_long( JNIEnv *, jobject, char *, char * ); jboolean is_interrupted( struct event_info_struct * ); int send_event(struct event_info_struct *, jint, int ); void dump_termios(char *,struct termios *); From yvespielusenet at free.fr Tue Jun 26 03:41:58 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 11:41:58 +0200 Subject: [Rxtx] [PARALLEL] resource in use Message-ID: <1182850918.3483.10.camel@localhost.localdomain> Hello, So now I want to modify the timeout of the library for parallel port. I have downloaded source code. There is a makefile for migw. SO I have installed mingw on ubuntu and modified the makefile.mingw32 to set it for my system. I have no error but some warnings. The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But When I want to use it the jvm crash :( How can I know what is wrong ? How rxtx windows release has been done ? thanks -- yves piel From yvespielusenet at free.fr Tue Jun 26 07:17:02 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 15:17:02 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182850918.3483.10.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> Message-ID: <1182863822.3483.17.camel@localhost.localdomain> Here is the Makefile I use, the output of the 'make' and the log of the jvm when it crashed : - The Makefile : http://yvespiel.free.fr/rxtx/Makefile - The make output : http://yvespiel.free.fr/rxtx/compile.txt - The crash log : http://yvespiel.free.fr/rxtx/hs_err_pid2100.log I have compiled rxtx under Debian testing with mingw : narma at linimi:/tmp/err$ dpkg -l | grep mingw ii mingw32 3.4.5.20060117.1.dfsg-3 ii mingw32-binutils 2.17.50-20070129.1-1 ii mingw32-runtime 3.12-1 thanks fort help :) Le mardi 26 juin 2007 ? 11:41 +0200, yves pielusenet a ?crit : > Hello, > So now I want to modify the timeout of the library for parallel port. I > have downloaded source code. There is a makefile for migw. SO I have > installed mingw on ubuntu and modified the makefile.mingw32 to set it > for my system. > I have no error but some warnings. > The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But > When I want to use it the jvm crash :( > > How can I know what is wrong ? > > How rxtx windows release has been done ? > > thanks > From yvespielusenet at free.fr Tue Jun 26 07:40:11 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 15:40:11 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182863822.3483.17.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> <1182863822.3483.17.camel@localhost.localdomain> Message-ID: <1182865211.3483.21.camel@localhost.localdomain> I have add the options '--enable-stdcall-fixup' to the 'i586-mingw32msvc-ld' commande. Now I have no warning. But the JVM always crashes :( The output seems more detailled, but I don't understand anything... Here is files : http://yvespiel.free.fr/rxtx/2/ -- yves piel Le mardi 26 juin 2007 ? 15:17 +0200, yves pielusenet a ?crit : > Here is the Makefile I use, the output of the 'make' and the log of the > jvm when it crashed : > > - The Makefile : http://yvespiel.free.fr/rxtx/Makefile > - The make output : http://yvespiel.free.fr/rxtx/compile.txt > - The crash log : http://yvespiel.free.fr/rxtx/hs_err_pid2100.log > > I have compiled rxtx under Debian testing with mingw : > narma at linimi:/tmp/err$ dpkg -l | grep mingw > ii mingw32 3.4.5.20060117.1.dfsg-3 > ii mingw32-binutils 2.17.50-20070129.1-1 > ii mingw32-runtime 3.12-1 > > thanks fort help :) > > > Le mardi 26 juin 2007 ? 11:41 +0200, yves pielusenet a ?crit : > > Hello, > > So now I want to modify the timeout of the library for parallel port. I > > have downloaded source code. There is a makefile for migw. SO I have > > installed mingw on ubuntu and modified the makefile.mingw32 to set it > > for my system. > > I have no error but some warnings. > > The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But > > When I want to use it the jvm crash :( > > > > How can I know what is wrong ? > > > > How rxtx windows release has been done ? > > > > thanks > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From yvespielusenet at free.fr Tue Jun 26 08:27:42 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 16:27:42 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182865211.3483.21.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> <1182863822.3483.17.camel@localhost.localdomain> <1182865211.3483.21.camel@localhost.localdomain> Message-ID: <1182868062.3483.24.camel@localhost.localdomain> I think thant the include files of jdk were not for windows but for linux. So I have copied include/ folder from windows to linux and I modified the Makefile to use those file. It compile fine but the JVM always crash :( http://yvespiel.free.fr/rxtx/3/ Le mardi 26 juin 2007 ? 15:40 +0200, yves pielusenet a ?crit : > I have add the options '--enable-stdcall-fixup' to the > 'i586-mingw32msvc-ld' commande. Now I have no warning. But the JVM > always crashes :( The output seems more detailled, but I don't > understand anything... > Here is files : > http://yvespiel.free.fr/rxtx/2/ > From netbeans at gatworks.com Fri Jun 1 05:38:50 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 07:38:50 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <465F7ADD.1010501@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> Message-ID: <4660054A.2040202@gatworks.com> Manuel Naranjo wrote: In the case of my module, you can > unplug the device but it will not delete the symlink until those apps > that had opened the port has closed it. This is done this way to avoid > kernel panics. What does this mean to user code ? I have tried the alternate route ( other than closing ) which is sleep inbetween the I/O errors ( an unplugged USB device). When the device is plugged back in, The writes to the device still get an I/O error. This would seem to be a lost cause for the application. From netbeans at gatworks.com Fri Jun 1 06:35:48 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 08:35:48 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <465F7ADD.1010501@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> Message-ID: <466012A4.90608@gatworks.com> Manuel Naranjo wrote: In the case of my module, you can > unplug the device but it will not delete the symlink until those apps > that had opened the port has closed it. T Did u also mean for this to happen? USB0 was not closed by application. Apparently USB1 got created when USB device was plugged back in. There is only one USB device on a 4 port USB hub. This also seems to suggest that application recovery to be impossible. > Jun 1 07:10:08 mylaptop kernel: garmin_gps 1-1.4:1.0: Garmin GPS usb/tty converter detected > Jun 1 07:10:08 mylaptop kernel: usb 1-1.4: Garmin GPS usb/tty converter now attached to ttyUSB0 > Jun 1 07:15:17 mylaptop kernel: usb 1-1: USB disconnect, address 4 > Jun 1 07:15:17 mylaptop kernel: usb 1-1.4: USB disconnect, address 5 > Jun 1 07:15:17 mylaptop kernel: garmin_gps 1-1.4:1.0: device disconnected > Jun 1 07:15:26 mylaptop kernel: usb 1-1: new full speed USB device using uhci_hcd and address 6 > Jun 1 07:15:26 mylaptop kernel: hub 1-1:1.0: USB hub found > Jun 1 07:15:26 mylaptop kernel: hub 1-1:1.0: 4 ports detected > Jun 1 07:15:27 mylaptop kernel: usb 1-1.4: new full speed USB device using uhci_hcd and address 7 > Jun 1 07:15:27 mylaptop kernel: garmin_gps 1-1.4:1.0: Garmin GPS usb/tty converter detected > Jun 1 07:15:27 mylaptop kernel: usb 1-1.4: Garmin GPS usb/tty converter now attached to ttyUSB1 From naranjo.manuel at gmail.com Fri Jun 1 09:17:22 2007 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Fri, 01 Jun 2007 12:17:22 -0300 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <466012A4.90608@gatworks.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> <466012A4.90608@gatworks.com> Message-ID: <46603882.5050701@gmail.com> Uncle George escribi?: > Manuel Naranjo wrote: > In the case of my module, you can > >> unplug the device but it will not delete the symlink until those apps >> that had opened the port has closed it. T >> > > Did u also mean for this to happen? USB0 was not closed by application. > > Apparently USB1 got created when USB device was plugged back in. There > is only one USB device on a 4 port USB hub. > > This also seems to suggest that application recovery to be impossible. > Exactly there's a dead symlink (you can read and write to it and nothing will happen) and a new port will be created when a new device is connencted. From netbeans at gatworks.com Fri Jun 1 10:20:46 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 12:20:46 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <46603882.5050701@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> <466012A4.90608@gatworks.com> <46603882.5050701@gmail.com> Message-ID: <4660475E.5090202@gatworks.com> Not sure what u mean by "symlink". U cant read/write to it anymore. U get I/O error. In this scenario the device effectively went dead, and only solution is to close the channel. reconnecting the USB device, although dead, but not closed, will create a second device. This does not seem to be a desirable side-effect. The user will now have ttyUSB1, wondering where did ttyUSB0 go to. The application will also be in a confused state, as well as RXTX, because RXTX wont know about ttyUSB1. Manuel Naranjo wrote: > Uncle George escribi?: >> Manuel Naranjo wrote: >> In the case of my module, you can >> >>> unplug the device but it will not delete the symlink until those apps >>> that had opened the port has closed it. T >>> >> Did u also mean for this to happen? USB0 was not closed by application. >> >> Apparently USB1 got created when USB device was plugged back in. There >> is only one USB device on a 4 port USB hub. >> >> This also seems to suggest that application recovery to be impossible. >> > Exactly there's a dead symlink (you can read and write to it and nothing > will happen) and a new port will be created when a new device is connencted. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From arnab.bhaumik at gmail.com Mon Jun 4 01:40:16 2007 From: arnab.bhaumik at gmail.com (arnab bhaumik) Date: Mon, 4 Jun 2007 13:10:16 +0530 Subject: [Rxtx] full duplex com port with rxtx Message-ID: hi , till now i did half duplex communication with rxtx package on com package. my question is : is it possible to use com port with full duplex mode with rxtx package . ther is example of SimpleRead class and SimpleWrite class. it is clear that if i can use both the class simultaneously then full duplex is possible......... arnab/vu2bpw -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070604/6edb0453/attachment-0011.html From lists at iDIAcomputing.com Mon Jun 4 07:53:17 2007 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Mon, 04 Jun 2007 09:53:17 -0400 Subject: [Rxtx] full duplex com port with rxtx In-Reply-To: References: Message-ID: <4664194D.90301@iDIAcomputing.com> arnab bhaumik wrote: > hi , > > till now i did half duplex communication with rxtx package on com > package. > > my question is : is it possible to use com port with full duplex mode > with rxtx package . > > > ther is example of SimpleRead class and SimpleWrite class. it is > clear that if i can use both the class simultaneously then full duplex > is possible......... I haven't looked at the SimpleRead and SimpleWrite classes (I originally wrote my code for the javax.comm api), but full duplex is certainly possible. My CommReader class requires an object analogous to a OutputStream or Writer. When started, it spawns a thread that reads the comm port and writes to that output device. In this way the input is asynchronous and dependent on the actual input data. For full duplex, I extend that class with CommReaderWriter, which adds synchronous output methods. Hope that helps, George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From supsoop at hotmail.com Mon Jun 4 15:21:06 2007 From: supsoop at hotmail.com (soop soop) Date: Mon, 04 Jun 2007 21:21:06 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- Message-ID: Hi Guys, Looked through the archives but still cannot figure this out. I have a Motorola G24 GPRS/GSM modem that I am connecting to my server running Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not detecting the port, CommPortIdentifier.getPortIdentifiers(). I have added the line to RXTXCommDriver: "ttyACM" // for USB Modems Rxtx still does not seem to find the port. Is there something I am missing to make this port visable? [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control Model driver for USB modems and ISDN adapters I really need your help as I have moved my server from windows to Linux and have been down for a few days because of this .. Thanks so much! _________________________________________________________________ PC Magazine’s 2007 editors’ choice for best Web mail—award-winning Windows Live Hotmail. http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 From tjarvi at qbang.org Mon Jun 4 16:17:35 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Jun 2007 16:17:35 -0600 (MDT) Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: On Mon, 4 Jun 2007, soop soop wrote: > Hi Guys, > > Looked through the archives but still cannot figure this out. I have a > Motorola G24 GPRS/GSM modem that I am connecting to my server running Ubuntu. > I can see my modem as is shows up as ttyACM0, but RXTX is not detecting the > port, CommPortIdentifier.getPortIdentifiers(). > > I have added the line to RXTXCommDriver: > > "ttyACM" // for USB Modems > > Rxtx still does not seem to find the port. Is there something I am missing to > make this port visable? > > [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver > [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device > [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control Model > driver for USB modems and ISDN adapters > > I really need your help as I have moved my server from windows to Linux and > have been down for a few days because of this .. Thanks so much! > You could try the INSTALL documentation that comes with the source for possible solutions. Those usually involve lockfile creation, permissions on the device file or the device is in use by another application (even another session of your application). The usual commands: ls -l /dev/ttyACM0 fuser /dev/ttyACM0 touch /var/lock/LCK.testfile && rm -f /var/lock/LCK.testfile whoami To disable lockfiles: ../configure --disable-lockfiles && make install -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Jun 4 16:22:52 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 04 Jun 2007 18:22:52 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <466490BC.3090801@gatworks.com> soop soop wrote: > I really need your help as I have moved my server from windows to Linux > and have been down for a few days because of this .. Thanks so much! can u open the device ? ie is the file protection/permissions keeping you out? From supsoop at hotmail.com Mon Jun 4 16:44:40 2007 From: supsoop at hotmail.com (soop soop) Date: Mon, 04 Jun 2007 22:44:40 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <466490BC.3090801@gatworks.com> Message-ID: Thanks for the reply, I see no exceptions being thrown, just no detection of the port whats so ever. I will run rxtx in debug mode and log. If this were a permissions issue would I not see some exceptions being thrown? >From: Uncle George >Reply-To: RXTX Developers and Users >To: RXTX Developers and Users >Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >Date: Mon, 04 Jun 2007 18:22:52 -0400 > >soop soop wrote: > > > I really need your help as I have moved my server from windows to Linux > > and have been down for a few days because of this .. Thanks so much! > >can u open the device ? ie is the file protection/permissions keeping >you out? >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ Get a preview of Live Earth, the hottest event this summer - only on MSN http://liveearth.msn.com?source=msntaglineliveearthhm From netbeans at gatworks.com Mon Jun 4 17:06:15 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 04 Jun 2007 19:06:15 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <46649AE7.10405@gatworks.com> Exceptions on what? On startup it wants to lookup all devices in /dev that it is capable of opening ( within the list of specific 'comm' devices ). If it cannot open, then does not get onto list. Part of this process, if configured, will also test if the "LOCK" schema can also be opened for the device. then it gets on the list of avail comm port. soop soop wrote: > Thanks for the reply, > > I see no exceptions being thrown, just no detection of the port whats so > ever. I will run rxtx in debug mode and log. If this were a permissions > issue would I not see some exceptions being thrown? > > >> From: Uncle George >> Reply-To: RXTX Developers and Users >> To: RXTX Developers and Users >> Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >> Date: Mon, 04 Jun 2007 18:22:52 -0400 >> >> soop soop wrote: >> >>> I really need your help as I have moved my server from windows to Linux >>> and have been down for a few days because of this .. Thanks so much! >> can u open the device ? ie is the file protection/permissions keeping >> you out? >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _________________________________________________________________ > Get a preview of Live Earth, the hottest event this summer - only on MSN > http://liveearth.msn.com?source=msntaglineliveearthhm > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From alex.flint at gmail.com Mon Jun 4 21:31:49 2007 From: alex.flint at gmail.com (Alex Flint) Date: Tue, 5 Jun 2007 13:01:49 +0930 Subject: [Rxtx] random EXCEPTION_ACCESS_VIOLATION errors Message-ID: Hi All, I'm running winXP and RXTX 2.1-7r2 (the latest from the webpage as of June 2007). I'm sending sequences of 64 lines (each line has about 15 chars) at various intervals. The strings are sent fine, until I get the following error (from hs_err_pid3316.log, at the end of this email). What can I do to avoid the error? Obviously this is a low-level memory exception, but is there any way I can keep the JVM running after such an error? I noticed the exact same problem here: http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20070129/1180520.html Cheers, Alex # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x100034fb, pid=3316, tid=2400 # # Java VM: Java HotSpot(TM) Client VM (1.6.0_01-b06 mixed mode, sharing) # Problematic frame: # C [rxtxSerial.dll+0x34fb] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # --------------- T H R E A D --------------- Current thread (0x00386400): JavaThread "main" [_thread_in_native, id=2400] siginfo: ExceptionCode=0xc0000005, reading address 0x20726f78 Registers: EAX=0x20726f20, EBX=0x6d8922c0, ECX=0x00000005, EDX=0x20726f20 ESP=0x003efa30, EBP=0x003efb68, ESI=0x269728a0, EDI=0x00386400 EIP=0x100034fb, EFLAGS=0x00010212 Top of Stack: (sp=0x003efa30) 0x003efa30: 003efa3c 003efa64 0000000f ffffffff 0x003efa40: 003efa40 2a97f808 003efa6c 2b190ca8 0x003efa50: 00000000 2b190ec0 003efa90 008e2dd7 0x003efa60: 003efa90 008e2dd7 26977f88 6d815e72 0x003efa70: 00000004 2696eae0 0000008a 003efb0c 0x003efa80: 6d852b4a 2696eae0 00000003 26970930 0x003efa90: 000000cb 2696eae0 6d86b264 00385d40 0x003efaa0: 0000003f 003efb0c 26977f90 2ace65d8 Instructions: (pc=0x100034fb) 0x100034eb: ff ff 8d 76 00 eb 02 89 f6 90 8b 45 f8 8b 55 f8 0x100034fb: 8b 4a 58 83 c9 04 89 48 58 83 c4 f8 8b 45 f8 8b Stack: [0x003a0000,0x003f0000), sp=0x003efa30, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x34fb] Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j gnu.io.RXTXPort.writeArray([BIIZ)V+0 j gnu.io.RXTXPort$SerialOutputStream.write([B)V+76 j com.bjt.media.server.CommLink.send(Ljava/lang/String;)V+48 j com.bjt.media.server.DigitoolConnection.select(I)V+73 j com.bjt.media.server.DigitoolConnection.main([Ljava/lang/String;)V+74 v ~StubRoutines::call_stub --------------- P R O C E S S --------------- Java Threads: ( => current thread ) 0x02a69400 JavaThread "Thread-0" [_thread_in_native, id=3052] 0x02a4d000 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=3920] 0x02a48400 JavaThread "CompilerThread0" daemon [_thread_blocked, id=1968] 0x02a47400 JavaThread "Attach Listener" daemon [_thread_blocked, id=2984] 0x02a46400 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=2660] 0x02a41c00 JavaThread "Finalizer" daemon [_thread_blocked, id=3924] 0x02a3d800 JavaThread "Reference Handler" daemon [_thread_blocked, id=4008] =>0x00386400 JavaThread "main" [_thread_in_native, id=2400] Other Threads: 0x02a34400 VMThread [id=3708] 0x02a4e800 WatcherThread [id=3964] VM state:not at safepoint (normal execution) VM Mutex/Monitor currently owned by a thread: None Heap def new generation total 960K, used 131K [0x22960000, 0x22a60000, 0x22e40000) eden space 896K, 7% used [0x22960000, 0x22970ea8, 0x22a40000) from space 64K, 99% used [0x22a50000, 0x22a5fff8, 0x22a60000) to space 64K, 0% used [0x22a40000, 0x22a40000, 0x22a50000) tenured generation total 4096K, used 76K [0x22e40000, 0x23240000, 0x26960000) the space 4096K, 1% used [0x22e40000, 0x22e53060, 0x22e53200, 0x23240000) compacting perm gen total 12288K, used 137K [0x26960000, 0x27560000, 0x2a960000) the space 12288K, 1% used [0x26960000, 0x26982518, 0x26982600, 0x27560000) ro space 8192K, 62% used [0x2a960000, 0x2ae5e4e8, 0x2ae5e600, 0x2b160000) rw space 12288K, 52% used [0x2b160000, 0x2b7a0e78, 0x2b7a1000, 0x2bd60000) Dynamic libraries: 0x00400000 - 0x00423000 C:\Program Files\Java\jre1.6.0_01\bin\javaw.exe 0x7c900000 - 0x7c9b0000 C:\WINDOWS\system32\ntdll.dll 0x7c800000 - 0x7c8f4000 C:\WINDOWS\system32\kernel32.dll 0x77dd0000 - 0x77e6b000 C:\WINDOWS\system32\ADVAPI32.dll 0x77e70000 - 0x77f01000 C:\WINDOWS\system32\RPCRT4.dll 0x7e410000 - 0x7e4a0000 C:\WINDOWS\system32\USER32.dll 0x77f10000 - 0x77f57000 C:\WINDOWS\system32\GDI32.dll 0x76390000 - 0x763ad000 C:\WINDOWS\system32\IMM32.DLL 0x7c340000 - 0x7c396000 C:\Program Files\Java\jre1.6.0_01\bin\msvcr71.dll 0x6d7c0000 - 0x6da07000 C:\Program Files\Java\jre1.6.0_01\bin\client\jvm.dll 0x76b40000 - 0x76b6d000 C:\WINDOWS\system32\WINMM.dll 0x5cd70000 - 0x5cd77000 C:\WINDOWS\system32\serwvdrv.dll 0x5b0a0000 - 0x5b0a7000 C:\WINDOWS\system32\umdmxfrm.dll 0x6d310000 - 0x6d318000 C:\Program Files\Java\jre1.6.0_01\bin\hpi.dll 0x76bf0000 - 0x76bfb000 C:\WINDOWS\system32\PSAPI.DLL 0x6d770000 - 0x6d77c000 C:\Program Files\Java\jre1.6.0_01\bin\verify.dll 0x6d3b0000 - 0x6d3cf000 C:\Program Files\Java\jre1.6.0_01\bin\java.dll 0x6d7b0000 - 0x6d7bf000 C:\Program Files\Java\jre1.6.0_01\bin\zip.dll 0x10000000 - 0x10012000 C:\Documents and Settings\Alex\workspace\MediaServer\rxtxSerial.dll 0x73d90000 - 0x73db7000 C:\WINDOWS\system32\crtdll.dll VM Arguments: jvm_args: -Djava.library.path=C:\Documents and Settings\Alex\workspace\MediaServer java_command: com.bjt.media.server.DigitoolConnection Launcher Type: SUN_STANDARD Environment Variables: CLASSPATH=.;C:\Program Files\Java\j2re1.4.2_07\lib\ext\QTJava.zip PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\wbem;c:\applications\php;C:\Program Files\MATLAB\R2006a\bin\win32;C:\Roger\Projects\UAV\Bin\Debug;C:\Program Files\Microsoft SQL Server\80\Tools\Binn\;c:\Program Files\Microsoft SQL Server\90\Tools\binn\;C:\Program Files\QuickTime\QTSystem\;C:\Pfps\system;C:\Program Files\Java\jdk1.6.0_01\bin;C:\Program Files\Java\jdk1.6.0_01\jre\bin USERNAME=Alex OS=Windows_NT PROCESSOR_IDENTIFIER=x86 Family 15 Model 4 Stepping 1, GenuineIntel --------------- S Y S T E M --------------- OS: Windows XP Build 2600 Service Pack 2 CPU:total 1 family 15, cmov, cx8, fxsr, mmx, sse, sse2 Memory: 4k page, physical 1046508k(275288k free), swap 2522816k(1909176k free) vm_info: Java HotSpot(TM) Client VM (1.6.0_01-b06) for windows-x86, built on Mar 14 2007 00:24:02 by "java_re" with unknown MS VC++:1310 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070604/c87ae1f0/attachment-0011.html From alwyn.schoeman at gmail.com Tue Jun 5 00:10:19 2007 From: alwyn.schoeman at gmail.com (Alwyn Schoeman) Date: Tue, 5 Jun 2007 08:10:19 +0200 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Hi, I'm using a similar modem. By default rxtx doesn't look for devices that start with ACM, so you need to modify the source code and recompile. Look in RXTXCommDriver and add values for ACM in the registerScannedPorts method in the Linux specific parts. Look for osName.equals("Linux")... On 6/4/07, soop soop wrote: > > Hi Guys, > > Looked through the archives but still cannot figure this out. I have a > Motorola G24 GPRS/GSM modem that I am connecting to my server running > Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not > detecting the port, CommPortIdentifier.getPortIdentifiers(). > > I have added the line to RXTXCommDriver: > > "ttyACM" // for USB Modems > > Rxtx still does not seem to find the port. Is there something I am missing > to make this port visable? > > [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver > [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device > [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control > Model > driver for USB modems and ISDN adapters > > I really need your help as I have moved my server from windows to Linux > and > have been down for a few days because of this .. Thanks so much! > > _________________________________________________________________ > PC Magazine's 2007 editors' choice for best Web mail?award-winning Windows > Live Hotmail. > > http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -- Alwyn Schoeman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/b6cb3053/attachment-0011.html From naranjo.manuel at gmail.com Tue Jun 5 06:48:45 2007 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Tue, 05 Jun 2007 09:48:45 -0300 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> References: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Message-ID: <46655BAD.7010501@gmail.com> That's right, an easier solution is creating symlinks to acm. For example make ttyS70 to 79 point to ACM0 to 9 and that will help you a lot, and doesn't even require compile. > Hi, > > I'm using a similar modem. By default rxtx doesn't look for devices > that start with ACM, so you need to modify the > source code and recompile. > > Look in RXTXCommDriver and add values for ACM in the > registerScannedPorts method in the Linux specific parts. Look for > osName.equals("Linux")... > From juanemc2 at gmail.com Tue Jun 5 07:02:43 2007 From: juanemc2 at gmail.com (Juan) Date: Tue, 5 Jun 2007 10:02:43 -0300 Subject: [Rxtx] Problems with Epson TMU220B POSPrinter using XON/XOFF Flow Control and rxtx jar and dll's with the serial port. Message-ID: Hi!, I?m having trouble printing to the serial port using the latest version of rxtx jar and dll's with an Epson POSPrinter. I`ve switched the printer to work with XON/XOFF Flow Control and have watched the serial port to be sure the printer is sending the XON XOFF stop and go characters. I`ve setted the port like this: CommPortIdentifier commPortIdentifier = CommPortIdentifier.* getPortIdentifier*(_portName); SerialPort serialPort = (SerialPort)commPortIdentifier.open(*this*.getClass().getName(), 2000); serialPort.setSerialPortParams(_baudRate, _dataBits, _stopBits, _parity); serialPort.setFlowControlMode( SerialPort.*FLOWCONTROL_XONXOFF_IN* | SerialPort.*FLOWCONTROL_XONXOFF_OUT*); where the baudRate is 9600 the dataBits is 8 the stopBits is 1 and the parity is 0 It seems as the library isn`t taking into account the XON XOFF setting. I would like to know if I`m setting correctly the Flow Control and if you had had any experiences using XON XOFF flow control and could give me some help to solve my problem. I`m very thankful in advance, Yours, Juan Polero -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/b080995a/attachment-0011.html From ehdez.correo at gmail.com Tue Jun 5 07:12:53 2007 From: ehdez.correo at gmail.com (=?ISO-8859-1?Q?Enrique_Hern=E1ndez?=) Date: Tue, 5 Jun 2007 09:12:53 -0400 Subject: [Rxtx] problem with rxtx Message-ID: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Hello: I doing a simple test to show the serial ports. This is the code: import java.util.Enumeration; import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; public class Show { private Enumeration portList; private CommPortIdentifier portId; private SerialPort port; /** Creates a new instance of Show */ public Show() { } public static void main(String args[]){ Show show = new Show(); show.portList = CommPortIdentifier.getPortIdentifiers(); String tPort = ""; System.out.println("========================================="); while(show.portList.hasMoreElements()){ show.portId = (CommPortIdentifier)show.portList.nextElement(); if(show.portId.getPortType() == CommPortIdentifier.PORT_SERIAL) tPort = "Serial"; else tPort = "Parallel"; System.out.println(show.portId.getName() + " " + tPort); } } } whit The problem is that this code not show the serial ports, this show the no use serial ports. I want to connect whit the modem but when windows open and connect the modem my application don't see the port(COMM3) when it is connect. what I can do? Is that the correct way to know the ports? thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/eedd744b/attachment-0011.html From ehdez.correo at gmail.com Tue Jun 5 07:42:13 2007 From: ehdez.correo at gmail.com (=?ISO-8859-1?Q?Enrique_Hern=E1ndez?=) Date: Tue, 5 Jun 2007 09:42:13 -0400 Subject: [Rxtx] serial port Message-ID: <4a814e1f0706050642p4ce9ac7bka80f9479c524c5ea@mail.gmail.com> Hello: How I can ask to the port what device is connect and information about this device. thanks. bye. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/4d10d26a/attachment-0011.html From supsoop at hotmail.com Tue Jun 5 09:29:00 2007 From: supsoop at hotmail.com (soop soop) Date: Tue, 05 Jun 2007 15:29:00 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Message-ID: Hi Guys, Thanks for all your help. I found the problem. I created a user, Tomcat55, for my tomcat but it did not belong to any group. I then added this user to dialout group to have access to the device ttyACM0. Works perfectly! Again permissions was the issue. This also seems to be persistent as a server reboot does not effect the access. Cheers! >From: "Alwyn Schoeman" >Reply-To: RXTX Developers and Users >To: "RXTX Developers and Users" >Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >Date: Tue, 5 Jun 2007 08:10:19 +0200 > >Hi, > >I'm using a similar modem. By default rxtx doesn't look for devices that >start with ACM, so you need to modify the >source code and recompile. > >Look in RXTXCommDriver and add values for ACM in the registerScannedPorts >method in the Linux specific parts. Look for osName.equals("Linux")... > >On 6/4/07, soop soop wrote: >> >>Hi Guys, >> >>Looked through the archives but still cannot figure this out. I have a >>Motorola G24 GPRS/GSM modem that I am connecting to my server running >>Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not >>detecting the port, CommPortIdentifier.getPortIdentifiers(). >> >>I have added the line to RXTXCommDriver: >> >>"ttyACM" // for USB Modems >> >>Rxtx still does not seem to find the port. Is there something I am missing >>to make this port visable? >> >>[ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver >>[ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device >>[ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control >>Model >>driver for USB modems and ISDN adapters >> >>I really need your help as I have moved my server from windows to Linux >>and >>have been down for a few days because of this .. Thanks so much! >> >>_________________________________________________________________ >>PC Magazine's 2007 editors' choice for best Web mail—award-winning Windows >>Live Hotmail. >> >>http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 >> >> >>_______________________________________________ >>Rxtx mailing list >>Rxtx at qbang.org >>http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > >-- >Alwyn Schoeman >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ Need a break? Find your escape route with Live Search Maps. http://maps.live.com/default.aspx?ss=Restaurants~Hotels~Amusement%20Park&cp=33.832922~-117.915659&style=r&lvl=13&tilt=-90&dir=0&alt=-1000&scene=1118863&encType=1&FORM=MGAC01 From netbeans at gatworks.com Tue Jun 5 09:42:31 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 11:42:31 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <46658467.20101@gatworks.com> soop soop wrote: > > Hi Guys, > > Thanks for all your help. I found the problem. I created a user, > Tomcat55, for my tomcat but it did not belong to any group. I then added Look at man pages for the program udev. From tjarvi at qbang.org Tue Jun 5 18:18:17 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Jun 2007 18:18:17 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Message-ID: On Tue, 5 Jun 2007, Enrique Hern?ndez wrote: > The problem is that this code not show the serial ports, this show the no > use serial ports. I want to connect whit the modem but when windows open and > connect the modem my application don't see the port(COMM3) when it is > connect. > what I can do? > Is that the correct way to know the ports? > Hello, We may have problems understanding each other. On windows, the port will not be an available serial port if another application has the port open. That is just how the library behaves. If you can not see the port in the enumerated list, you could not open it. Also note that enumeration only happens once. If you add a port such as a new USB dongle, the port will not be visible until the next time your application runs. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Tue Jun 5 18:45:01 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 20:45:01 -0400 Subject: [Rxtx] problem with rxtx In-Reply-To: References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Message-ID: <4666038D.8090700@gatworks.com> Trent Jarvi wrote: > > > Also note that enumeration only happens once. If you add a port such as > a new USB dongle, the port will not be visible until the next time your > application runs. Is this written in stone ? somewhere? From tjarvi at qbang.org Tue Jun 5 18:54:36 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Jun 2007 18:54:36 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <4666038D.8090700@gatworks.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> Message-ID: On Tue, 5 Jun 2007, Uncle George wrote: > Trent Jarvi wrote: >> >> >> Also note that enumeration only happens once. If you add a port such as >> a new USB dongle, the port will not be visible until the next time your >> application runs. > > Is this written in stone ? somewhere? It is just the current behavior. There is nothing preventing a fix that allows reenumeration. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Tue Jun 5 19:55:19 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 21:55:19 -0400 Subject: [Rxtx] problem with rxtx In-Reply-To: References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> Message-ID: <46661407.4020308@gatworks.com> >> Is this written in stone ? somewhere? > > It is just the current behavior. There is nothing preventing a fix that > allows reenumeration. With usb, ..... , things come and go. Seems a shame that you have to kill application to get at the device u just plugged in. From joachim at buechse.ch Wed Jun 6 01:50:06 2007 From: joachim at buechse.ch (Joachim Buechse) Date: Wed, 6 Jun 2007 09:50:06 +0200 Subject: [Rxtx] problem with rxtx In-Reply-To: <46661407.4020308@gatworks.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> <46661407.4020308@gatworks.com> Message-ID: <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> On MacOS RXTX's enumeration handling is more flexible. It will find new ports that are added during the lifetime of the application. But this is inherently incompatible with suns javax.comm implementation... Regards, Joachim On 06.06.2007, at 03:55, Uncle George wrote: > >>> Is this written in stone ? somewhere? >> >> It is just the current behavior. There is nothing preventing a >> fix that >> allows reenumeration. > > With usb, ..... , things come and go. Seems a shame that you have to > kill application to get at the device u just plugged in. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Jun 6 06:06:48 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Jun 2007 06:06:48 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> <46661407.4020308@gatworks.com> <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> Message-ID: Sun's javax.comm is not a major concern going forward. As long as we do not break old applications using rxtx, I see no reason to limit rxtx to that convention. We have already rejected version 3 from Sun as a dead end and limited our compatability to version 2. That does not mean we will not try to work with Sun and others but the current javax.comm convention (v3) is not a well conceived path. There has been discussion about doing a JSR which is one valid option. On Wed, 6 Jun 2007, Joachim Buechse wrote: > On MacOS RXTX's enumeration handling is more flexible. It will find > new ports that are added during the lifetime of the application. But > this is inherently incompatible with suns javax.comm implementation... > > Regards, > Joachim > > On 06.06.2007, at 03:55, Uncle George wrote: > >> >>>> Is this written in stone ? somewhere? >>> >>> It is just the current behavior. There is nothing preventing a >>> fix that >>> allows reenumeration. >> >> With usb, ..... , things come and go. Seems a shame that you have to >> kill application to get at the device u just plugged in. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From yvespielusenet at free.fr Wed Jun 6 08:46:35 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 16:46:35 +0200 Subject: [Rxtx] [PARALLEL] resource in use Message-ID: <1181141195.3407.20.camel@localhost.localdomain> Hello, I want to use rxtx in my application. I haveto send data to a very old printer (which have a drum and hammers http://perso.orange.fr/tiie/page00010017.html) This is printer is connecter with centronics. It works well but, while it's writting and I putthe printer off-line, after about 45 seconds, I have this error : ------------------------------------- java.io.IOException: La ressource demand?e est en cours d'utilisation. in writeArray at gnu.io.LPRPort.writeArray(Native Method) at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:292) at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:161) at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:156) at mce.buffer.bufferManager.BufferManager$PrintBuffer.run(BufferManager.java:141) The IOexception means "The wanted resource is in use" ------------------------------------- Here is the line 141 of BufferManager : ------------------------------------- while(send){ try{ fos.write(bb); <=== line 141 send = false; } catch(Exception e){ javax.swing.JOptionPane.showMessageDialog(null, "Erreur d'envoie. Veuillez cliquer sur OK pour relancer l'impression de la vignette.\nV?rifiez votre impression !", "Erreur d'envoie", javax.swing.JOptionPane.WARNING_MESSAGE); e.printStackTrace(System.err); System.err.flush(); System.out.println(e); send = true; } } -------------------------------- 'fos' is an outputstream which contains the rxtx stream (this.os is the rxtx outputstream) : -------------------------------- public void write(byte[] bb) throws IOException{ this.write(bb, 0, bb.length); } public void write(byte[] bb, int off, int len) throws IOException{ while(!imp1.isPrinterSelected() || !imp2.isPrinterSelected()){ } this.os.write(bb, off, len); } -------------------------------- Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( can you help me ? thank you :) -- yves piel From yvespielusenet at free.fr Wed Jun 6 09:11:15 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 17:11:15 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181141195.3407.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> Message-ID: <1181142675.3407.23.camel@localhost.localdomain> I forgot to tell that It's under windows XP and java 1.5. Le mercredi 06 juin 2007 ? 16:46 +0200, yves pielusenet a ?crit : > Hello, > I want to use rxtx in my application. I haveto send data to a very old > printer (which have a drum and hammers > http://perso.orange.fr/tiie/page00010017.html) > This is printer is connecter with centronics. It works well but, while > it's writting and I putthe printer off-line, after about 45 seconds, I > have this error : > ------------------------------------- > java.io.IOException: La ressource demand?e est en cours d'utilisation. > in writeArray > at gnu.io.LPRPort.writeArray(Native Method) > at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:292) > at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:161) > at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:156) > at mce.buffer.bufferManager.BufferManager$PrintBuffer.run(BufferManager.java:141) > > The IOexception means "The wanted resource is in use" > ------------------------------------- > > Here is the line 141 of BufferManager : > > ------------------------------------- > while(send){ > try{ > fos.write(bb); <=== line 141 > send = false; > } > catch(Exception e){ > javax.swing.JOptionPane.showMessageDialog(null, "Erreur d'envoie. Veuillez cliquer sur OK pour relancer l'impression de la vignette.\nV?rifiez votre impression !", "Erreur d'envoie", javax.swing.JOptionPane.WARNING_MESSAGE); > e.printStackTrace(System.err); > System.err.flush(); > System.out.println(e); > send = true; > } > } > -------------------------------- > 'fos' is an outputstream which contains the rxtx stream (this.os is the rxtx outputstream) : > > -------------------------------- > public void write(byte[] bb) throws IOException{ > this.write(bb, 0, bb.length); > } > public void write(byte[] bb, int off, int len) throws IOException{ > while(!imp1.isPrinterSelected() || !imp2.isPrinterSelected()){ > } > this.os.write(bb, off, len); > } > -------------------------------- > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > can you help me ? > > thank you :) > From netbeans at gatworks.com Wed Jun 6 09:21:46 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 11:21:46 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181141195.3407.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> Message-ID: <4666D10A.8000507@gatworks.com> } > -------------------------------- > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > can you help me ? > > thank you :) > windoz or linux? ( I guess windoz ) for windoz, there appears to be a timeout ( as Comments suggest ) of about 40seconds. > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } for linux, there is no implied timeout. > if( write( fd, bytes, count ) < 0 ) > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); From netbeans at gatworks.com Wed Jun 6 09:39:41 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 11:39:41 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666D10A.8000507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> Message-ID: <4666D53D.90000@gatworks.com> Uncle George wrote: > } >> -------------------------------- >> >> Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( >> >> can you help me ? From reading the code, I can see your concern. And it appears you are correct, because some of the data will be sent to the OS printer buffers, and then it will refuse to accept anymore. Unfortunately, writeArray does not return the num of characters written :{ So application has no idea to how many characters were accepted by the OS. I dont do windoz, so I cant say with absolute certainty what windoz will do with an off-line condition. If you have the source, and can compile, then maybe u can increase the loop count to hit 4hours? From yvespielusenet at free.fr Wed Jun 6 09:53:25 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 17:53:25 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666D10A.8000507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> Message-ID: <1181145205.3407.35.camel@localhost.localdomain> Thank you for your explanation :) This timeout comes when no data has been send to the printer after 40seconds if I well understand. But why there is such a timeout ? If I setthe printer offline while it's printing I mustn't have an exception. I don't understand why the "printer should solv all problems like buffer full" in 40 seconds. If I pause the printer the buffer will not be emptied, isn't it ? I not very familiar with C/C++, but it seem that the exception is thrown only when countWritten == 0, that means no data at all has been sent. So Is my code is good since when I intercept this exception I send all my buffer again. There is no way that the printer receive two times same bytes ? thanks ps: yes the application is running on windows XP since I developpe under Debian Le mercredi 06 juin 2007 ? 11:21 -0400, Uncle George a ?crit : > } > > -------------------------------- > > > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > > > can you help me ? > > > > thank you :) > > > > windoz or linux? ( I guess windoz ) > > for windoz, there appears to be a timeout ( as Comments suggest ) of > about 40seconds. > > while( count > 0 ){ > > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > > /* > > this are 20 * 2 seconds, in this time a printer (or other parallel device) > > should solv all problems like buffer full, etc > > */ > > if(errorCount++ < 20){ > > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > > continue; > > } > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > for linux, there is no implied timeout. > > if( write( fd, bytes, count ) < 0 ) > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Wed Jun 6 10:34:24 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 12:34:24 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181145205.3407.35.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> Message-ID: <4666E210.30507@gatworks.com> yves pielusenet wrote: > Thank you for your explanation :) > This timeout comes when no data has been send to the printer after > 40seconds if I well understand. But why there is such a timeout ? If I > setthe printer offline while it's printing I mustn't have an exception. > I don't understand why the "printer should solv all problems like buffer > full" in 40 seconds. If I pause the printer the buffer will not be > emptied, isn't it ? > > I not very familiar with C/C++, but it seem that the exception is thrown > only when countWritten == 0, that means no data at all has been sent. So > Is my code is good since when I intercept this exception I send all my > buffer again. There is no way that the printer receive two times same > bytes ? More technically, the function call returns and reports that 0 characters was written in this call. when 0 characters are written, it will check how many times 0 characters was written. If it has tried LESS than 20 times(errorCount), it will sleep() and try to write again. After 20 times, it wont sleep, but throw you the exception. Now suppose you are writing a 120 character line. you off-lined/paused your printer. The OS has room for 80 more characters in it's printer buffer. The WriteFile() will have a char count of 120, but on return the countWritten = 80. You still have 40 more characters to print. Since countWritten != 0, the counters: bytes += countWritten; count -= countWritten; get updated, and the Writefile now has a count of 40 characters. Since the printer is off-line, the countwritten is 0. And so the loop continues, till 40 seconds is up. As to why it is this way, i dont know ( not a windoz maven ); Also the sleep(20) in the loop is not so intuitive to suggest 2 seconds of sleep. I would have guessed 20seconds, or 20milliseconds. But go figure. BTW: Since your computer sends you error messages in French, does it curse in English? :)))) From yvespielusenet at free.fr Thu Jun 7 02:27:44 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Thu, 07 Jun 2007 10:27:44 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666E210.30507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> Message-ID: <1181204864.3501.10.camel@localhost.localdomain> Maybe in my case I should re-compile rxtx and change the code. Instead of send an exception I should display a dialog box to ask if it's printer problem or if it should trie to send bytes. Something like : while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } if(displayDialogBox("Try again to send datas ??")){ errorCount = 0; } else{ throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } } Le mercredi 06 juin 2007 ? 12:34 -0400, Uncle George a ?crit : > yves pielusenet wrote: > > Thank you for your explanation :) > > This timeout comes when no data has been send to the printer after > > 40seconds if I well understand. But why there is such a timeout ? If I > > setthe printer offline while it's printing I mustn't have an exception. > > I don't understand why the "printer should solv all problems like buffer > > full" in 40 seconds. If I pause the printer the buffer will not be > > emptied, isn't it ? > > > > I not very familiar with C/C++, but it seem that the exception is thrown > > only when countWritten == 0, that means no data at all has been sent. So > > Is my code is good since when I intercept this exception I send all my > > buffer again. There is no way that the printer receive two times same > > bytes ? > More technically, the function call returns and reports that 0 > characters was written in this call. > when 0 characters are written, it will check how many times 0 characters > was written. If it has tried LESS than 20 times(errorCount), it will > sleep() and try to write again. > After 20 times, it wont sleep, but throw you the exception. > > Now suppose you are writing a 120 character line. you off-lined/paused > your printer. The OS has room for 80 more characters in it's printer > buffer. The WriteFile() will have a char count of 120, but on return the > countWritten = 80. You still have 40 more characters to print. > Since countWritten != 0, the counters: > bytes += countWritten; > count -= countWritten; > get updated, and the Writefile now has a count of 40 characters. Since > the printer is off-line, the countwritten is 0. And so the loop > continues, till 40 seconds is up. > > As to why it is this way, i dont know ( not a windoz maven ); > Also the sleep(20) in the loop is not so intuitive to suggest 2 seconds > of sleep. I would have guessed 20seconds, or 20milliseconds. But go figure. > > BTW: Since your computer sends you error messages in French, does it > curse in English? :)))) > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 06:11:43 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 08:11:43 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181204864.3501.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> Message-ID: <4667F5FF.8070903@gatworks.com> your suggestion appears good. I dont know what displayDialogBox exactly will do, so all I can say it that it looks good. But I'd like to wait 10min before first dialog box And a 5 min wait for every dialog box there after. And since these are custom solution/choices, maybe a more exact explanation of what the issue is. if(errorCount++ < 300){ // wait 10min ( 10min * 60sec / 2 ) Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } if(displayDialogBox("Printer has Paused. Retry sending data?")){ errorCount = 150; // Wait for 5 min thereafter continue; } > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } yves pielusenet wrote: > Maybe in my case I should re-compile rxtx and change the code. Instead > of send an exception I should display a dialog box to ask if it's > printer problem or if it should trie to send bytes. Something like : > > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > > if(displayDialogBox("Try again to send datas ??")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > } > From yvespielusenet at free.fr Thu Jun 7 07:17:21 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Thu, 07 Jun 2007 15:17:21 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4667F5FF.8070903@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <4667F5FF.8070903@gatworks.com> Message-ID: <1181222241.3501.20.camel@localhost.localdomain> thank you :) 'displayDialogBox()' I think doesn't exist. It was just for the example :) But I think It should not be so complicated to display a dialog box under windows with YES/NO buttons. When yes is clicked it return 0 other it returns 1. Le jeudi 07 juin 2007 ? 08:11 -0400, Uncle George a ?crit : > your suggestion appears good. I dont know what displayDialogBox exactly > will do, so all I can say it that it looks good. > > But I'd like to wait 10min before first dialog box And a 5 min wait for > every dialog box there after. And since these are custom > solution/choices, maybe a more exact explanation of what the issue is. > > if(errorCount++ < 300){ // wait 10min ( 10min * 60sec / 2 ) > Sleep( 20 ); /* make a small pause to execute all other requests > in all other threads */ > continue; > } > > if(displayDialogBox("Printer has Paused. Retry sending data?")){ > errorCount = 150; // Wait for 5 min thereafter > continue; > } > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > > yves pielusenet wrote: > > Maybe in my case I should re-compile rxtx and change the code. Instead > > of send an exception I should display a dialog box to ask if it's > > printer problem or if it should trie to send bytes. Something like : > > > > while( count > 0 ){ > > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > > /* > > this are 20 * 2 seconds, in this time a printer (or other parallel device) > > should solv all problems like buffer full, etc > > */ > > if(errorCount++ < 20){ > > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > > continue; > > } > > > > if(displayDialogBox("Try again to send datas ??")){ > > errorCount = 0; > > } > > else{ > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > } > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 07:41:43 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 09:41:43 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181222241.3501.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <4667F5FF.8070903@gatworks.com> <1181222241.3501.20.camel@localhost.localdomain> Message-ID: <46680B17.8050109@gatworks.com> yves pielusenet wrote: > thank you :) > 'displayDialogBox()' I think doesn't exist. It was just for the > example :) too bad. Good luck. From rtrout at webbresearch.com Thu Jun 7 11:23:04 2007 From: rtrout at webbresearch.com (Robert Trout) Date: Thu, 07 Jun 2007 13:23:04 -0400 Subject: [Rxtx] Disconnected PortServer TS causes Java to hang Message-ID: <1181236984.14186.33.camel@sisyphus.DinkumSoftware.com> I'm running Linux with sun's Java 1.4.2, Java comm API 2.0, RXTX 2.0-7pre1, and the RealPort digi driver. "/dev/ttyrp00" is a RealPort device. My Java application never returns from a ComPortIdentifier.getPortIdentifier("/dev/ttyrp00") call while the Digi PortServer TS 4 is disconnected from the network. If I later re-connect the PortServer, the call returns about 30 seconds later (it's like a serial port read or write is blocking until the PortServer is re- connected). With the PortServer disconnected, minicom immediately responds with "cannot open /dev/ttyrp00: No such file or directory". I would like my Java application to behave similarly. That is, respond with an error condition instead of hanging when the PortServer is not connected. Since minicom and Java behave differently, I think this "hanging" behavior may be due to RXTX or Java? Has anyone had a similar issue? Solutions? Suggestions? Thanks, Robert From vicnevicne at gmail.com Thu Jun 7 12:16:02 2007 From: vicnevicne at gmail.com (Vicne) Date: Thu, 07 Jun 2007 20:16:02 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181204864.3501.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> Message-ID: <46684B62.7080802@gmail.com> yves pielusenet wrote: > Maybe in my case I should re-compile rxtx and change the code. Instead > of send an exception I should display a dialog box to ask if it's > printer problem or if it should trie to send bytes. Something like : > > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > > if(displayDialogBox("Try again to send datas ??")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > } > Sorry to step in without a specific solution to your problem, but I wanted to share my feeling regarding this proposal. AFAIK, it's generally considered bad practice to pop-up a prompt from a library. The main reason is that in general use, you can't guarantee that someone is actually present behind the console. Imagine a print server in a machine room, connected to a park of printers. In that case, when one printer fails, the logical behaviour would be to use an other one. If you change RxTx the way you propose, the printer queue will simply be stuck with a useless "Try again to send data ?" prompt until an administrator opens a remote connection to the print server's console and clicks "no". Second, it would create a dependency upon the existence of a graphical console (if you go the graphical "dialogBox" way). On many applications (typically server or embedded ones), the JVM is "headless" and if you try to pop-up a dialog, your app would throw an exception (at best) or just wouldn't display the prompt anywhere... Going the "text console" way is not more reliable, because on graphical environments, the text console is hidden unless explicitly requested. My advice would be to think again and find another solution. Ideas are : - make the number of retries a parameter so that you can tune it to what you think is reasonable - throw a more specific exception when the number of retries has been reached, so that a specific prompt can be shown at a higher level Anyway, if you feel that the prompt is the way to go in your case, I would at least make that prompt conditional. The least intrusive way would probably be using a system property, like if("true".equals(System.getProperty("org.rxtx.usePrompt")) && displayDialogBox("Retry sending data ?")){ errorCount = 0; } else{ throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } By default, the behaviour would remain as it is now, but you could force the prompts by defining the property at VM launch if desired. (for example : java.exe -Dorg.rxtx.usePrompt=true myApp) Also, you seemed to say you wanted the printer to start again exactly where is stopped. It would indeed be the best way when the printer is put offline for a few seconds. On the other hand, if the printer is turned off (or the printer runs out of paper, or someone steps on the mains cable), then the only way to go back to a "stable" situation would be by printing the item (page, label, etc.) again from scratch... Just my two cents. Vicne PS : By the way, the dialog box thing is very platform dependant on the C-side, and I think the simplest way would probably be to bridge it to a Java call where you can implement it like you proposed : public boolean displayDialogBox(prompt) { return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); } From netbeans at gatworks.com Thu Jun 7 14:08:24 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 16:08:24 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46684B62.7080802@gmail.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> Message-ID: <466865B8.4060004@gatworks.com> My feeling is that the code that was suggested was for his environs ( his shop ). The issue here is that after a 40+ second wait, an exception will be thrown. But you really dont have a way of 'cancelling' all the WriteFiles() that have already occured before the exception so that your writeArray and the Commapi can backtrack to a position in which they are in sync. The main ( really mine ) concern is not to lose data, or replicate data. After 40seconds, 300 seconds, 55min, no matter how long, data should not be lost or duplicated. But as soon as the exception is thrown, that possibility exists. Maybe an event should be thrown instead? Vicne wrote: > yves pielusenet wrote: >> Maybe in my case I should re-compile rxtx and change the code. Instead >> of send an exception I should display a dialog box to ask if it's >> printer problem or if it should trie to send bytes. Something like : >> >> while( count > 0 ){ >> if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ >> /* >> this are 20 * 2 seconds, in this time a printer (or other parallel device) >> should solv all problems like buffer full, etc >> */ >> if(errorCount++ < 20){ >> Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ >> continue; >> } >> >> if(displayDialogBox("Try again to send datas ??")){ >> errorCount = 0; >> } >> else{ >> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >> break; >> } >> } >> > > Sorry to step in without a specific solution to your problem, but I > wanted to share my feeling regarding this proposal. AFAIK, it's > generally considered bad practice to pop-up a prompt from a library. > The main reason is that in general use, you can't guarantee that > someone is actually present behind the console. Imagine a print server > in a machine room, connected to a park of printers. In that case, when > one printer fails, the logical behaviour would be to use an other one. > If you change RxTx the way you propose, the printer queue will simply be > stuck with a useless "Try again to send data ?" prompt until an > administrator opens a remote connection to the print server's console > and clicks "no". > Second, it would create a dependency upon the existence of a > graphical console (if you go the graphical "dialogBox" way). On many > applications (typically server or embedded ones), the JVM is "headless" > and if you try to pop-up a dialog, your app would throw an exception (at > best) or just wouldn't display the prompt anywhere... Going the "text > console" way is not more reliable, because on graphical environments, > the text console is hidden unless explicitly requested. > > My advice would be to think again and find another solution. Ideas are : > - make the number of retries a parameter so that you can tune it to what > you think is reasonable > - throw a more specific exception when the number of retries has been > reached, so that a specific prompt can be shown at a higher level > > Anyway, if you feel that the prompt is the way to go in your case, I > would at least make that prompt conditional. The least intrusive way > would probably be using a system property, like > > if("true".equals(System.getProperty("org.rxtx.usePrompt")) > && displayDialogBox("Retry sending data ?")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > > > By default, the behaviour would remain as it is now, but you could > force the prompts by defining the property at VM launch if desired. (for > example : java.exe -Dorg.rxtx.usePrompt=true myApp) > > > Also, you seemed to say you wanted the printer to start again > exactly where is stopped. It would indeed be the best way when the > printer is put offline for a few seconds. On the other hand, if the > printer is turned off (or the printer runs out of paper, or someone > steps on the mains cable), then the only way to go back to a "stable" > situation would be by printing the item (page, label, etc.) again from > scratch... > > > Just my two cents. > > > Vicne > > PS : By the way, the dialog box thing is very platform dependant on the > C-side, and I think the simplest way would probably be to bridge it to a > Java call where you can implement it like you proposed : > > public boolean displayDialogBox(prompt) { > return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", > JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); > } > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Thu Jun 7 17:48:11 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 Jun 2007 17:48:11 -0600 (MDT) Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <466865B8.4060004@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> Message-ID: An event is possible. I'm amazed this is the largest problem encountered while using the parallel code. How would the write ever exit if we throw events? Isn't this going to lead to hung applications? On Thu, 7 Jun 2007, Uncle George wrote: > My feeling is that the code that was suggested was for his environs ( > his shop ). > > The issue here is that after a 40+ second wait, an exception will be > thrown. But you really dont have a way of 'cancelling' all the > WriteFiles() that have already occured before the exception so that your > writeArray and the Commapi can backtrack to a position in which they are > in sync. > > The main ( really mine ) concern is not to lose data, or replicate data. > After 40seconds, 300 seconds, 55min, no matter how long, data should > not be lost or duplicated. But as soon as the exception is thrown, that > possibility exists. > > Maybe an event should be thrown instead? > > Vicne wrote: >> yves pielusenet wrote: >>> Maybe in my case I should re-compile rxtx and change the code. Instead >>> of send an exception I should display a dialog box to ask if it's >>> printer problem or if it should trie to send bytes. Something like : >>> >>> while( count > 0 ){ >>> if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ >>> /* >>> this are 20 * 2 seconds, in this time a printer (or other parallel device) >>> should solv all problems like buffer full, etc >>> */ >>> if(errorCount++ < 20){ >>> Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ >>> continue; >>> } >>> >>> if(displayDialogBox("Try again to send datas ??")){ >>> errorCount = 0; >>> } >>> else{ >>> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >>> break; >>> } >>> } >>> >> >> Sorry to step in without a specific solution to your problem, but I >> wanted to share my feeling regarding this proposal. AFAIK, it's >> generally considered bad practice to pop-up a prompt from a library. >> The main reason is that in general use, you can't guarantee that >> someone is actually present behind the console. Imagine a print server >> in a machine room, connected to a park of printers. In that case, when >> one printer fails, the logical behaviour would be to use an other one. >> If you change RxTx the way you propose, the printer queue will simply be >> stuck with a useless "Try again to send data ?" prompt until an >> administrator opens a remote connection to the print server's console >> and clicks "no". >> Second, it would create a dependency upon the existence of a >> graphical console (if you go the graphical "dialogBox" way). On many >> applications (typically server or embedded ones), the JVM is "headless" >> and if you try to pop-up a dialog, your app would throw an exception (at >> best) or just wouldn't display the prompt anywhere... Going the "text >> console" way is not more reliable, because on graphical environments, >> the text console is hidden unless explicitly requested. >> >> My advice would be to think again and find another solution. Ideas are : >> - make the number of retries a parameter so that you can tune it to what >> you think is reasonable >> - throw a more specific exception when the number of retries has been >> reached, so that a specific prompt can be shown at a higher level >> >> Anyway, if you feel that the prompt is the way to go in your case, I >> would at least make that prompt conditional. The least intrusive way >> would probably be using a system property, like >> >> if("true".equals(System.getProperty("org.rxtx.usePrompt")) >> && displayDialogBox("Retry sending data ?")){ >> errorCount = 0; >> } >> else{ >> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >> break; >> } >> >> >> By default, the behaviour would remain as it is now, but you could >> force the prompts by defining the property at VM launch if desired. (for >> example : java.exe -Dorg.rxtx.usePrompt=true myApp) >> >> >> Also, you seemed to say you wanted the printer to start again >> exactly where is stopped. It would indeed be the best way when the >> printer is put offline for a few seconds. On the other hand, if the >> printer is turned off (or the printer runs out of paper, or someone >> steps on the mains cable), then the only way to go back to a "stable" >> situation would be by printing the item (page, label, etc.) again from >> scratch... >> >> >> Just my two cents. >> >> >> Vicne >> >> PS : By the way, the dialog box thing is very platform dependant on the >> C-side, and I think the simplest way would probably be to bridge it to a >> Java call where you can implement it like you proposed : >> >> public boolean displayDialogBox(prompt) { >> return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", >> JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); >> } >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 19:18:51 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 21:18:51 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> Message-ID: <4668AE7B.3060409@gatworks.com> The UNIX version of writeArray is not too great either. It is possible that the write will only process some of the bytes. #else if( write( fd, bytes, count ) < 0 ) throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); #endif -------------------------------- Maybe it might be better to have the native function inform the caller of the # of characters written, then the commapi/output-buffer can be modified to reflect the #of chars written. If an exception is to be thrown, for too many loops of chars written == 0, then exception wont affect the state of the output buffer. Then a ParallelPort.restart() can be called to resume printing whats in the buffer. Trent Jarvi wrote: > An event is possible. I'm amazed this is the largest problem encountered > while using the parallel code. > > How would the write ever exit if we throw events? Isn't this going to > lead to hung applications? Sure. If you dont time out, then there is nothing that will force an EXIT from the write(). Issue is what has the OS done with the write. > > On Thu, 7 Jun 2007, Uncle George wrote: > >> My feeling is that the code that was suggested was for his environs ( >> his shop ). From yvespielusenet at free.fr Fri Jun 8 01:09:01 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Fri, 08 Jun 2007 09:09:01 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4668AE7B.3060409@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> Message-ID: <1181286541.3674.10.camel@localhost.localdomain> It is not possible that the rxtx java method write(byte[], int offset, int length) return anint which contains the number of byte really send to the printer instead of an exception ? So this is the programm which will see if all bytes have been sent. If not it can retry to send the unsended bytes. -------------------------------------------------------- int sended = 0; while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ sended += countWritten; /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } return sended; /*throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break;*/ } ... ... return countWritten; ------------------------------------------------ Le jeudi 07 juin 2007 ? 21:18 -0400, Uncle George a ?crit : > The UNIX version of writeArray is not too great either. It is possible > that the write will only process some of the bytes. > > #else > if( write( fd, bytes, count ) < 0 ) > throw_java_exception_system_msg( env, IO_EXCEPTION, > "writeArray" ); > #endif > -------------------------------- > > Maybe it might be better to have the native function inform the caller > of the # of characters written, then the commapi/output-buffer can be > modified to reflect the #of chars written. If an exception is to be > thrown, for too many loops of chars written == 0, then exception wont > affect the state of the output buffer. Then a ParallelPort.restart() can > be called to resume printing whats in the buffer. > > > Trent Jarvi wrote: > > An event is possible. I'm amazed this is the largest problem encountered > > while using the parallel code. > > > > How would the write ever exit if we throw events? Isn't this going to > > lead to hung applications? > Sure. If you dont time out, then there is nothing that will force an > EXIT from the write(). Issue is what has the OS done with the write. > > > > On Thu, 7 Jun 2007, Uncle George wrote: > > > >> My feeling is that the code that was suggested was for his environs ( > >> his shop ). > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Fri Jun 8 03:45:00 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 11:45:00 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181286541.3674.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> Message-ID: <20070608094500.GC21069@elberon.bln.de.ingenico.com> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > It is not possible that the rxtx java method write(byte[], int offset, > int length) return anint which contains the number of byte really send > to the printer instead of an exception ? > So this is the programm which will see if all bytes have been sent. If > not it can retry to send the unsended bytes. I think write() is void because in Java people love to do this since OutputStream :-) Of course on such interfaces you cannot implement something nice. If you would have a int write, you would not implement the interface and no applications expecting this interface would link/work/compile. oki, Steffen P.S.: (OT) If you propose not to implement the Java interfaces (especially not on JNI level), maybe optionally offering a wrapper that removes e.g. the write return value and so on to downgrade the powerful classic old POSIX read/write style to the modern limited Java style, then I agree :-) Same for read. Instead of things like "int avialable()" it is more powerful to have an approach as select(2) offers (to guarante the caller that read/write will not block [nothing else make sense anyway IMHO] but may read/write less bytes then requested). The caller gets full control and the higher level protocols can care about timeouts, invoking read in some loops and/or implement retransmission. On top of such an implementation, where everything is controlled, defined, guaranteed and reliable, someone could use an InputStream or OutputStream style interface. Or even better: don't use them at all :) just BTW :-) St. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From yvespielusenet at free.fr Fri Jun 8 05:52:45 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Fri, 08 Jun 2007 13:52:45 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <20070608094500.GC21069@elberon.bln.de.ingenico.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> Message-ID: <1181303565.11203.3.camel@localhost.localdomain> So maybe a better way should be to create a new Exception class which has a method "int getWrittenByte()". So the Exception should be use to send again bytes which are not printed yet. yves Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : > * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > > It is not possible that the rxtx java method write(byte[], int offset, > > int length) return anint which contains the number of byte really send > > to the printer instead of an exception ? > > So this is the programm which will see if all bytes have been sent. If > > not it can retry to send the unsended bytes. > > I think write() is void because in Java people love to do this > since OutputStream :-) Of course on such interfaces you cannot > implement something nice. If you would have a int write, you > would not implement the interface and no applications expecting > this interface would link/work/compile. > > oki, > > Steffen > > P.S.: (OT) > If you propose not to implement the Java interfaces (especially > not on JNI level), maybe optionally offering a wrapper that > removes e.g. the write return value and so on to downgrade the > powerful classic old POSIX read/write style to the modern limited > Java style, then I agree :-) Same for read. Instead of things > like "int avialable()" it is more powerful to have an approach as > select(2) offers (to guarante the caller that read/write will not > block [nothing else make sense anyway IMHO] but may read/write > less bytes then requested). The caller gets full control and the > higher level protocols can care about timeouts, invoking read in > some loops and/or implement retransmission. On top of such an > implementation, where everything is controlled, defined, > guaranteed and reliable, someone could use an InputStream or > OutputStream style interface. Or even better: don't use them at > all :) just BTW :-) > St. > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > 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. > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > 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. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Fri Jun 8 06:46:21 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 08:46:21 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181303565.11203.3.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> Message-ID: <46694F9D.5080501@gatworks.com> It seems that with outputstream.write(b[]), you become terribly uncoordinated as soon as an exception is thrown. Docs do not say what happens to the data. Yet from a practicable point of view, one would like to know if the write was accepted in-full, or rejected before any writes. There are no in betweens, as partial writes are not reportable. So for an outputstream.write(), in order for it to return, the full write request has to be taken, and stored in an internal output buffer. If there is no room, the write() is suspended, till there is room. Or throw's an IOException( "no room in buffer") ; As the select() loop for write reports buffer room avail, then more of the internal buffer is sent to the printer. yves pielusenet wrote: > So maybe a better way should be to create a new Exception class which > has a method "int getWrittenByte()". So the Exception should be use to > send again bytes which are not printed yet. > > yves > > Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : >> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: >>> It is not possible that the rxtx java method write(byte[], int offset, >>> int length) return anint which contains the number of byte really send >>> to the printer instead of an exception ? >>> So this is the programm which will see if all bytes have been sent. If >>> not it can retry to send the unsended bytes. >> I think write() is void because in Java people love to do this >> since OutputStream :-) Of course on such interfaces you cannot >> implement something nice. If you would have a int write, you >> would not implement the interface and no applications expecting >> this interface would link/work/compile. >> >> oki, >> >> Steffen >> >> P.S.: (OT) >> If you propose not to implement the Java interfaces (especially >> not on JNI level), maybe optionally offering a wrapper that >> removes e.g. the write return value and so on to downgrade the >> powerful classic old POSIX read/write style to the modern limited >> Java style, then I agree :-) Same for read. Instead of things >> like "int avialable()" it is more powerful to have an approach as >> select(2) offers (to guarante the caller that read/write will not >> block [nothing else make sense anyway IMHO] but may read/write >> less bytes then requested). The caller gets full control and the >> higher level protocols can care about timeouts, invoking read in >> some loops and/or implement retransmission. On top of such an >> implementation, where everything is controlled, defined, >> guaranteed and reliable, someone could use an InputStream or >> OutputStream style interface. Or even better: don't use them at >> all :) just BTW :-) >> St. >> >> About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. >> 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. >> >> About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. >> 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. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From Steffen.DETTMER at ingenico.com Fri Jun 8 08:12:18 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 16:12:18 +0200 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <46694F9D.5080501@gatworks.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: <20070608141218.GE21069@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 08:46 -0400: > It seems that with outputstream.write(b[]), you become terribly > uncoordinated as soon as an exception is thrown. Docs do not say what > happens to the data. (yes, so avoiding it seems to be good :)) > Yet from a practicable point of view, one would like to know if the > write was accepted in-full, or rejected before any writes. There are no > in betweens, as partial writes are not reportable. (which is an artificial API limitation. I never understood how this happend when they invented JDK because the well-known BSD socket API and thus [probably] WinSock does this correct, but anyway) > So for an outputstream.write(), in order for it to return, the full > write request has to be taken, and stored in an internal output buffer. > If there is no room, the write() is suspended, till there is room. Or > throw's an IOException( "no room in buffer") ; As the select() loop for > write reports buffer room avail, then more of the internal buffer is > sent to the printer. yes, might be good in case of a printer. May be horrible in case of PPP/TCP or some other transmission control protocol which may e.g. repeat data or even omit parts of it (e.g. internet realtime radio station broadcasting)... So I think the idea of "int write" (e.g. BSD sockets, linux files and so on) still is the best. A clean API / implementation should guarantee and allow implementations (users) to rely on that; assumptions and automatic background-sending and so on may look pragmatic and may even work on the first look, but may fail in other situations. BTW, if e.g. BSD socket API is known, why not simply copy it (until something better is invented :)) instead of fiddling around with JDK APIs? anyway, have a nice weekend everyone :-) oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Fri Jun 8 08:55:56 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 10:55:56 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070608141218.GE21069@elberon.bln.de.ingenico.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> Message-ID: <46696DFC.7000801@gatworks.com> >> write reports buffer room avail, then more of the internal buffer is >> sent to the printer. > > yes, might be good in case of a printer. May be horrible in case > of PPP/TCP or some other transmission control protocol which > may e.g. repeat data or even omit parts of it (e.g. internet > realtime radio station broadcasting)... So I think the idea of > "int write" (e.g. BSD sockets, linux files and so on) still is > the best. A clean API / implementation should guarantee and allow > implementations (users) to rely on that; assumptions and > automatic background-sending and so on may look pragmatic and may > even work on the first look, but may fail in other situations. > BTW, if e.g. BSD socket API is known, why not simply copy it > (until something better is invented :)) instead of fiddling > around with JDK APIs? But we were talking about the Parallel Port, and the transmission of data over the commapi/parallel-port schema. There isn't much in bi-directional software communication. Its a simple write one byte at a time interface. I'm not looking to change the comm-api. I'm just looking to alter the interaction between the Native ParallelPort functions, and the java ParallelPort functions that call them. This might be more readily doable than to get a committee to re-specify java-API specs. BTW: Whats is off-topic? ( help: not looking for def of off-topic ) From j.kenneth.gentle at acm.org Fri Jun 8 08:58:59 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Fri, 08 Jun 2007 10:58:59 -0400 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <20070608141218.GE21069@elberon.bln.de.ingenico.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> Message-ID: <200706081459.l58Ex5rA019991@qbang.org> Perhaps it is a bit late to jump in on this one, but here goes anyway. If the solutions all seem to "break" the contract with "java.io.outputstream", then, as noted, that may not be the appropriate contract. At the risk of being heretical, JDK1.4 introduced the "nio" package to address some of the compatibility issues with C apis mentioned in previous posts. The interface "java.nio.channels.WriteableByteChannel" defines the following single method: int write(ByteBuffer source); int, strangely enough, is the actual number of bytes written. So, if RXTX as written, against the JavaCOMM api and OutputStream, doesn't do what we want, how about writing a different set of bindings using the java.nio classes and as much of the underlying native code as possible. Note that just because the java.nio.channels.WriteableByteChannel sends back a result, OutputStream.write doesn't have to - and they could both call the same underlying native code. My 2 cents - maybe not worth even that... Ken From netbeans at gatworks.com Fri Jun 8 10:37:28 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 12:37:28 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <200706081459.l58Ex5rA019991@qbang.org> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> Message-ID: <466985C8.8000505@gatworks.com> Ken Gentle wrote: > Perhaps it is a bit late to jump in on this one, but here goes anyway. Common in, the waters fine. > > If the solutions all seem to "break" the contract with > "java.io.outputstream", then, as noted, that may not be the > appropriate contract. > How would the contract be broken? The machinery underneath is handling the contract. From j.kenneth.gentle at acm.org Fri Jun 8 10:48:01 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Fri, 08 Jun 2007 12:48:01 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466985C8.8000505@gatworks.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> Message-ID: <200706081648.l58Gm7YA022904@qbang.org> At 12:37 2007-06-08, you wrote: >Ken Gentle wrote: > > > > If the solutions all seem to "break" the contract with > > "java.io.outputstream", then, as noted, that may not be the > > appropriate contract. > > >How would the contract be broken? The machinery underneath is handling >the contract. It seems that a lot of the discussion has been about not only the timeout and being able to adjust it in the "machinery layer", but also about knowing in the Java layer, in the event of a timeout or exception, how many characters have been written to the device. An OutputStream won't ever do this with out an extension and including a return value "breaks" the contract, right? So, go with a Java IO api that *does* return the number of bytes written, out of the NIO package. I know it doesn't allow for a strict implementation of the JavaCOMM API - however, using NIO classes in place of the IO classes isn't that big a break and would allow those applications that need such information a way to get it. Maybe I'm misunderstanding the problem... Ken From netbeans at gatworks.com Fri Jun 8 11:24:14 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 13:24:14 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <200706081648.l58Gm7YA022904@qbang.org> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> Message-ID: <466990BE.7040100@gatworks.com> Ken Gentle wrote: An > OutputStream won't ever do this with out an extension and including a > return value "breaks" the contract, right? > i was not thinking of change the API to OutputSream. Are there specs for how output stream should work internally? for instance: String data = "Hello this is a line of data"; Outputstream.write( data.getbytes() ); ParallelPort.suspend(); int free = ParallelPort.getoutputbufferfree(); There is a symbiotic relationship between outputstream and the functionality of ParallelPort. From Steffen.DETTMER at ingenico.com Fri Jun 8 11:15:39 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 19:15:39 +0200 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <200706081459.l58Ex5rA019991@qbang.org> References: <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> Message-ID: <20070608171539.GK21069@elberon.bln.de.ingenico.com> * Ken Gentle wrote on Fri, Jun 08, 2007 at 10:58 -0400: > If the solutions all seem to "break" the contract with > "java.io.outputstream", then, as noted, that may not be the > appropriate contract. > > At the risk of being heretical, JDK1.4 introduced the "nio" package > to address some of the compatibility issues with C apis mentioned in > previous posts. The interface > "java.nio.channels.WriteableByteChannel" defines the following single method: > > int write(ByteBuffer source); > > int, strangely enough, is the actual number of bytes written. Yes, AFAIK one of the motivations for the NIO interface was, that the JDK-1.3 APIs (InputStream, e.g.) were not powerfull enough, especially for multi-connection-TCP servers or so. I don't know much about it but I've heard of a project where NIO usage was removed because of stability issues in multi-threaded environments and performance limitations under some circumstances. IIRC the "nio.ByteBuffer" is something very special (namely something you cannot implement in Java, it is "magic" or part of the language itself). Not sure if this is such a great idea (but for performance in the end sometimes heavy prices must be paid) :) > So, if RXTX as written, against the JavaCOMM api and OutputStream, > doesn't do what we want, how about writing a different set of > bindings using the java.nio classes and as much of the underlying > native code as possible. Yes, this would be an idea: use a full-featured interface on JNI, and, if wanted, deliver some wrappers converting this to a less-featured Java-compliant interface. However, powerful things as e.g. "select" are difficult to "emulate" if you are e.g. on some (older?) windows. But if you expose the full-featured APIs, you need to emulate them full-featured, theoretically. In the end it depends what you do on the serial line. If you just want to talk to a modem, then you may not need precise timeouts. But if you need to implement complexer protocols which define response times and timeouts, you may quickly get into difficulties. For instance, AFAIK, rxtx 1.7.2 (?) for windows is very messy with timeouts (there is a maximum, higher values are truncated; resolution is 100ms only; the function may take up to twice the timeout because internally it may be called twice). Probably for most people this is OK, but probably not for all. But having precise timeouts should be OK for all :-) Well, in the end it is nice to wish but somewhat hard to implement (many platforms, connections, USB, BlueTooth, whatever). oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Steffen.DETTMER at ingenico.com Fri Jun 8 11:04:22 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 19:04:22 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <46696DFC.7000801@gatworks.com> References: <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <46696DFC.7000801@gatworks.com> Message-ID: <20070608170422.GJ21069@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 10:55 -0400: > > BTW, if e.g. BSD socket API is known, why not simply copy it > > (until something better is invented :)) instead of fiddling > > around with JDK APIs? > > But we were talking about the Parallel Port, and the > transmission of data over the commapi/parallel-port schema. > There isn't much in bi-directional software communication. Its > a simple write one byte at a time interface. First, there are things like PLIP (http://en.wikipedia.org/wiki/Plip) - well, probably not widely used, sure ;) Second, I think if there is a good simple API known to support all that (with known "best practices") or so and there is no forcing need to invent a new one, why not simply using it? > I'm not looking to change the comm-api. I'm just looking to > alter the interaction between the Native ParallelPort > functions, and the java ParallelPort functions that call them. Ahh, yes. I think this is what I tried to ask. Having an usable JNI interface and on top (in pure java) some wrapper to InputStream or whatever could be done (e.g. by ignoring the return value of write or throwing if != length). Developers could then use the full-featured (non-JAVA-standard) API or select among various wrappers (as InputStream). > This might be more readily doable than to get a committee to > re-specify java-API specs. Yes, of course. I'm afraid that the Java APIs change regularily, but still yet with limited success it seems, so maybe they get it in one of the next iterations; who knows, maybe Java-9 has a BSD-like socket API :) SCNR. > BTW: Whats is off-topic? ( help: not looking for def of > off-topic ) I think I started some "re-specify java-API specs" which was OT probably. oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From lists at iDIAcomputing.com Fri Jun 8 18:48:54 2007 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Fri, 08 Jun 2007 20:48:54 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46684B62.7080802@gmail.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> Message-ID: <4669F8F6.3040101@iDIAcomputing.com> Vicne wrote: > Sorry to step in without a specific solution to your problem, but I > wanted to share my feeling regarding this proposal. AFAIK, it's > generally considered bad practice to pop-up a prompt from a library. ... > > My advice would be to think again and find another solution. Ideas are : > - make the number of retries a parameter so that you can tune it to what > you think is reasonable > - throw a more specific exception when the number of retries has been > reached, so that a specific prompt can be shown at a higher level You could also allow the client code to register a callback class which returns a boolean indicating whether to retry or cancel. This callback class could pop up a dialog, if appropriate, or follow some preset policy, or.... - George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From joachim at buechse.ch Sat Jun 9 09:43:16 2007 From: joachim at buechse.ch (Joachim Buechse) Date: Sat, 9 Jun 2007 17:43:16 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46694F9D.5080501@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: You should not forget, that in the case of an exception it may not even be known what happened to the data. You have a kernel buffer, outgoing chip buffer, incoming chip buffer, etc. So of course, it would be nice to know up to which point data was correctly processed, but this feedback does not exist on the hardware or protocol level and hence can in general not be magicly created on the software level... Regards, Joachim On 08.06.2007, at 14:46, Uncle George wrote: > It seems that with outputstream.write(b[]), you become terribly > uncoordinated as soon as an exception is thrown. Docs do not say what > happens to the data. > > Yet from a practicable point of view, one would like to know if the > write was accepted in-full, or rejected before any writes. There > are no > in betweens, as partial writes are not reportable. > > So for an outputstream.write(), in order for it to return, the full > write request has to be taken, and stored in an internal output > buffer. > If there is no room, the write() is suspended, till there is room. Or > throw's an IOException( "no room in buffer") ; As the select() loop > for > write reports buffer room avail, then more of the internal buffer is > sent to the printer. > > > > yves pielusenet wrote: >> So maybe a better way should be to create a new Exception class which >> has a method "int getWrittenByte()". So the Exception should be >> use to >> send again bytes which are not printed yet. >> >> yves >> >> Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : >>> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: >>>> It is not possible that the rxtx java method write(byte[], int >>>> offset, >>>> int length) return anint which contains the number of byte >>>> really send >>>> to the printer instead of an exception ? >>>> So this is the programm which will see if all bytes have been >>>> sent. If >>>> not it can retry to send the unsended bytes. >>> I think write() is void because in Java people love to do this >>> since OutputStream :-) Of course on such interfaces you cannot >>> implement something nice. If you would have a int write, you >>> would not implement the interface and no applications expecting >>> this interface would link/work/compile. >>> >>> oki, >>> >>> Steffen >>> >>> P.S.: (OT) >>> If you propose not to implement the Java interfaces (especially >>> not on JNI level), maybe optionally offering a wrapper that >>> removes e.g. the write return value and so on to downgrade the >>> powerful classic old POSIX read/write style to the modern limited >>> Java style, then I agree :-) Same for read. Instead of things >>> like "int avialable()" it is more powerful to have an approach as >>> select(2) offers (to guarante the caller that read/write will not >>> block [nothing else make sense anyway IMHO] but may read/write >>> less bytes then requested). The caller gets full control and the >>> higher level protocols can care about timeouts, invoking read in >>> some loops and/or implement retransmission. On top of such an >>> implementation, where everything is controlled, defined, >>> guaranteed and reliable, someone could use an InputStream or >>> OutputStream style interface. Or even better: don't use them at >>> all :) just BTW :-) >>> St. >>> >>> About Ingenico Throughout the world businesses rely on Ingenico >>> for secure and expedient electronic transaction acceptance. >>> Ingenico products leverage proven technology, established >>> standards and unparalleled ergonomics to provide optimal >>> reliability, versatility and usability. This comprehensive range >>> of products is complemented by a global array of services and >>> partnerships, enabling businesses in a number of vertical sectors >>> to accept transactions anywhere their business takes them. >>> 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. >>> >>> About Ingenico Throughout the world businesses rely on Ingenico >>> for secure and expedient electronic transaction acceptance. >>> Ingenico products leverage proven technology, established >>> standards and unparalleled ergonomics to provide optimal >>> reliability, versatility and usability. This comprehensive range >>> of products is complemented by a global array of services and >>> partnerships, enabling businesses in a number of vertical sectors >>> to accept transactions anywhere their business takes them. >>> 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. >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx 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 yvespielusenet at free.fr Mon Jun 11 03:15:12 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Mon, 11 Jun 2007 11:15:12 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: <1181553312.8335.14.camel@localhost.localdomain> So can someone tell a solution for my problem :( Must I say to the user to not put the printer off-line ? I can't since he has to do some pauses, verify print, paper conditioning etc... How do other people ? Before I use the parport librarry to read port status : http://www.geocities.com/Juanga69/parport/ (which doesn't work on windows XP) And I send data into the file LPT1 I use to have no problem when printer was disabled. thanks -- yves piel Le samedi 09 juin 2007 ? 17:43 +0200, Joachim Buechse a ?crit : > You should not forget, that in the case of an exception it may not > even be known what happened to the data. > > You have a kernel buffer, outgoing chip buffer, incoming chip buffer, > etc. So of course, it would be nice to know up to which point data > was correctly processed, but this feedback does not exist on the > hardware or protocol level and hence can in general not be magicly > created on the software level... > > Regards, > Joachim > > On 08.06.2007, at 14:46, Uncle George wrote: > > > It seems that with outputstream.write(b[]), you become terribly > > uncoordinated as soon as an exception is thrown. Docs do not say what > > happens to the data. > > > > Yet from a practicable point of view, one would like to know if the > > write was accepted in-full, or rejected before any writes. There > > are no > > in betweens, as partial writes are not reportable. > > > > So for an outputstream.write(), in order for it to return, the full > > write request has to be taken, and stored in an internal output > > buffer. > > If there is no room, the write() is suspended, till there is room. Or > > throw's an IOException( "no room in buffer") ; As the select() loop > > for > > write reports buffer room avail, then more of the internal buffer is > > sent to the printer. > > > > > > > > yves pielusenet wrote: > >> So maybe a better way should be to create a new Exception class which > >> has a method "int getWrittenByte()". So the Exception should be > >> use to > >> send again bytes which are not printed yet. > >> > >> yves > >> > >> Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : > >>> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > >>>> It is not possible that the rxtx java method write(byte[], int > >>>> offset, > >>>> int length) return anint which contains the number of byte > >>>> really send > >>>> to the printer instead of an exception ? > >>>> So this is the programm which will see if all bytes have been > >>>> sent. If > >>>> not it can retry to send the unsended bytes. > >>> I think write() is void because in Java people love to do this > >>> since OutputStream :-) Of course on such interfaces you cannot > >>> implement something nice. If you would have a int write, you > >>> would not implement the interface and no applications expecting > >>> this interface would link/work/compile. > >>> > >>> oki, > >>> > >>> Steffen > >>> > >>> P.S.: (OT) > >>> If you propose not to implement the Java interfaces (especially > >>> not on JNI level), maybe optionally offering a wrapper that > >>> removes e.g. the write return value and so on to downgrade the > >>> powerful classic old POSIX read/write style to the modern limited > >>> Java style, then I agree :-) Same for read. Instead of things > >>> like "int avialable()" it is more powerful to have an approach as > >>> select(2) offers (to guarante the caller that read/write will not > >>> block [nothing else make sense anyway IMHO] but may read/write > >>> less bytes then requested). The caller gets full control and the > >>> higher level protocols can care about timeouts, invoking read in > >>> some loops and/or implement retransmission. On top of such an > >>> implementation, where everything is controlled, defined, > >>> guaranteed and reliable, someone could use an InputStream or > >>> OutputStream style interface. Or even better: don't use them at > >>> all :) just BTW :-) > >>> St. > >>> > >>> About Ingenico Throughout the world businesses rely on Ingenico > >>> for secure and expedient electronic transaction acceptance. > >>> Ingenico products leverage proven technology, established > >>> standards and unparalleled ergonomics to provide optimal > >>> reliability, versatility and usability. This comprehensive range > >>> of products is complemented by a global array of services and > >>> partnerships, enabling businesses in a number of vertical sectors > >>> to accept transactions anywhere their business takes them. > >>> 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. > >>> > >>> About Ingenico Throughout the world businesses rely on Ingenico > >>> for secure and expedient electronic transaction acceptance. > >>> Ingenico products leverage proven technology, established > >>> standards and unparalleled ergonomics to provide optimal > >>> reliability, versatility and usability. This comprehensive range > >>> of products is complemented by a global array of services and > >>> partnerships, enabling businesses in a number of vertical sectors > >>> to accept transactions anywhere their business takes them. > >>> 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. > >>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx 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 > From Steffen.DETTMER at ingenico.com Mon Jun 11 03:56:18 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 11:56:18 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466990BE.7040100@gatworks.com> References: <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> Message-ID: <20070611095618.GA10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 13:24 -0400: > i was not thinking of change the API to OutputSream. Then I think either someone uses OutputStream (and has no reliable information about incomplete writes) or someone uses somethink else. > Are there specs for how output stream should work internally? > > for instance: > String data = "Hello this is a line of data"; > Outputstream.write( data.getbytes() ); > ParallelPort.suspend(); > int free = ParallelPort.getoutputbufferfree(); > > There is a symbiotic relationship between outputstream and the > functionality of ParallelPort. If you need OutputStream "plus something else", in short you're needing "something else". Personally I dislike the code above a lot. The stream "looks" like if it would be an OutputStream, but in fact it isn't. You need to call getoutputbufferfree later to check if write succeeded (but OutputStream promises that write succeedes synchronous, blocking, or throws an exception). So it is not an OutputStream. No application written for OutputStreams would work without change (because it won't know getoutputbufferfree at all). It is not abstracted from ParallelPort. I think this would be wrong. Then I think an alternative interface instead is better. Let's assume we had some "connection" (to distinguish between OutputStreams and Channels). Then why not working as on a file handle in POSIX: do { // ... select maybe using timer ... readyForWrite = ... if (readyForWrite) { int writtenBytes = connection.write(toWrite); toWrite.remove(0, writtenBytes); } while(readyForWrite && toWrite.length > 0); I think, having such a write isn't the big problem. I think, the difficult thing is around "select" - however this would look like. It should be OO, typesafe, performant, supporting multiple connections/channels/streams in various modes and should be orthogonal to other functionalities. Of course, this heavily depends on what the application is doing; for a simple situation (like reading a small, mandatory file from a local disk) this would be to uncomfortable (and offering unneeded features only). just BTW :) oki, Steffen -- // Modeline for VIM. Please don't remove. // (Help: autoindent, expandtab, shiftwidth=4, tabstop=4, textwidth=75) // vi: set ai et sw=4 ts=4 tw=75 ft=java: About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Mon Jun 11 05:38:33 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 07:38:33 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611095618.GA10821@elberon.bln.de.ingenico.com> References: <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> Message-ID: <466D3439.4020805@gatworks.com> Steffen DETTMER wrote: > (but OutputStream promises that write > succeedes synchronous, blocking, or throws an exception). Where is it so written? From Steffen.DETTMER at ingenico.com Mon Jun 11 06:36:50 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 14:36:50 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466D3439.4020805@gatworks.com> References: <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> <466D3439.4020805@gatworks.com> Message-ID: <20070611123650.GI10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Mon, Jun 11, 2007 at 07:38 -0400: > Steffen DETTMER wrote: > > > (but OutputStream promises that write > > succeedes synchronous, blocking, or throws an exception). > > Where is it so written? Now, as you ask, I think it is not written that clearly but follows from specification. mmm... Am I wrong? I understand the API doc in this way: * http://java.sun.com/j2se/1.4.2/docs/api/java/io/OutputStream.html#write(byte[]) > public void write(byte[] b) > throws IOException > > Writes b.length bytes from the specified byte array to this > output stream. The general contract for write(b) is that > it should have exactly the same effect as the call write(b, > 0, b.length). > > Parameters: > b - the data. > Throws: > IOException - if an I/O error occurs. > See Also: > write(byte[], int, int) and there is: > public void write(byte[] b, > int off, > int len) > throws IOException > > Writes len bytes from the specified byte array starting at > offset off to this output stream. The general contract for > write(b, off, len) is that some of the bytes in the array b > are written to the output stream in order; element b[off] > is the first byte written and b[off+len-1] is the last byte > written by this operation. > > The write method of OutputStream calls the write method of > one argument on each of the bytes to be written out. > Subclasses are encouraged to override this method and > provide a more efficient implementation. > > If b is null, a NullPointerException is thrown. > > If off is negative, or len is negative, or off+len is > greater than the length of the array b, then an > IndexOutOfBoundsException is thrown. > > Parameters: > b - the data. > off - the start offset in the data. > len - the number of bytes to write. > Throws: > IOException - if an I/O error occurs. In particular, an > IOException is thrown if the output stream is closed. In general, any specialisation (derived child class) must comform to this. So write in the end is specified (!) as "The write method ... calls the write method ... on each of the bytes to be written out". This is what must be implemented by ANY OutputStream. Of course, there is: "Subclasses are encouraged to override this method and provide a more efficient implementation." which IMHO does not contradict - the more efficient must behave in exactly the same way of course (just wasting less resources than a simple byte-by-byte write). So it does not matter here I think. The write that finally defines the behavior tells basically: > "Writes the specified byte to this output stream. The general > contract for write is that one byte is written to the output > stream. " > > Throws: > IOException - if an I/O error occurs. which IMHO is another way of saying "write writes the byte immediately and returns on success (only), otherwise an exception is thrown". Especially it cannot happen that zero bytes are written (i.e. the specified byte is NOT written) without an exception. So by this write must be synchronous and blocking, because otherwise it could not reliably know if an asynchronous operation will succeede or not (some getAsyncResult or so would be needed). Since write(byte[]) does this for each byte (or with a behavior beeing exactly the same as if it would do), I think this means that the write(byte[]) succeedes synchronous/blocking or throws an exception. Did I an error in reasoning or confused something or so? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From j.kenneth.gentle at acm.org Mon Jun 11 06:51:25 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 11 Jun 2007 08:51:25 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611123650.GI10821@elberon.bln.de.ingenico.com> References: <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> <466D3439.4020805@gatworks.com> <20070611123650.GI10821@elberon.bln.de.ingenico.com> Message-ID: <200706111251.l5BCpS9T017831@qbang.org> It is as Steffen describes. "InputStream" and "OutputStream" are inherently synchronous (which is why so many java programs resort to threads to use them). Anything outside of this "contract" is *not* an InputStream or OutputStream. That is why there is a new package for things that don't behave like the old *Stream classes - the NIO package. If you look carefully at the IO package, you'll note that almost all the classes are _Decorator_ pattern implementations of the *Stream classes - and the interface presents the _same_ behavior to the calling code in all cases - a synchronous operation that completes successfully or throws an exception (with the one exception of "read" that returns a "-1" on end-of-stream. I know I've read this numerous times - I'd suggest checking the Language Spec or one of the books by Bloch or Gosling. Ken At 08:36 2007-06-11, you wrote: >* Uncle George wrote on Mon, Jun 11, 2007 at 07:38 -0400: > > Steffen DETTMER wrote: > > > > > (but OutputStream promises that write > > > succeedes synchronous, blocking, or throws an exception). > > > > Where is it so written? > >Now, as you ask, I think it is not written that clearly but >follows from specification. mmm... > >Am I wrong? > >I understand the API doc in this way: > >* >http://java.sun.com/j2se/1.4.2/docs/api/java/io/OutputStream.html#write(byte[]) > > public void write(byte[] b) > > throws IOException > > > > Writes b.length bytes from the specified byte array to this > > output stream. The general contract for write(b) is that > > it should have exactly the same effect as the call write(b, > > 0, b.length). > > > > Parameters: > > b - the data. > > Throws: > > IOException - if an I/O error occurs. > > See Also: > > write(byte[], int, int) > > >and there is: > > > > public void write(byte[] b, > > int off, > > int len) > > throws IOException > > > > Writes len bytes from the specified byte array starting at > > offset off to this output stream. The general contract for > > write(b, off, len) is that some of the bytes in the array b > > are written to the output stream in order; element b[off] > > is the first byte written and b[off+len-1] is the last byte > > written by this operation. > > > > The write method of OutputStream calls the write method of > > one argument on each of the bytes to be written out. > > Subclasses are encouraged to override this method and > > provide a more efficient implementation. > > > > If b is null, a NullPointerException is thrown. > > > > If off is negative, or len is negative, or off+len is > > greater than the length of the array b, then an > > IndexOutOfBoundsException is thrown. > > > > Parameters: > > b - the data. > > off - the start offset in the data. > > len - the number of bytes to write. > > Throws: > > IOException - if an I/O error occurs. In particular, an > > IOException is thrown if the output stream is closed. > > >In general, any specialisation (derived child class) must comform >to this. So write in the end is specified (!) as "The write >method ... calls the write method ... on each of the bytes to be >written out". This is what must be implemented by ANY >OutputStream. > >Of course, there is: "Subclasses are encouraged to override this >method and provide a more efficient implementation." which IMHO >does not contradict - the more efficient must behave in exactly >the same way of course (just wasting less resources than a simple >byte-by-byte write). So it does not matter here I think. > > > >The write that finally defines the behavior tells basically: > > > "Writes the specified byte to this output stream. The general > > contract for write is that one byte is written to the output > > stream. " > > > > Throws: > > IOException - if an I/O error occurs. > > >which IMHO is another way of saying "write writes the byte >immediately and returns on success (only), otherwise an exception >is thrown". Especially it cannot happen that zero bytes are >written (i.e. the specified byte is NOT written) without an >exception. So by this write must be synchronous and blocking, >because otherwise it could not reliably know if an asynchronous >operation will succeede or not (some getAsyncResult or so would >be needed). > >Since write(byte[]) does this for each byte (or with a behavior >beeing exactly the same as if it would do), I think this means >that the write(byte[]) succeedes synchronous/blocking or throws >an exception. > >Did I an error in reasoning or confused something or so? > >oki, > >Steffen > >About Ingenico Throughout the world businesses rely on Ingenico for >secure and expedient electronic transaction acceptance. Ingenico >products leverage proven technology, established standards and >unparalleled ergonomics to provide optimal reliability, versatility >and usability. This comprehensive range of products is complemented >by a global array of services and partnerships, enabling businesses >in a number of vertical sectors to accept transactions anywhere >their business takes them. >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. > >About Ingenico Throughout the world businesses rely on Ingenico for >secure and expedient electronic transaction acceptance. Ingenico >products leverage proven technology, established standards and >unparalleled ergonomics to provide optimal reliability, versatility >and usability. This comprehensive range of products is complemented >by a global array of services and partnerships, enabling businesses >in a number of vertical sectors to accept transactions anywhere >their business takes them. >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. > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From alesinskyy at googlemail.com Mon Jun 11 07:25:33 2007 From: alesinskyy at googlemail.com (Oleksandr Alesinskyy) Date: Mon, 11 Jun 2007 15:25:33 +0200 Subject: [Rxtx] [OT] select :-) Message-ID: Sorry, but I have to disagree with following statement: "So write in the end is specified (!) as "The write method ... calls the write method ... on each of the bytes to be written out". This is what must be implemented by ANY OutputStream.". This is not part of the specification or contract, it is just revealed implementation detail of the OutputStream. It is not stated anywhere that behavoiur of derived classes shall conform with this one. Statement concerning "synchronous" nature of the output stream is invalid as well. Really synchronous stream does not require flush() but OutputStream has it. From Steffen.DETTMER at ingenico.com Mon Jun 11 08:21:16 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 16:21:16 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: Message-ID: <20070611142116.GN10821@elberon.bln.de.ingenico.com> * Oleksandr Alesinskyy wrote on Mon, Jun 11, 2007 at 15:25 +0200: > Sorry, but I have to disagree with following statement: > "So write in the end is specified (!) as "The write > method ... calls the write method ... on each of the bytes to be > written out". This is what must be implemented by ANY > OutputStream.". > > This is not part of the specification or contract, it is just > revealed implementation detail of the OutputStream. It is not > stated anywhere that behavoiur of derived classes shall conform > with this one. (I didn't meant that the implementation must really write byte by byte, but that it must "look as if it would do" - because all implementations of OutputStream must "look" in the same way [which is another way of saying "do abstract" I think]) I think the API doc is not "revealing implementation details" but it is the *specification* of that interface and derivations must (should) conform to this specification. Isn't this the idea of interfaces? A function that expects an OutputStream should work on ANY OutputStream, shouldn't it? just kidding: I mean, what would be the point in implementing a checksum function as OutputStream.write which throws its result as IOException? Or which requires to call close() as very first operation to tell that the application is about to transmit confidential data? :-) > Statement concerning "synchronous" nature of the output stream > is invalid as well. Really synchronous stream does not require > flush() but OutputStream has it. ahh, interesting point! I think this is another bug in the API. flush() is wrong. Because write specifies "The general contract for write is that one byte is written to the output stream." but not "a byte may be written or buffered". Actually, an application would need to call flush() after each write (or bunch of write calls) to ensure that write really did something otherwise I think. I didn't found in the spec of OutputStream that it would be required to call flush(). This should mean that calling flush is not required which in turn leads to the conclusion that write must be synchrous (private threads are forbidden because not specified :)) which in turn leads to the conclusion that flush() is not needed at all... I mean, what if someone would only store in write and do the "real write" in flush() and never else? An application could write in one stream and read on another one (e.g. in bidirectional communication) and would never get anything back, because nothing was actually written because no flush was called? Then someone could even think that on error in some write the data could remain buffered AND throw an exception, retrying to send the data in the next write. Ohh, and if there would be some message number inside, and underlaying write (e.g. a protocol offering InputStream/OutputStream) would check this and throw "DuplicatedMessageNumber" the stream would only throw it again and again beeing unusable... In short: I have no clue how someone could be able to implement an asynchrounos write (which is realiable and correct) without beeing specific to anything which is not specified by OutputStream. Well, I think in the end OutputStream was not intended for such communication or protocol implementations - but to read a local disk file or so. In case of I/O errors usually you can abort your application and change the hard disk :-) oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Bob_Jacobsen at lbl.gov Mon Jun 11 09:32:23 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Mon, 11 Jun 2007 08:32:23 -0700 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611142116.GN10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> Message-ID: At 4:21 PM +0200 6/11/07, Steffen DETTMER wrote: > > Statement concerning "synchronous" nature of the output stream >> is invalid as well. Really synchronous stream does not require >> flush() but OutputStream has it. > >ahh, interesting point! > >I think this is another bug in the API. flush() is wrong. Because >write specifies "The general contract for write is that one byte >is written to the output stream." but not "a byte may be written >or buffered". > >Actually, an application would need to call flush() after each >write (or bunch of write calls) to ensure that write really did >something otherwise I think. OutputStreams don't _have_ to be synchronous or asynchronous, but the OutputStream API was be arranged so that subclasses _can_ be synchronous or asynchronous. Such generality is the hardest part of getting an API right. Hence, if at some point a program using an OutputStream wants to be sure that the data has been pushed all the way out, flush() is available. For some subclasses, e.g. the buffered ones, this has important behavior. Others write the data from each call, and flush() doesn't do anything. You _can_ omit it in programs that are known to use this second type, but there's no requirement that you do so; the interface is general in that way. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From Steffen.DETTMER at ingenico.com Mon Jun 11 12:32:39 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 20:32:39 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> Message-ID: <20070611183239.GT10821@elberon.bln.de.ingenico.com> * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: > >Actually, an application would need to call flush() after each > >write (or bunch of write calls) to ensure that write really did > >something otherwise I think. > OutputStreams don't _have_ to be synchronous or asynchronous, > but the OutputStream API was be arranged so that subclasses > _can_ be synchronous or asynchronous. Ahh, oki. Thanks for the clarificaion. So in short, flush() MUST be called on OutputStream, this is just not documented correctly or so clearly (right?). So the overall usage semantics would be: 1. call write (multiple times if desired) 2. call flush only if both succeeded, write was successful. If flush fails it remains unknown if a part of the data was written and/or will be repeated. So the spec (API doc) is wrong. Correct would be to tell that write behaves as told as long as it is followed by a call to flush, otherwise data may or may not get lost (depending wheter close() is called and calls flush(), which seems not to be guaranteed/required). BTW, I think it is a little bit... erm... interesting to find the specification (java API doc reference) wrong, having a need to conclude it from the presence of some methods with "it would make no sense if they behave exactly as specified, so specification must be wrong (incomplete)". > Such generality is the hardest part of getting an API right. Yes, seems to be proven ;) > Hence, if at some point a program using an OutputStream wants > to be sure that the data has been pushed all the way out, > flush() is available. For some subclasses, e.g. the buffered > ones, this has important behavior. Others write the data from > each call, and flush() doesn't do anything. > You _can_ omit it in programs that are known to use this second > type, but there's no requirement that you do so; the interface > is general in that way. I think, it still it must be called always, otherwise the application could break if passing a different runtime type as OutputStream. I think, if the application/method needs a special "type of OutputStream" then the parameter type must be a subclass but not OutputStream, maybe a PrintStream or so - otherwise the compiler could not detect this error (passing wrong type). Is this correct? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Bob_Jacobsen at lbl.gov Mon Jun 11 13:00:52 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Mon, 11 Jun 2007 12:00:52 -0700 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611183239.GT10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> Message-ID: At 8:32 PM +0200 6/11/07, Steffen DETTMER wrote: >So the spec (API doc) is wrong. Correct would be to tell that >write behaves as told as long as it is followed by a call to >flush, otherwise data may or may not get lost (depending wheter >close() is called and calls flush(), which seems not to be >guaranteed/required). I'm not entirely sure that the spec is wrong, but reasonable people can differ on this. In the 1.5 JavaDocs, all that the docs say for the write methods is that they write to the _output_ _stream_; there is no guarantee of anything beyond that. Only the flush method has any guarantee about the data, which is >Flushes this output stream and forces any buffered output bytes to >be written out. The general contract of flush is that calling it is >an indication that, if any bytes previously written have been >buffered by the implementation of the output stream, such bytes >should immediately be written to their intended destination. People commonly use various OutputStreams without using flush(), and it often works, but it's a bad practice and will eventually bite them. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From netbeans at gatworks.com Mon Jun 11 13:31:57 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 15:31:57 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611183239.GT10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> Message-ID: <466DA32D.1010602@gatworks.com> Steffen DETTMER wrote: > * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: >>> Actually, an application would need to call flush() after each >>> write (or bunch of write calls) to ensure that write really did >>> something otherwise I think. > >> OutputStreams don't _have_ to be synchronous or asynchronous, >> but the OutputStream API was be arranged so that subclasses >> _can_ be synchronous or asynchronous. > > Ahh, oki. Thanks for the clarificaion. > > So in short, flush() MUST be called on OutputStream, this is just > not documented correctly or so clearly (right?). No. Flush can be called to force all current data in java buffer's to be written to the kernel - NOW. A flush() can also *imply* that, besides writing out the buffer's that java employs, may also imply/ask the kernel to write all data thusfar written to the kernel, to be physically placed on the destination device - NOW. For some OS's there is no need to do a kernel flush(), as the I/O is synchronized already. Since this is java, you never know what OS your on. From tjarvi at qbang.org Mon Jun 11 19:28:27 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Jun 2007 19:28:27 -0600 (MDT) Subject: [Rxtx] [OT] select :-) In-Reply-To: <466DA32D.1010602@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: On Mon, 11 Jun 2007, Uncle George wrote: > Steffen DETTMER wrote: >> * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: >>>> Actually, an application would need to call flush() after each >>>> write (or bunch of write calls) to ensure that write really did >>>> something otherwise I think. >> >>> OutputStreams don't _have_ to be synchronous or asynchronous, >>> but the OutputStream API was be arranged so that subclasses >>> _can_ be synchronous or asynchronous. >> >> Ahh, oki. Thanks for the clarificaion. >> >> So in short, flush() MUST be called on OutputStream, this is just >> not documented correctly or so clearly (right?). > No. > Flush can be called to force all current data in java buffer's to be > written to the kernel - NOW. > > A flush() can also *imply* that, besides writing out the buffer's that > java employs, may also imply/ask the kernel to write all data thusfar > written to the kernel, to be physically placed on the destination device > - NOW. > For some OS's there is no need to do a kernel flush(), as the I/O is > synchronized already. Since this is java, you never know what OS your on. To add to the confusion, flush on the C side throws away data. drain makes sure it is written. Looking at the ParallelImp.c we can probably do better. /* we set a timeout because all calls are sequentiell (also with asynchron) this means that the default timeout of unlimited blocks all calls (also close and status request) if the device is down */ GetCommTimeouts( (HANDLE)fd, &timeouts ); timeouts.WriteTotalTimeoutMultiplier = 0; timeouts.WriteTotalTimeoutConstant = 2000; /* 2000 is the min value for the default Windows NT and Windows 2000 driver */ SetCommTimeouts( (HANDLE)fd, &timeouts ); while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } errorCount = 0; bytes += countWritten; count -= countWritten; } LPRPort has some timeout code that appears to be doing nothing but flipping bits back and forth right now. The commapi rxtx follows allows for timeout control from javax.comm.CommPort. The above is a solution that worked in one specific use case. With timeouts in place, the original 'old printer going offline' problem could be solved. That printer code isn't written in stone. In fact it was ajusted from being able to print 'asdf' to a daisy wheel printer to working for one person. BTW, I've finished teaching after hours tonight and will be moving forward with a new rxtx release in my free time. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Jun 11 21:28:04 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 23:28:04 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: <466E12C4.1010305@gatworks.com> > Looking at the ParallelImp.c we can probably do better. > The problem stemmed from the possibility that the writev routine could have written some of the buffer, in chunks, printer pauses, refuses any more chunks, and a timeout occurs. Do you or do you not cause an exception to be thrown? Is there a way to set timeout for a ParallelPort data output stream? I cant find it. From tjarvi at qbang.org Mon Jun 11 22:17:23 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Jun 2007 22:17:23 -0600 (MDT) Subject: [Rxtx] [OT] select :-) In-Reply-To: <466E12C4.1010305@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> <466E12C4.1010305@gatworks.com> Message-ID: On Mon, 11 Jun 2007, Uncle George wrote: >> Looking at the ParallelImp.c we can probably do better. >> > The problem stemmed from the possibility that the writev routine could > have written some of the buffer, in chunks, printer pauses, refuses any > more chunks, and a timeout occurs. Do you or do you not cause an > exception to be thrown? > > Is there a way to set timeout for a ParallelPort data output stream? I > cant find it. hmm I looked again after you asked. The timeouts are only controllable on the receive side. This comes from CommPort; the parent. So what we are talking about is some bytes in memory that rxtx has and is supposed to write. A buffer perhaps? The approach with rxtx in the past has been to ignore output buffer sizes. The assumption is that the library does not know how to best handle buffers. There are buffered output streams that can do buffering on top of rxtx for instance. There is also a question regarding what was actually ment when the API was put together. My suspicion is that it was put together while looking at one OS API and was never ment to be anything more than a hook into that API. The comments are fairly telling combined with reading the w32 API. So looking at the problem again.. The current timeout behavior appears fairly arbitrary. Presumably this is to prevent a program from hanging instead of using a helper thread to write - heavy handed for new programmers. Even so, I don't think the write should timeout at all if it is not configurable. >From the API perspective, "What Timeout?" -- Trent Jarvi tjarvi at qbang.org From Steffen.DETTMER at ingenico.com Tue Jun 12 02:14:48 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 12 Jun 2007 10:14:48 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466DA32D.1010602@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: <20070612081447.GU10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Mon, Jun 11, 2007 at 15:31 -0400: > Steffen DETTMER wrote: > > Ahh, oki. Thanks for the clarificaion. > > > > So in short, flush() MUST be called on OutputStream, this is just > > not documented correctly or so clearly (right?). > No. hum (though now I got it, but...). > Flush can be called to force all current data in java buffer's to be > written to the kernel - NOW. > > A flush() can also *imply* that, besides writing out the > buffer's that java employs, may also imply/ask the kernel to > write all data thusfar written to the kernel, to be physically > placed on the destination device - NOW. > > For some OS's there is no need to do a kernel flush(), as the I/O is > synchronized already. Since this is java, you never know what OS your on. (well, but if you're going to kernel level, even flush cannot guarantee that data will "be physically placed". Maybe you're flushing to a file via NFS (and the client "thinks" that it was written, but maybe it was just buffered by the NFS server) or so... but of course such exceptions of the rules are constructable always.) Well, you tell that depending on the OS it can be that flush is needed or it can be that flush is not needed (beacuse the I/O is synchronized already), right? Also, applications should work on any OS, which includes the OSes that do need flush. Since the application cannot know whether flush is needed or not because it doesn't know what the OS is doing, it has to call flush, hasn't it? I mean, if it would not call flush then it would not work on such OSes (except the written data would not be needed at all, but in this would be an artificial example :)). Since applications are supposed to work this would be wrong, wouldn't it? So would it be correct to say: "Applications, that should work under all OSes (including the OSes where the I/O is not synchronised already), have to call flush on OutputStream to ensure the data is transfered to the kernel." or is this wrong? If so, then I'm afraid I missed the point again :( oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Tue Jun 12 04:46:52 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 12 Jun 2007 06:46:52 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070612081447.GU10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> <20070612081447.GU10821@elberon.bln.de.ingenico.com> Message-ID: <466E799C.7060700@gatworks.com> S > (well, but if you're going to kernel level, even flush cannot > guarantee that data will "be physically placed". Thats true now-a-days because ( from "man 2 sync" ) : > According to the standard specification (e.g., SVID), sync() schedules > the writes, but may return before the actual writing is done. However, > since version 1.3.20 Linux does actually wait. (This still does not > guarantee data integrity: modern disks have large caches.) My disk drive has 8mb cache. Maybe you're > flushing to a file via NFS (and the client "thinks" that it was > written, but maybe it was just buffered by the NFS server) or > so... but of course such exceptions of the rules are > constructable always.) > > Well, you tell that depending on the OS it can be that flush is > needed or it can be that flush is not needed (beacuse the I/O is > synchronized already), right? Also, applications should work on > any OS, which includes the OSes that do need flush. Its not OS's that need flush, its applications that want to have some assurance that data is written to the device that really needs to use flush. If your program ( or thread ) dies then it is in your best interest to write out the critical data as soon as possible, as economical as possible. These are trade-off's that the application programmer makes. A big buffer may mean big loss of data, a small buffer may mean spending too much time writing out data. > > > So would it be correct to say: > > "Applications, that should work under all OSes (including the > OSes where the I/O is not synchronised already), have to call > flush on OutputStream to ensure the data is transfered to the > kernel." > > or is this wrong? If so, then I'm afraid I missed the point again > :( > No that is not wrong. Ensuring that data is transfered to the OS is just about what any application can do. From tjarvi at qbang.org Thu Jun 14 08:16:47 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 14 Jun 2007 08:16:47 -0600 (MDT) Subject: [Rxtx] rxtx and usb-serial solution In-Reply-To: References: Message-ID: On Thu, 14 Jun 2007, Vladimir Kirtchev wrote: > Hi Trent, > > I develop a Java application which communicates with devices which have > USB-to-Serial bridge in them. The target OS is Linux. So for this purpose I > use RXTX. > > But I encountered a strange problem - when reading from the InputStream, I > receive series of zeros. I have this problem under Linux only. Under Windows > it is fine. > Actually this problem is the same as the one described here: > http://marc.info/?l=rxtx&m=109703190731748&w=2. > > > So I searched for the problem in the native code. And found that the root of > the problem is in SerialImp.c, > int configure_port( int fd ) > { > ... > ttyset.c_iflag = INPCK; > ... > } > > This line enables input parity checking, and the data sent from the device > is processed by the OS driver before being read with read(). > In this case the driver detects some problem and sets the received bytes to > zero. > > On the other hand in the Java part a set the serial port parameters with > SerialPort.PARITY_NONE. According to me, except all other things, this > should also disable INPCK in c_iflag. > > So I refactored the method translate_parity(...) to the following: > > int translate_parity( JNIEnv *env, struct termios *ttyset, jint parity ) > { > ENTER( "translate_parity" ); > #ifdef CMSPAR > ttyset->c_cflag &= ~(PARENB | PARODD | CMSPAR ); > #endif /* CMSPAR */ > switch( parity ) { > case JPARITY_NONE: > ttyset->c_iflag &= ~INPCK; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_EVEN: > ttyset->c_cflag |= PARENB; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_ODD: > ttyset->c_cflag |= PARENB | PARODD; > LEAVE( "translate_parity" ); > return 0; > #ifdef CMSPAR > case JPARITY_MARK: > ttyset->c_cflag |= PARENB | PARODD | CMSPAR; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_SPACE: > ttyset->c_cflag |= PARENB | CMSPAR; > LEAVE( "translate_parity" ); > return 0; > #endif /* CMSPAR */ > default: > printf("Parity missed %i\n", (int) parity ); > } > > LEAVE( "translate_parity" ); > /* > For some reason the native exceptions are not being caught. Moving this > to the Java side fixed the issue. taj. > throw_java_exception( env, UNSUPPORTED_COMM_OPERATION, > "", "parity value not supported" ); > */ > return 1; > } > > This modification solved the problem and now it works correctly under Linux. > > I think I will be a nice if this is idea is included in a future release of > RXTX. > > Thanks Vadim, I'll try that out. Forwarding to the rxtx mail-list too. This is probably not going to help USB drivers on windows which I'm sure some are looking for. As far as I can tell, windows USB bluetooth and serial dongles are limited by driver functionality. Some are good and others lack key features. -- Trent Jarvi tjarvi at qbang.org From dan.sandberg.lists at gmail.com Mon Jun 18 14:43:39 2007 From: dan.sandberg.lists at gmail.com (Dan Sandberg) Date: Mon, 18 Jun 2007 13:43:39 -0700 Subject: [Rxtx] Fix for JNI Get/Set Field Errors Message-ID: <4676EE7B.7060800@gmail.com> Hi, I've fixed the problems that cause the following JNI error when extra JNI checking ( -Xjni:check ) is turned on. FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) The problem was basically that GetLong was being used to get ints, and SetInt was used for longs. The patch below fixes this. Please let me know if there are any questions / problems. Cheers, -Dan diff -aur old/SerialImp.c src/SerialImp.c --- old/SerialImp.c 2007-06-18 13:24:33.000000000 -0700 +++ src/SerialImp.c 2007-06-18 06:26:26.000000000 -0700 @@ -1337,7 +1337,7 @@ report("init_threads: get eis\n"); jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); report("init_threads: set eis\n"); - (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); + (*eis->env)->SetLongField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); report("init_threads: stop\n"); report_time_end( ); return( 1 ); @@ -1530,7 +1530,7 @@ jobject jobj, jboolean interrupted ) { int fd = get_java_var( env, jobj,"fd","I" ); - struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var( env, jobj, "eis", "J" ); + struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var_long( env, jobj, "eis", "J" ); int result, count=0; char message[80]; @@ -2939,7 +2939,7 @@ /* TRENT */ int flag, count = 0; struct event_info_struct *eis = ( struct event_info_struct * ) - get_java_var( env, *jobj,"eis","J" ); + get_java_var_long( env, *jobj,"eis","J" ); report_time_start(); flag = eis->eventflags[SPE_DATA_AVAILABLE]; @@ -4873,9 +4873,9 @@ exceptions: none comments: ----------------------------------------------------------*/ -size_t get_java_var( JNIEnv *env, jobject jobj, char *id, char *type ) +long get_java_var_long( JNIEnv *env, jobject jobj, char *id, char *type ) { - int result = 0; + long result = 0; jclass jclazz = (*env)->GetObjectClass( env, jobj ); jfieldID jfd = (*env)->GetFieldID( env, jclazz, id, type ); @@ -4889,7 +4889,11 @@ LEAVE( "get_java_var" ); return result; } - result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); + if ( !strcmp( type, "J" ) ) { + result = (long)( (*env)->GetLongField( env, jobj, jfd ) ); + } else { + result = (int) ( (*env)->GetIntField( env, jobj, jfd ) ); + } /* ct7 & gel * Added DeleteLocalRef */ (*env)->DeleteLocalRef( env, jclazz ); if(!strncmp( "fd",id,2) && result == 0) @@ -4900,6 +4904,10 @@ return result; } +int get_java_var( JNIEnv *env, jobject jobj, char *id, char *type ) { + return (int) get_java_var_long( env, jobj, id, type ); +} + /*---------------------------------------------------------- throw_java_exception diff -aur old/SerialImp.h src/SerialImp.h --- old/SerialImp.h 2007-06-18 13:24:39.000000000 -0700 +++ src/SerialImp.h 2007-06-18 06:23:43.000000000 -0700 @@ -413,7 +413,8 @@ void system_wait(); void finalize_event_info_struct( struct event_info_struct * ); int read_byte_array( JNIEnv *, jobject *, int, unsigned char *, int, int ); -size_t get_java_var( JNIEnv *, jobject, char *, char * ); +int get_java_var( JNIEnv *, jobject, char *, char * ); +long get_java_var_long( JNIEnv *, jobject, char *, char * ); jboolean is_interrupted( struct event_info_struct * ); int send_event(struct event_info_struct *, jint, int ); void dump_termios(char *,struct termios *); From yvespielusenet at free.fr Tue Jun 26 03:41:58 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 11:41:58 +0200 Subject: [Rxtx] [PARALLEL] resource in use Message-ID: <1182850918.3483.10.camel@localhost.localdomain> Hello, So now I want to modify the timeout of the library for parallel port. I have downloaded source code. There is a makefile for migw. SO I have installed mingw on ubuntu and modified the makefile.mingw32 to set it for my system. I have no error but some warnings. The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But When I want to use it the jvm crash :( How can I know what is wrong ? How rxtx windows release has been done ? thanks -- yves piel From yvespielusenet at free.fr Tue Jun 26 07:17:02 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 15:17:02 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182850918.3483.10.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> Message-ID: <1182863822.3483.17.camel@localhost.localdomain> Here is the Makefile I use, the output of the 'make' and the log of the jvm when it crashed : - The Makefile : http://yvespiel.free.fr/rxtx/Makefile - The make output : http://yvespiel.free.fr/rxtx/compile.txt - The crash log : http://yvespiel.free.fr/rxtx/hs_err_pid2100.log I have compiled rxtx under Debian testing with mingw : narma at linimi:/tmp/err$ dpkg -l | grep mingw ii mingw32 3.4.5.20060117.1.dfsg-3 ii mingw32-binutils 2.17.50-20070129.1-1 ii mingw32-runtime 3.12-1 thanks fort help :) Le mardi 26 juin 2007 ? 11:41 +0200, yves pielusenet a ?crit : > Hello, > So now I want to modify the timeout of the library for parallel port. I > have downloaded source code. There is a makefile for migw. SO I have > installed mingw on ubuntu and modified the makefile.mingw32 to set it > for my system. > I have no error but some warnings. > The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But > When I want to use it the jvm crash :( > > How can I know what is wrong ? > > How rxtx windows release has been done ? > > thanks > From yvespielusenet at free.fr Tue Jun 26 07:40:11 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 15:40:11 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182863822.3483.17.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> <1182863822.3483.17.camel@localhost.localdomain> Message-ID: <1182865211.3483.21.camel@localhost.localdomain> I have add the options '--enable-stdcall-fixup' to the 'i586-mingw32msvc-ld' commande. Now I have no warning. But the JVM always crashes :( The output seems more detailled, but I don't understand anything... Here is files : http://yvespiel.free.fr/rxtx/2/ -- yves piel Le mardi 26 juin 2007 ? 15:17 +0200, yves pielusenet a ?crit : > Here is the Makefile I use, the output of the 'make' and the log of the > jvm when it crashed : > > - The Makefile : http://yvespiel.free.fr/rxtx/Makefile > - The make output : http://yvespiel.free.fr/rxtx/compile.txt > - The crash log : http://yvespiel.free.fr/rxtx/hs_err_pid2100.log > > I have compiled rxtx under Debian testing with mingw : > narma at linimi:/tmp/err$ dpkg -l | grep mingw > ii mingw32 3.4.5.20060117.1.dfsg-3 > ii mingw32-binutils 2.17.50-20070129.1-1 > ii mingw32-runtime 3.12-1 > > thanks fort help :) > > > Le mardi 26 juin 2007 ? 11:41 +0200, yves pielusenet a ?crit : > > Hello, > > So now I want to modify the timeout of the library for parallel port. I > > have downloaded source code. There is a makefile for migw. SO I have > > installed mingw on ubuntu and modified the makefile.mingw32 to set it > > for my system. > > I have no error but some warnings. > > The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But > > When I want to use it the jvm crash :( > > > > How can I know what is wrong ? > > > > How rxtx windows release has been done ? > > > > thanks > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From yvespielusenet at free.fr Tue Jun 26 08:27:42 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 16:27:42 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182865211.3483.21.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> <1182863822.3483.17.camel@localhost.localdomain> <1182865211.3483.21.camel@localhost.localdomain> Message-ID: <1182868062.3483.24.camel@localhost.localdomain> I think thant the include files of jdk were not for windows but for linux. So I have copied include/ folder from windows to linux and I modified the Makefile to use those file. It compile fine but the JVM always crash :( http://yvespiel.free.fr/rxtx/3/ Le mardi 26 juin 2007 ? 15:40 +0200, yves pielusenet a ?crit : > I have add the options '--enable-stdcall-fixup' to the > 'i586-mingw32msvc-ld' commande. Now I have no warning. But the JVM > always crashes :( The output seems more detailled, but I don't > understand anything... > Here is files : > http://yvespiel.free.fr/rxtx/2/ > From netbeans at gatworks.com Fri Jun 1 05:38:50 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 07:38:50 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <465F7ADD.1010501@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> Message-ID: <4660054A.2040202@gatworks.com> Manuel Naranjo wrote: In the case of my module, you can > unplug the device but it will not delete the symlink until those apps > that had opened the port has closed it. This is done this way to avoid > kernel panics. What does this mean to user code ? I have tried the alternate route ( other than closing ) which is sleep inbetween the I/O errors ( an unplugged USB device). When the device is plugged back in, The writes to the device still get an I/O error. This would seem to be a lost cause for the application. From netbeans at gatworks.com Fri Jun 1 06:35:48 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 08:35:48 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <465F7ADD.1010501@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> Message-ID: <466012A4.90608@gatworks.com> Manuel Naranjo wrote: In the case of my module, you can > unplug the device but it will not delete the symlink until those apps > that had opened the port has closed it. T Did u also mean for this to happen? USB0 was not closed by application. Apparently USB1 got created when USB device was plugged back in. There is only one USB device on a 4 port USB hub. This also seems to suggest that application recovery to be impossible. > Jun 1 07:10:08 mylaptop kernel: garmin_gps 1-1.4:1.0: Garmin GPS usb/tty converter detected > Jun 1 07:10:08 mylaptop kernel: usb 1-1.4: Garmin GPS usb/tty converter now attached to ttyUSB0 > Jun 1 07:15:17 mylaptop kernel: usb 1-1: USB disconnect, address 4 > Jun 1 07:15:17 mylaptop kernel: usb 1-1.4: USB disconnect, address 5 > Jun 1 07:15:17 mylaptop kernel: garmin_gps 1-1.4:1.0: device disconnected > Jun 1 07:15:26 mylaptop kernel: usb 1-1: new full speed USB device using uhci_hcd and address 6 > Jun 1 07:15:26 mylaptop kernel: hub 1-1:1.0: USB hub found > Jun 1 07:15:26 mylaptop kernel: hub 1-1:1.0: 4 ports detected > Jun 1 07:15:27 mylaptop kernel: usb 1-1.4: new full speed USB device using uhci_hcd and address 7 > Jun 1 07:15:27 mylaptop kernel: garmin_gps 1-1.4:1.0: Garmin GPS usb/tty converter detected > Jun 1 07:15:27 mylaptop kernel: usb 1-1.4: Garmin GPS usb/tty converter now attached to ttyUSB1 From naranjo.manuel at gmail.com Fri Jun 1 09:17:22 2007 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Fri, 01 Jun 2007 12:17:22 -0300 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <466012A4.90608@gatworks.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> <466012A4.90608@gatworks.com> Message-ID: <46603882.5050701@gmail.com> Uncle George escribi?: > Manuel Naranjo wrote: > In the case of my module, you can > >> unplug the device but it will not delete the symlink until those apps >> that had opened the port has closed it. T >> > > Did u also mean for this to happen? USB0 was not closed by application. > > Apparently USB1 got created when USB device was plugged back in. There > is only one USB device on a 4 port USB hub. > > This also seems to suggest that application recovery to be impossible. > Exactly there's a dead symlink (you can read and write to it and nothing will happen) and a new port will be created when a new device is connencted. From netbeans at gatworks.com Fri Jun 1 10:20:46 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 12:20:46 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <46603882.5050701@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> <466012A4.90608@gatworks.com> <46603882.5050701@gmail.com> Message-ID: <4660475E.5090202@gatworks.com> Not sure what u mean by "symlink". U cant read/write to it anymore. U get I/O error. In this scenario the device effectively went dead, and only solution is to close the channel. reconnecting the USB device, although dead, but not closed, will create a second device. This does not seem to be a desirable side-effect. The user will now have ttyUSB1, wondering where did ttyUSB0 go to. The application will also be in a confused state, as well as RXTX, because RXTX wont know about ttyUSB1. Manuel Naranjo wrote: > Uncle George escribi?: >> Manuel Naranjo wrote: >> In the case of my module, you can >> >>> unplug the device but it will not delete the symlink until those apps >>> that had opened the port has closed it. T >>> >> Did u also mean for this to happen? USB0 was not closed by application. >> >> Apparently USB1 got created when USB device was plugged back in. There >> is only one USB device on a 4 port USB hub. >> >> This also seems to suggest that application recovery to be impossible. >> > Exactly there's a dead symlink (you can read and write to it and nothing > will happen) and a new port will be created when a new device is connencted. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From arnab.bhaumik at gmail.com Mon Jun 4 01:40:16 2007 From: arnab.bhaumik at gmail.com (arnab bhaumik) Date: Mon, 4 Jun 2007 13:10:16 +0530 Subject: [Rxtx] full duplex com port with rxtx Message-ID: hi , till now i did half duplex communication with rxtx package on com package. my question is : is it possible to use com port with full duplex mode with rxtx package . ther is example of SimpleRead class and SimpleWrite class. it is clear that if i can use both the class simultaneously then full duplex is possible......... arnab/vu2bpw -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070604/6edb0453/attachment.html From lists at iDIAcomputing.com Mon Jun 4 07:53:17 2007 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Mon, 04 Jun 2007 09:53:17 -0400 Subject: [Rxtx] full duplex com port with rxtx In-Reply-To: References: Message-ID: <4664194D.90301@iDIAcomputing.com> arnab bhaumik wrote: > hi , > > till now i did half duplex communication with rxtx package on com > package. > > my question is : is it possible to use com port with full duplex mode > with rxtx package . > > > ther is example of SimpleRead class and SimpleWrite class. it is > clear that if i can use both the class simultaneously then full duplex > is possible......... I haven't looked at the SimpleRead and SimpleWrite classes (I originally wrote my code for the javax.comm api), but full duplex is certainly possible. My CommReader class requires an object analogous to a OutputStream or Writer. When started, it spawns a thread that reads the comm port and writes to that output device. In this way the input is asynchronous and dependent on the actual input data. For full duplex, I extend that class with CommReaderWriter, which adds synchronous output methods. Hope that helps, George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From supsoop at hotmail.com Mon Jun 4 15:21:06 2007 From: supsoop at hotmail.com (soop soop) Date: Mon, 04 Jun 2007 21:21:06 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- Message-ID: Hi Guys, Looked through the archives but still cannot figure this out. I have a Motorola G24 GPRS/GSM modem that I am connecting to my server running Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not detecting the port, CommPortIdentifier.getPortIdentifiers(). I have added the line to RXTXCommDriver: "ttyACM" // for USB Modems Rxtx still does not seem to find the port. Is there something I am missing to make this port visable? [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control Model driver for USB modems and ISDN adapters I really need your help as I have moved my server from windows to Linux and have been down for a few days because of this .. Thanks so much! _________________________________________________________________ PC Magazine’s 2007 editors’ choice for best Web mail—award-winning Windows Live Hotmail. http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 From tjarvi at qbang.org Mon Jun 4 16:17:35 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Jun 2007 16:17:35 -0600 (MDT) Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: On Mon, 4 Jun 2007, soop soop wrote: > Hi Guys, > > Looked through the archives but still cannot figure this out. I have a > Motorola G24 GPRS/GSM modem that I am connecting to my server running Ubuntu. > I can see my modem as is shows up as ttyACM0, but RXTX is not detecting the > port, CommPortIdentifier.getPortIdentifiers(). > > I have added the line to RXTXCommDriver: > > "ttyACM" // for USB Modems > > Rxtx still does not seem to find the port. Is there something I am missing to > make this port visable? > > [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver > [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device > [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control Model > driver for USB modems and ISDN adapters > > I really need your help as I have moved my server from windows to Linux and > have been down for a few days because of this .. Thanks so much! > You could try the INSTALL documentation that comes with the source for possible solutions. Those usually involve lockfile creation, permissions on the device file or the device is in use by another application (even another session of your application). The usual commands: ls -l /dev/ttyACM0 fuser /dev/ttyACM0 touch /var/lock/LCK.testfile && rm -f /var/lock/LCK.testfile whoami To disable lockfiles: ../configure --disable-lockfiles && make install -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Jun 4 16:22:52 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 04 Jun 2007 18:22:52 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <466490BC.3090801@gatworks.com> soop soop wrote: > I really need your help as I have moved my server from windows to Linux > and have been down for a few days because of this .. Thanks so much! can u open the device ? ie is the file protection/permissions keeping you out? From supsoop at hotmail.com Mon Jun 4 16:44:40 2007 From: supsoop at hotmail.com (soop soop) Date: Mon, 04 Jun 2007 22:44:40 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <466490BC.3090801@gatworks.com> Message-ID: Thanks for the reply, I see no exceptions being thrown, just no detection of the port whats so ever. I will run rxtx in debug mode and log. If this were a permissions issue would I not see some exceptions being thrown? >From: Uncle George >Reply-To: RXTX Developers and Users >To: RXTX Developers and Users >Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >Date: Mon, 04 Jun 2007 18:22:52 -0400 > >soop soop wrote: > > > I really need your help as I have moved my server from windows to Linux > > and have been down for a few days because of this .. Thanks so much! > >can u open the device ? ie is the file protection/permissions keeping >you out? >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ Get a preview of Live Earth, the hottest event this summer - only on MSN http://liveearth.msn.com?source=msntaglineliveearthhm From netbeans at gatworks.com Mon Jun 4 17:06:15 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 04 Jun 2007 19:06:15 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <46649AE7.10405@gatworks.com> Exceptions on what? On startup it wants to lookup all devices in /dev that it is capable of opening ( within the list of specific 'comm' devices ). If it cannot open, then does not get onto list. Part of this process, if configured, will also test if the "LOCK" schema can also be opened for the device. then it gets on the list of avail comm port. soop soop wrote: > Thanks for the reply, > > I see no exceptions being thrown, just no detection of the port whats so > ever. I will run rxtx in debug mode and log. If this were a permissions > issue would I not see some exceptions being thrown? > > >> From: Uncle George >> Reply-To: RXTX Developers and Users >> To: RXTX Developers and Users >> Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >> Date: Mon, 04 Jun 2007 18:22:52 -0400 >> >> soop soop wrote: >> >>> I really need your help as I have moved my server from windows to Linux >>> and have been down for a few days because of this .. Thanks so much! >> can u open the device ? ie is the file protection/permissions keeping >> you out? >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _________________________________________________________________ > Get a preview of Live Earth, the hottest event this summer - only on MSN > http://liveearth.msn.com?source=msntaglineliveearthhm > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From alex.flint at gmail.com Mon Jun 4 21:31:49 2007 From: alex.flint at gmail.com (Alex Flint) Date: Tue, 5 Jun 2007 13:01:49 +0930 Subject: [Rxtx] random EXCEPTION_ACCESS_VIOLATION errors Message-ID: Hi All, I'm running winXP and RXTX 2.1-7r2 (the latest from the webpage as of June 2007). I'm sending sequences of 64 lines (each line has about 15 chars) at various intervals. The strings are sent fine, until I get the following error (from hs_err_pid3316.log, at the end of this email). What can I do to avoid the error? Obviously this is a low-level memory exception, but is there any way I can keep the JVM running after such an error? I noticed the exact same problem here: http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20070129/1180520.html Cheers, Alex # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x100034fb, pid=3316, tid=2400 # # Java VM: Java HotSpot(TM) Client VM (1.6.0_01-b06 mixed mode, sharing) # Problematic frame: # C [rxtxSerial.dll+0x34fb] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # --------------- T H R E A D --------------- Current thread (0x00386400): JavaThread "main" [_thread_in_native, id=2400] siginfo: ExceptionCode=0xc0000005, reading address 0x20726f78 Registers: EAX=0x20726f20, EBX=0x6d8922c0, ECX=0x00000005, EDX=0x20726f20 ESP=0x003efa30, EBP=0x003efb68, ESI=0x269728a0, EDI=0x00386400 EIP=0x100034fb, EFLAGS=0x00010212 Top of Stack: (sp=0x003efa30) 0x003efa30: 003efa3c 003efa64 0000000f ffffffff 0x003efa40: 003efa40 2a97f808 003efa6c 2b190ca8 0x003efa50: 00000000 2b190ec0 003efa90 008e2dd7 0x003efa60: 003efa90 008e2dd7 26977f88 6d815e72 0x003efa70: 00000004 2696eae0 0000008a 003efb0c 0x003efa80: 6d852b4a 2696eae0 00000003 26970930 0x003efa90: 000000cb 2696eae0 6d86b264 00385d40 0x003efaa0: 0000003f 003efb0c 26977f90 2ace65d8 Instructions: (pc=0x100034fb) 0x100034eb: ff ff 8d 76 00 eb 02 89 f6 90 8b 45 f8 8b 55 f8 0x100034fb: 8b 4a 58 83 c9 04 89 48 58 83 c4 f8 8b 45 f8 8b Stack: [0x003a0000,0x003f0000), sp=0x003efa30, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x34fb] Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j gnu.io.RXTXPort.writeArray([BIIZ)V+0 j gnu.io.RXTXPort$SerialOutputStream.write([B)V+76 j com.bjt.media.server.CommLink.send(Ljava/lang/String;)V+48 j com.bjt.media.server.DigitoolConnection.select(I)V+73 j com.bjt.media.server.DigitoolConnection.main([Ljava/lang/String;)V+74 v ~StubRoutines::call_stub --------------- P R O C E S S --------------- Java Threads: ( => current thread ) 0x02a69400 JavaThread "Thread-0" [_thread_in_native, id=3052] 0x02a4d000 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=3920] 0x02a48400 JavaThread "CompilerThread0" daemon [_thread_blocked, id=1968] 0x02a47400 JavaThread "Attach Listener" daemon [_thread_blocked, id=2984] 0x02a46400 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=2660] 0x02a41c00 JavaThread "Finalizer" daemon [_thread_blocked, id=3924] 0x02a3d800 JavaThread "Reference Handler" daemon [_thread_blocked, id=4008] =>0x00386400 JavaThread "main" [_thread_in_native, id=2400] Other Threads: 0x02a34400 VMThread [id=3708] 0x02a4e800 WatcherThread [id=3964] VM state:not at safepoint (normal execution) VM Mutex/Monitor currently owned by a thread: None Heap def new generation total 960K, used 131K [0x22960000, 0x22a60000, 0x22e40000) eden space 896K, 7% used [0x22960000, 0x22970ea8, 0x22a40000) from space 64K, 99% used [0x22a50000, 0x22a5fff8, 0x22a60000) to space 64K, 0% used [0x22a40000, 0x22a40000, 0x22a50000) tenured generation total 4096K, used 76K [0x22e40000, 0x23240000, 0x26960000) the space 4096K, 1% used [0x22e40000, 0x22e53060, 0x22e53200, 0x23240000) compacting perm gen total 12288K, used 137K [0x26960000, 0x27560000, 0x2a960000) the space 12288K, 1% used [0x26960000, 0x26982518, 0x26982600, 0x27560000) ro space 8192K, 62% used [0x2a960000, 0x2ae5e4e8, 0x2ae5e600, 0x2b160000) rw space 12288K, 52% used [0x2b160000, 0x2b7a0e78, 0x2b7a1000, 0x2bd60000) Dynamic libraries: 0x00400000 - 0x00423000 C:\Program Files\Java\jre1.6.0_01\bin\javaw.exe 0x7c900000 - 0x7c9b0000 C:\WINDOWS\system32\ntdll.dll 0x7c800000 - 0x7c8f4000 C:\WINDOWS\system32\kernel32.dll 0x77dd0000 - 0x77e6b000 C:\WINDOWS\system32\ADVAPI32.dll 0x77e70000 - 0x77f01000 C:\WINDOWS\system32\RPCRT4.dll 0x7e410000 - 0x7e4a0000 C:\WINDOWS\system32\USER32.dll 0x77f10000 - 0x77f57000 C:\WINDOWS\system32\GDI32.dll 0x76390000 - 0x763ad000 C:\WINDOWS\system32\IMM32.DLL 0x7c340000 - 0x7c396000 C:\Program Files\Java\jre1.6.0_01\bin\msvcr71.dll 0x6d7c0000 - 0x6da07000 C:\Program Files\Java\jre1.6.0_01\bin\client\jvm.dll 0x76b40000 - 0x76b6d000 C:\WINDOWS\system32\WINMM.dll 0x5cd70000 - 0x5cd77000 C:\WINDOWS\system32\serwvdrv.dll 0x5b0a0000 - 0x5b0a7000 C:\WINDOWS\system32\umdmxfrm.dll 0x6d310000 - 0x6d318000 C:\Program Files\Java\jre1.6.0_01\bin\hpi.dll 0x76bf0000 - 0x76bfb000 C:\WINDOWS\system32\PSAPI.DLL 0x6d770000 - 0x6d77c000 C:\Program Files\Java\jre1.6.0_01\bin\verify.dll 0x6d3b0000 - 0x6d3cf000 C:\Program Files\Java\jre1.6.0_01\bin\java.dll 0x6d7b0000 - 0x6d7bf000 C:\Program Files\Java\jre1.6.0_01\bin\zip.dll 0x10000000 - 0x10012000 C:\Documents and Settings\Alex\workspace\MediaServer\rxtxSerial.dll 0x73d90000 - 0x73db7000 C:\WINDOWS\system32\crtdll.dll VM Arguments: jvm_args: -Djava.library.path=C:\Documents and Settings\Alex\workspace\MediaServer java_command: com.bjt.media.server.DigitoolConnection Launcher Type: SUN_STANDARD Environment Variables: CLASSPATH=.;C:\Program Files\Java\j2re1.4.2_07\lib\ext\QTJava.zip PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\wbem;c:\applications\php;C:\Program Files\MATLAB\R2006a\bin\win32;C:\Roger\Projects\UAV\Bin\Debug;C:\Program Files\Microsoft SQL Server\80\Tools\Binn\;c:\Program Files\Microsoft SQL Server\90\Tools\binn\;C:\Program Files\QuickTime\QTSystem\;C:\Pfps\system;C:\Program Files\Java\jdk1.6.0_01\bin;C:\Program Files\Java\jdk1.6.0_01\jre\bin USERNAME=Alex OS=Windows_NT PROCESSOR_IDENTIFIER=x86 Family 15 Model 4 Stepping 1, GenuineIntel --------------- S Y S T E M --------------- OS: Windows XP Build 2600 Service Pack 2 CPU:total 1 family 15, cmov, cx8, fxsr, mmx, sse, sse2 Memory: 4k page, physical 1046508k(275288k free), swap 2522816k(1909176k free) vm_info: Java HotSpot(TM) Client VM (1.6.0_01-b06) for windows-x86, built on Mar 14 2007 00:24:02 by "java_re" with unknown MS VC++:1310 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070604/c87ae1f0/attachment.html From alwyn.schoeman at gmail.com Tue Jun 5 00:10:19 2007 From: alwyn.schoeman at gmail.com (Alwyn Schoeman) Date: Tue, 5 Jun 2007 08:10:19 +0200 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Hi, I'm using a similar modem. By default rxtx doesn't look for devices that start with ACM, so you need to modify the source code and recompile. Look in RXTXCommDriver and add values for ACM in the registerScannedPorts method in the Linux specific parts. Look for osName.equals("Linux")... On 6/4/07, soop soop wrote: > > Hi Guys, > > Looked through the archives but still cannot figure this out. I have a > Motorola G24 GPRS/GSM modem that I am connecting to my server running > Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not > detecting the port, CommPortIdentifier.getPortIdentifiers(). > > I have added the line to RXTXCommDriver: > > "ttyACM" // for USB Modems > > Rxtx still does not seem to find the port. Is there something I am missing > to make this port visable? > > [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver > [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device > [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control > Model > driver for USB modems and ISDN adapters > > I really need your help as I have moved my server from windows to Linux > and > have been down for a few days because of this .. Thanks so much! > > _________________________________________________________________ > PC Magazine's 2007 editors' choice for best Web mail?award-winning Windows > Live Hotmail. > > http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -- Alwyn Schoeman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/b6cb3053/attachment.html From naranjo.manuel at gmail.com Tue Jun 5 06:48:45 2007 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Tue, 05 Jun 2007 09:48:45 -0300 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> References: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Message-ID: <46655BAD.7010501@gmail.com> That's right, an easier solution is creating symlinks to acm. For example make ttyS70 to 79 point to ACM0 to 9 and that will help you a lot, and doesn't even require compile. > Hi, > > I'm using a similar modem. By default rxtx doesn't look for devices > that start with ACM, so you need to modify the > source code and recompile. > > Look in RXTXCommDriver and add values for ACM in the > registerScannedPorts method in the Linux specific parts. Look for > osName.equals("Linux")... > From juanemc2 at gmail.com Tue Jun 5 07:02:43 2007 From: juanemc2 at gmail.com (Juan) Date: Tue, 5 Jun 2007 10:02:43 -0300 Subject: [Rxtx] Problems with Epson TMU220B POSPrinter using XON/XOFF Flow Control and rxtx jar and dll's with the serial port. Message-ID: Hi!, I?m having trouble printing to the serial port using the latest version of rxtx jar and dll's with an Epson POSPrinter. I`ve switched the printer to work with XON/XOFF Flow Control and have watched the serial port to be sure the printer is sending the XON XOFF stop and go characters. I`ve setted the port like this: CommPortIdentifier commPortIdentifier = CommPortIdentifier.* getPortIdentifier*(_portName); SerialPort serialPort = (SerialPort)commPortIdentifier.open(*this*.getClass().getName(), 2000); serialPort.setSerialPortParams(_baudRate, _dataBits, _stopBits, _parity); serialPort.setFlowControlMode( SerialPort.*FLOWCONTROL_XONXOFF_IN* | SerialPort.*FLOWCONTROL_XONXOFF_OUT*); where the baudRate is 9600 the dataBits is 8 the stopBits is 1 and the parity is 0 It seems as the library isn`t taking into account the XON XOFF setting. I would like to know if I`m setting correctly the Flow Control and if you had had any experiences using XON XOFF flow control and could give me some help to solve my problem. I`m very thankful in advance, Yours, Juan Polero -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/b080995a/attachment.html From ehdez.correo at gmail.com Tue Jun 5 07:12:53 2007 From: ehdez.correo at gmail.com (=?ISO-8859-1?Q?Enrique_Hern=E1ndez?=) Date: Tue, 5 Jun 2007 09:12:53 -0400 Subject: [Rxtx] problem with rxtx Message-ID: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Hello: I doing a simple test to show the serial ports. This is the code: import java.util.Enumeration; import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; public class Show { private Enumeration portList; private CommPortIdentifier portId; private SerialPort port; /** Creates a new instance of Show */ public Show() { } public static void main(String args[]){ Show show = new Show(); show.portList = CommPortIdentifier.getPortIdentifiers(); String tPort = ""; System.out.println("========================================="); while(show.portList.hasMoreElements()){ show.portId = (CommPortIdentifier)show.portList.nextElement(); if(show.portId.getPortType() == CommPortIdentifier.PORT_SERIAL) tPort = "Serial"; else tPort = "Parallel"; System.out.println(show.portId.getName() + " " + tPort); } } } whit The problem is that this code not show the serial ports, this show the no use serial ports. I want to connect whit the modem but when windows open and connect the modem my application don't see the port(COMM3) when it is connect. what I can do? Is that the correct way to know the ports? thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/eedd744b/attachment.html From ehdez.correo at gmail.com Tue Jun 5 07:42:13 2007 From: ehdez.correo at gmail.com (=?ISO-8859-1?Q?Enrique_Hern=E1ndez?=) Date: Tue, 5 Jun 2007 09:42:13 -0400 Subject: [Rxtx] serial port Message-ID: <4a814e1f0706050642p4ce9ac7bka80f9479c524c5ea@mail.gmail.com> Hello: How I can ask to the port what device is connect and information about this device. thanks. bye. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/4d10d26a/attachment.html From supsoop at hotmail.com Tue Jun 5 09:29:00 2007 From: supsoop at hotmail.com (soop soop) Date: Tue, 05 Jun 2007 15:29:00 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Message-ID: Hi Guys, Thanks for all your help. I found the problem. I created a user, Tomcat55, for my tomcat but it did not belong to any group. I then added this user to dialout group to have access to the device ttyACM0. Works perfectly! Again permissions was the issue. This also seems to be persistent as a server reboot does not effect the access. Cheers! >From: "Alwyn Schoeman" >Reply-To: RXTX Developers and Users >To: "RXTX Developers and Users" >Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >Date: Tue, 5 Jun 2007 08:10:19 +0200 > >Hi, > >I'm using a similar modem. By default rxtx doesn't look for devices that >start with ACM, so you need to modify the >source code and recompile. > >Look in RXTXCommDriver and add values for ACM in the registerScannedPorts >method in the Linux specific parts. Look for osName.equals("Linux")... > >On 6/4/07, soop soop wrote: >> >>Hi Guys, >> >>Looked through the archives but still cannot figure this out. I have a >>Motorola G24 GPRS/GSM modem that I am connecting to my server running >>Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not >>detecting the port, CommPortIdentifier.getPortIdentifiers(). >> >>I have added the line to RXTXCommDriver: >> >>"ttyACM" // for USB Modems >> >>Rxtx still does not seem to find the port. Is there something I am missing >>to make this port visable? >> >>[ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver >>[ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device >>[ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control >>Model >>driver for USB modems and ISDN adapters >> >>I really need your help as I have moved my server from windows to Linux >>and >>have been down for a few days because of this .. Thanks so much! >> >>_________________________________________________________________ >>PC Magazine's 2007 editors' choice for best Web mail—award-winning Windows >>Live Hotmail. >> >>http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 >> >> >>_______________________________________________ >>Rxtx mailing list >>Rxtx at qbang.org >>http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > >-- >Alwyn Schoeman >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ Need a break? Find your escape route with Live Search Maps. http://maps.live.com/default.aspx?ss=Restaurants~Hotels~Amusement%20Park&cp=33.832922~-117.915659&style=r&lvl=13&tilt=-90&dir=0&alt=-1000&scene=1118863&encType=1&FORM=MGAC01 From netbeans at gatworks.com Tue Jun 5 09:42:31 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 11:42:31 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <46658467.20101@gatworks.com> soop soop wrote: > > Hi Guys, > > Thanks for all your help. I found the problem. I created a user, > Tomcat55, for my tomcat but it did not belong to any group. I then added Look at man pages for the program udev. From tjarvi at qbang.org Tue Jun 5 18:18:17 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Jun 2007 18:18:17 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Message-ID: On Tue, 5 Jun 2007, Enrique Hern?ndez wrote: > The problem is that this code not show the serial ports, this show the no > use serial ports. I want to connect whit the modem but when windows open and > connect the modem my application don't see the port(COMM3) when it is > connect. > what I can do? > Is that the correct way to know the ports? > Hello, We may have problems understanding each other. On windows, the port will not be an available serial port if another application has the port open. That is just how the library behaves. If you can not see the port in the enumerated list, you could not open it. Also note that enumeration only happens once. If you add a port such as a new USB dongle, the port will not be visible until the next time your application runs. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Tue Jun 5 18:45:01 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 20:45:01 -0400 Subject: [Rxtx] problem with rxtx In-Reply-To: References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Message-ID: <4666038D.8090700@gatworks.com> Trent Jarvi wrote: > > > Also note that enumeration only happens once. If you add a port such as > a new USB dongle, the port will not be visible until the next time your > application runs. Is this written in stone ? somewhere? From tjarvi at qbang.org Tue Jun 5 18:54:36 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Jun 2007 18:54:36 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <4666038D.8090700@gatworks.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> Message-ID: On Tue, 5 Jun 2007, Uncle George wrote: > Trent Jarvi wrote: >> >> >> Also note that enumeration only happens once. If you add a port such as >> a new USB dongle, the port will not be visible until the next time your >> application runs. > > Is this written in stone ? somewhere? It is just the current behavior. There is nothing preventing a fix that allows reenumeration. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Tue Jun 5 19:55:19 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 21:55:19 -0400 Subject: [Rxtx] problem with rxtx In-Reply-To: References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> Message-ID: <46661407.4020308@gatworks.com> >> Is this written in stone ? somewhere? > > It is just the current behavior. There is nothing preventing a fix that > allows reenumeration. With usb, ..... , things come and go. Seems a shame that you have to kill application to get at the device u just plugged in. From joachim at buechse.ch Wed Jun 6 01:50:06 2007 From: joachim at buechse.ch (Joachim Buechse) Date: Wed, 6 Jun 2007 09:50:06 +0200 Subject: [Rxtx] problem with rxtx In-Reply-To: <46661407.4020308@gatworks.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> <46661407.4020308@gatworks.com> Message-ID: <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> On MacOS RXTX's enumeration handling is more flexible. It will find new ports that are added during the lifetime of the application. But this is inherently incompatible with suns javax.comm implementation... Regards, Joachim On 06.06.2007, at 03:55, Uncle George wrote: > >>> Is this written in stone ? somewhere? >> >> It is just the current behavior. There is nothing preventing a >> fix that >> allows reenumeration. > > With usb, ..... , things come and go. Seems a shame that you have to > kill application to get at the device u just plugged in. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Jun 6 06:06:48 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Jun 2007 06:06:48 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> <46661407.4020308@gatworks.com> <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> Message-ID: Sun's javax.comm is not a major concern going forward. As long as we do not break old applications using rxtx, I see no reason to limit rxtx to that convention. We have already rejected version 3 from Sun as a dead end and limited our compatability to version 2. That does not mean we will not try to work with Sun and others but the current javax.comm convention (v3) is not a well conceived path. There has been discussion about doing a JSR which is one valid option. On Wed, 6 Jun 2007, Joachim Buechse wrote: > On MacOS RXTX's enumeration handling is more flexible. It will find > new ports that are added during the lifetime of the application. But > this is inherently incompatible with suns javax.comm implementation... > > Regards, > Joachim > > On 06.06.2007, at 03:55, Uncle George wrote: > >> >>>> Is this written in stone ? somewhere? >>> >>> It is just the current behavior. There is nothing preventing a >>> fix that >>> allows reenumeration. >> >> With usb, ..... , things come and go. Seems a shame that you have to >> kill application to get at the device u just plugged in. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From yvespielusenet at free.fr Wed Jun 6 08:46:35 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 16:46:35 +0200 Subject: [Rxtx] [PARALLEL] resource in use Message-ID: <1181141195.3407.20.camel@localhost.localdomain> Hello, I want to use rxtx in my application. I haveto send data to a very old printer (which have a drum and hammers http://perso.orange.fr/tiie/page00010017.html) This is printer is connecter with centronics. It works well but, while it's writting and I putthe printer off-line, after about 45 seconds, I have this error : ------------------------------------- java.io.IOException: La ressource demand?e est en cours d'utilisation. in writeArray at gnu.io.LPRPort.writeArray(Native Method) at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:292) at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:161) at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:156) at mce.buffer.bufferManager.BufferManager$PrintBuffer.run(BufferManager.java:141) The IOexception means "The wanted resource is in use" ------------------------------------- Here is the line 141 of BufferManager : ------------------------------------- while(send){ try{ fos.write(bb); <=== line 141 send = false; } catch(Exception e){ javax.swing.JOptionPane.showMessageDialog(null, "Erreur d'envoie. Veuillez cliquer sur OK pour relancer l'impression de la vignette.\nV?rifiez votre impression !", "Erreur d'envoie", javax.swing.JOptionPane.WARNING_MESSAGE); e.printStackTrace(System.err); System.err.flush(); System.out.println(e); send = true; } } -------------------------------- 'fos' is an outputstream which contains the rxtx stream (this.os is the rxtx outputstream) : -------------------------------- public void write(byte[] bb) throws IOException{ this.write(bb, 0, bb.length); } public void write(byte[] bb, int off, int len) throws IOException{ while(!imp1.isPrinterSelected() || !imp2.isPrinterSelected()){ } this.os.write(bb, off, len); } -------------------------------- Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( can you help me ? thank you :) -- yves piel From yvespielusenet at free.fr Wed Jun 6 09:11:15 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 17:11:15 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181141195.3407.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> Message-ID: <1181142675.3407.23.camel@localhost.localdomain> I forgot to tell that It's under windows XP and java 1.5. Le mercredi 06 juin 2007 ? 16:46 +0200, yves pielusenet a ?crit : > Hello, > I want to use rxtx in my application. I haveto send data to a very old > printer (which have a drum and hammers > http://perso.orange.fr/tiie/page00010017.html) > This is printer is connecter with centronics. It works well but, while > it's writting and I putthe printer off-line, after about 45 seconds, I > have this error : > ------------------------------------- > java.io.IOException: La ressource demand?e est en cours d'utilisation. > in writeArray > at gnu.io.LPRPort.writeArray(Native Method) > at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:292) > at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:161) > at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:156) > at mce.buffer.bufferManager.BufferManager$PrintBuffer.run(BufferManager.java:141) > > The IOexception means "The wanted resource is in use" > ------------------------------------- > > Here is the line 141 of BufferManager : > > ------------------------------------- > while(send){ > try{ > fos.write(bb); <=== line 141 > send = false; > } > catch(Exception e){ > javax.swing.JOptionPane.showMessageDialog(null, "Erreur d'envoie. Veuillez cliquer sur OK pour relancer l'impression de la vignette.\nV?rifiez votre impression !", "Erreur d'envoie", javax.swing.JOptionPane.WARNING_MESSAGE); > e.printStackTrace(System.err); > System.err.flush(); > System.out.println(e); > send = true; > } > } > -------------------------------- > 'fos' is an outputstream which contains the rxtx stream (this.os is the rxtx outputstream) : > > -------------------------------- > public void write(byte[] bb) throws IOException{ > this.write(bb, 0, bb.length); > } > public void write(byte[] bb, int off, int len) throws IOException{ > while(!imp1.isPrinterSelected() || !imp2.isPrinterSelected()){ > } > this.os.write(bb, off, len); > } > -------------------------------- > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > can you help me ? > > thank you :) > From netbeans at gatworks.com Wed Jun 6 09:21:46 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 11:21:46 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181141195.3407.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> Message-ID: <4666D10A.8000507@gatworks.com> } > -------------------------------- > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > can you help me ? > > thank you :) > windoz or linux? ( I guess windoz ) for windoz, there appears to be a timeout ( as Comments suggest ) of about 40seconds. > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } for linux, there is no implied timeout. > if( write( fd, bytes, count ) < 0 ) > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); From netbeans at gatworks.com Wed Jun 6 09:39:41 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 11:39:41 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666D10A.8000507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> Message-ID: <4666D53D.90000@gatworks.com> Uncle George wrote: > } >> -------------------------------- >> >> Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( >> >> can you help me ? From reading the code, I can see your concern. And it appears you are correct, because some of the data will be sent to the OS printer buffers, and then it will refuse to accept anymore. Unfortunately, writeArray does not return the num of characters written :{ So application has no idea to how many characters were accepted by the OS. I dont do windoz, so I cant say with absolute certainty what windoz will do with an off-line condition. If you have the source, and can compile, then maybe u can increase the loop count to hit 4hours? From yvespielusenet at free.fr Wed Jun 6 09:53:25 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 17:53:25 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666D10A.8000507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> Message-ID: <1181145205.3407.35.camel@localhost.localdomain> Thank you for your explanation :) This timeout comes when no data has been send to the printer after 40seconds if I well understand. But why there is such a timeout ? If I setthe printer offline while it's printing I mustn't have an exception. I don't understand why the "printer should solv all problems like buffer full" in 40 seconds. If I pause the printer the buffer will not be emptied, isn't it ? I not very familiar with C/C++, but it seem that the exception is thrown only when countWritten == 0, that means no data at all has been sent. So Is my code is good since when I intercept this exception I send all my buffer again. There is no way that the printer receive two times same bytes ? thanks ps: yes the application is running on windows XP since I developpe under Debian Le mercredi 06 juin 2007 ? 11:21 -0400, Uncle George a ?crit : > } > > -------------------------------- > > > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > > > can you help me ? > > > > thank you :) > > > > windoz or linux? ( I guess windoz ) > > for windoz, there appears to be a timeout ( as Comments suggest ) of > about 40seconds. > > while( count > 0 ){ > > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > > /* > > this are 20 * 2 seconds, in this time a printer (or other parallel device) > > should solv all problems like buffer full, etc > > */ > > if(errorCount++ < 20){ > > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > > continue; > > } > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > for linux, there is no implied timeout. > > if( write( fd, bytes, count ) < 0 ) > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Wed Jun 6 10:34:24 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 12:34:24 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181145205.3407.35.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> Message-ID: <4666E210.30507@gatworks.com> yves pielusenet wrote: > Thank you for your explanation :) > This timeout comes when no data has been send to the printer after > 40seconds if I well understand. But why there is such a timeout ? If I > setthe printer offline while it's printing I mustn't have an exception. > I don't understand why the "printer should solv all problems like buffer > full" in 40 seconds. If I pause the printer the buffer will not be > emptied, isn't it ? > > I not very familiar with C/C++, but it seem that the exception is thrown > only when countWritten == 0, that means no data at all has been sent. So > Is my code is good since when I intercept this exception I send all my > buffer again. There is no way that the printer receive two times same > bytes ? More technically, the function call returns and reports that 0 characters was written in this call. when 0 characters are written, it will check how many times 0 characters was written. If it has tried LESS than 20 times(errorCount), it will sleep() and try to write again. After 20 times, it wont sleep, but throw you the exception. Now suppose you are writing a 120 character line. you off-lined/paused your printer. The OS has room for 80 more characters in it's printer buffer. The WriteFile() will have a char count of 120, but on return the countWritten = 80. You still have 40 more characters to print. Since countWritten != 0, the counters: bytes += countWritten; count -= countWritten; get updated, and the Writefile now has a count of 40 characters. Since the printer is off-line, the countwritten is 0. And so the loop continues, till 40 seconds is up. As to why it is this way, i dont know ( not a windoz maven ); Also the sleep(20) in the loop is not so intuitive to suggest 2 seconds of sleep. I would have guessed 20seconds, or 20milliseconds. But go figure. BTW: Since your computer sends you error messages in French, does it curse in English? :)))) From yvespielusenet at free.fr Thu Jun 7 02:27:44 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Thu, 07 Jun 2007 10:27:44 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666E210.30507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> Message-ID: <1181204864.3501.10.camel@localhost.localdomain> Maybe in my case I should re-compile rxtx and change the code. Instead of send an exception I should display a dialog box to ask if it's printer problem or if it should trie to send bytes. Something like : while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } if(displayDialogBox("Try again to send datas ??")){ errorCount = 0; } else{ throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } } Le mercredi 06 juin 2007 ? 12:34 -0400, Uncle George a ?crit : > yves pielusenet wrote: > > Thank you for your explanation :) > > This timeout comes when no data has been send to the printer after > > 40seconds if I well understand. But why there is such a timeout ? If I > > setthe printer offline while it's printing I mustn't have an exception. > > I don't understand why the "printer should solv all problems like buffer > > full" in 40 seconds. If I pause the printer the buffer will not be > > emptied, isn't it ? > > > > I not very familiar with C/C++, but it seem that the exception is thrown > > only when countWritten == 0, that means no data at all has been sent. So > > Is my code is good since when I intercept this exception I send all my > > buffer again. There is no way that the printer receive two times same > > bytes ? > More technically, the function call returns and reports that 0 > characters was written in this call. > when 0 characters are written, it will check how many times 0 characters > was written. If it has tried LESS than 20 times(errorCount), it will > sleep() and try to write again. > After 20 times, it wont sleep, but throw you the exception. > > Now suppose you are writing a 120 character line. you off-lined/paused > your printer. The OS has room for 80 more characters in it's printer > buffer. The WriteFile() will have a char count of 120, but on return the > countWritten = 80. You still have 40 more characters to print. > Since countWritten != 0, the counters: > bytes += countWritten; > count -= countWritten; > get updated, and the Writefile now has a count of 40 characters. Since > the printer is off-line, the countwritten is 0. And so the loop > continues, till 40 seconds is up. > > As to why it is this way, i dont know ( not a windoz maven ); > Also the sleep(20) in the loop is not so intuitive to suggest 2 seconds > of sleep. I would have guessed 20seconds, or 20milliseconds. But go figure. > > BTW: Since your computer sends you error messages in French, does it > curse in English? :)))) > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 06:11:43 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 08:11:43 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181204864.3501.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> Message-ID: <4667F5FF.8070903@gatworks.com> your suggestion appears good. I dont know what displayDialogBox exactly will do, so all I can say it that it looks good. But I'd like to wait 10min before first dialog box And a 5 min wait for every dialog box there after. And since these are custom solution/choices, maybe a more exact explanation of what the issue is. if(errorCount++ < 300){ // wait 10min ( 10min * 60sec / 2 ) Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } if(displayDialogBox("Printer has Paused. Retry sending data?")){ errorCount = 150; // Wait for 5 min thereafter continue; } > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } yves pielusenet wrote: > Maybe in my case I should re-compile rxtx and change the code. Instead > of send an exception I should display a dialog box to ask if it's > printer problem or if it should trie to send bytes. Something like : > > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > > if(displayDialogBox("Try again to send datas ??")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > } > From yvespielusenet at free.fr Thu Jun 7 07:17:21 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Thu, 07 Jun 2007 15:17:21 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4667F5FF.8070903@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <4667F5FF.8070903@gatworks.com> Message-ID: <1181222241.3501.20.camel@localhost.localdomain> thank you :) 'displayDialogBox()' I think doesn't exist. It was just for the example :) But I think It should not be so complicated to display a dialog box under windows with YES/NO buttons. When yes is clicked it return 0 other it returns 1. Le jeudi 07 juin 2007 ? 08:11 -0400, Uncle George a ?crit : > your suggestion appears good. I dont know what displayDialogBox exactly > will do, so all I can say it that it looks good. > > But I'd like to wait 10min before first dialog box And a 5 min wait for > every dialog box there after. And since these are custom > solution/choices, maybe a more exact explanation of what the issue is. > > if(errorCount++ < 300){ // wait 10min ( 10min * 60sec / 2 ) > Sleep( 20 ); /* make a small pause to execute all other requests > in all other threads */ > continue; > } > > if(displayDialogBox("Printer has Paused. Retry sending data?")){ > errorCount = 150; // Wait for 5 min thereafter > continue; > } > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > > yves pielusenet wrote: > > Maybe in my case I should re-compile rxtx and change the code. Instead > > of send an exception I should display a dialog box to ask if it's > > printer problem or if it should trie to send bytes. Something like : > > > > while( count > 0 ){ > > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > > /* > > this are 20 * 2 seconds, in this time a printer (or other parallel device) > > should solv all problems like buffer full, etc > > */ > > if(errorCount++ < 20){ > > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > > continue; > > } > > > > if(displayDialogBox("Try again to send datas ??")){ > > errorCount = 0; > > } > > else{ > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > } > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 07:41:43 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 09:41:43 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181222241.3501.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <4667F5FF.8070903@gatworks.com> <1181222241.3501.20.camel@localhost.localdomain> Message-ID: <46680B17.8050109@gatworks.com> yves pielusenet wrote: > thank you :) > 'displayDialogBox()' I think doesn't exist. It was just for the > example :) too bad. Good luck. From rtrout at webbresearch.com Thu Jun 7 11:23:04 2007 From: rtrout at webbresearch.com (Robert Trout) Date: Thu, 07 Jun 2007 13:23:04 -0400 Subject: [Rxtx] Disconnected PortServer TS causes Java to hang Message-ID: <1181236984.14186.33.camel@sisyphus.DinkumSoftware.com> I'm running Linux with sun's Java 1.4.2, Java comm API 2.0, RXTX 2.0-7pre1, and the RealPort digi driver. "/dev/ttyrp00" is a RealPort device. My Java application never returns from a ComPortIdentifier.getPortIdentifier("/dev/ttyrp00") call while the Digi PortServer TS 4 is disconnected from the network. If I later re-connect the PortServer, the call returns about 30 seconds later (it's like a serial port read or write is blocking until the PortServer is re- connected). With the PortServer disconnected, minicom immediately responds with "cannot open /dev/ttyrp00: No such file or directory". I would like my Java application to behave similarly. That is, respond with an error condition instead of hanging when the PortServer is not connected. Since minicom and Java behave differently, I think this "hanging" behavior may be due to RXTX or Java? Has anyone had a similar issue? Solutions? Suggestions? Thanks, Robert From vicnevicne at gmail.com Thu Jun 7 12:16:02 2007 From: vicnevicne at gmail.com (Vicne) Date: Thu, 07 Jun 2007 20:16:02 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181204864.3501.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> Message-ID: <46684B62.7080802@gmail.com> yves pielusenet wrote: > Maybe in my case I should re-compile rxtx and change the code. Instead > of send an exception I should display a dialog box to ask if it's > printer problem or if it should trie to send bytes. Something like : > > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > > if(displayDialogBox("Try again to send datas ??")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > } > Sorry to step in without a specific solution to your problem, but I wanted to share my feeling regarding this proposal. AFAIK, it's generally considered bad practice to pop-up a prompt from a library. The main reason is that in general use, you can't guarantee that someone is actually present behind the console. Imagine a print server in a machine room, connected to a park of printers. In that case, when one printer fails, the logical behaviour would be to use an other one. If you change RxTx the way you propose, the printer queue will simply be stuck with a useless "Try again to send data ?" prompt until an administrator opens a remote connection to the print server's console and clicks "no". Second, it would create a dependency upon the existence of a graphical console (if you go the graphical "dialogBox" way). On many applications (typically server or embedded ones), the JVM is "headless" and if you try to pop-up a dialog, your app would throw an exception (at best) or just wouldn't display the prompt anywhere... Going the "text console" way is not more reliable, because on graphical environments, the text console is hidden unless explicitly requested. My advice would be to think again and find another solution. Ideas are : - make the number of retries a parameter so that you can tune it to what you think is reasonable - throw a more specific exception when the number of retries has been reached, so that a specific prompt can be shown at a higher level Anyway, if you feel that the prompt is the way to go in your case, I would at least make that prompt conditional. The least intrusive way would probably be using a system property, like if("true".equals(System.getProperty("org.rxtx.usePrompt")) && displayDialogBox("Retry sending data ?")){ errorCount = 0; } else{ throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } By default, the behaviour would remain as it is now, but you could force the prompts by defining the property at VM launch if desired. (for example : java.exe -Dorg.rxtx.usePrompt=true myApp) Also, you seemed to say you wanted the printer to start again exactly where is stopped. It would indeed be the best way when the printer is put offline for a few seconds. On the other hand, if the printer is turned off (or the printer runs out of paper, or someone steps on the mains cable), then the only way to go back to a "stable" situation would be by printing the item (page, label, etc.) again from scratch... Just my two cents. Vicne PS : By the way, the dialog box thing is very platform dependant on the C-side, and I think the simplest way would probably be to bridge it to a Java call where you can implement it like you proposed : public boolean displayDialogBox(prompt) { return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); } From netbeans at gatworks.com Thu Jun 7 14:08:24 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 16:08:24 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46684B62.7080802@gmail.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> Message-ID: <466865B8.4060004@gatworks.com> My feeling is that the code that was suggested was for his environs ( his shop ). The issue here is that after a 40+ second wait, an exception will be thrown. But you really dont have a way of 'cancelling' all the WriteFiles() that have already occured before the exception so that your writeArray and the Commapi can backtrack to a position in which they are in sync. The main ( really mine ) concern is not to lose data, or replicate data. After 40seconds, 300 seconds, 55min, no matter how long, data should not be lost or duplicated. But as soon as the exception is thrown, that possibility exists. Maybe an event should be thrown instead? Vicne wrote: > yves pielusenet wrote: >> Maybe in my case I should re-compile rxtx and change the code. Instead >> of send an exception I should display a dialog box to ask if it's >> printer problem or if it should trie to send bytes. Something like : >> >> while( count > 0 ){ >> if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ >> /* >> this are 20 * 2 seconds, in this time a printer (or other parallel device) >> should solv all problems like buffer full, etc >> */ >> if(errorCount++ < 20){ >> Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ >> continue; >> } >> >> if(displayDialogBox("Try again to send datas ??")){ >> errorCount = 0; >> } >> else{ >> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >> break; >> } >> } >> > > Sorry to step in without a specific solution to your problem, but I > wanted to share my feeling regarding this proposal. AFAIK, it's > generally considered bad practice to pop-up a prompt from a library. > The main reason is that in general use, you can't guarantee that > someone is actually present behind the console. Imagine a print server > in a machine room, connected to a park of printers. In that case, when > one printer fails, the logical behaviour would be to use an other one. > If you change RxTx the way you propose, the printer queue will simply be > stuck with a useless "Try again to send data ?" prompt until an > administrator opens a remote connection to the print server's console > and clicks "no". > Second, it would create a dependency upon the existence of a > graphical console (if you go the graphical "dialogBox" way). On many > applications (typically server or embedded ones), the JVM is "headless" > and if you try to pop-up a dialog, your app would throw an exception (at > best) or just wouldn't display the prompt anywhere... Going the "text > console" way is not more reliable, because on graphical environments, > the text console is hidden unless explicitly requested. > > My advice would be to think again and find another solution. Ideas are : > - make the number of retries a parameter so that you can tune it to what > you think is reasonable > - throw a more specific exception when the number of retries has been > reached, so that a specific prompt can be shown at a higher level > > Anyway, if you feel that the prompt is the way to go in your case, I > would at least make that prompt conditional. The least intrusive way > would probably be using a system property, like > > if("true".equals(System.getProperty("org.rxtx.usePrompt")) > && displayDialogBox("Retry sending data ?")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > > > By default, the behaviour would remain as it is now, but you could > force the prompts by defining the property at VM launch if desired. (for > example : java.exe -Dorg.rxtx.usePrompt=true myApp) > > > Also, you seemed to say you wanted the printer to start again > exactly where is stopped. It would indeed be the best way when the > printer is put offline for a few seconds. On the other hand, if the > printer is turned off (or the printer runs out of paper, or someone > steps on the mains cable), then the only way to go back to a "stable" > situation would be by printing the item (page, label, etc.) again from > scratch... > > > Just my two cents. > > > Vicne > > PS : By the way, the dialog box thing is very platform dependant on the > C-side, and I think the simplest way would probably be to bridge it to a > Java call where you can implement it like you proposed : > > public boolean displayDialogBox(prompt) { > return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", > JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); > } > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Thu Jun 7 17:48:11 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 Jun 2007 17:48:11 -0600 (MDT) Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <466865B8.4060004@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> Message-ID: An event is possible. I'm amazed this is the largest problem encountered while using the parallel code. How would the write ever exit if we throw events? Isn't this going to lead to hung applications? On Thu, 7 Jun 2007, Uncle George wrote: > My feeling is that the code that was suggested was for his environs ( > his shop ). > > The issue here is that after a 40+ second wait, an exception will be > thrown. But you really dont have a way of 'cancelling' all the > WriteFiles() that have already occured before the exception so that your > writeArray and the Commapi can backtrack to a position in which they are > in sync. > > The main ( really mine ) concern is not to lose data, or replicate data. > After 40seconds, 300 seconds, 55min, no matter how long, data should > not be lost or duplicated. But as soon as the exception is thrown, that > possibility exists. > > Maybe an event should be thrown instead? > > Vicne wrote: >> yves pielusenet wrote: >>> Maybe in my case I should re-compile rxtx and change the code. Instead >>> of send an exception I should display a dialog box to ask if it's >>> printer problem or if it should trie to send bytes. Something like : >>> >>> while( count > 0 ){ >>> if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ >>> /* >>> this are 20 * 2 seconds, in this time a printer (or other parallel device) >>> should solv all problems like buffer full, etc >>> */ >>> if(errorCount++ < 20){ >>> Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ >>> continue; >>> } >>> >>> if(displayDialogBox("Try again to send datas ??")){ >>> errorCount = 0; >>> } >>> else{ >>> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >>> break; >>> } >>> } >>> >> >> Sorry to step in without a specific solution to your problem, but I >> wanted to share my feeling regarding this proposal. AFAIK, it's >> generally considered bad practice to pop-up a prompt from a library. >> The main reason is that in general use, you can't guarantee that >> someone is actually present behind the console. Imagine a print server >> in a machine room, connected to a park of printers. In that case, when >> one printer fails, the logical behaviour would be to use an other one. >> If you change RxTx the way you propose, the printer queue will simply be >> stuck with a useless "Try again to send data ?" prompt until an >> administrator opens a remote connection to the print server's console >> and clicks "no". >> Second, it would create a dependency upon the existence of a >> graphical console (if you go the graphical "dialogBox" way). On many >> applications (typically server or embedded ones), the JVM is "headless" >> and if you try to pop-up a dialog, your app would throw an exception (at >> best) or just wouldn't display the prompt anywhere... Going the "text >> console" way is not more reliable, because on graphical environments, >> the text console is hidden unless explicitly requested. >> >> My advice would be to think again and find another solution. Ideas are : >> - make the number of retries a parameter so that you can tune it to what >> you think is reasonable >> - throw a more specific exception when the number of retries has been >> reached, so that a specific prompt can be shown at a higher level >> >> Anyway, if you feel that the prompt is the way to go in your case, I >> would at least make that prompt conditional. The least intrusive way >> would probably be using a system property, like >> >> if("true".equals(System.getProperty("org.rxtx.usePrompt")) >> && displayDialogBox("Retry sending data ?")){ >> errorCount = 0; >> } >> else{ >> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >> break; >> } >> >> >> By default, the behaviour would remain as it is now, but you could >> force the prompts by defining the property at VM launch if desired. (for >> example : java.exe -Dorg.rxtx.usePrompt=true myApp) >> >> >> Also, you seemed to say you wanted the printer to start again >> exactly where is stopped. It would indeed be the best way when the >> printer is put offline for a few seconds. On the other hand, if the >> printer is turned off (or the printer runs out of paper, or someone >> steps on the mains cable), then the only way to go back to a "stable" >> situation would be by printing the item (page, label, etc.) again from >> scratch... >> >> >> Just my two cents. >> >> >> Vicne >> >> PS : By the way, the dialog box thing is very platform dependant on the >> C-side, and I think the simplest way would probably be to bridge it to a >> Java call where you can implement it like you proposed : >> >> public boolean displayDialogBox(prompt) { >> return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", >> JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); >> } >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 19:18:51 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 21:18:51 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> Message-ID: <4668AE7B.3060409@gatworks.com> The UNIX version of writeArray is not too great either. It is possible that the write will only process some of the bytes. #else if( write( fd, bytes, count ) < 0 ) throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); #endif -------------------------------- Maybe it might be better to have the native function inform the caller of the # of characters written, then the commapi/output-buffer can be modified to reflect the #of chars written. If an exception is to be thrown, for too many loops of chars written == 0, then exception wont affect the state of the output buffer. Then a ParallelPort.restart() can be called to resume printing whats in the buffer. Trent Jarvi wrote: > An event is possible. I'm amazed this is the largest problem encountered > while using the parallel code. > > How would the write ever exit if we throw events? Isn't this going to > lead to hung applications? Sure. If you dont time out, then there is nothing that will force an EXIT from the write(). Issue is what has the OS done with the write. > > On Thu, 7 Jun 2007, Uncle George wrote: > >> My feeling is that the code that was suggested was for his environs ( >> his shop ). From yvespielusenet at free.fr Fri Jun 8 01:09:01 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Fri, 08 Jun 2007 09:09:01 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4668AE7B.3060409@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> Message-ID: <1181286541.3674.10.camel@localhost.localdomain> It is not possible that the rxtx java method write(byte[], int offset, int length) return anint which contains the number of byte really send to the printer instead of an exception ? So this is the programm which will see if all bytes have been sent. If not it can retry to send the unsended bytes. -------------------------------------------------------- int sended = 0; while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ sended += countWritten; /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } return sended; /*throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break;*/ } ... ... return countWritten; ------------------------------------------------ Le jeudi 07 juin 2007 ? 21:18 -0400, Uncle George a ?crit : > The UNIX version of writeArray is not too great either. It is possible > that the write will only process some of the bytes. > > #else > if( write( fd, bytes, count ) < 0 ) > throw_java_exception_system_msg( env, IO_EXCEPTION, > "writeArray" ); > #endif > -------------------------------- > > Maybe it might be better to have the native function inform the caller > of the # of characters written, then the commapi/output-buffer can be > modified to reflect the #of chars written. If an exception is to be > thrown, for too many loops of chars written == 0, then exception wont > affect the state of the output buffer. Then a ParallelPort.restart() can > be called to resume printing whats in the buffer. > > > Trent Jarvi wrote: > > An event is possible. I'm amazed this is the largest problem encountered > > while using the parallel code. > > > > How would the write ever exit if we throw events? Isn't this going to > > lead to hung applications? > Sure. If you dont time out, then there is nothing that will force an > EXIT from the write(). Issue is what has the OS done with the write. > > > > On Thu, 7 Jun 2007, Uncle George wrote: > > > >> My feeling is that the code that was suggested was for his environs ( > >> his shop ). > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Fri Jun 8 03:45:00 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 11:45:00 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181286541.3674.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> Message-ID: <20070608094500.GC21069@elberon.bln.de.ingenico.com> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > It is not possible that the rxtx java method write(byte[], int offset, > int length) return anint which contains the number of byte really send > to the printer instead of an exception ? > So this is the programm which will see if all bytes have been sent. If > not it can retry to send the unsended bytes. I think write() is void because in Java people love to do this since OutputStream :-) Of course on such interfaces you cannot implement something nice. If you would have a int write, you would not implement the interface and no applications expecting this interface would link/work/compile. oki, Steffen P.S.: (OT) If you propose not to implement the Java interfaces (especially not on JNI level), maybe optionally offering a wrapper that removes e.g. the write return value and so on to downgrade the powerful classic old POSIX read/write style to the modern limited Java style, then I agree :-) Same for read. Instead of things like "int avialable()" it is more powerful to have an approach as select(2) offers (to guarante the caller that read/write will not block [nothing else make sense anyway IMHO] but may read/write less bytes then requested). The caller gets full control and the higher level protocols can care about timeouts, invoking read in some loops and/or implement retransmission. On top of such an implementation, where everything is controlled, defined, guaranteed and reliable, someone could use an InputStream or OutputStream style interface. Or even better: don't use them at all :) just BTW :-) St. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From yvespielusenet at free.fr Fri Jun 8 05:52:45 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Fri, 08 Jun 2007 13:52:45 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <20070608094500.GC21069@elberon.bln.de.ingenico.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> Message-ID: <1181303565.11203.3.camel@localhost.localdomain> So maybe a better way should be to create a new Exception class which has a method "int getWrittenByte()". So the Exception should be use to send again bytes which are not printed yet. yves Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : > * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > > It is not possible that the rxtx java method write(byte[], int offset, > > int length) return anint which contains the number of byte really send > > to the printer instead of an exception ? > > So this is the programm which will see if all bytes have been sent. If > > not it can retry to send the unsended bytes. > > I think write() is void because in Java people love to do this > since OutputStream :-) Of course on such interfaces you cannot > implement something nice. If you would have a int write, you > would not implement the interface and no applications expecting > this interface would link/work/compile. > > oki, > > Steffen > > P.S.: (OT) > If you propose not to implement the Java interfaces (especially > not on JNI level), maybe optionally offering a wrapper that > removes e.g. the write return value and so on to downgrade the > powerful classic old POSIX read/write style to the modern limited > Java style, then I agree :-) Same for read. Instead of things > like "int avialable()" it is more powerful to have an approach as > select(2) offers (to guarante the caller that read/write will not > block [nothing else make sense anyway IMHO] but may read/write > less bytes then requested). The caller gets full control and the > higher level protocols can care about timeouts, invoking read in > some loops and/or implement retransmission. On top of such an > implementation, where everything is controlled, defined, > guaranteed and reliable, someone could use an InputStream or > OutputStream style interface. Or even better: don't use them at > all :) just BTW :-) > St. > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > 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. > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > 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. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Fri Jun 8 06:46:21 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 08:46:21 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181303565.11203.3.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> Message-ID: <46694F9D.5080501@gatworks.com> It seems that with outputstream.write(b[]), you become terribly uncoordinated as soon as an exception is thrown. Docs do not say what happens to the data. Yet from a practicable point of view, one would like to know if the write was accepted in-full, or rejected before any writes. There are no in betweens, as partial writes are not reportable. So for an outputstream.write(), in order for it to return, the full write request has to be taken, and stored in an internal output buffer. If there is no room, the write() is suspended, till there is room. Or throw's an IOException( "no room in buffer") ; As the select() loop for write reports buffer room avail, then more of the internal buffer is sent to the printer. yves pielusenet wrote: > So maybe a better way should be to create a new Exception class which > has a method "int getWrittenByte()". So the Exception should be use to > send again bytes which are not printed yet. > > yves > > Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : >> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: >>> It is not possible that the rxtx java method write(byte[], int offset, >>> int length) return anint which contains the number of byte really send >>> to the printer instead of an exception ? >>> So this is the programm which will see if all bytes have been sent. If >>> not it can retry to send the unsended bytes. >> I think write() is void because in Java people love to do this >> since OutputStream :-) Of course on such interfaces you cannot >> implement something nice. If you would have a int write, you >> would not implement the interface and no applications expecting >> this interface would link/work/compile. >> >> oki, >> >> Steffen >> >> P.S.: (OT) >> If you propose not to implement the Java interfaces (especially >> not on JNI level), maybe optionally offering a wrapper that >> removes e.g. the write return value and so on to downgrade the >> powerful classic old POSIX read/write style to the modern limited >> Java style, then I agree :-) Same for read. Instead of things >> like "int avialable()" it is more powerful to have an approach as >> select(2) offers (to guarante the caller that read/write will not >> block [nothing else make sense anyway IMHO] but may read/write >> less bytes then requested). The caller gets full control and the >> higher level protocols can care about timeouts, invoking read in >> some loops and/or implement retransmission. On top of such an >> implementation, where everything is controlled, defined, >> guaranteed and reliable, someone could use an InputStream or >> OutputStream style interface. Or even better: don't use them at >> all :) just BTW :-) >> St. >> >> About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. >> 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. >> >> About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. >> 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. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From Steffen.DETTMER at ingenico.com Fri Jun 8 08:12:18 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 16:12:18 +0200 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <46694F9D.5080501@gatworks.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: <20070608141218.GE21069@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 08:46 -0400: > It seems that with outputstream.write(b[]), you become terribly > uncoordinated as soon as an exception is thrown. Docs do not say what > happens to the data. (yes, so avoiding it seems to be good :)) > Yet from a practicable point of view, one would like to know if the > write was accepted in-full, or rejected before any writes. There are no > in betweens, as partial writes are not reportable. (which is an artificial API limitation. I never understood how this happend when they invented JDK because the well-known BSD socket API and thus [probably] WinSock does this correct, but anyway) > So for an outputstream.write(), in order for it to return, the full > write request has to be taken, and stored in an internal output buffer. > If there is no room, the write() is suspended, till there is room. Or > throw's an IOException( "no room in buffer") ; As the select() loop for > write reports buffer room avail, then more of the internal buffer is > sent to the printer. yes, might be good in case of a printer. May be horrible in case of PPP/TCP or some other transmission control protocol which may e.g. repeat data or even omit parts of it (e.g. internet realtime radio station broadcasting)... So I think the idea of "int write" (e.g. BSD sockets, linux files and so on) still is the best. A clean API / implementation should guarantee and allow implementations (users) to rely on that; assumptions and automatic background-sending and so on may look pragmatic and may even work on the first look, but may fail in other situations. BTW, if e.g. BSD socket API is known, why not simply copy it (until something better is invented :)) instead of fiddling around with JDK APIs? anyway, have a nice weekend everyone :-) oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Fri Jun 8 08:55:56 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 10:55:56 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070608141218.GE21069@elberon.bln.de.ingenico.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> Message-ID: <46696DFC.7000801@gatworks.com> >> write reports buffer room avail, then more of the internal buffer is >> sent to the printer. > > yes, might be good in case of a printer. May be horrible in case > of PPP/TCP or some other transmission control protocol which > may e.g. repeat data or even omit parts of it (e.g. internet > realtime radio station broadcasting)... So I think the idea of > "int write" (e.g. BSD sockets, linux files and so on) still is > the best. A clean API / implementation should guarantee and allow > implementations (users) to rely on that; assumptions and > automatic background-sending and so on may look pragmatic and may > even work on the first look, but may fail in other situations. > BTW, if e.g. BSD socket API is known, why not simply copy it > (until something better is invented :)) instead of fiddling > around with JDK APIs? But we were talking about the Parallel Port, and the transmission of data over the commapi/parallel-port schema. There isn't much in bi-directional software communication. Its a simple write one byte at a time interface. I'm not looking to change the comm-api. I'm just looking to alter the interaction between the Native ParallelPort functions, and the java ParallelPort functions that call them. This might be more readily doable than to get a committee to re-specify java-API specs. BTW: Whats is off-topic? ( help: not looking for def of off-topic ) From j.kenneth.gentle at acm.org Fri Jun 8 08:58:59 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Fri, 08 Jun 2007 10:58:59 -0400 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <20070608141218.GE21069@elberon.bln.de.ingenico.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> Message-ID: <200706081459.l58Ex5rA019991@qbang.org> Perhaps it is a bit late to jump in on this one, but here goes anyway. If the solutions all seem to "break" the contract with "java.io.outputstream", then, as noted, that may not be the appropriate contract. At the risk of being heretical, JDK1.4 introduced the "nio" package to address some of the compatibility issues with C apis mentioned in previous posts. The interface "java.nio.channels.WriteableByteChannel" defines the following single method: int write(ByteBuffer source); int, strangely enough, is the actual number of bytes written. So, if RXTX as written, against the JavaCOMM api and OutputStream, doesn't do what we want, how about writing a different set of bindings using the java.nio classes and as much of the underlying native code as possible. Note that just because the java.nio.channels.WriteableByteChannel sends back a result, OutputStream.write doesn't have to - and they could both call the same underlying native code. My 2 cents - maybe not worth even that... Ken From netbeans at gatworks.com Fri Jun 8 10:37:28 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 12:37:28 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <200706081459.l58Ex5rA019991@qbang.org> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> Message-ID: <466985C8.8000505@gatworks.com> Ken Gentle wrote: > Perhaps it is a bit late to jump in on this one, but here goes anyway. Common in, the waters fine. > > If the solutions all seem to "break" the contract with > "java.io.outputstream", then, as noted, that may not be the > appropriate contract. > How would the contract be broken? The machinery underneath is handling the contract. From j.kenneth.gentle at acm.org Fri Jun 8 10:48:01 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Fri, 08 Jun 2007 12:48:01 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466985C8.8000505@gatworks.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> Message-ID: <200706081648.l58Gm7YA022904@qbang.org> At 12:37 2007-06-08, you wrote: >Ken Gentle wrote: > > > > If the solutions all seem to "break" the contract with > > "java.io.outputstream", then, as noted, that may not be the > > appropriate contract. > > >How would the contract be broken? The machinery underneath is handling >the contract. It seems that a lot of the discussion has been about not only the timeout and being able to adjust it in the "machinery layer", but also about knowing in the Java layer, in the event of a timeout or exception, how many characters have been written to the device. An OutputStream won't ever do this with out an extension and including a return value "breaks" the contract, right? So, go with a Java IO api that *does* return the number of bytes written, out of the NIO package. I know it doesn't allow for a strict implementation of the JavaCOMM API - however, using NIO classes in place of the IO classes isn't that big a break and would allow those applications that need such information a way to get it. Maybe I'm misunderstanding the problem... Ken From netbeans at gatworks.com Fri Jun 8 11:24:14 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 13:24:14 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <200706081648.l58Gm7YA022904@qbang.org> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> Message-ID: <466990BE.7040100@gatworks.com> Ken Gentle wrote: An > OutputStream won't ever do this with out an extension and including a > return value "breaks" the contract, right? > i was not thinking of change the API to OutputSream. Are there specs for how output stream should work internally? for instance: String data = "Hello this is a line of data"; Outputstream.write( data.getbytes() ); ParallelPort.suspend(); int free = ParallelPort.getoutputbufferfree(); There is a symbiotic relationship between outputstream and the functionality of ParallelPort. From Steffen.DETTMER at ingenico.com Fri Jun 8 11:15:39 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 19:15:39 +0200 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <200706081459.l58Ex5rA019991@qbang.org> References: <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> Message-ID: <20070608171539.GK21069@elberon.bln.de.ingenico.com> * Ken Gentle wrote on Fri, Jun 08, 2007 at 10:58 -0400: > If the solutions all seem to "break" the contract with > "java.io.outputstream", then, as noted, that may not be the > appropriate contract. > > At the risk of being heretical, JDK1.4 introduced the "nio" package > to address some of the compatibility issues with C apis mentioned in > previous posts. The interface > "java.nio.channels.WriteableByteChannel" defines the following single method: > > int write(ByteBuffer source); > > int, strangely enough, is the actual number of bytes written. Yes, AFAIK one of the motivations for the NIO interface was, that the JDK-1.3 APIs (InputStream, e.g.) were not powerfull enough, especially for multi-connection-TCP servers or so. I don't know much about it but I've heard of a project where NIO usage was removed because of stability issues in multi-threaded environments and performance limitations under some circumstances. IIRC the "nio.ByteBuffer" is something very special (namely something you cannot implement in Java, it is "magic" or part of the language itself). Not sure if this is such a great idea (but for performance in the end sometimes heavy prices must be paid) :) > So, if RXTX as written, against the JavaCOMM api and OutputStream, > doesn't do what we want, how about writing a different set of > bindings using the java.nio classes and as much of the underlying > native code as possible. Yes, this would be an idea: use a full-featured interface on JNI, and, if wanted, deliver some wrappers converting this to a less-featured Java-compliant interface. However, powerful things as e.g. "select" are difficult to "emulate" if you are e.g. on some (older?) windows. But if you expose the full-featured APIs, you need to emulate them full-featured, theoretically. In the end it depends what you do on the serial line. If you just want to talk to a modem, then you may not need precise timeouts. But if you need to implement complexer protocols which define response times and timeouts, you may quickly get into difficulties. For instance, AFAIK, rxtx 1.7.2 (?) for windows is very messy with timeouts (there is a maximum, higher values are truncated; resolution is 100ms only; the function may take up to twice the timeout because internally it may be called twice). Probably for most people this is OK, but probably not for all. But having precise timeouts should be OK for all :-) Well, in the end it is nice to wish but somewhat hard to implement (many platforms, connections, USB, BlueTooth, whatever). oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Steffen.DETTMER at ingenico.com Fri Jun 8 11:04:22 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 19:04:22 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <46696DFC.7000801@gatworks.com> References: <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <46696DFC.7000801@gatworks.com> Message-ID: <20070608170422.GJ21069@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 10:55 -0400: > > BTW, if e.g. BSD socket API is known, why not simply copy it > > (until something better is invented :)) instead of fiddling > > around with JDK APIs? > > But we were talking about the Parallel Port, and the > transmission of data over the commapi/parallel-port schema. > There isn't much in bi-directional software communication. Its > a simple write one byte at a time interface. First, there are things like PLIP (http://en.wikipedia.org/wiki/Plip) - well, probably not widely used, sure ;) Second, I think if there is a good simple API known to support all that (with known "best practices") or so and there is no forcing need to invent a new one, why not simply using it? > I'm not looking to change the comm-api. I'm just looking to > alter the interaction between the Native ParallelPort > functions, and the java ParallelPort functions that call them. Ahh, yes. I think this is what I tried to ask. Having an usable JNI interface and on top (in pure java) some wrapper to InputStream or whatever could be done (e.g. by ignoring the return value of write or throwing if != length). Developers could then use the full-featured (non-JAVA-standard) API or select among various wrappers (as InputStream). > This might be more readily doable than to get a committee to > re-specify java-API specs. Yes, of course. I'm afraid that the Java APIs change regularily, but still yet with limited success it seems, so maybe they get it in one of the next iterations; who knows, maybe Java-9 has a BSD-like socket API :) SCNR. > BTW: Whats is off-topic? ( help: not looking for def of > off-topic ) I think I started some "re-specify java-API specs" which was OT probably. oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From lists at iDIAcomputing.com Fri Jun 8 18:48:54 2007 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Fri, 08 Jun 2007 20:48:54 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46684B62.7080802@gmail.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> Message-ID: <4669F8F6.3040101@iDIAcomputing.com> Vicne wrote: > Sorry to step in without a specific solution to your problem, but I > wanted to share my feeling regarding this proposal. AFAIK, it's > generally considered bad practice to pop-up a prompt from a library. ... > > My advice would be to think again and find another solution. Ideas are : > - make the number of retries a parameter so that you can tune it to what > you think is reasonable > - throw a more specific exception when the number of retries has been > reached, so that a specific prompt can be shown at a higher level You could also allow the client code to register a callback class which returns a boolean indicating whether to retry or cancel. This callback class could pop up a dialog, if appropriate, or follow some preset policy, or.... - George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From joachim at buechse.ch Sat Jun 9 09:43:16 2007 From: joachim at buechse.ch (Joachim Buechse) Date: Sat, 9 Jun 2007 17:43:16 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46694F9D.5080501@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: You should not forget, that in the case of an exception it may not even be known what happened to the data. You have a kernel buffer, outgoing chip buffer, incoming chip buffer, etc. So of course, it would be nice to know up to which point data was correctly processed, but this feedback does not exist on the hardware or protocol level and hence can in general not be magicly created on the software level... Regards, Joachim On 08.06.2007, at 14:46, Uncle George wrote: > It seems that with outputstream.write(b[]), you become terribly > uncoordinated as soon as an exception is thrown. Docs do not say what > happens to the data. > > Yet from a practicable point of view, one would like to know if the > write was accepted in-full, or rejected before any writes. There > are no > in betweens, as partial writes are not reportable. > > So for an outputstream.write(), in order for it to return, the full > write request has to be taken, and stored in an internal output > buffer. > If there is no room, the write() is suspended, till there is room. Or > throw's an IOException( "no room in buffer") ; As the select() loop > for > write reports buffer room avail, then more of the internal buffer is > sent to the printer. > > > > yves pielusenet wrote: >> So maybe a better way should be to create a new Exception class which >> has a method "int getWrittenByte()". So the Exception should be >> use to >> send again bytes which are not printed yet. >> >> yves >> >> Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : >>> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: >>>> It is not possible that the rxtx java method write(byte[], int >>>> offset, >>>> int length) return anint which contains the number of byte >>>> really send >>>> to the printer instead of an exception ? >>>> So this is the programm which will see if all bytes have been >>>> sent. If >>>> not it can retry to send the unsended bytes. >>> I think write() is void because in Java people love to do this >>> since OutputStream :-) Of course on such interfaces you cannot >>> implement something nice. If you would have a int write, you >>> would not implement the interface and no applications expecting >>> this interface would link/work/compile. >>> >>> oki, >>> >>> Steffen >>> >>> P.S.: (OT) >>> If you propose not to implement the Java interfaces (especially >>> not on JNI level), maybe optionally offering a wrapper that >>> removes e.g. the write return value and so on to downgrade the >>> powerful classic old POSIX read/write style to the modern limited >>> Java style, then I agree :-) Same for read. Instead of things >>> like "int avialable()" it is more powerful to have an approach as >>> select(2) offers (to guarante the caller that read/write will not >>> block [nothing else make sense anyway IMHO] but may read/write >>> less bytes then requested). The caller gets full control and the >>> higher level protocols can care about timeouts, invoking read in >>> some loops and/or implement retransmission. On top of such an >>> implementation, where everything is controlled, defined, >>> guaranteed and reliable, someone could use an InputStream or >>> OutputStream style interface. Or even better: don't use them at >>> all :) just BTW :-) >>> St. >>> >>> About Ingenico Throughout the world businesses rely on Ingenico >>> for secure and expedient electronic transaction acceptance. >>> Ingenico products leverage proven technology, established >>> standards and unparalleled ergonomics to provide optimal >>> reliability, versatility and usability. This comprehensive range >>> of products is complemented by a global array of services and >>> partnerships, enabling businesses in a number of vertical sectors >>> to accept transactions anywhere their business takes them. >>> 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. >>> >>> About Ingenico Throughout the world businesses rely on Ingenico >>> for secure and expedient electronic transaction acceptance. >>> Ingenico products leverage proven technology, established >>> standards and unparalleled ergonomics to provide optimal >>> reliability, versatility and usability. This comprehensive range >>> of products is complemented by a global array of services and >>> partnerships, enabling businesses in a number of vertical sectors >>> to accept transactions anywhere their business takes them. >>> 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. >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx 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 yvespielusenet at free.fr Mon Jun 11 03:15:12 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Mon, 11 Jun 2007 11:15:12 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: <1181553312.8335.14.camel@localhost.localdomain> So can someone tell a solution for my problem :( Must I say to the user to not put the printer off-line ? I can't since he has to do some pauses, verify print, paper conditioning etc... How do other people ? Before I use the parport librarry to read port status : http://www.geocities.com/Juanga69/parport/ (which doesn't work on windows XP) And I send data into the file LPT1 I use to have no problem when printer was disabled. thanks -- yves piel Le samedi 09 juin 2007 ? 17:43 +0200, Joachim Buechse a ?crit : > You should not forget, that in the case of an exception it may not > even be known what happened to the data. > > You have a kernel buffer, outgoing chip buffer, incoming chip buffer, > etc. So of course, it would be nice to know up to which point data > was correctly processed, but this feedback does not exist on the > hardware or protocol level and hence can in general not be magicly > created on the software level... > > Regards, > Joachim > > On 08.06.2007, at 14:46, Uncle George wrote: > > > It seems that with outputstream.write(b[]), you become terribly > > uncoordinated as soon as an exception is thrown. Docs do not say what > > happens to the data. > > > > Yet from a practicable point of view, one would like to know if the > > write was accepted in-full, or rejected before any writes. There > > are no > > in betweens, as partial writes are not reportable. > > > > So for an outputstream.write(), in order for it to return, the full > > write request has to be taken, and stored in an internal output > > buffer. > > If there is no room, the write() is suspended, till there is room. Or > > throw's an IOException( "no room in buffer") ; As the select() loop > > for > > write reports buffer room avail, then more of the internal buffer is > > sent to the printer. > > > > > > > > yves pielusenet wrote: > >> So maybe a better way should be to create a new Exception class which > >> has a method "int getWrittenByte()". So the Exception should be > >> use to > >> send again bytes which are not printed yet. > >> > >> yves > >> > >> Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : > >>> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > >>>> It is not possible that the rxtx java method write(byte[], int > >>>> offset, > >>>> int length) return anint which contains the number of byte > >>>> really send > >>>> to the printer instead of an exception ? > >>>> So this is the programm which will see if all bytes have been > >>>> sent. If > >>>> not it can retry to send the unsended bytes. > >>> I think write() is void because in Java people love to do this > >>> since OutputStream :-) Of course on such interfaces you cannot > >>> implement something nice. If you would have a int write, you > >>> would not implement the interface and no applications expecting > >>> this interface would link/work/compile. > >>> > >>> oki, > >>> > >>> Steffen > >>> > >>> P.S.: (OT) > >>> If you propose not to implement the Java interfaces (especially > >>> not on JNI level), maybe optionally offering a wrapper that > >>> removes e.g. the write return value and so on to downgrade the > >>> powerful classic old POSIX read/write style to the modern limited > >>> Java style, then I agree :-) Same for read. Instead of things > >>> like "int avialable()" it is more powerful to have an approach as > >>> select(2) offers (to guarante the caller that read/write will not > >>> block [nothing else make sense anyway IMHO] but may read/write > >>> less bytes then requested). The caller gets full control and the > >>> higher level protocols can care about timeouts, invoking read in > >>> some loops and/or implement retransmission. On top of such an > >>> implementation, where everything is controlled, defined, > >>> guaranteed and reliable, someone could use an InputStream or > >>> OutputStream style interface. Or even better: don't use them at > >>> all :) just BTW :-) > >>> St. > >>> > >>> About Ingenico Throughout the world businesses rely on Ingenico > >>> for secure and expedient electronic transaction acceptance. > >>> Ingenico products leverage proven technology, established > >>> standards and unparalleled ergonomics to provide optimal > >>> reliability, versatility and usability. This comprehensive range > >>> of products is complemented by a global array of services and > >>> partnerships, enabling businesses in a number of vertical sectors > >>> to accept transactions anywhere their business takes them. > >>> 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. > >>> > >>> About Ingenico Throughout the world businesses rely on Ingenico > >>> for secure and expedient electronic transaction acceptance. > >>> Ingenico products leverage proven technology, established > >>> standards and unparalleled ergonomics to provide optimal > >>> reliability, versatility and usability. This comprehensive range > >>> of products is complemented by a global array of services and > >>> partnerships, enabling businesses in a number of vertical sectors > >>> to accept transactions anywhere their business takes them. > >>> 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. > >>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx 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 > From Steffen.DETTMER at ingenico.com Mon Jun 11 03:56:18 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 11:56:18 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466990BE.7040100@gatworks.com> References: <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> Message-ID: <20070611095618.GA10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 13:24 -0400: > i was not thinking of change the API to OutputSream. Then I think either someone uses OutputStream (and has no reliable information about incomplete writes) or someone uses somethink else. > Are there specs for how output stream should work internally? > > for instance: > String data = "Hello this is a line of data"; > Outputstream.write( data.getbytes() ); > ParallelPort.suspend(); > int free = ParallelPort.getoutputbufferfree(); > > There is a symbiotic relationship between outputstream and the > functionality of ParallelPort. If you need OutputStream "plus something else", in short you're needing "something else". Personally I dislike the code above a lot. The stream "looks" like if it would be an OutputStream, but in fact it isn't. You need to call getoutputbufferfree later to check if write succeeded (but OutputStream promises that write succeedes synchronous, blocking, or throws an exception). So it is not an OutputStream. No application written for OutputStreams would work without change (because it won't know getoutputbufferfree at all). It is not abstracted from ParallelPort. I think this would be wrong. Then I think an alternative interface instead is better. Let's assume we had some "connection" (to distinguish between OutputStreams and Channels). Then why not working as on a file handle in POSIX: do { // ... select maybe using timer ... readyForWrite = ... if (readyForWrite) { int writtenBytes = connection.write(toWrite); toWrite.remove(0, writtenBytes); } while(readyForWrite && toWrite.length > 0); I think, having such a write isn't the big problem. I think, the difficult thing is around "select" - however this would look like. It should be OO, typesafe, performant, supporting multiple connections/channels/streams in various modes and should be orthogonal to other functionalities. Of course, this heavily depends on what the application is doing; for a simple situation (like reading a small, mandatory file from a local disk) this would be to uncomfortable (and offering unneeded features only). just BTW :) oki, Steffen -- // Modeline for VIM. Please don't remove. // (Help: autoindent, expandtab, shiftwidth=4, tabstop=4, textwidth=75) // vi: set ai et sw=4 ts=4 tw=75 ft=java: About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Mon Jun 11 05:38:33 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 07:38:33 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611095618.GA10821@elberon.bln.de.ingenico.com> References: <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> Message-ID: <466D3439.4020805@gatworks.com> Steffen DETTMER wrote: > (but OutputStream promises that write > succeedes synchronous, blocking, or throws an exception). Where is it so written? From Steffen.DETTMER at ingenico.com Mon Jun 11 06:36:50 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 14:36:50 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466D3439.4020805@gatworks.com> References: <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> <466D3439.4020805@gatworks.com> Message-ID: <20070611123650.GI10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Mon, Jun 11, 2007 at 07:38 -0400: > Steffen DETTMER wrote: > > > (but OutputStream promises that write > > succeedes synchronous, blocking, or throws an exception). > > Where is it so written? Now, as you ask, I think it is not written that clearly but follows from specification. mmm... Am I wrong? I understand the API doc in this way: * http://java.sun.com/j2se/1.4.2/docs/api/java/io/OutputStream.html#write(byte[]) > public void write(byte[] b) > throws IOException > > Writes b.length bytes from the specified byte array to this > output stream. The general contract for write(b) is that > it should have exactly the same effect as the call write(b, > 0, b.length). > > Parameters: > b - the data. > Throws: > IOException - if an I/O error occurs. > See Also: > write(byte[], int, int) and there is: > public void write(byte[] b, > int off, > int len) > throws IOException > > Writes len bytes from the specified byte array starting at > offset off to this output stream. The general contract for > write(b, off, len) is that some of the bytes in the array b > are written to the output stream in order; element b[off] > is the first byte written and b[off+len-1] is the last byte > written by this operation. > > The write method of OutputStream calls the write method of > one argument on each of the bytes to be written out. > Subclasses are encouraged to override this method and > provide a more efficient implementation. > > If b is null, a NullPointerException is thrown. > > If off is negative, or len is negative, or off+len is > greater than the length of the array b, then an > IndexOutOfBoundsException is thrown. > > Parameters: > b - the data. > off - the start offset in the data. > len - the number of bytes to write. > Throws: > IOException - if an I/O error occurs. In particular, an > IOException is thrown if the output stream is closed. In general, any specialisation (derived child class) must comform to this. So write in the end is specified (!) as "The write method ... calls the write method ... on each of the bytes to be written out". This is what must be implemented by ANY OutputStream. Of course, there is: "Subclasses are encouraged to override this method and provide a more efficient implementation." which IMHO does not contradict - the more efficient must behave in exactly the same way of course (just wasting less resources than a simple byte-by-byte write). So it does not matter here I think. The write that finally defines the behavior tells basically: > "Writes the specified byte to this output stream. The general > contract for write is that one byte is written to the output > stream. " > > Throws: > IOException - if an I/O error occurs. which IMHO is another way of saying "write writes the byte immediately and returns on success (only), otherwise an exception is thrown". Especially it cannot happen that zero bytes are written (i.e. the specified byte is NOT written) without an exception. So by this write must be synchronous and blocking, because otherwise it could not reliably know if an asynchronous operation will succeede or not (some getAsyncResult or so would be needed). Since write(byte[]) does this for each byte (or with a behavior beeing exactly the same as if it would do), I think this means that the write(byte[]) succeedes synchronous/blocking or throws an exception. Did I an error in reasoning or confused something or so? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From j.kenneth.gentle at acm.org Mon Jun 11 06:51:25 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 11 Jun 2007 08:51:25 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611123650.GI10821@elberon.bln.de.ingenico.com> References: <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> <466D3439.4020805@gatworks.com> <20070611123650.GI10821@elberon.bln.de.ingenico.com> Message-ID: <200706111251.l5BCpS9T017831@qbang.org> It is as Steffen describes. "InputStream" and "OutputStream" are inherently synchronous (which is why so many java programs resort to threads to use them). Anything outside of this "contract" is *not* an InputStream or OutputStream. That is why there is a new package for things that don't behave like the old *Stream classes - the NIO package. If you look carefully at the IO package, you'll note that almost all the classes are _Decorator_ pattern implementations of the *Stream classes - and the interface presents the _same_ behavior to the calling code in all cases - a synchronous operation that completes successfully or throws an exception (with the one exception of "read" that returns a "-1" on end-of-stream. I know I've read this numerous times - I'd suggest checking the Language Spec or one of the books by Bloch or Gosling. Ken At 08:36 2007-06-11, you wrote: >* Uncle George wrote on Mon, Jun 11, 2007 at 07:38 -0400: > > Steffen DETTMER wrote: > > > > > (but OutputStream promises that write > > > succeedes synchronous, blocking, or throws an exception). > > > > Where is it so written? > >Now, as you ask, I think it is not written that clearly but >follows from specification. mmm... > >Am I wrong? > >I understand the API doc in this way: > >* >http://java.sun.com/j2se/1.4.2/docs/api/java/io/OutputStream.html#write(byte[]) > > public void write(byte[] b) > > throws IOException > > > > Writes b.length bytes from the specified byte array to this > > output stream. The general contract for write(b) is that > > it should have exactly the same effect as the call write(b, > > 0, b.length). > > > > Parameters: > > b - the data. > > Throws: > > IOException - if an I/O error occurs. > > See Also: > > write(byte[], int, int) > > >and there is: > > > > public void write(byte[] b, > > int off, > > int len) > > throws IOException > > > > Writes len bytes from the specified byte array starting at > > offset off to this output stream. The general contract for > > write(b, off, len) is that some of the bytes in the array b > > are written to the output stream in order; element b[off] > > is the first byte written and b[off+len-1] is the last byte > > written by this operation. > > > > The write method of OutputStream calls the write method of > > one argument on each of the bytes to be written out. > > Subclasses are encouraged to override this method and > > provide a more efficient implementation. > > > > If b is null, a NullPointerException is thrown. > > > > If off is negative, or len is negative, or off+len is > > greater than the length of the array b, then an > > IndexOutOfBoundsException is thrown. > > > > Parameters: > > b - the data. > > off - the start offset in the data. > > len - the number of bytes to write. > > Throws: > > IOException - if an I/O error occurs. In particular, an > > IOException is thrown if the output stream is closed. > > >In general, any specialisation (derived child class) must comform >to this. So write in the end is specified (!) as "The write >method ... calls the write method ... on each of the bytes to be >written out". This is what must be implemented by ANY >OutputStream. > >Of course, there is: "Subclasses are encouraged to override this >method and provide a more efficient implementation." which IMHO >does not contradict - the more efficient must behave in exactly >the same way of course (just wasting less resources than a simple >byte-by-byte write). So it does not matter here I think. > > > >The write that finally defines the behavior tells basically: > > > "Writes the specified byte to this output stream. The general > > contract for write is that one byte is written to the output > > stream. " > > > > Throws: > > IOException - if an I/O error occurs. > > >which IMHO is another way of saying "write writes the byte >immediately and returns on success (only), otherwise an exception >is thrown". Especially it cannot happen that zero bytes are >written (i.e. the specified byte is NOT written) without an >exception. So by this write must be synchronous and blocking, >because otherwise it could not reliably know if an asynchronous >operation will succeede or not (some getAsyncResult or so would >be needed). > >Since write(byte[]) does this for each byte (or with a behavior >beeing exactly the same as if it would do), I think this means >that the write(byte[]) succeedes synchronous/blocking or throws >an exception. > >Did I an error in reasoning or confused something or so? > >oki, > >Steffen > >About Ingenico Throughout the world businesses rely on Ingenico for >secure and expedient electronic transaction acceptance. Ingenico >products leverage proven technology, established standards and >unparalleled ergonomics to provide optimal reliability, versatility >and usability. This comprehensive range of products is complemented >by a global array of services and partnerships, enabling businesses >in a number of vertical sectors to accept transactions anywhere >their business takes them. >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. > >About Ingenico Throughout the world businesses rely on Ingenico for >secure and expedient electronic transaction acceptance. Ingenico >products leverage proven technology, established standards and >unparalleled ergonomics to provide optimal reliability, versatility >and usability. This comprehensive range of products is complemented >by a global array of services and partnerships, enabling businesses >in a number of vertical sectors to accept transactions anywhere >their business takes them. >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. > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From alesinskyy at googlemail.com Mon Jun 11 07:25:33 2007 From: alesinskyy at googlemail.com (Oleksandr Alesinskyy) Date: Mon, 11 Jun 2007 15:25:33 +0200 Subject: [Rxtx] [OT] select :-) Message-ID: Sorry, but I have to disagree with following statement: "So write in the end is specified (!) as "The write method ... calls the write method ... on each of the bytes to be written out". This is what must be implemented by ANY OutputStream.". This is not part of the specification or contract, it is just revealed implementation detail of the OutputStream. It is not stated anywhere that behavoiur of derived classes shall conform with this one. Statement concerning "synchronous" nature of the output stream is invalid as well. Really synchronous stream does not require flush() but OutputStream has it. From Steffen.DETTMER at ingenico.com Mon Jun 11 08:21:16 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 16:21:16 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: Message-ID: <20070611142116.GN10821@elberon.bln.de.ingenico.com> * Oleksandr Alesinskyy wrote on Mon, Jun 11, 2007 at 15:25 +0200: > Sorry, but I have to disagree with following statement: > "So write in the end is specified (!) as "The write > method ... calls the write method ... on each of the bytes to be > written out". This is what must be implemented by ANY > OutputStream.". > > This is not part of the specification or contract, it is just > revealed implementation detail of the OutputStream. It is not > stated anywhere that behavoiur of derived classes shall conform > with this one. (I didn't meant that the implementation must really write byte by byte, but that it must "look as if it would do" - because all implementations of OutputStream must "look" in the same way [which is another way of saying "do abstract" I think]) I think the API doc is not "revealing implementation details" but it is the *specification* of that interface and derivations must (should) conform to this specification. Isn't this the idea of interfaces? A function that expects an OutputStream should work on ANY OutputStream, shouldn't it? just kidding: I mean, what would be the point in implementing a checksum function as OutputStream.write which throws its result as IOException? Or which requires to call close() as very first operation to tell that the application is about to transmit confidential data? :-) > Statement concerning "synchronous" nature of the output stream > is invalid as well. Really synchronous stream does not require > flush() but OutputStream has it. ahh, interesting point! I think this is another bug in the API. flush() is wrong. Because write specifies "The general contract for write is that one byte is written to the output stream." but not "a byte may be written or buffered". Actually, an application would need to call flush() after each write (or bunch of write calls) to ensure that write really did something otherwise I think. I didn't found in the spec of OutputStream that it would be required to call flush(). This should mean that calling flush is not required which in turn leads to the conclusion that write must be synchrous (private threads are forbidden because not specified :)) which in turn leads to the conclusion that flush() is not needed at all... I mean, what if someone would only store in write and do the "real write" in flush() and never else? An application could write in one stream and read on another one (e.g. in bidirectional communication) and would never get anything back, because nothing was actually written because no flush was called? Then someone could even think that on error in some write the data could remain buffered AND throw an exception, retrying to send the data in the next write. Ohh, and if there would be some message number inside, and underlaying write (e.g. a protocol offering InputStream/OutputStream) would check this and throw "DuplicatedMessageNumber" the stream would only throw it again and again beeing unusable... In short: I have no clue how someone could be able to implement an asynchrounos write (which is realiable and correct) without beeing specific to anything which is not specified by OutputStream. Well, I think in the end OutputStream was not intended for such communication or protocol implementations - but to read a local disk file or so. In case of I/O errors usually you can abort your application and change the hard disk :-) oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Bob_Jacobsen at lbl.gov Mon Jun 11 09:32:23 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Mon, 11 Jun 2007 08:32:23 -0700 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611142116.GN10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> Message-ID: At 4:21 PM +0200 6/11/07, Steffen DETTMER wrote: > > Statement concerning "synchronous" nature of the output stream >> is invalid as well. Really synchronous stream does not require >> flush() but OutputStream has it. > >ahh, interesting point! > >I think this is another bug in the API. flush() is wrong. Because >write specifies "The general contract for write is that one byte >is written to the output stream." but not "a byte may be written >or buffered". > >Actually, an application would need to call flush() after each >write (or bunch of write calls) to ensure that write really did >something otherwise I think. OutputStreams don't _have_ to be synchronous or asynchronous, but the OutputStream API was be arranged so that subclasses _can_ be synchronous or asynchronous. Such generality is the hardest part of getting an API right. Hence, if at some point a program using an OutputStream wants to be sure that the data has been pushed all the way out, flush() is available. For some subclasses, e.g. the buffered ones, this has important behavior. Others write the data from each call, and flush() doesn't do anything. You _can_ omit it in programs that are known to use this second type, but there's no requirement that you do so; the interface is general in that way. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From Steffen.DETTMER at ingenico.com Mon Jun 11 12:32:39 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 20:32:39 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> Message-ID: <20070611183239.GT10821@elberon.bln.de.ingenico.com> * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: > >Actually, an application would need to call flush() after each > >write (or bunch of write calls) to ensure that write really did > >something otherwise I think. > OutputStreams don't _have_ to be synchronous or asynchronous, > but the OutputStream API was be arranged so that subclasses > _can_ be synchronous or asynchronous. Ahh, oki. Thanks for the clarificaion. So in short, flush() MUST be called on OutputStream, this is just not documented correctly or so clearly (right?). So the overall usage semantics would be: 1. call write (multiple times if desired) 2. call flush only if both succeeded, write was successful. If flush fails it remains unknown if a part of the data was written and/or will be repeated. So the spec (API doc) is wrong. Correct would be to tell that write behaves as told as long as it is followed by a call to flush, otherwise data may or may not get lost (depending wheter close() is called and calls flush(), which seems not to be guaranteed/required). BTW, I think it is a little bit... erm... interesting to find the specification (java API doc reference) wrong, having a need to conclude it from the presence of some methods with "it would make no sense if they behave exactly as specified, so specification must be wrong (incomplete)". > Such generality is the hardest part of getting an API right. Yes, seems to be proven ;) > Hence, if at some point a program using an OutputStream wants > to be sure that the data has been pushed all the way out, > flush() is available. For some subclasses, e.g. the buffered > ones, this has important behavior. Others write the data from > each call, and flush() doesn't do anything. > You _can_ omit it in programs that are known to use this second > type, but there's no requirement that you do so; the interface > is general in that way. I think, it still it must be called always, otherwise the application could break if passing a different runtime type as OutputStream. I think, if the application/method needs a special "type of OutputStream" then the parameter type must be a subclass but not OutputStream, maybe a PrintStream or so - otherwise the compiler could not detect this error (passing wrong type). Is this correct? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Bob_Jacobsen at lbl.gov Mon Jun 11 13:00:52 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Mon, 11 Jun 2007 12:00:52 -0700 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611183239.GT10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> Message-ID: At 8:32 PM +0200 6/11/07, Steffen DETTMER wrote: >So the spec (API doc) is wrong. Correct would be to tell that >write behaves as told as long as it is followed by a call to >flush, otherwise data may or may not get lost (depending wheter >close() is called and calls flush(), which seems not to be >guaranteed/required). I'm not entirely sure that the spec is wrong, but reasonable people can differ on this. In the 1.5 JavaDocs, all that the docs say for the write methods is that they write to the _output_ _stream_; there is no guarantee of anything beyond that. Only the flush method has any guarantee about the data, which is >Flushes this output stream and forces any buffered output bytes to >be written out. The general contract of flush is that calling it is >an indication that, if any bytes previously written have been >buffered by the implementation of the output stream, such bytes >should immediately be written to their intended destination. People commonly use various OutputStreams without using flush(), and it often works, but it's a bad practice and will eventually bite them. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From netbeans at gatworks.com Mon Jun 11 13:31:57 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 15:31:57 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611183239.GT10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> Message-ID: <466DA32D.1010602@gatworks.com> Steffen DETTMER wrote: > * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: >>> Actually, an application would need to call flush() after each >>> write (or bunch of write calls) to ensure that write really did >>> something otherwise I think. > >> OutputStreams don't _have_ to be synchronous or asynchronous, >> but the OutputStream API was be arranged so that subclasses >> _can_ be synchronous or asynchronous. > > Ahh, oki. Thanks for the clarificaion. > > So in short, flush() MUST be called on OutputStream, this is just > not documented correctly or so clearly (right?). No. Flush can be called to force all current data in java buffer's to be written to the kernel - NOW. A flush() can also *imply* that, besides writing out the buffer's that java employs, may also imply/ask the kernel to write all data thusfar written to the kernel, to be physically placed on the destination device - NOW. For some OS's there is no need to do a kernel flush(), as the I/O is synchronized already. Since this is java, you never know what OS your on. From tjarvi at qbang.org Mon Jun 11 19:28:27 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Jun 2007 19:28:27 -0600 (MDT) Subject: [Rxtx] [OT] select :-) In-Reply-To: <466DA32D.1010602@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: On Mon, 11 Jun 2007, Uncle George wrote: > Steffen DETTMER wrote: >> * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: >>>> Actually, an application would need to call flush() after each >>>> write (or bunch of write calls) to ensure that write really did >>>> something otherwise I think. >> >>> OutputStreams don't _have_ to be synchronous or asynchronous, >>> but the OutputStream API was be arranged so that subclasses >>> _can_ be synchronous or asynchronous. >> >> Ahh, oki. Thanks for the clarificaion. >> >> So in short, flush() MUST be called on OutputStream, this is just >> not documented correctly or so clearly (right?). > No. > Flush can be called to force all current data in java buffer's to be > written to the kernel - NOW. > > A flush() can also *imply* that, besides writing out the buffer's that > java employs, may also imply/ask the kernel to write all data thusfar > written to the kernel, to be physically placed on the destination device > - NOW. > For some OS's there is no need to do a kernel flush(), as the I/O is > synchronized already. Since this is java, you never know what OS your on. To add to the confusion, flush on the C side throws away data. drain makes sure it is written. Looking at the ParallelImp.c we can probably do better. /* we set a timeout because all calls are sequentiell (also with asynchron) this means that the default timeout of unlimited blocks all calls (also close and status request) if the device is down */ GetCommTimeouts( (HANDLE)fd, &timeouts ); timeouts.WriteTotalTimeoutMultiplier = 0; timeouts.WriteTotalTimeoutConstant = 2000; /* 2000 is the min value for the default Windows NT and Windows 2000 driver */ SetCommTimeouts( (HANDLE)fd, &timeouts ); while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } errorCount = 0; bytes += countWritten; count -= countWritten; } LPRPort has some timeout code that appears to be doing nothing but flipping bits back and forth right now. The commapi rxtx follows allows for timeout control from javax.comm.CommPort. The above is a solution that worked in one specific use case. With timeouts in place, the original 'old printer going offline' problem could be solved. That printer code isn't written in stone. In fact it was ajusted from being able to print 'asdf' to a daisy wheel printer to working for one person. BTW, I've finished teaching after hours tonight and will be moving forward with a new rxtx release in my free time. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Jun 11 21:28:04 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 23:28:04 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: <466E12C4.1010305@gatworks.com> > Looking at the ParallelImp.c we can probably do better. > The problem stemmed from the possibility that the writev routine could have written some of the buffer, in chunks, printer pauses, refuses any more chunks, and a timeout occurs. Do you or do you not cause an exception to be thrown? Is there a way to set timeout for a ParallelPort data output stream? I cant find it. From tjarvi at qbang.org Mon Jun 11 22:17:23 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Jun 2007 22:17:23 -0600 (MDT) Subject: [Rxtx] [OT] select :-) In-Reply-To: <466E12C4.1010305@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> <466E12C4.1010305@gatworks.com> Message-ID: On Mon, 11 Jun 2007, Uncle George wrote: >> Looking at the ParallelImp.c we can probably do better. >> > The problem stemmed from the possibility that the writev routine could > have written some of the buffer, in chunks, printer pauses, refuses any > more chunks, and a timeout occurs. Do you or do you not cause an > exception to be thrown? > > Is there a way to set timeout for a ParallelPort data output stream? I > cant find it. hmm I looked again after you asked. The timeouts are only controllable on the receive side. This comes from CommPort; the parent. So what we are talking about is some bytes in memory that rxtx has and is supposed to write. A buffer perhaps? The approach with rxtx in the past has been to ignore output buffer sizes. The assumption is that the library does not know how to best handle buffers. There are buffered output streams that can do buffering on top of rxtx for instance. There is also a question regarding what was actually ment when the API was put together. My suspicion is that it was put together while looking at one OS API and was never ment to be anything more than a hook into that API. The comments are fairly telling combined with reading the w32 API. So looking at the problem again.. The current timeout behavior appears fairly arbitrary. Presumably this is to prevent a program from hanging instead of using a helper thread to write - heavy handed for new programmers. Even so, I don't think the write should timeout at all if it is not configurable. >From the API perspective, "What Timeout?" -- Trent Jarvi tjarvi at qbang.org From Steffen.DETTMER at ingenico.com Tue Jun 12 02:14:48 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 12 Jun 2007 10:14:48 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466DA32D.1010602@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: <20070612081447.GU10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Mon, Jun 11, 2007 at 15:31 -0400: > Steffen DETTMER wrote: > > Ahh, oki. Thanks for the clarificaion. > > > > So in short, flush() MUST be called on OutputStream, this is just > > not documented correctly or so clearly (right?). > No. hum (though now I got it, but...). > Flush can be called to force all current data in java buffer's to be > written to the kernel - NOW. > > A flush() can also *imply* that, besides writing out the > buffer's that java employs, may also imply/ask the kernel to > write all data thusfar written to the kernel, to be physically > placed on the destination device - NOW. > > For some OS's there is no need to do a kernel flush(), as the I/O is > synchronized already. Since this is java, you never know what OS your on. (well, but if you're going to kernel level, even flush cannot guarantee that data will "be physically placed". Maybe you're flushing to a file via NFS (and the client "thinks" that it was written, but maybe it was just buffered by the NFS server) or so... but of course such exceptions of the rules are constructable always.) Well, you tell that depending on the OS it can be that flush is needed or it can be that flush is not needed (beacuse the I/O is synchronized already), right? Also, applications should work on any OS, which includes the OSes that do need flush. Since the application cannot know whether flush is needed or not because it doesn't know what the OS is doing, it has to call flush, hasn't it? I mean, if it would not call flush then it would not work on such OSes (except the written data would not be needed at all, but in this would be an artificial example :)). Since applications are supposed to work this would be wrong, wouldn't it? So would it be correct to say: "Applications, that should work under all OSes (including the OSes where the I/O is not synchronised already), have to call flush on OutputStream to ensure the data is transfered to the kernel." or is this wrong? If so, then I'm afraid I missed the point again :( oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Tue Jun 12 04:46:52 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 12 Jun 2007 06:46:52 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070612081447.GU10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> <20070612081447.GU10821@elberon.bln.de.ingenico.com> Message-ID: <466E799C.7060700@gatworks.com> S > (well, but if you're going to kernel level, even flush cannot > guarantee that data will "be physically placed". Thats true now-a-days because ( from "man 2 sync" ) : > According to the standard specification (e.g., SVID), sync() schedules > the writes, but may return before the actual writing is done. However, > since version 1.3.20 Linux does actually wait. (This still does not > guarantee data integrity: modern disks have large caches.) My disk drive has 8mb cache. Maybe you're > flushing to a file via NFS (and the client "thinks" that it was > written, but maybe it was just buffered by the NFS server) or > so... but of course such exceptions of the rules are > constructable always.) > > Well, you tell that depending on the OS it can be that flush is > needed or it can be that flush is not needed (beacuse the I/O is > synchronized already), right? Also, applications should work on > any OS, which includes the OSes that do need flush. Its not OS's that need flush, its applications that want to have some assurance that data is written to the device that really needs to use flush. If your program ( or thread ) dies then it is in your best interest to write out the critical data as soon as possible, as economical as possible. These are trade-off's that the application programmer makes. A big buffer may mean big loss of data, a small buffer may mean spending too much time writing out data. > > > So would it be correct to say: > > "Applications, that should work under all OSes (including the > OSes where the I/O is not synchronised already), have to call > flush on OutputStream to ensure the data is transfered to the > kernel." > > or is this wrong? If so, then I'm afraid I missed the point again > :( > No that is not wrong. Ensuring that data is transfered to the OS is just about what any application can do. From tjarvi at qbang.org Thu Jun 14 08:16:47 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 14 Jun 2007 08:16:47 -0600 (MDT) Subject: [Rxtx] rxtx and usb-serial solution In-Reply-To: References: Message-ID: On Thu, 14 Jun 2007, Vladimir Kirtchev wrote: > Hi Trent, > > I develop a Java application which communicates with devices which have > USB-to-Serial bridge in them. The target OS is Linux. So for this purpose I > use RXTX. > > But I encountered a strange problem - when reading from the InputStream, I > receive series of zeros. I have this problem under Linux only. Under Windows > it is fine. > Actually this problem is the same as the one described here: > http://marc.info/?l=rxtx&m=109703190731748&w=2. > > > So I searched for the problem in the native code. And found that the root of > the problem is in SerialImp.c, > int configure_port( int fd ) > { > ... > ttyset.c_iflag = INPCK; > ... > } > > This line enables input parity checking, and the data sent from the device > is processed by the OS driver before being read with read(). > In this case the driver detects some problem and sets the received bytes to > zero. > > On the other hand in the Java part a set the serial port parameters with > SerialPort.PARITY_NONE. According to me, except all other things, this > should also disable INPCK in c_iflag. > > So I refactored the method translate_parity(...) to the following: > > int translate_parity( JNIEnv *env, struct termios *ttyset, jint parity ) > { > ENTER( "translate_parity" ); > #ifdef CMSPAR > ttyset->c_cflag &= ~(PARENB | PARODD | CMSPAR ); > #endif /* CMSPAR */ > switch( parity ) { > case JPARITY_NONE: > ttyset->c_iflag &= ~INPCK; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_EVEN: > ttyset->c_cflag |= PARENB; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_ODD: > ttyset->c_cflag |= PARENB | PARODD; > LEAVE( "translate_parity" ); > return 0; > #ifdef CMSPAR > case JPARITY_MARK: > ttyset->c_cflag |= PARENB | PARODD | CMSPAR; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_SPACE: > ttyset->c_cflag |= PARENB | CMSPAR; > LEAVE( "translate_parity" ); > return 0; > #endif /* CMSPAR */ > default: > printf("Parity missed %i\n", (int) parity ); > } > > LEAVE( "translate_parity" ); > /* > For some reason the native exceptions are not being caught. Moving this > to the Java side fixed the issue. taj. > throw_java_exception( env, UNSUPPORTED_COMM_OPERATION, > "", "parity value not supported" ); > */ > return 1; > } > > This modification solved the problem and now it works correctly under Linux. > > I think I will be a nice if this is idea is included in a future release of > RXTX. > > Thanks Vadim, I'll try that out. Forwarding to the rxtx mail-list too. This is probably not going to help USB drivers on windows which I'm sure some are looking for. As far as I can tell, windows USB bluetooth and serial dongles are limited by driver functionality. Some are good and others lack key features. -- Trent Jarvi tjarvi at qbang.org From dan.sandberg.lists at gmail.com Mon Jun 18 14:43:39 2007 From: dan.sandberg.lists at gmail.com (Dan Sandberg) Date: Mon, 18 Jun 2007 13:43:39 -0700 Subject: [Rxtx] Fix for JNI Get/Set Field Errors Message-ID: <4676EE7B.7060800@gmail.com> Hi, I've fixed the problems that cause the following JNI error when extra JNI checking ( -Xjni:check ) is turned on. FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) The problem was basically that GetLong was being used to get ints, and SetInt was used for longs. The patch below fixes this. Please let me know if there are any questions / problems. Cheers, -Dan diff -aur old/SerialImp.c src/SerialImp.c --- old/SerialImp.c 2007-06-18 13:24:33.000000000 -0700 +++ src/SerialImp.c 2007-06-18 06:26:26.000000000 -0700 @@ -1337,7 +1337,7 @@ report("init_threads: get eis\n"); jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); report("init_threads: set eis\n"); - (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); + (*eis->env)->SetLongField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); report("init_threads: stop\n"); report_time_end( ); return( 1 ); @@ -1530,7 +1530,7 @@ jobject jobj, jboolean interrupted ) { int fd = get_java_var( env, jobj,"fd","I" ); - struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var( env, jobj, "eis", "J" ); + struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var_long( env, jobj, "eis", "J" ); int result, count=0; char message[80]; @@ -2939,7 +2939,7 @@ /* TRENT */ int flag, count = 0; struct event_info_struct *eis = ( struct event_info_struct * ) - get_java_var( env, *jobj,"eis","J" ); + get_java_var_long( env, *jobj,"eis","J" ); report_time_start(); flag = eis->eventflags[SPE_DATA_AVAILABLE]; @@ -4873,9 +4873,9 @@ exceptions: none comments: ----------------------------------------------------------*/ -size_t get_java_var( JNIEnv *env, jobject jobj, char *id, char *type ) +long get_java_var_long( JNIEnv *env, jobject jobj, char *id, char *type ) { - int result = 0; + long result = 0; jclass jclazz = (*env)->GetObjectClass( env, jobj ); jfieldID jfd = (*env)->GetFieldID( env, jclazz, id, type ); @@ -4889,7 +4889,11 @@ LEAVE( "get_java_var" ); return result; } - result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); + if ( !strcmp( type, "J" ) ) { + result = (long)( (*env)->GetLongField( env, jobj, jfd ) ); + } else { + result = (int) ( (*env)->GetIntField( env, jobj, jfd ) ); + } /* ct7 & gel * Added DeleteLocalRef */ (*env)->DeleteLocalRef( env, jclazz ); if(!strncmp( "fd",id,2) && result == 0) @@ -4900,6 +4904,10 @@ return result; } +int get_java_var( JNIEnv *env, jobject jobj, char *id, char *type ) { + return (int) get_java_var_long( env, jobj, id, type ); +} + /*---------------------------------------------------------- throw_java_exception diff -aur old/SerialImp.h src/SerialImp.h --- old/SerialImp.h 2007-06-18 13:24:39.000000000 -0700 +++ src/SerialImp.h 2007-06-18 06:23:43.000000000 -0700 @@ -413,7 +413,8 @@ void system_wait(); void finalize_event_info_struct( struct event_info_struct * ); int read_byte_array( JNIEnv *, jobject *, int, unsigned char *, int, int ); -size_t get_java_var( JNIEnv *, jobject, char *, char * ); +int get_java_var( JNIEnv *, jobject, char *, char * ); +long get_java_var_long( JNIEnv *, jobject, char *, char * ); jboolean is_interrupted( struct event_info_struct * ); int send_event(struct event_info_struct *, jint, int ); void dump_termios(char *,struct termios *); From yvespielusenet at free.fr Tue Jun 26 03:41:58 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 11:41:58 +0200 Subject: [Rxtx] [PARALLEL] resource in use Message-ID: <1182850918.3483.10.camel@localhost.localdomain> Hello, So now I want to modify the timeout of the library for parallel port. I have downloaded source code. There is a makefile for migw. SO I have installed mingw on ubuntu and modified the makefile.mingw32 to set it for my system. I have no error but some warnings. The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But When I want to use it the jvm crash :( How can I know what is wrong ? How rxtx windows release has been done ? thanks -- yves piel From yvespielusenet at free.fr Tue Jun 26 07:17:02 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 15:17:02 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182850918.3483.10.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> Message-ID: <1182863822.3483.17.camel@localhost.localdomain> Here is the Makefile I use, the output of the 'make' and the log of the jvm when it crashed : - The Makefile : http://yvespiel.free.fr/rxtx/Makefile - The make output : http://yvespiel.free.fr/rxtx/compile.txt - The crash log : http://yvespiel.free.fr/rxtx/hs_err_pid2100.log I have compiled rxtx under Debian testing with mingw : narma at linimi:/tmp/err$ dpkg -l | grep mingw ii mingw32 3.4.5.20060117.1.dfsg-3 ii mingw32-binutils 2.17.50-20070129.1-1 ii mingw32-runtime 3.12-1 thanks fort help :) Le mardi 26 juin 2007 ? 11:41 +0200, yves pielusenet a ?crit : > Hello, > So now I want to modify the timeout of the library for parallel port. I > have downloaded source code. There is a makefile for migw. SO I have > installed mingw on ubuntu and modified the makefile.mingw32 to set it > for my system. > I have no error but some warnings. > The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But > When I want to use it the jvm crash :( > > How can I know what is wrong ? > > How rxtx windows release has been done ? > > thanks > From yvespielusenet at free.fr Tue Jun 26 07:40:11 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 15:40:11 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182863822.3483.17.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> <1182863822.3483.17.camel@localhost.localdomain> Message-ID: <1182865211.3483.21.camel@localhost.localdomain> I have add the options '--enable-stdcall-fixup' to the 'i586-mingw32msvc-ld' commande. Now I have no warning. But the JVM always crashes :( The output seems more detailled, but I don't understand anything... Here is files : http://yvespiel.free.fr/rxtx/2/ -- yves piel Le mardi 26 juin 2007 ? 15:17 +0200, yves pielusenet a ?crit : > Here is the Makefile I use, the output of the 'make' and the log of the > jvm when it crashed : > > - The Makefile : http://yvespiel.free.fr/rxtx/Makefile > - The make output : http://yvespiel.free.fr/rxtx/compile.txt > - The crash log : http://yvespiel.free.fr/rxtx/hs_err_pid2100.log > > I have compiled rxtx under Debian testing with mingw : > narma at linimi:/tmp/err$ dpkg -l | grep mingw > ii mingw32 3.4.5.20060117.1.dfsg-3 > ii mingw32-binutils 2.17.50-20070129.1-1 > ii mingw32-runtime 3.12-1 > > thanks fort help :) > > > Le mardi 26 juin 2007 ? 11:41 +0200, yves pielusenet a ?crit : > > Hello, > > So now I want to modify the timeout of the library for parallel port. I > > have downloaded source code. There is a makefile for migw. SO I have > > installed mingw on ubuntu and modified the makefile.mingw32 to set it > > for my system. > > I have no error but some warnings. > > The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But > > When I want to use it the jvm crash :( > > > > How can I know what is wrong ? > > > > How rxtx windows release has been done ? > > > > thanks > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From yvespielusenet at free.fr Tue Jun 26 08:27:42 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 16:27:42 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182865211.3483.21.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> <1182863822.3483.17.camel@localhost.localdomain> <1182865211.3483.21.camel@localhost.localdomain> Message-ID: <1182868062.3483.24.camel@localhost.localdomain> I think thant the include files of jdk were not for windows but for linux. So I have copied include/ folder from windows to linux and I modified the Makefile to use those file. It compile fine but the JVM always crash :( http://yvespiel.free.fr/rxtx/3/ Le mardi 26 juin 2007 ? 15:40 +0200, yves pielusenet a ?crit : > I have add the options '--enable-stdcall-fixup' to the > 'i586-mingw32msvc-ld' commande. Now I have no warning. But the JVM > always crashes :( The output seems more detailled, but I don't > understand anything... > Here is files : > http://yvespiel.free.fr/rxtx/2/ > From netbeans at gatworks.com Fri Jun 1 05:38:50 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 07:38:50 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <465F7ADD.1010501@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> Message-ID: <4660054A.2040202@gatworks.com> Manuel Naranjo wrote: In the case of my module, you can > unplug the device but it will not delete the symlink until those apps > that had opened the port has closed it. This is done this way to avoid > kernel panics. What does this mean to user code ? I have tried the alternate route ( other than closing ) which is sleep inbetween the I/O errors ( an unplugged USB device). When the device is plugged back in, The writes to the device still get an I/O error. This would seem to be a lost cause for the application. From netbeans at gatworks.com Fri Jun 1 06:35:48 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 08:35:48 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <465F7ADD.1010501@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> Message-ID: <466012A4.90608@gatworks.com> Manuel Naranjo wrote: In the case of my module, you can > unplug the device but it will not delete the symlink until those apps > that had opened the port has closed it. T Did u also mean for this to happen? USB0 was not closed by application. Apparently USB1 got created when USB device was plugged back in. There is only one USB device on a 4 port USB hub. This also seems to suggest that application recovery to be impossible. > Jun 1 07:10:08 mylaptop kernel: garmin_gps 1-1.4:1.0: Garmin GPS usb/tty converter detected > Jun 1 07:10:08 mylaptop kernel: usb 1-1.4: Garmin GPS usb/tty converter now attached to ttyUSB0 > Jun 1 07:15:17 mylaptop kernel: usb 1-1: USB disconnect, address 4 > Jun 1 07:15:17 mylaptop kernel: usb 1-1.4: USB disconnect, address 5 > Jun 1 07:15:17 mylaptop kernel: garmin_gps 1-1.4:1.0: device disconnected > Jun 1 07:15:26 mylaptop kernel: usb 1-1: new full speed USB device using uhci_hcd and address 6 > Jun 1 07:15:26 mylaptop kernel: hub 1-1:1.0: USB hub found > Jun 1 07:15:26 mylaptop kernel: hub 1-1:1.0: 4 ports detected > Jun 1 07:15:27 mylaptop kernel: usb 1-1.4: new full speed USB device using uhci_hcd and address 7 > Jun 1 07:15:27 mylaptop kernel: garmin_gps 1-1.4:1.0: Garmin GPS usb/tty converter detected > Jun 1 07:15:27 mylaptop kernel: usb 1-1.4: Garmin GPS usb/tty converter now attached to ttyUSB1 From naranjo.manuel at gmail.com Fri Jun 1 09:17:22 2007 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Fri, 01 Jun 2007 12:17:22 -0300 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <466012A4.90608@gatworks.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> <466012A4.90608@gatworks.com> Message-ID: <46603882.5050701@gmail.com> Uncle George escribi?: > Manuel Naranjo wrote: > In the case of my module, you can > >> unplug the device but it will not delete the symlink until those apps >> that had opened the port has closed it. T >> > > Did u also mean for this to happen? USB0 was not closed by application. > > Apparently USB1 got created when USB device was plugged back in. There > is only one USB device on a 4 port USB hub. > > This also seems to suggest that application recovery to be impossible. > Exactly there's a dead symlink (you can read and write to it and nothing will happen) and a new port will be created when a new device is connencted. From netbeans at gatworks.com Fri Jun 1 10:20:46 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 12:20:46 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <46603882.5050701@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> <466012A4.90608@gatworks.com> <46603882.5050701@gmail.com> Message-ID: <4660475E.5090202@gatworks.com> Not sure what u mean by "symlink". U cant read/write to it anymore. U get I/O error. In this scenario the device effectively went dead, and only solution is to close the channel. reconnecting the USB device, although dead, but not closed, will create a second device. This does not seem to be a desirable side-effect. The user will now have ttyUSB1, wondering where did ttyUSB0 go to. The application will also be in a confused state, as well as RXTX, because RXTX wont know about ttyUSB1. Manuel Naranjo wrote: > Uncle George escribi?: >> Manuel Naranjo wrote: >> In the case of my module, you can >> >>> unplug the device but it will not delete the symlink until those apps >>> that had opened the port has closed it. T >>> >> Did u also mean for this to happen? USB0 was not closed by application. >> >> Apparently USB1 got created when USB device was plugged back in. There >> is only one USB device on a 4 port USB hub. >> >> This also seems to suggest that application recovery to be impossible. >> > Exactly there's a dead symlink (you can read and write to it and nothing > will happen) and a new port will be created when a new device is connencted. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From arnab.bhaumik at gmail.com Mon Jun 4 01:40:16 2007 From: arnab.bhaumik at gmail.com (arnab bhaumik) Date: Mon, 4 Jun 2007 13:10:16 +0530 Subject: [Rxtx] full duplex com port with rxtx Message-ID: hi , till now i did half duplex communication with rxtx package on com package. my question is : is it possible to use com port with full duplex mode with rxtx package . ther is example of SimpleRead class and SimpleWrite class. it is clear that if i can use both the class simultaneously then full duplex is possible......... arnab/vu2bpw -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070604/6edb0453/attachment-0001.html From lists at iDIAcomputing.com Mon Jun 4 07:53:17 2007 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Mon, 04 Jun 2007 09:53:17 -0400 Subject: [Rxtx] full duplex com port with rxtx In-Reply-To: References: Message-ID: <4664194D.90301@iDIAcomputing.com> arnab bhaumik wrote: > hi , > > till now i did half duplex communication with rxtx package on com > package. > > my question is : is it possible to use com port with full duplex mode > with rxtx package . > > > ther is example of SimpleRead class and SimpleWrite class. it is > clear that if i can use both the class simultaneously then full duplex > is possible......... I haven't looked at the SimpleRead and SimpleWrite classes (I originally wrote my code for the javax.comm api), but full duplex is certainly possible. My CommReader class requires an object analogous to a OutputStream or Writer. When started, it spawns a thread that reads the comm port and writes to that output device. In this way the input is asynchronous and dependent on the actual input data. For full duplex, I extend that class with CommReaderWriter, which adds synchronous output methods. Hope that helps, George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From supsoop at hotmail.com Mon Jun 4 15:21:06 2007 From: supsoop at hotmail.com (soop soop) Date: Mon, 04 Jun 2007 21:21:06 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- Message-ID: Hi Guys, Looked through the archives but still cannot figure this out. I have a Motorola G24 GPRS/GSM modem that I am connecting to my server running Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not detecting the port, CommPortIdentifier.getPortIdentifiers(). I have added the line to RXTXCommDriver: "ttyACM" // for USB Modems Rxtx still does not seem to find the port. Is there something I am missing to make this port visable? [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control Model driver for USB modems and ISDN adapters I really need your help as I have moved my server from windows to Linux and have been down for a few days because of this .. Thanks so much! _________________________________________________________________ PC Magazine’s 2007 editors’ choice for best Web mail—award-winning Windows Live Hotmail. http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 From tjarvi at qbang.org Mon Jun 4 16:17:35 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Jun 2007 16:17:35 -0600 (MDT) Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: On Mon, 4 Jun 2007, soop soop wrote: > Hi Guys, > > Looked through the archives but still cannot figure this out. I have a > Motorola G24 GPRS/GSM modem that I am connecting to my server running Ubuntu. > I can see my modem as is shows up as ttyACM0, but RXTX is not detecting the > port, CommPortIdentifier.getPortIdentifiers(). > > I have added the line to RXTXCommDriver: > > "ttyACM" // for USB Modems > > Rxtx still does not seem to find the port. Is there something I am missing to > make this port visable? > > [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver > [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device > [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control Model > driver for USB modems and ISDN adapters > > I really need your help as I have moved my server from windows to Linux and > have been down for a few days because of this .. Thanks so much! > You could try the INSTALL documentation that comes with the source for possible solutions. Those usually involve lockfile creation, permissions on the device file or the device is in use by another application (even another session of your application). The usual commands: ls -l /dev/ttyACM0 fuser /dev/ttyACM0 touch /var/lock/LCK.testfile && rm -f /var/lock/LCK.testfile whoami To disable lockfiles: ../configure --disable-lockfiles && make install -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Jun 4 16:22:52 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 04 Jun 2007 18:22:52 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <466490BC.3090801@gatworks.com> soop soop wrote: > I really need your help as I have moved my server from windows to Linux > and have been down for a few days because of this .. Thanks so much! can u open the device ? ie is the file protection/permissions keeping you out? From supsoop at hotmail.com Mon Jun 4 16:44:40 2007 From: supsoop at hotmail.com (soop soop) Date: Mon, 04 Jun 2007 22:44:40 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <466490BC.3090801@gatworks.com> Message-ID: Thanks for the reply, I see no exceptions being thrown, just no detection of the port whats so ever. I will run rxtx in debug mode and log. If this were a permissions issue would I not see some exceptions being thrown? >From: Uncle George >Reply-To: RXTX Developers and Users >To: RXTX Developers and Users >Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >Date: Mon, 04 Jun 2007 18:22:52 -0400 > >soop soop wrote: > > > I really need your help as I have moved my server from windows to Linux > > and have been down for a few days because of this .. Thanks so much! > >can u open the device ? ie is the file protection/permissions keeping >you out? >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ Get a preview of Live Earth, the hottest event this summer - only on MSN http://liveearth.msn.com?source=msntaglineliveearthhm From netbeans at gatworks.com Mon Jun 4 17:06:15 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 04 Jun 2007 19:06:15 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <46649AE7.10405@gatworks.com> Exceptions on what? On startup it wants to lookup all devices in /dev that it is capable of opening ( within the list of specific 'comm' devices ). If it cannot open, then does not get onto list. Part of this process, if configured, will also test if the "LOCK" schema can also be opened for the device. then it gets on the list of avail comm port. soop soop wrote: > Thanks for the reply, > > I see no exceptions being thrown, just no detection of the port whats so > ever. I will run rxtx in debug mode and log. If this were a permissions > issue would I not see some exceptions being thrown? > > >> From: Uncle George >> Reply-To: RXTX Developers and Users >> To: RXTX Developers and Users >> Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >> Date: Mon, 04 Jun 2007 18:22:52 -0400 >> >> soop soop wrote: >> >>> I really need your help as I have moved my server from windows to Linux >>> and have been down for a few days because of this .. Thanks so much! >> can u open the device ? ie is the file protection/permissions keeping >> you out? >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _________________________________________________________________ > Get a preview of Live Earth, the hottest event this summer - only on MSN > http://liveearth.msn.com?source=msntaglineliveearthhm > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From alex.flint at gmail.com Mon Jun 4 21:31:49 2007 From: alex.flint at gmail.com (Alex Flint) Date: Tue, 5 Jun 2007 13:01:49 +0930 Subject: [Rxtx] random EXCEPTION_ACCESS_VIOLATION errors Message-ID: Hi All, I'm running winXP and RXTX 2.1-7r2 (the latest from the webpage as of June 2007). I'm sending sequences of 64 lines (each line has about 15 chars) at various intervals. The strings are sent fine, until I get the following error (from hs_err_pid3316.log, at the end of this email). What can I do to avoid the error? Obviously this is a low-level memory exception, but is there any way I can keep the JVM running after such an error? I noticed the exact same problem here: http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20070129/1180520.html Cheers, Alex # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x100034fb, pid=3316, tid=2400 # # Java VM: Java HotSpot(TM) Client VM (1.6.0_01-b06 mixed mode, sharing) # Problematic frame: # C [rxtxSerial.dll+0x34fb] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # --------------- T H R E A D --------------- Current thread (0x00386400): JavaThread "main" [_thread_in_native, id=2400] siginfo: ExceptionCode=0xc0000005, reading address 0x20726f78 Registers: EAX=0x20726f20, EBX=0x6d8922c0, ECX=0x00000005, EDX=0x20726f20 ESP=0x003efa30, EBP=0x003efb68, ESI=0x269728a0, EDI=0x00386400 EIP=0x100034fb, EFLAGS=0x00010212 Top of Stack: (sp=0x003efa30) 0x003efa30: 003efa3c 003efa64 0000000f ffffffff 0x003efa40: 003efa40 2a97f808 003efa6c 2b190ca8 0x003efa50: 00000000 2b190ec0 003efa90 008e2dd7 0x003efa60: 003efa90 008e2dd7 26977f88 6d815e72 0x003efa70: 00000004 2696eae0 0000008a 003efb0c 0x003efa80: 6d852b4a 2696eae0 00000003 26970930 0x003efa90: 000000cb 2696eae0 6d86b264 00385d40 0x003efaa0: 0000003f 003efb0c 26977f90 2ace65d8 Instructions: (pc=0x100034fb) 0x100034eb: ff ff 8d 76 00 eb 02 89 f6 90 8b 45 f8 8b 55 f8 0x100034fb: 8b 4a 58 83 c9 04 89 48 58 83 c4 f8 8b 45 f8 8b Stack: [0x003a0000,0x003f0000), sp=0x003efa30, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x34fb] Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j gnu.io.RXTXPort.writeArray([BIIZ)V+0 j gnu.io.RXTXPort$SerialOutputStream.write([B)V+76 j com.bjt.media.server.CommLink.send(Ljava/lang/String;)V+48 j com.bjt.media.server.DigitoolConnection.select(I)V+73 j com.bjt.media.server.DigitoolConnection.main([Ljava/lang/String;)V+74 v ~StubRoutines::call_stub --------------- P R O C E S S --------------- Java Threads: ( => current thread ) 0x02a69400 JavaThread "Thread-0" [_thread_in_native, id=3052] 0x02a4d000 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=3920] 0x02a48400 JavaThread "CompilerThread0" daemon [_thread_blocked, id=1968] 0x02a47400 JavaThread "Attach Listener" daemon [_thread_blocked, id=2984] 0x02a46400 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=2660] 0x02a41c00 JavaThread "Finalizer" daemon [_thread_blocked, id=3924] 0x02a3d800 JavaThread "Reference Handler" daemon [_thread_blocked, id=4008] =>0x00386400 JavaThread "main" [_thread_in_native, id=2400] Other Threads: 0x02a34400 VMThread [id=3708] 0x02a4e800 WatcherThread [id=3964] VM state:not at safepoint (normal execution) VM Mutex/Monitor currently owned by a thread: None Heap def new generation total 960K, used 131K [0x22960000, 0x22a60000, 0x22e40000) eden space 896K, 7% used [0x22960000, 0x22970ea8, 0x22a40000) from space 64K, 99% used [0x22a50000, 0x22a5fff8, 0x22a60000) to space 64K, 0% used [0x22a40000, 0x22a40000, 0x22a50000) tenured generation total 4096K, used 76K [0x22e40000, 0x23240000, 0x26960000) the space 4096K, 1% used [0x22e40000, 0x22e53060, 0x22e53200, 0x23240000) compacting perm gen total 12288K, used 137K [0x26960000, 0x27560000, 0x2a960000) the space 12288K, 1% used [0x26960000, 0x26982518, 0x26982600, 0x27560000) ro space 8192K, 62% used [0x2a960000, 0x2ae5e4e8, 0x2ae5e600, 0x2b160000) rw space 12288K, 52% used [0x2b160000, 0x2b7a0e78, 0x2b7a1000, 0x2bd60000) Dynamic libraries: 0x00400000 - 0x00423000 C:\Program Files\Java\jre1.6.0_01\bin\javaw.exe 0x7c900000 - 0x7c9b0000 C:\WINDOWS\system32\ntdll.dll 0x7c800000 - 0x7c8f4000 C:\WINDOWS\system32\kernel32.dll 0x77dd0000 - 0x77e6b000 C:\WINDOWS\system32\ADVAPI32.dll 0x77e70000 - 0x77f01000 C:\WINDOWS\system32\RPCRT4.dll 0x7e410000 - 0x7e4a0000 C:\WINDOWS\system32\USER32.dll 0x77f10000 - 0x77f57000 C:\WINDOWS\system32\GDI32.dll 0x76390000 - 0x763ad000 C:\WINDOWS\system32\IMM32.DLL 0x7c340000 - 0x7c396000 C:\Program Files\Java\jre1.6.0_01\bin\msvcr71.dll 0x6d7c0000 - 0x6da07000 C:\Program Files\Java\jre1.6.0_01\bin\client\jvm.dll 0x76b40000 - 0x76b6d000 C:\WINDOWS\system32\WINMM.dll 0x5cd70000 - 0x5cd77000 C:\WINDOWS\system32\serwvdrv.dll 0x5b0a0000 - 0x5b0a7000 C:\WINDOWS\system32\umdmxfrm.dll 0x6d310000 - 0x6d318000 C:\Program Files\Java\jre1.6.0_01\bin\hpi.dll 0x76bf0000 - 0x76bfb000 C:\WINDOWS\system32\PSAPI.DLL 0x6d770000 - 0x6d77c000 C:\Program Files\Java\jre1.6.0_01\bin\verify.dll 0x6d3b0000 - 0x6d3cf000 C:\Program Files\Java\jre1.6.0_01\bin\java.dll 0x6d7b0000 - 0x6d7bf000 C:\Program Files\Java\jre1.6.0_01\bin\zip.dll 0x10000000 - 0x10012000 C:\Documents and Settings\Alex\workspace\MediaServer\rxtxSerial.dll 0x73d90000 - 0x73db7000 C:\WINDOWS\system32\crtdll.dll VM Arguments: jvm_args: -Djava.library.path=C:\Documents and Settings\Alex\workspace\MediaServer java_command: com.bjt.media.server.DigitoolConnection Launcher Type: SUN_STANDARD Environment Variables: CLASSPATH=.;C:\Program Files\Java\j2re1.4.2_07\lib\ext\QTJava.zip PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\wbem;c:\applications\php;C:\Program Files\MATLAB\R2006a\bin\win32;C:\Roger\Projects\UAV\Bin\Debug;C:\Program Files\Microsoft SQL Server\80\Tools\Binn\;c:\Program Files\Microsoft SQL Server\90\Tools\binn\;C:\Program Files\QuickTime\QTSystem\;C:\Pfps\system;C:\Program Files\Java\jdk1.6.0_01\bin;C:\Program Files\Java\jdk1.6.0_01\jre\bin USERNAME=Alex OS=Windows_NT PROCESSOR_IDENTIFIER=x86 Family 15 Model 4 Stepping 1, GenuineIntel --------------- S Y S T E M --------------- OS: Windows XP Build 2600 Service Pack 2 CPU:total 1 family 15, cmov, cx8, fxsr, mmx, sse, sse2 Memory: 4k page, physical 1046508k(275288k free), swap 2522816k(1909176k free) vm_info: Java HotSpot(TM) Client VM (1.6.0_01-b06) for windows-x86, built on Mar 14 2007 00:24:02 by "java_re" with unknown MS VC++:1310 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070604/c87ae1f0/attachment-0001.html From alwyn.schoeman at gmail.com Tue Jun 5 00:10:19 2007 From: alwyn.schoeman at gmail.com (Alwyn Schoeman) Date: Tue, 5 Jun 2007 08:10:19 +0200 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Hi, I'm using a similar modem. By default rxtx doesn't look for devices that start with ACM, so you need to modify the source code and recompile. Look in RXTXCommDriver and add values for ACM in the registerScannedPorts method in the Linux specific parts. Look for osName.equals("Linux")... On 6/4/07, soop soop wrote: > > Hi Guys, > > Looked through the archives but still cannot figure this out. I have a > Motorola G24 GPRS/GSM modem that I am connecting to my server running > Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not > detecting the port, CommPortIdentifier.getPortIdentifiers(). > > I have added the line to RXTXCommDriver: > > "ttyACM" // for USB Modems > > Rxtx still does not seem to find the port. Is there something I am missing > to make this port visable? > > [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver > [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device > [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control > Model > driver for USB modems and ISDN adapters > > I really need your help as I have moved my server from windows to Linux > and > have been down for a few days because of this .. Thanks so much! > > _________________________________________________________________ > PC Magazine's 2007 editors' choice for best Web mail?award-winning Windows > Live Hotmail. > > http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -- Alwyn Schoeman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/b6cb3053/attachment-0001.html From naranjo.manuel at gmail.com Tue Jun 5 06:48:45 2007 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Tue, 05 Jun 2007 09:48:45 -0300 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> References: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Message-ID: <46655BAD.7010501@gmail.com> That's right, an easier solution is creating symlinks to acm. For example make ttyS70 to 79 point to ACM0 to 9 and that will help you a lot, and doesn't even require compile. > Hi, > > I'm using a similar modem. By default rxtx doesn't look for devices > that start with ACM, so you need to modify the > source code and recompile. > > Look in RXTXCommDriver and add values for ACM in the > registerScannedPorts method in the Linux specific parts. Look for > osName.equals("Linux")... > From juanemc2 at gmail.com Tue Jun 5 07:02:43 2007 From: juanemc2 at gmail.com (Juan) Date: Tue, 5 Jun 2007 10:02:43 -0300 Subject: [Rxtx] Problems with Epson TMU220B POSPrinter using XON/XOFF Flow Control and rxtx jar and dll's with the serial port. Message-ID: Hi!, I?m having trouble printing to the serial port using the latest version of rxtx jar and dll's with an Epson POSPrinter. I`ve switched the printer to work with XON/XOFF Flow Control and have watched the serial port to be sure the printer is sending the XON XOFF stop and go characters. I`ve setted the port like this: CommPortIdentifier commPortIdentifier = CommPortIdentifier.* getPortIdentifier*(_portName); SerialPort serialPort = (SerialPort)commPortIdentifier.open(*this*.getClass().getName(), 2000); serialPort.setSerialPortParams(_baudRate, _dataBits, _stopBits, _parity); serialPort.setFlowControlMode( SerialPort.*FLOWCONTROL_XONXOFF_IN* | SerialPort.*FLOWCONTROL_XONXOFF_OUT*); where the baudRate is 9600 the dataBits is 8 the stopBits is 1 and the parity is 0 It seems as the library isn`t taking into account the XON XOFF setting. I would like to know if I`m setting correctly the Flow Control and if you had had any experiences using XON XOFF flow control and could give me some help to solve my problem. I`m very thankful in advance, Yours, Juan Polero -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/b080995a/attachment-0001.html From ehdez.correo at gmail.com Tue Jun 5 07:12:53 2007 From: ehdez.correo at gmail.com (=?ISO-8859-1?Q?Enrique_Hern=E1ndez?=) Date: Tue, 5 Jun 2007 09:12:53 -0400 Subject: [Rxtx] problem with rxtx Message-ID: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Hello: I doing a simple test to show the serial ports. This is the code: import java.util.Enumeration; import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; public class Show { private Enumeration portList; private CommPortIdentifier portId; private SerialPort port; /** Creates a new instance of Show */ public Show() { } public static void main(String args[]){ Show show = new Show(); show.portList = CommPortIdentifier.getPortIdentifiers(); String tPort = ""; System.out.println("========================================="); while(show.portList.hasMoreElements()){ show.portId = (CommPortIdentifier)show.portList.nextElement(); if(show.portId.getPortType() == CommPortIdentifier.PORT_SERIAL) tPort = "Serial"; else tPort = "Parallel"; System.out.println(show.portId.getName() + " " + tPort); } } } whit The problem is that this code not show the serial ports, this show the no use serial ports. I want to connect whit the modem but when windows open and connect the modem my application don't see the port(COMM3) when it is connect. what I can do? Is that the correct way to know the ports? thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/eedd744b/attachment-0001.html From ehdez.correo at gmail.com Tue Jun 5 07:42:13 2007 From: ehdez.correo at gmail.com (=?ISO-8859-1?Q?Enrique_Hern=E1ndez?=) Date: Tue, 5 Jun 2007 09:42:13 -0400 Subject: [Rxtx] serial port Message-ID: <4a814e1f0706050642p4ce9ac7bka80f9479c524c5ea@mail.gmail.com> Hello: How I can ask to the port what device is connect and information about this device. thanks. bye. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/4d10d26a/attachment-0001.html From supsoop at hotmail.com Tue Jun 5 09:29:00 2007 From: supsoop at hotmail.com (soop soop) Date: Tue, 05 Jun 2007 15:29:00 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Message-ID: Hi Guys, Thanks for all your help. I found the problem. I created a user, Tomcat55, for my tomcat but it did not belong to any group. I then added this user to dialout group to have access to the device ttyACM0. Works perfectly! Again permissions was the issue. This also seems to be persistent as a server reboot does not effect the access. Cheers! >From: "Alwyn Schoeman" >Reply-To: RXTX Developers and Users >To: "RXTX Developers and Users" >Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >Date: Tue, 5 Jun 2007 08:10:19 +0200 > >Hi, > >I'm using a similar modem. By default rxtx doesn't look for devices that >start with ACM, so you need to modify the >source code and recompile. > >Look in RXTXCommDriver and add values for ACM in the registerScannedPorts >method in the Linux specific parts. Look for osName.equals("Linux")... > >On 6/4/07, soop soop wrote: >> >>Hi Guys, >> >>Looked through the archives but still cannot figure this out. I have a >>Motorola G24 GPRS/GSM modem that I am connecting to my server running >>Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not >>detecting the port, CommPortIdentifier.getPortIdentifiers(). >> >>I have added the line to RXTXCommDriver: >> >>"ttyACM" // for USB Modems >> >>Rxtx still does not seem to find the port. Is there something I am missing >>to make this port visable? >> >>[ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver >>[ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device >>[ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control >>Model >>driver for USB modems and ISDN adapters >> >>I really need your help as I have moved my server from windows to Linux >>and >>have been down for a few days because of this .. Thanks so much! >> >>_________________________________________________________________ >>PC Magazine's 2007 editors' choice for best Web mail—award-winning Windows >>Live Hotmail. >> >>http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 >> >> >>_______________________________________________ >>Rxtx mailing list >>Rxtx at qbang.org >>http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > >-- >Alwyn Schoeman >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ Need a break? Find your escape route with Live Search Maps. http://maps.live.com/default.aspx?ss=Restaurants~Hotels~Amusement%20Park&cp=33.832922~-117.915659&style=r&lvl=13&tilt=-90&dir=0&alt=-1000&scene=1118863&encType=1&FORM=MGAC01 From netbeans at gatworks.com Tue Jun 5 09:42:31 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 11:42:31 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <46658467.20101@gatworks.com> soop soop wrote: > > Hi Guys, > > Thanks for all your help. I found the problem. I created a user, > Tomcat55, for my tomcat but it did not belong to any group. I then added Look at man pages for the program udev. From tjarvi at qbang.org Tue Jun 5 18:18:17 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Jun 2007 18:18:17 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Message-ID: On Tue, 5 Jun 2007, Enrique Hern?ndez wrote: > The problem is that this code not show the serial ports, this show the no > use serial ports. I want to connect whit the modem but when windows open and > connect the modem my application don't see the port(COMM3) when it is > connect. > what I can do? > Is that the correct way to know the ports? > Hello, We may have problems understanding each other. On windows, the port will not be an available serial port if another application has the port open. That is just how the library behaves. If you can not see the port in the enumerated list, you could not open it. Also note that enumeration only happens once. If you add a port such as a new USB dongle, the port will not be visible until the next time your application runs. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Tue Jun 5 18:45:01 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 20:45:01 -0400 Subject: [Rxtx] problem with rxtx In-Reply-To: References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Message-ID: <4666038D.8090700@gatworks.com> Trent Jarvi wrote: > > > Also note that enumeration only happens once. If you add a port such as > a new USB dongle, the port will not be visible until the next time your > application runs. Is this written in stone ? somewhere? From tjarvi at qbang.org Tue Jun 5 18:54:36 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Jun 2007 18:54:36 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <4666038D.8090700@gatworks.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> Message-ID: On Tue, 5 Jun 2007, Uncle George wrote: > Trent Jarvi wrote: >> >> >> Also note that enumeration only happens once. If you add a port such as >> a new USB dongle, the port will not be visible until the next time your >> application runs. > > Is this written in stone ? somewhere? It is just the current behavior. There is nothing preventing a fix that allows reenumeration. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Tue Jun 5 19:55:19 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 21:55:19 -0400 Subject: [Rxtx] problem with rxtx In-Reply-To: References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> Message-ID: <46661407.4020308@gatworks.com> >> Is this written in stone ? somewhere? > > It is just the current behavior. There is nothing preventing a fix that > allows reenumeration. With usb, ..... , things come and go. Seems a shame that you have to kill application to get at the device u just plugged in. From joachim at buechse.ch Wed Jun 6 01:50:06 2007 From: joachim at buechse.ch (Joachim Buechse) Date: Wed, 6 Jun 2007 09:50:06 +0200 Subject: [Rxtx] problem with rxtx In-Reply-To: <46661407.4020308@gatworks.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> <46661407.4020308@gatworks.com> Message-ID: <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> On MacOS RXTX's enumeration handling is more flexible. It will find new ports that are added during the lifetime of the application. But this is inherently incompatible with suns javax.comm implementation... Regards, Joachim On 06.06.2007, at 03:55, Uncle George wrote: > >>> Is this written in stone ? somewhere? >> >> It is just the current behavior. There is nothing preventing a >> fix that >> allows reenumeration. > > With usb, ..... , things come and go. Seems a shame that you have to > kill application to get at the device u just plugged in. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Jun 6 06:06:48 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Jun 2007 06:06:48 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> <46661407.4020308@gatworks.com> <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> Message-ID: Sun's javax.comm is not a major concern going forward. As long as we do not break old applications using rxtx, I see no reason to limit rxtx to that convention. We have already rejected version 3 from Sun as a dead end and limited our compatability to version 2. That does not mean we will not try to work with Sun and others but the current javax.comm convention (v3) is not a well conceived path. There has been discussion about doing a JSR which is one valid option. On Wed, 6 Jun 2007, Joachim Buechse wrote: > On MacOS RXTX's enumeration handling is more flexible. It will find > new ports that are added during the lifetime of the application. But > this is inherently incompatible with suns javax.comm implementation... > > Regards, > Joachim > > On 06.06.2007, at 03:55, Uncle George wrote: > >> >>>> Is this written in stone ? somewhere? >>> >>> It is just the current behavior. There is nothing preventing a >>> fix that >>> allows reenumeration. >> >> With usb, ..... , things come and go. Seems a shame that you have to >> kill application to get at the device u just plugged in. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From yvespielusenet at free.fr Wed Jun 6 08:46:35 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 16:46:35 +0200 Subject: [Rxtx] [PARALLEL] resource in use Message-ID: <1181141195.3407.20.camel@localhost.localdomain> Hello, I want to use rxtx in my application. I haveto send data to a very old printer (which have a drum and hammers http://perso.orange.fr/tiie/page00010017.html) This is printer is connecter with centronics. It works well but, while it's writting and I putthe printer off-line, after about 45 seconds, I have this error : ------------------------------------- java.io.IOException: La ressource demand?e est en cours d'utilisation. in writeArray at gnu.io.LPRPort.writeArray(Native Method) at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:292) at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:161) at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:156) at mce.buffer.bufferManager.BufferManager$PrintBuffer.run(BufferManager.java:141) The IOexception means "The wanted resource is in use" ------------------------------------- Here is the line 141 of BufferManager : ------------------------------------- while(send){ try{ fos.write(bb); <=== line 141 send = false; } catch(Exception e){ javax.swing.JOptionPane.showMessageDialog(null, "Erreur d'envoie. Veuillez cliquer sur OK pour relancer l'impression de la vignette.\nV?rifiez votre impression !", "Erreur d'envoie", javax.swing.JOptionPane.WARNING_MESSAGE); e.printStackTrace(System.err); System.err.flush(); System.out.println(e); send = true; } } -------------------------------- 'fos' is an outputstream which contains the rxtx stream (this.os is the rxtx outputstream) : -------------------------------- public void write(byte[] bb) throws IOException{ this.write(bb, 0, bb.length); } public void write(byte[] bb, int off, int len) throws IOException{ while(!imp1.isPrinterSelected() || !imp2.isPrinterSelected()){ } this.os.write(bb, off, len); } -------------------------------- Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( can you help me ? thank you :) -- yves piel From yvespielusenet at free.fr Wed Jun 6 09:11:15 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 17:11:15 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181141195.3407.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> Message-ID: <1181142675.3407.23.camel@localhost.localdomain> I forgot to tell that It's under windows XP and java 1.5. Le mercredi 06 juin 2007 ? 16:46 +0200, yves pielusenet a ?crit : > Hello, > I want to use rxtx in my application. I haveto send data to a very old > printer (which have a drum and hammers > http://perso.orange.fr/tiie/page00010017.html) > This is printer is connecter with centronics. It works well but, while > it's writting and I putthe printer off-line, after about 45 seconds, I > have this error : > ------------------------------------- > java.io.IOException: La ressource demand?e est en cours d'utilisation. > in writeArray > at gnu.io.LPRPort.writeArray(Native Method) > at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:292) > at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:161) > at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:156) > at mce.buffer.bufferManager.BufferManager$PrintBuffer.run(BufferManager.java:141) > > The IOexception means "The wanted resource is in use" > ------------------------------------- > > Here is the line 141 of BufferManager : > > ------------------------------------- > while(send){ > try{ > fos.write(bb); <=== line 141 > send = false; > } > catch(Exception e){ > javax.swing.JOptionPane.showMessageDialog(null, "Erreur d'envoie. Veuillez cliquer sur OK pour relancer l'impression de la vignette.\nV?rifiez votre impression !", "Erreur d'envoie", javax.swing.JOptionPane.WARNING_MESSAGE); > e.printStackTrace(System.err); > System.err.flush(); > System.out.println(e); > send = true; > } > } > -------------------------------- > 'fos' is an outputstream which contains the rxtx stream (this.os is the rxtx outputstream) : > > -------------------------------- > public void write(byte[] bb) throws IOException{ > this.write(bb, 0, bb.length); > } > public void write(byte[] bb, int off, int len) throws IOException{ > while(!imp1.isPrinterSelected() || !imp2.isPrinterSelected()){ > } > this.os.write(bb, off, len); > } > -------------------------------- > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > can you help me ? > > thank you :) > From netbeans at gatworks.com Wed Jun 6 09:21:46 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 11:21:46 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181141195.3407.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> Message-ID: <4666D10A.8000507@gatworks.com> } > -------------------------------- > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > can you help me ? > > thank you :) > windoz or linux? ( I guess windoz ) for windoz, there appears to be a timeout ( as Comments suggest ) of about 40seconds. > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } for linux, there is no implied timeout. > if( write( fd, bytes, count ) < 0 ) > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); From netbeans at gatworks.com Wed Jun 6 09:39:41 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 11:39:41 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666D10A.8000507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> Message-ID: <4666D53D.90000@gatworks.com> Uncle George wrote: > } >> -------------------------------- >> >> Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( >> >> can you help me ? From reading the code, I can see your concern. And it appears you are correct, because some of the data will be sent to the OS printer buffers, and then it will refuse to accept anymore. Unfortunately, writeArray does not return the num of characters written :{ So application has no idea to how many characters were accepted by the OS. I dont do windoz, so I cant say with absolute certainty what windoz will do with an off-line condition. If you have the source, and can compile, then maybe u can increase the loop count to hit 4hours? From yvespielusenet at free.fr Wed Jun 6 09:53:25 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 17:53:25 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666D10A.8000507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> Message-ID: <1181145205.3407.35.camel@localhost.localdomain> Thank you for your explanation :) This timeout comes when no data has been send to the printer after 40seconds if I well understand. But why there is such a timeout ? If I setthe printer offline while it's printing I mustn't have an exception. I don't understand why the "printer should solv all problems like buffer full" in 40 seconds. If I pause the printer the buffer will not be emptied, isn't it ? I not very familiar with C/C++, but it seem that the exception is thrown only when countWritten == 0, that means no data at all has been sent. So Is my code is good since when I intercept this exception I send all my buffer again. There is no way that the printer receive two times same bytes ? thanks ps: yes the application is running on windows XP since I developpe under Debian Le mercredi 06 juin 2007 ? 11:21 -0400, Uncle George a ?crit : > } > > -------------------------------- > > > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > > > can you help me ? > > > > thank you :) > > > > windoz or linux? ( I guess windoz ) > > for windoz, there appears to be a timeout ( as Comments suggest ) of > about 40seconds. > > while( count > 0 ){ > > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > > /* > > this are 20 * 2 seconds, in this time a printer (or other parallel device) > > should solv all problems like buffer full, etc > > */ > > if(errorCount++ < 20){ > > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > > continue; > > } > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > for linux, there is no implied timeout. > > if( write( fd, bytes, count ) < 0 ) > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Wed Jun 6 10:34:24 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 12:34:24 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181145205.3407.35.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> Message-ID: <4666E210.30507@gatworks.com> yves pielusenet wrote: > Thank you for your explanation :) > This timeout comes when no data has been send to the printer after > 40seconds if I well understand. But why there is such a timeout ? If I > setthe printer offline while it's printing I mustn't have an exception. > I don't understand why the "printer should solv all problems like buffer > full" in 40 seconds. If I pause the printer the buffer will not be > emptied, isn't it ? > > I not very familiar with C/C++, but it seem that the exception is thrown > only when countWritten == 0, that means no data at all has been sent. So > Is my code is good since when I intercept this exception I send all my > buffer again. There is no way that the printer receive two times same > bytes ? More technically, the function call returns and reports that 0 characters was written in this call. when 0 characters are written, it will check how many times 0 characters was written. If it has tried LESS than 20 times(errorCount), it will sleep() and try to write again. After 20 times, it wont sleep, but throw you the exception. Now suppose you are writing a 120 character line. you off-lined/paused your printer. The OS has room for 80 more characters in it's printer buffer. The WriteFile() will have a char count of 120, but on return the countWritten = 80. You still have 40 more characters to print. Since countWritten != 0, the counters: bytes += countWritten; count -= countWritten; get updated, and the Writefile now has a count of 40 characters. Since the printer is off-line, the countwritten is 0. And so the loop continues, till 40 seconds is up. As to why it is this way, i dont know ( not a windoz maven ); Also the sleep(20) in the loop is not so intuitive to suggest 2 seconds of sleep. I would have guessed 20seconds, or 20milliseconds. But go figure. BTW: Since your computer sends you error messages in French, does it curse in English? :)))) From yvespielusenet at free.fr Thu Jun 7 02:27:44 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Thu, 07 Jun 2007 10:27:44 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666E210.30507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> Message-ID: <1181204864.3501.10.camel@localhost.localdomain> Maybe in my case I should re-compile rxtx and change the code. Instead of send an exception I should display a dialog box to ask if it's printer problem or if it should trie to send bytes. Something like : while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } if(displayDialogBox("Try again to send datas ??")){ errorCount = 0; } else{ throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } } Le mercredi 06 juin 2007 ? 12:34 -0400, Uncle George a ?crit : > yves pielusenet wrote: > > Thank you for your explanation :) > > This timeout comes when no data has been send to the printer after > > 40seconds if I well understand. But why there is such a timeout ? If I > > setthe printer offline while it's printing I mustn't have an exception. > > I don't understand why the "printer should solv all problems like buffer > > full" in 40 seconds. If I pause the printer the buffer will not be > > emptied, isn't it ? > > > > I not very familiar with C/C++, but it seem that the exception is thrown > > only when countWritten == 0, that means no data at all has been sent. So > > Is my code is good since when I intercept this exception I send all my > > buffer again. There is no way that the printer receive two times same > > bytes ? > More technically, the function call returns and reports that 0 > characters was written in this call. > when 0 characters are written, it will check how many times 0 characters > was written. If it has tried LESS than 20 times(errorCount), it will > sleep() and try to write again. > After 20 times, it wont sleep, but throw you the exception. > > Now suppose you are writing a 120 character line. you off-lined/paused > your printer. The OS has room for 80 more characters in it's printer > buffer. The WriteFile() will have a char count of 120, but on return the > countWritten = 80. You still have 40 more characters to print. > Since countWritten != 0, the counters: > bytes += countWritten; > count -= countWritten; > get updated, and the Writefile now has a count of 40 characters. Since > the printer is off-line, the countwritten is 0. And so the loop > continues, till 40 seconds is up. > > As to why it is this way, i dont know ( not a windoz maven ); > Also the sleep(20) in the loop is not so intuitive to suggest 2 seconds > of sleep. I would have guessed 20seconds, or 20milliseconds. But go figure. > > BTW: Since your computer sends you error messages in French, does it > curse in English? :)))) > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 06:11:43 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 08:11:43 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181204864.3501.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> Message-ID: <4667F5FF.8070903@gatworks.com> your suggestion appears good. I dont know what displayDialogBox exactly will do, so all I can say it that it looks good. But I'd like to wait 10min before first dialog box And a 5 min wait for every dialog box there after. And since these are custom solution/choices, maybe a more exact explanation of what the issue is. if(errorCount++ < 300){ // wait 10min ( 10min * 60sec / 2 ) Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } if(displayDialogBox("Printer has Paused. Retry sending data?")){ errorCount = 150; // Wait for 5 min thereafter continue; } > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } yves pielusenet wrote: > Maybe in my case I should re-compile rxtx and change the code. Instead > of send an exception I should display a dialog box to ask if it's > printer problem or if it should trie to send bytes. Something like : > > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > > if(displayDialogBox("Try again to send datas ??")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > } > From yvespielusenet at free.fr Thu Jun 7 07:17:21 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Thu, 07 Jun 2007 15:17:21 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4667F5FF.8070903@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <4667F5FF.8070903@gatworks.com> Message-ID: <1181222241.3501.20.camel@localhost.localdomain> thank you :) 'displayDialogBox()' I think doesn't exist. It was just for the example :) But I think It should not be so complicated to display a dialog box under windows with YES/NO buttons. When yes is clicked it return 0 other it returns 1. Le jeudi 07 juin 2007 ? 08:11 -0400, Uncle George a ?crit : > your suggestion appears good. I dont know what displayDialogBox exactly > will do, so all I can say it that it looks good. > > But I'd like to wait 10min before first dialog box And a 5 min wait for > every dialog box there after. And since these are custom > solution/choices, maybe a more exact explanation of what the issue is. > > if(errorCount++ < 300){ // wait 10min ( 10min * 60sec / 2 ) > Sleep( 20 ); /* make a small pause to execute all other requests > in all other threads */ > continue; > } > > if(displayDialogBox("Printer has Paused. Retry sending data?")){ > errorCount = 150; // Wait for 5 min thereafter > continue; > } > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > > yves pielusenet wrote: > > Maybe in my case I should re-compile rxtx and change the code. Instead > > of send an exception I should display a dialog box to ask if it's > > printer problem or if it should trie to send bytes. Something like : > > > > while( count > 0 ){ > > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > > /* > > this are 20 * 2 seconds, in this time a printer (or other parallel device) > > should solv all problems like buffer full, etc > > */ > > if(errorCount++ < 20){ > > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > > continue; > > } > > > > if(displayDialogBox("Try again to send datas ??")){ > > errorCount = 0; > > } > > else{ > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > } > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 07:41:43 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 09:41:43 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181222241.3501.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <4667F5FF.8070903@gatworks.com> <1181222241.3501.20.camel@localhost.localdomain> Message-ID: <46680B17.8050109@gatworks.com> yves pielusenet wrote: > thank you :) > 'displayDialogBox()' I think doesn't exist. It was just for the > example :) too bad. Good luck. From rtrout at webbresearch.com Thu Jun 7 11:23:04 2007 From: rtrout at webbresearch.com (Robert Trout) Date: Thu, 07 Jun 2007 13:23:04 -0400 Subject: [Rxtx] Disconnected PortServer TS causes Java to hang Message-ID: <1181236984.14186.33.camel@sisyphus.DinkumSoftware.com> I'm running Linux with sun's Java 1.4.2, Java comm API 2.0, RXTX 2.0-7pre1, and the RealPort digi driver. "/dev/ttyrp00" is a RealPort device. My Java application never returns from a ComPortIdentifier.getPortIdentifier("/dev/ttyrp00") call while the Digi PortServer TS 4 is disconnected from the network. If I later re-connect the PortServer, the call returns about 30 seconds later (it's like a serial port read or write is blocking until the PortServer is re- connected). With the PortServer disconnected, minicom immediately responds with "cannot open /dev/ttyrp00: No such file or directory". I would like my Java application to behave similarly. That is, respond with an error condition instead of hanging when the PortServer is not connected. Since minicom and Java behave differently, I think this "hanging" behavior may be due to RXTX or Java? Has anyone had a similar issue? Solutions? Suggestions? Thanks, Robert From vicnevicne at gmail.com Thu Jun 7 12:16:02 2007 From: vicnevicne at gmail.com (Vicne) Date: Thu, 07 Jun 2007 20:16:02 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181204864.3501.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> Message-ID: <46684B62.7080802@gmail.com> yves pielusenet wrote: > Maybe in my case I should re-compile rxtx and change the code. Instead > of send an exception I should display a dialog box to ask if it's > printer problem or if it should trie to send bytes. Something like : > > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > > if(displayDialogBox("Try again to send datas ??")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > } > Sorry to step in without a specific solution to your problem, but I wanted to share my feeling regarding this proposal. AFAIK, it's generally considered bad practice to pop-up a prompt from a library. The main reason is that in general use, you can't guarantee that someone is actually present behind the console. Imagine a print server in a machine room, connected to a park of printers. In that case, when one printer fails, the logical behaviour would be to use an other one. If you change RxTx the way you propose, the printer queue will simply be stuck with a useless "Try again to send data ?" prompt until an administrator opens a remote connection to the print server's console and clicks "no". Second, it would create a dependency upon the existence of a graphical console (if you go the graphical "dialogBox" way). On many applications (typically server or embedded ones), the JVM is "headless" and if you try to pop-up a dialog, your app would throw an exception (at best) or just wouldn't display the prompt anywhere... Going the "text console" way is not more reliable, because on graphical environments, the text console is hidden unless explicitly requested. My advice would be to think again and find another solution. Ideas are : - make the number of retries a parameter so that you can tune it to what you think is reasonable - throw a more specific exception when the number of retries has been reached, so that a specific prompt can be shown at a higher level Anyway, if you feel that the prompt is the way to go in your case, I would at least make that prompt conditional. The least intrusive way would probably be using a system property, like if("true".equals(System.getProperty("org.rxtx.usePrompt")) && displayDialogBox("Retry sending data ?")){ errorCount = 0; } else{ throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } By default, the behaviour would remain as it is now, but you could force the prompts by defining the property at VM launch if desired. (for example : java.exe -Dorg.rxtx.usePrompt=true myApp) Also, you seemed to say you wanted the printer to start again exactly where is stopped. It would indeed be the best way when the printer is put offline for a few seconds. On the other hand, if the printer is turned off (or the printer runs out of paper, or someone steps on the mains cable), then the only way to go back to a "stable" situation would be by printing the item (page, label, etc.) again from scratch... Just my two cents. Vicne PS : By the way, the dialog box thing is very platform dependant on the C-side, and I think the simplest way would probably be to bridge it to a Java call where you can implement it like you proposed : public boolean displayDialogBox(prompt) { return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); } From netbeans at gatworks.com Thu Jun 7 14:08:24 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 16:08:24 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46684B62.7080802@gmail.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> Message-ID: <466865B8.4060004@gatworks.com> My feeling is that the code that was suggested was for his environs ( his shop ). The issue here is that after a 40+ second wait, an exception will be thrown. But you really dont have a way of 'cancelling' all the WriteFiles() that have already occured before the exception so that your writeArray and the Commapi can backtrack to a position in which they are in sync. The main ( really mine ) concern is not to lose data, or replicate data. After 40seconds, 300 seconds, 55min, no matter how long, data should not be lost or duplicated. But as soon as the exception is thrown, that possibility exists. Maybe an event should be thrown instead? Vicne wrote: > yves pielusenet wrote: >> Maybe in my case I should re-compile rxtx and change the code. Instead >> of send an exception I should display a dialog box to ask if it's >> printer problem or if it should trie to send bytes. Something like : >> >> while( count > 0 ){ >> if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ >> /* >> this are 20 * 2 seconds, in this time a printer (or other parallel device) >> should solv all problems like buffer full, etc >> */ >> if(errorCount++ < 20){ >> Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ >> continue; >> } >> >> if(displayDialogBox("Try again to send datas ??")){ >> errorCount = 0; >> } >> else{ >> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >> break; >> } >> } >> > > Sorry to step in without a specific solution to your problem, but I > wanted to share my feeling regarding this proposal. AFAIK, it's > generally considered bad practice to pop-up a prompt from a library. > The main reason is that in general use, you can't guarantee that > someone is actually present behind the console. Imagine a print server > in a machine room, connected to a park of printers. In that case, when > one printer fails, the logical behaviour would be to use an other one. > If you change RxTx the way you propose, the printer queue will simply be > stuck with a useless "Try again to send data ?" prompt until an > administrator opens a remote connection to the print server's console > and clicks "no". > Second, it would create a dependency upon the existence of a > graphical console (if you go the graphical "dialogBox" way). On many > applications (typically server or embedded ones), the JVM is "headless" > and if you try to pop-up a dialog, your app would throw an exception (at > best) or just wouldn't display the prompt anywhere... Going the "text > console" way is not more reliable, because on graphical environments, > the text console is hidden unless explicitly requested. > > My advice would be to think again and find another solution. Ideas are : > - make the number of retries a parameter so that you can tune it to what > you think is reasonable > - throw a more specific exception when the number of retries has been > reached, so that a specific prompt can be shown at a higher level > > Anyway, if you feel that the prompt is the way to go in your case, I > would at least make that prompt conditional. The least intrusive way > would probably be using a system property, like > > if("true".equals(System.getProperty("org.rxtx.usePrompt")) > && displayDialogBox("Retry sending data ?")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > > > By default, the behaviour would remain as it is now, but you could > force the prompts by defining the property at VM launch if desired. (for > example : java.exe -Dorg.rxtx.usePrompt=true myApp) > > > Also, you seemed to say you wanted the printer to start again > exactly where is stopped. It would indeed be the best way when the > printer is put offline for a few seconds. On the other hand, if the > printer is turned off (or the printer runs out of paper, or someone > steps on the mains cable), then the only way to go back to a "stable" > situation would be by printing the item (page, label, etc.) again from > scratch... > > > Just my two cents. > > > Vicne > > PS : By the way, the dialog box thing is very platform dependant on the > C-side, and I think the simplest way would probably be to bridge it to a > Java call where you can implement it like you proposed : > > public boolean displayDialogBox(prompt) { > return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", > JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); > } > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Thu Jun 7 17:48:11 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 Jun 2007 17:48:11 -0600 (MDT) Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <466865B8.4060004@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> Message-ID: An event is possible. I'm amazed this is the largest problem encountered while using the parallel code. How would the write ever exit if we throw events? Isn't this going to lead to hung applications? On Thu, 7 Jun 2007, Uncle George wrote: > My feeling is that the code that was suggested was for his environs ( > his shop ). > > The issue here is that after a 40+ second wait, an exception will be > thrown. But you really dont have a way of 'cancelling' all the > WriteFiles() that have already occured before the exception so that your > writeArray and the Commapi can backtrack to a position in which they are > in sync. > > The main ( really mine ) concern is not to lose data, or replicate data. > After 40seconds, 300 seconds, 55min, no matter how long, data should > not be lost or duplicated. But as soon as the exception is thrown, that > possibility exists. > > Maybe an event should be thrown instead? > > Vicne wrote: >> yves pielusenet wrote: >>> Maybe in my case I should re-compile rxtx and change the code. Instead >>> of send an exception I should display a dialog box to ask if it's >>> printer problem or if it should trie to send bytes. Something like : >>> >>> while( count > 0 ){ >>> if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ >>> /* >>> this are 20 * 2 seconds, in this time a printer (or other parallel device) >>> should solv all problems like buffer full, etc >>> */ >>> if(errorCount++ < 20){ >>> Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ >>> continue; >>> } >>> >>> if(displayDialogBox("Try again to send datas ??")){ >>> errorCount = 0; >>> } >>> else{ >>> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >>> break; >>> } >>> } >>> >> >> Sorry to step in without a specific solution to your problem, but I >> wanted to share my feeling regarding this proposal. AFAIK, it's >> generally considered bad practice to pop-up a prompt from a library. >> The main reason is that in general use, you can't guarantee that >> someone is actually present behind the console. Imagine a print server >> in a machine room, connected to a park of printers. In that case, when >> one printer fails, the logical behaviour would be to use an other one. >> If you change RxTx the way you propose, the printer queue will simply be >> stuck with a useless "Try again to send data ?" prompt until an >> administrator opens a remote connection to the print server's console >> and clicks "no". >> Second, it would create a dependency upon the existence of a >> graphical console (if you go the graphical "dialogBox" way). On many >> applications (typically server or embedded ones), the JVM is "headless" >> and if you try to pop-up a dialog, your app would throw an exception (at >> best) or just wouldn't display the prompt anywhere... Going the "text >> console" way is not more reliable, because on graphical environments, >> the text console is hidden unless explicitly requested. >> >> My advice would be to think again and find another solution. Ideas are : >> - make the number of retries a parameter so that you can tune it to what >> you think is reasonable >> - throw a more specific exception when the number of retries has been >> reached, so that a specific prompt can be shown at a higher level >> >> Anyway, if you feel that the prompt is the way to go in your case, I >> would at least make that prompt conditional. The least intrusive way >> would probably be using a system property, like >> >> if("true".equals(System.getProperty("org.rxtx.usePrompt")) >> && displayDialogBox("Retry sending data ?")){ >> errorCount = 0; >> } >> else{ >> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >> break; >> } >> >> >> By default, the behaviour would remain as it is now, but you could >> force the prompts by defining the property at VM launch if desired. (for >> example : java.exe -Dorg.rxtx.usePrompt=true myApp) >> >> >> Also, you seemed to say you wanted the printer to start again >> exactly where is stopped. It would indeed be the best way when the >> printer is put offline for a few seconds. On the other hand, if the >> printer is turned off (or the printer runs out of paper, or someone >> steps on the mains cable), then the only way to go back to a "stable" >> situation would be by printing the item (page, label, etc.) again from >> scratch... >> >> >> Just my two cents. >> >> >> Vicne >> >> PS : By the way, the dialog box thing is very platform dependant on the >> C-side, and I think the simplest way would probably be to bridge it to a >> Java call where you can implement it like you proposed : >> >> public boolean displayDialogBox(prompt) { >> return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", >> JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); >> } >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 19:18:51 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 21:18:51 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> Message-ID: <4668AE7B.3060409@gatworks.com> The UNIX version of writeArray is not too great either. It is possible that the write will only process some of the bytes. #else if( write( fd, bytes, count ) < 0 ) throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); #endif -------------------------------- Maybe it might be better to have the native function inform the caller of the # of characters written, then the commapi/output-buffer can be modified to reflect the #of chars written. If an exception is to be thrown, for too many loops of chars written == 0, then exception wont affect the state of the output buffer. Then a ParallelPort.restart() can be called to resume printing whats in the buffer. Trent Jarvi wrote: > An event is possible. I'm amazed this is the largest problem encountered > while using the parallel code. > > How would the write ever exit if we throw events? Isn't this going to > lead to hung applications? Sure. If you dont time out, then there is nothing that will force an EXIT from the write(). Issue is what has the OS done with the write. > > On Thu, 7 Jun 2007, Uncle George wrote: > >> My feeling is that the code that was suggested was for his environs ( >> his shop ). From yvespielusenet at free.fr Fri Jun 8 01:09:01 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Fri, 08 Jun 2007 09:09:01 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4668AE7B.3060409@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> Message-ID: <1181286541.3674.10.camel@localhost.localdomain> It is not possible that the rxtx java method write(byte[], int offset, int length) return anint which contains the number of byte really send to the printer instead of an exception ? So this is the programm which will see if all bytes have been sent. If not it can retry to send the unsended bytes. -------------------------------------------------------- int sended = 0; while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ sended += countWritten; /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } return sended; /*throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break;*/ } ... ... return countWritten; ------------------------------------------------ Le jeudi 07 juin 2007 ? 21:18 -0400, Uncle George a ?crit : > The UNIX version of writeArray is not too great either. It is possible > that the write will only process some of the bytes. > > #else > if( write( fd, bytes, count ) < 0 ) > throw_java_exception_system_msg( env, IO_EXCEPTION, > "writeArray" ); > #endif > -------------------------------- > > Maybe it might be better to have the native function inform the caller > of the # of characters written, then the commapi/output-buffer can be > modified to reflect the #of chars written. If an exception is to be > thrown, for too many loops of chars written == 0, then exception wont > affect the state of the output buffer. Then a ParallelPort.restart() can > be called to resume printing whats in the buffer. > > > Trent Jarvi wrote: > > An event is possible. I'm amazed this is the largest problem encountered > > while using the parallel code. > > > > How would the write ever exit if we throw events? Isn't this going to > > lead to hung applications? > Sure. If you dont time out, then there is nothing that will force an > EXIT from the write(). Issue is what has the OS done with the write. > > > > On Thu, 7 Jun 2007, Uncle George wrote: > > > >> My feeling is that the code that was suggested was for his environs ( > >> his shop ). > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Fri Jun 8 03:45:00 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 11:45:00 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181286541.3674.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> Message-ID: <20070608094500.GC21069@elberon.bln.de.ingenico.com> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > It is not possible that the rxtx java method write(byte[], int offset, > int length) return anint which contains the number of byte really send > to the printer instead of an exception ? > So this is the programm which will see if all bytes have been sent. If > not it can retry to send the unsended bytes. I think write() is void because in Java people love to do this since OutputStream :-) Of course on such interfaces you cannot implement something nice. If you would have a int write, you would not implement the interface and no applications expecting this interface would link/work/compile. oki, Steffen P.S.: (OT) If you propose not to implement the Java interfaces (especially not on JNI level), maybe optionally offering a wrapper that removes e.g. the write return value and so on to downgrade the powerful classic old POSIX read/write style to the modern limited Java style, then I agree :-) Same for read. Instead of things like "int avialable()" it is more powerful to have an approach as select(2) offers (to guarante the caller that read/write will not block [nothing else make sense anyway IMHO] but may read/write less bytes then requested). The caller gets full control and the higher level protocols can care about timeouts, invoking read in some loops and/or implement retransmission. On top of such an implementation, where everything is controlled, defined, guaranteed and reliable, someone could use an InputStream or OutputStream style interface. Or even better: don't use them at all :) just BTW :-) St. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From yvespielusenet at free.fr Fri Jun 8 05:52:45 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Fri, 08 Jun 2007 13:52:45 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <20070608094500.GC21069@elberon.bln.de.ingenico.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> Message-ID: <1181303565.11203.3.camel@localhost.localdomain> So maybe a better way should be to create a new Exception class which has a method "int getWrittenByte()". So the Exception should be use to send again bytes which are not printed yet. yves Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : > * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > > It is not possible that the rxtx java method write(byte[], int offset, > > int length) return anint which contains the number of byte really send > > to the printer instead of an exception ? > > So this is the programm which will see if all bytes have been sent. If > > not it can retry to send the unsended bytes. > > I think write() is void because in Java people love to do this > since OutputStream :-) Of course on such interfaces you cannot > implement something nice. If you would have a int write, you > would not implement the interface and no applications expecting > this interface would link/work/compile. > > oki, > > Steffen > > P.S.: (OT) > If you propose not to implement the Java interfaces (especially > not on JNI level), maybe optionally offering a wrapper that > removes e.g. the write return value and so on to downgrade the > powerful classic old POSIX read/write style to the modern limited > Java style, then I agree :-) Same for read. Instead of things > like "int avialable()" it is more powerful to have an approach as > select(2) offers (to guarante the caller that read/write will not > block [nothing else make sense anyway IMHO] but may read/write > less bytes then requested). The caller gets full control and the > higher level protocols can care about timeouts, invoking read in > some loops and/or implement retransmission. On top of such an > implementation, where everything is controlled, defined, > guaranteed and reliable, someone could use an InputStream or > OutputStream style interface. Or even better: don't use them at > all :) just BTW :-) > St. > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > 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. > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > 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. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Fri Jun 8 06:46:21 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 08:46:21 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181303565.11203.3.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> Message-ID: <46694F9D.5080501@gatworks.com> It seems that with outputstream.write(b[]), you become terribly uncoordinated as soon as an exception is thrown. Docs do not say what happens to the data. Yet from a practicable point of view, one would like to know if the write was accepted in-full, or rejected before any writes. There are no in betweens, as partial writes are not reportable. So for an outputstream.write(), in order for it to return, the full write request has to be taken, and stored in an internal output buffer. If there is no room, the write() is suspended, till there is room. Or throw's an IOException( "no room in buffer") ; As the select() loop for write reports buffer room avail, then more of the internal buffer is sent to the printer. yves pielusenet wrote: > So maybe a better way should be to create a new Exception class which > has a method "int getWrittenByte()". So the Exception should be use to > send again bytes which are not printed yet. > > yves > > Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : >> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: >>> It is not possible that the rxtx java method write(byte[], int offset, >>> int length) return anint which contains the number of byte really send >>> to the printer instead of an exception ? >>> So this is the programm which will see if all bytes have been sent. If >>> not it can retry to send the unsended bytes. >> I think write() is void because in Java people love to do this >> since OutputStream :-) Of course on such interfaces you cannot >> implement something nice. If you would have a int write, you >> would not implement the interface and no applications expecting >> this interface would link/work/compile. >> >> oki, >> >> Steffen >> >> P.S.: (OT) >> If you propose not to implement the Java interfaces (especially >> not on JNI level), maybe optionally offering a wrapper that >> removes e.g. the write return value and so on to downgrade the >> powerful classic old POSIX read/write style to the modern limited >> Java style, then I agree :-) Same for read. Instead of things >> like "int avialable()" it is more powerful to have an approach as >> select(2) offers (to guarante the caller that read/write will not >> block [nothing else make sense anyway IMHO] but may read/write >> less bytes then requested). The caller gets full control and the >> higher level protocols can care about timeouts, invoking read in >> some loops and/or implement retransmission. On top of such an >> implementation, where everything is controlled, defined, >> guaranteed and reliable, someone could use an InputStream or >> OutputStream style interface. Or even better: don't use them at >> all :) just BTW :-) >> St. >> >> About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. >> 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. >> >> About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. >> 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. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From Steffen.DETTMER at ingenico.com Fri Jun 8 08:12:18 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 16:12:18 +0200 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <46694F9D.5080501@gatworks.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: <20070608141218.GE21069@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 08:46 -0400: > It seems that with outputstream.write(b[]), you become terribly > uncoordinated as soon as an exception is thrown. Docs do not say what > happens to the data. (yes, so avoiding it seems to be good :)) > Yet from a practicable point of view, one would like to know if the > write was accepted in-full, or rejected before any writes. There are no > in betweens, as partial writes are not reportable. (which is an artificial API limitation. I never understood how this happend when they invented JDK because the well-known BSD socket API and thus [probably] WinSock does this correct, but anyway) > So for an outputstream.write(), in order for it to return, the full > write request has to be taken, and stored in an internal output buffer. > If there is no room, the write() is suspended, till there is room. Or > throw's an IOException( "no room in buffer") ; As the select() loop for > write reports buffer room avail, then more of the internal buffer is > sent to the printer. yes, might be good in case of a printer. May be horrible in case of PPP/TCP or some other transmission control protocol which may e.g. repeat data or even omit parts of it (e.g. internet realtime radio station broadcasting)... So I think the idea of "int write" (e.g. BSD sockets, linux files and so on) still is the best. A clean API / implementation should guarantee and allow implementations (users) to rely on that; assumptions and automatic background-sending and so on may look pragmatic and may even work on the first look, but may fail in other situations. BTW, if e.g. BSD socket API is known, why not simply copy it (until something better is invented :)) instead of fiddling around with JDK APIs? anyway, have a nice weekend everyone :-) oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Fri Jun 8 08:55:56 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 10:55:56 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070608141218.GE21069@elberon.bln.de.ingenico.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> Message-ID: <46696DFC.7000801@gatworks.com> >> write reports buffer room avail, then more of the internal buffer is >> sent to the printer. > > yes, might be good in case of a printer. May be horrible in case > of PPP/TCP or some other transmission control protocol which > may e.g. repeat data or even omit parts of it (e.g. internet > realtime radio station broadcasting)... So I think the idea of > "int write" (e.g. BSD sockets, linux files and so on) still is > the best. A clean API / implementation should guarantee and allow > implementations (users) to rely on that; assumptions and > automatic background-sending and so on may look pragmatic and may > even work on the first look, but may fail in other situations. > BTW, if e.g. BSD socket API is known, why not simply copy it > (until something better is invented :)) instead of fiddling > around with JDK APIs? But we were talking about the Parallel Port, and the transmission of data over the commapi/parallel-port schema. There isn't much in bi-directional software communication. Its a simple write one byte at a time interface. I'm not looking to change the comm-api. I'm just looking to alter the interaction between the Native ParallelPort functions, and the java ParallelPort functions that call them. This might be more readily doable than to get a committee to re-specify java-API specs. BTW: Whats is off-topic? ( help: not looking for def of off-topic ) From j.kenneth.gentle at acm.org Fri Jun 8 08:58:59 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Fri, 08 Jun 2007 10:58:59 -0400 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <20070608141218.GE21069@elberon.bln.de.ingenico.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> Message-ID: <200706081459.l58Ex5rA019991@qbang.org> Perhaps it is a bit late to jump in on this one, but here goes anyway. If the solutions all seem to "break" the contract with "java.io.outputstream", then, as noted, that may not be the appropriate contract. At the risk of being heretical, JDK1.4 introduced the "nio" package to address some of the compatibility issues with C apis mentioned in previous posts. The interface "java.nio.channels.WriteableByteChannel" defines the following single method: int write(ByteBuffer source); int, strangely enough, is the actual number of bytes written. So, if RXTX as written, against the JavaCOMM api and OutputStream, doesn't do what we want, how about writing a different set of bindings using the java.nio classes and as much of the underlying native code as possible. Note that just because the java.nio.channels.WriteableByteChannel sends back a result, OutputStream.write doesn't have to - and they could both call the same underlying native code. My 2 cents - maybe not worth even that... Ken From netbeans at gatworks.com Fri Jun 8 10:37:28 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 12:37:28 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <200706081459.l58Ex5rA019991@qbang.org> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> Message-ID: <466985C8.8000505@gatworks.com> Ken Gentle wrote: > Perhaps it is a bit late to jump in on this one, but here goes anyway. Common in, the waters fine. > > If the solutions all seem to "break" the contract with > "java.io.outputstream", then, as noted, that may not be the > appropriate contract. > How would the contract be broken? The machinery underneath is handling the contract. From j.kenneth.gentle at acm.org Fri Jun 8 10:48:01 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Fri, 08 Jun 2007 12:48:01 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466985C8.8000505@gatworks.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> Message-ID: <200706081648.l58Gm7YA022904@qbang.org> At 12:37 2007-06-08, you wrote: >Ken Gentle wrote: > > > > If the solutions all seem to "break" the contract with > > "java.io.outputstream", then, as noted, that may not be the > > appropriate contract. > > >How would the contract be broken? The machinery underneath is handling >the contract. It seems that a lot of the discussion has been about not only the timeout and being able to adjust it in the "machinery layer", but also about knowing in the Java layer, in the event of a timeout or exception, how many characters have been written to the device. An OutputStream won't ever do this with out an extension and including a return value "breaks" the contract, right? So, go with a Java IO api that *does* return the number of bytes written, out of the NIO package. I know it doesn't allow for a strict implementation of the JavaCOMM API - however, using NIO classes in place of the IO classes isn't that big a break and would allow those applications that need such information a way to get it. Maybe I'm misunderstanding the problem... Ken From netbeans at gatworks.com Fri Jun 8 11:24:14 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 13:24:14 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <200706081648.l58Gm7YA022904@qbang.org> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> Message-ID: <466990BE.7040100@gatworks.com> Ken Gentle wrote: An > OutputStream won't ever do this with out an extension and including a > return value "breaks" the contract, right? > i was not thinking of change the API to OutputSream. Are there specs for how output stream should work internally? for instance: String data = "Hello this is a line of data"; Outputstream.write( data.getbytes() ); ParallelPort.suspend(); int free = ParallelPort.getoutputbufferfree(); There is a symbiotic relationship between outputstream and the functionality of ParallelPort. From Steffen.DETTMER at ingenico.com Fri Jun 8 11:15:39 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 19:15:39 +0200 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <200706081459.l58Ex5rA019991@qbang.org> References: <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> Message-ID: <20070608171539.GK21069@elberon.bln.de.ingenico.com> * Ken Gentle wrote on Fri, Jun 08, 2007 at 10:58 -0400: > If the solutions all seem to "break" the contract with > "java.io.outputstream", then, as noted, that may not be the > appropriate contract. > > At the risk of being heretical, JDK1.4 introduced the "nio" package > to address some of the compatibility issues with C apis mentioned in > previous posts. The interface > "java.nio.channels.WriteableByteChannel" defines the following single method: > > int write(ByteBuffer source); > > int, strangely enough, is the actual number of bytes written. Yes, AFAIK one of the motivations for the NIO interface was, that the JDK-1.3 APIs (InputStream, e.g.) were not powerfull enough, especially for multi-connection-TCP servers or so. I don't know much about it but I've heard of a project where NIO usage was removed because of stability issues in multi-threaded environments and performance limitations under some circumstances. IIRC the "nio.ByteBuffer" is something very special (namely something you cannot implement in Java, it is "magic" or part of the language itself). Not sure if this is such a great idea (but for performance in the end sometimes heavy prices must be paid) :) > So, if RXTX as written, against the JavaCOMM api and OutputStream, > doesn't do what we want, how about writing a different set of > bindings using the java.nio classes and as much of the underlying > native code as possible. Yes, this would be an idea: use a full-featured interface on JNI, and, if wanted, deliver some wrappers converting this to a less-featured Java-compliant interface. However, powerful things as e.g. "select" are difficult to "emulate" if you are e.g. on some (older?) windows. But if you expose the full-featured APIs, you need to emulate them full-featured, theoretically. In the end it depends what you do on the serial line. If you just want to talk to a modem, then you may not need precise timeouts. But if you need to implement complexer protocols which define response times and timeouts, you may quickly get into difficulties. For instance, AFAIK, rxtx 1.7.2 (?) for windows is very messy with timeouts (there is a maximum, higher values are truncated; resolution is 100ms only; the function may take up to twice the timeout because internally it may be called twice). Probably for most people this is OK, but probably not for all. But having precise timeouts should be OK for all :-) Well, in the end it is nice to wish but somewhat hard to implement (many platforms, connections, USB, BlueTooth, whatever). oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Steffen.DETTMER at ingenico.com Fri Jun 8 11:04:22 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 19:04:22 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <46696DFC.7000801@gatworks.com> References: <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <46696DFC.7000801@gatworks.com> Message-ID: <20070608170422.GJ21069@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 10:55 -0400: > > BTW, if e.g. BSD socket API is known, why not simply copy it > > (until something better is invented :)) instead of fiddling > > around with JDK APIs? > > But we were talking about the Parallel Port, and the > transmission of data over the commapi/parallel-port schema. > There isn't much in bi-directional software communication. Its > a simple write one byte at a time interface. First, there are things like PLIP (http://en.wikipedia.org/wiki/Plip) - well, probably not widely used, sure ;) Second, I think if there is a good simple API known to support all that (with known "best practices") or so and there is no forcing need to invent a new one, why not simply using it? > I'm not looking to change the comm-api. I'm just looking to > alter the interaction between the Native ParallelPort > functions, and the java ParallelPort functions that call them. Ahh, yes. I think this is what I tried to ask. Having an usable JNI interface and on top (in pure java) some wrapper to InputStream or whatever could be done (e.g. by ignoring the return value of write or throwing if != length). Developers could then use the full-featured (non-JAVA-standard) API or select among various wrappers (as InputStream). > This might be more readily doable than to get a committee to > re-specify java-API specs. Yes, of course. I'm afraid that the Java APIs change regularily, but still yet with limited success it seems, so maybe they get it in one of the next iterations; who knows, maybe Java-9 has a BSD-like socket API :) SCNR. > BTW: Whats is off-topic? ( help: not looking for def of > off-topic ) I think I started some "re-specify java-API specs" which was OT probably. oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From lists at iDIAcomputing.com Fri Jun 8 18:48:54 2007 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Fri, 08 Jun 2007 20:48:54 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46684B62.7080802@gmail.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> Message-ID: <4669F8F6.3040101@iDIAcomputing.com> Vicne wrote: > Sorry to step in without a specific solution to your problem, but I > wanted to share my feeling regarding this proposal. AFAIK, it's > generally considered bad practice to pop-up a prompt from a library. ... > > My advice would be to think again and find another solution. Ideas are : > - make the number of retries a parameter so that you can tune it to what > you think is reasonable > - throw a more specific exception when the number of retries has been > reached, so that a specific prompt can be shown at a higher level You could also allow the client code to register a callback class which returns a boolean indicating whether to retry or cancel. This callback class could pop up a dialog, if appropriate, or follow some preset policy, or.... - George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From joachim at buechse.ch Sat Jun 9 09:43:16 2007 From: joachim at buechse.ch (Joachim Buechse) Date: Sat, 9 Jun 2007 17:43:16 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46694F9D.5080501@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: You should not forget, that in the case of an exception it may not even be known what happened to the data. You have a kernel buffer, outgoing chip buffer, incoming chip buffer, etc. So of course, it would be nice to know up to which point data was correctly processed, but this feedback does not exist on the hardware or protocol level and hence can in general not be magicly created on the software level... Regards, Joachim On 08.06.2007, at 14:46, Uncle George wrote: > It seems that with outputstream.write(b[]), you become terribly > uncoordinated as soon as an exception is thrown. Docs do not say what > happens to the data. > > Yet from a practicable point of view, one would like to know if the > write was accepted in-full, or rejected before any writes. There > are no > in betweens, as partial writes are not reportable. > > So for an outputstream.write(), in order for it to return, the full > write request has to be taken, and stored in an internal output > buffer. > If there is no room, the write() is suspended, till there is room. Or > throw's an IOException( "no room in buffer") ; As the select() loop > for > write reports buffer room avail, then more of the internal buffer is > sent to the printer. > > > > yves pielusenet wrote: >> So maybe a better way should be to create a new Exception class which >> has a method "int getWrittenByte()". So the Exception should be >> use to >> send again bytes which are not printed yet. >> >> yves >> >> Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : >>> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: >>>> It is not possible that the rxtx java method write(byte[], int >>>> offset, >>>> int length) return anint which contains the number of byte >>>> really send >>>> to the printer instead of an exception ? >>>> So this is the programm which will see if all bytes have been >>>> sent. If >>>> not it can retry to send the unsended bytes. >>> I think write() is void because in Java people love to do this >>> since OutputStream :-) Of course on such interfaces you cannot >>> implement something nice. If you would have a int write, you >>> would not implement the interface and no applications expecting >>> this interface would link/work/compile. >>> >>> oki, >>> >>> Steffen >>> >>> P.S.: (OT) >>> If you propose not to implement the Java interfaces (especially >>> not on JNI level), maybe optionally offering a wrapper that >>> removes e.g. the write return value and so on to downgrade the >>> powerful classic old POSIX read/write style to the modern limited >>> Java style, then I agree :-) Same for read. Instead of things >>> like "int avialable()" it is more powerful to have an approach as >>> select(2) offers (to guarante the caller that read/write will not >>> block [nothing else make sense anyway IMHO] but may read/write >>> less bytes then requested). The caller gets full control and the >>> higher level protocols can care about timeouts, invoking read in >>> some loops and/or implement retransmission. On top of such an >>> implementation, where everything is controlled, defined, >>> guaranteed and reliable, someone could use an InputStream or >>> OutputStream style interface. Or even better: don't use them at >>> all :) just BTW :-) >>> St. >>> >>> About Ingenico Throughout the world businesses rely on Ingenico >>> for secure and expedient electronic transaction acceptance. >>> Ingenico products leverage proven technology, established >>> standards and unparalleled ergonomics to provide optimal >>> reliability, versatility and usability. This comprehensive range >>> of products is complemented by a global array of services and >>> partnerships, enabling businesses in a number of vertical sectors >>> to accept transactions anywhere their business takes them. >>> 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. >>> >>> About Ingenico Throughout the world businesses rely on Ingenico >>> for secure and expedient electronic transaction acceptance. >>> Ingenico products leverage proven technology, established >>> standards and unparalleled ergonomics to provide optimal >>> reliability, versatility and usability. This comprehensive range >>> of products is complemented by a global array of services and >>> partnerships, enabling businesses in a number of vertical sectors >>> to accept transactions anywhere their business takes them. >>> 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. >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx 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 yvespielusenet at free.fr Mon Jun 11 03:15:12 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Mon, 11 Jun 2007 11:15:12 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: <1181553312.8335.14.camel@localhost.localdomain> So can someone tell a solution for my problem :( Must I say to the user to not put the printer off-line ? I can't since he has to do some pauses, verify print, paper conditioning etc... How do other people ? Before I use the parport librarry to read port status : http://www.geocities.com/Juanga69/parport/ (which doesn't work on windows XP) And I send data into the file LPT1 I use to have no problem when printer was disabled. thanks -- yves piel Le samedi 09 juin 2007 ? 17:43 +0200, Joachim Buechse a ?crit : > You should not forget, that in the case of an exception it may not > even be known what happened to the data. > > You have a kernel buffer, outgoing chip buffer, incoming chip buffer, > etc. So of course, it would be nice to know up to which point data > was correctly processed, but this feedback does not exist on the > hardware or protocol level and hence can in general not be magicly > created on the software level... > > Regards, > Joachim > > On 08.06.2007, at 14:46, Uncle George wrote: > > > It seems that with outputstream.write(b[]), you become terribly > > uncoordinated as soon as an exception is thrown. Docs do not say what > > happens to the data. > > > > Yet from a practicable point of view, one would like to know if the > > write was accepted in-full, or rejected before any writes. There > > are no > > in betweens, as partial writes are not reportable. > > > > So for an outputstream.write(), in order for it to return, the full > > write request has to be taken, and stored in an internal output > > buffer. > > If there is no room, the write() is suspended, till there is room. Or > > throw's an IOException( "no room in buffer") ; As the select() loop > > for > > write reports buffer room avail, then more of the internal buffer is > > sent to the printer. > > > > > > > > yves pielusenet wrote: > >> So maybe a better way should be to create a new Exception class which > >> has a method "int getWrittenByte()". So the Exception should be > >> use to > >> send again bytes which are not printed yet. > >> > >> yves > >> > >> Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : > >>> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > >>>> It is not possible that the rxtx java method write(byte[], int > >>>> offset, > >>>> int length) return anint which contains the number of byte > >>>> really send > >>>> to the printer instead of an exception ? > >>>> So this is the programm which will see if all bytes have been > >>>> sent. If > >>>> not it can retry to send the unsended bytes. > >>> I think write() is void because in Java people love to do this > >>> since OutputStream :-) Of course on such interfaces you cannot > >>> implement something nice. If you would have a int write, you > >>> would not implement the interface and no applications expecting > >>> this interface would link/work/compile. > >>> > >>> oki, > >>> > >>> Steffen > >>> > >>> P.S.: (OT) > >>> If you propose not to implement the Java interfaces (especially > >>> not on JNI level), maybe optionally offering a wrapper that > >>> removes e.g. the write return value and so on to downgrade the > >>> powerful classic old POSIX read/write style to the modern limited > >>> Java style, then I agree :-) Same for read. Instead of things > >>> like "int avialable()" it is more powerful to have an approach as > >>> select(2) offers (to guarante the caller that read/write will not > >>> block [nothing else make sense anyway IMHO] but may read/write > >>> less bytes then requested). The caller gets full control and the > >>> higher level protocols can care about timeouts, invoking read in > >>> some loops and/or implement retransmission. On top of such an > >>> implementation, where everything is controlled, defined, > >>> guaranteed and reliable, someone could use an InputStream or > >>> OutputStream style interface. Or even better: don't use them at > >>> all :) just BTW :-) > >>> St. > >>> > >>> About Ingenico Throughout the world businesses rely on Ingenico > >>> for secure and expedient electronic transaction acceptance. > >>> Ingenico products leverage proven technology, established > >>> standards and unparalleled ergonomics to provide optimal > >>> reliability, versatility and usability. This comprehensive range > >>> of products is complemented by a global array of services and > >>> partnerships, enabling businesses in a number of vertical sectors > >>> to accept transactions anywhere their business takes them. > >>> 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. > >>> > >>> About Ingenico Throughout the world businesses rely on Ingenico > >>> for secure and expedient electronic transaction acceptance. > >>> Ingenico products leverage proven technology, established > >>> standards and unparalleled ergonomics to provide optimal > >>> reliability, versatility and usability. This comprehensive range > >>> of products is complemented by a global array of services and > >>> partnerships, enabling businesses in a number of vertical sectors > >>> to accept transactions anywhere their business takes them. > >>> 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. > >>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx 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 > From Steffen.DETTMER at ingenico.com Mon Jun 11 03:56:18 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 11:56:18 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466990BE.7040100@gatworks.com> References: <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> Message-ID: <20070611095618.GA10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 13:24 -0400: > i was not thinking of change the API to OutputSream. Then I think either someone uses OutputStream (and has no reliable information about incomplete writes) or someone uses somethink else. > Are there specs for how output stream should work internally? > > for instance: > String data = "Hello this is a line of data"; > Outputstream.write( data.getbytes() ); > ParallelPort.suspend(); > int free = ParallelPort.getoutputbufferfree(); > > There is a symbiotic relationship between outputstream and the > functionality of ParallelPort. If you need OutputStream "plus something else", in short you're needing "something else". Personally I dislike the code above a lot. The stream "looks" like if it would be an OutputStream, but in fact it isn't. You need to call getoutputbufferfree later to check if write succeeded (but OutputStream promises that write succeedes synchronous, blocking, or throws an exception). So it is not an OutputStream. No application written for OutputStreams would work without change (because it won't know getoutputbufferfree at all). It is not abstracted from ParallelPort. I think this would be wrong. Then I think an alternative interface instead is better. Let's assume we had some "connection" (to distinguish between OutputStreams and Channels). Then why not working as on a file handle in POSIX: do { // ... select maybe using timer ... readyForWrite = ... if (readyForWrite) { int writtenBytes = connection.write(toWrite); toWrite.remove(0, writtenBytes); } while(readyForWrite && toWrite.length > 0); I think, having such a write isn't the big problem. I think, the difficult thing is around "select" - however this would look like. It should be OO, typesafe, performant, supporting multiple connections/channels/streams in various modes and should be orthogonal to other functionalities. Of course, this heavily depends on what the application is doing; for a simple situation (like reading a small, mandatory file from a local disk) this would be to uncomfortable (and offering unneeded features only). just BTW :) oki, Steffen -- // Modeline for VIM. Please don't remove. // (Help: autoindent, expandtab, shiftwidth=4, tabstop=4, textwidth=75) // vi: set ai et sw=4 ts=4 tw=75 ft=java: About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Mon Jun 11 05:38:33 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 07:38:33 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611095618.GA10821@elberon.bln.de.ingenico.com> References: <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> Message-ID: <466D3439.4020805@gatworks.com> Steffen DETTMER wrote: > (but OutputStream promises that write > succeedes synchronous, blocking, or throws an exception). Where is it so written? From Steffen.DETTMER at ingenico.com Mon Jun 11 06:36:50 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 14:36:50 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466D3439.4020805@gatworks.com> References: <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> <466D3439.4020805@gatworks.com> Message-ID: <20070611123650.GI10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Mon, Jun 11, 2007 at 07:38 -0400: > Steffen DETTMER wrote: > > > (but OutputStream promises that write > > succeedes synchronous, blocking, or throws an exception). > > Where is it so written? Now, as you ask, I think it is not written that clearly but follows from specification. mmm... Am I wrong? I understand the API doc in this way: * http://java.sun.com/j2se/1.4.2/docs/api/java/io/OutputStream.html#write(byte[]) > public void write(byte[] b) > throws IOException > > Writes b.length bytes from the specified byte array to this > output stream. The general contract for write(b) is that > it should have exactly the same effect as the call write(b, > 0, b.length). > > Parameters: > b - the data. > Throws: > IOException - if an I/O error occurs. > See Also: > write(byte[], int, int) and there is: > public void write(byte[] b, > int off, > int len) > throws IOException > > Writes len bytes from the specified byte array starting at > offset off to this output stream. The general contract for > write(b, off, len) is that some of the bytes in the array b > are written to the output stream in order; element b[off] > is the first byte written and b[off+len-1] is the last byte > written by this operation. > > The write method of OutputStream calls the write method of > one argument on each of the bytes to be written out. > Subclasses are encouraged to override this method and > provide a more efficient implementation. > > If b is null, a NullPointerException is thrown. > > If off is negative, or len is negative, or off+len is > greater than the length of the array b, then an > IndexOutOfBoundsException is thrown. > > Parameters: > b - the data. > off - the start offset in the data. > len - the number of bytes to write. > Throws: > IOException - if an I/O error occurs. In particular, an > IOException is thrown if the output stream is closed. In general, any specialisation (derived child class) must comform to this. So write in the end is specified (!) as "The write method ... calls the write method ... on each of the bytes to be written out". This is what must be implemented by ANY OutputStream. Of course, there is: "Subclasses are encouraged to override this method and provide a more efficient implementation." which IMHO does not contradict - the more efficient must behave in exactly the same way of course (just wasting less resources than a simple byte-by-byte write). So it does not matter here I think. The write that finally defines the behavior tells basically: > "Writes the specified byte to this output stream. The general > contract for write is that one byte is written to the output > stream. " > > Throws: > IOException - if an I/O error occurs. which IMHO is another way of saying "write writes the byte immediately and returns on success (only), otherwise an exception is thrown". Especially it cannot happen that zero bytes are written (i.e. the specified byte is NOT written) without an exception. So by this write must be synchronous and blocking, because otherwise it could not reliably know if an asynchronous operation will succeede or not (some getAsyncResult or so would be needed). Since write(byte[]) does this for each byte (or with a behavior beeing exactly the same as if it would do), I think this means that the write(byte[]) succeedes synchronous/blocking or throws an exception. Did I an error in reasoning or confused something or so? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From j.kenneth.gentle at acm.org Mon Jun 11 06:51:25 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 11 Jun 2007 08:51:25 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611123650.GI10821@elberon.bln.de.ingenico.com> References: <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> <466D3439.4020805@gatworks.com> <20070611123650.GI10821@elberon.bln.de.ingenico.com> Message-ID: <200706111251.l5BCpS9T017831@qbang.org> It is as Steffen describes. "InputStream" and "OutputStream" are inherently synchronous (which is why so many java programs resort to threads to use them). Anything outside of this "contract" is *not* an InputStream or OutputStream. That is why there is a new package for things that don't behave like the old *Stream classes - the NIO package. If you look carefully at the IO package, you'll note that almost all the classes are _Decorator_ pattern implementations of the *Stream classes - and the interface presents the _same_ behavior to the calling code in all cases - a synchronous operation that completes successfully or throws an exception (with the one exception of "read" that returns a "-1" on end-of-stream. I know I've read this numerous times - I'd suggest checking the Language Spec or one of the books by Bloch or Gosling. Ken At 08:36 2007-06-11, you wrote: >* Uncle George wrote on Mon, Jun 11, 2007 at 07:38 -0400: > > Steffen DETTMER wrote: > > > > > (but OutputStream promises that write > > > succeedes synchronous, blocking, or throws an exception). > > > > Where is it so written? > >Now, as you ask, I think it is not written that clearly but >follows from specification. mmm... > >Am I wrong? > >I understand the API doc in this way: > >* >http://java.sun.com/j2se/1.4.2/docs/api/java/io/OutputStream.html#write(byte[]) > > public void write(byte[] b) > > throws IOException > > > > Writes b.length bytes from the specified byte array to this > > output stream. The general contract for write(b) is that > > it should have exactly the same effect as the call write(b, > > 0, b.length). > > > > Parameters: > > b - the data. > > Throws: > > IOException - if an I/O error occurs. > > See Also: > > write(byte[], int, int) > > >and there is: > > > > public void write(byte[] b, > > int off, > > int len) > > throws IOException > > > > Writes len bytes from the specified byte array starting at > > offset off to this output stream. The general contract for > > write(b, off, len) is that some of the bytes in the array b > > are written to the output stream in order; element b[off] > > is the first byte written and b[off+len-1] is the last byte > > written by this operation. > > > > The write method of OutputStream calls the write method of > > one argument on each of the bytes to be written out. > > Subclasses are encouraged to override this method and > > provide a more efficient implementation. > > > > If b is null, a NullPointerException is thrown. > > > > If off is negative, or len is negative, or off+len is > > greater than the length of the array b, then an > > IndexOutOfBoundsException is thrown. > > > > Parameters: > > b - the data. > > off - the start offset in the data. > > len - the number of bytes to write. > > Throws: > > IOException - if an I/O error occurs. In particular, an > > IOException is thrown if the output stream is closed. > > >In general, any specialisation (derived child class) must comform >to this. So write in the end is specified (!) as "The write >method ... calls the write method ... on each of the bytes to be >written out". This is what must be implemented by ANY >OutputStream. > >Of course, there is: "Subclasses are encouraged to override this >method and provide a more efficient implementation." which IMHO >does not contradict - the more efficient must behave in exactly >the same way of course (just wasting less resources than a simple >byte-by-byte write). So it does not matter here I think. > > > >The write that finally defines the behavior tells basically: > > > "Writes the specified byte to this output stream. The general > > contract for write is that one byte is written to the output > > stream. " > > > > Throws: > > IOException - if an I/O error occurs. > > >which IMHO is another way of saying "write writes the byte >immediately and returns on success (only), otherwise an exception >is thrown". Especially it cannot happen that zero bytes are >written (i.e. the specified byte is NOT written) without an >exception. So by this write must be synchronous and blocking, >because otherwise it could not reliably know if an asynchronous >operation will succeede or not (some getAsyncResult or so would >be needed). > >Since write(byte[]) does this for each byte (or with a behavior >beeing exactly the same as if it would do), I think this means >that the write(byte[]) succeedes synchronous/blocking or throws >an exception. > >Did I an error in reasoning or confused something or so? > >oki, > >Steffen > >About Ingenico Throughout the world businesses rely on Ingenico for >secure and expedient electronic transaction acceptance. Ingenico >products leverage proven technology, established standards and >unparalleled ergonomics to provide optimal reliability, versatility >and usability. This comprehensive range of products is complemented >by a global array of services and partnerships, enabling businesses >in a number of vertical sectors to accept transactions anywhere >their business takes them. >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. > >About Ingenico Throughout the world businesses rely on Ingenico for >secure and expedient electronic transaction acceptance. Ingenico >products leverage proven technology, established standards and >unparalleled ergonomics to provide optimal reliability, versatility >and usability. This comprehensive range of products is complemented >by a global array of services and partnerships, enabling businesses >in a number of vertical sectors to accept transactions anywhere >their business takes them. >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. > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From alesinskyy at googlemail.com Mon Jun 11 07:25:33 2007 From: alesinskyy at googlemail.com (Oleksandr Alesinskyy) Date: Mon, 11 Jun 2007 15:25:33 +0200 Subject: [Rxtx] [OT] select :-) Message-ID: Sorry, but I have to disagree with following statement: "So write in the end is specified (!) as "The write method ... calls the write method ... on each of the bytes to be written out". This is what must be implemented by ANY OutputStream.". This is not part of the specification or contract, it is just revealed implementation detail of the OutputStream. It is not stated anywhere that behavoiur of derived classes shall conform with this one. Statement concerning "synchronous" nature of the output stream is invalid as well. Really synchronous stream does not require flush() but OutputStream has it. From Steffen.DETTMER at ingenico.com Mon Jun 11 08:21:16 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 16:21:16 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: Message-ID: <20070611142116.GN10821@elberon.bln.de.ingenico.com> * Oleksandr Alesinskyy wrote on Mon, Jun 11, 2007 at 15:25 +0200: > Sorry, but I have to disagree with following statement: > "So write in the end is specified (!) as "The write > method ... calls the write method ... on each of the bytes to be > written out". This is what must be implemented by ANY > OutputStream.". > > This is not part of the specification or contract, it is just > revealed implementation detail of the OutputStream. It is not > stated anywhere that behavoiur of derived classes shall conform > with this one. (I didn't meant that the implementation must really write byte by byte, but that it must "look as if it would do" - because all implementations of OutputStream must "look" in the same way [which is another way of saying "do abstract" I think]) I think the API doc is not "revealing implementation details" but it is the *specification* of that interface and derivations must (should) conform to this specification. Isn't this the idea of interfaces? A function that expects an OutputStream should work on ANY OutputStream, shouldn't it? just kidding: I mean, what would be the point in implementing a checksum function as OutputStream.write which throws its result as IOException? Or which requires to call close() as very first operation to tell that the application is about to transmit confidential data? :-) > Statement concerning "synchronous" nature of the output stream > is invalid as well. Really synchronous stream does not require > flush() but OutputStream has it. ahh, interesting point! I think this is another bug in the API. flush() is wrong. Because write specifies "The general contract for write is that one byte is written to the output stream." but not "a byte may be written or buffered". Actually, an application would need to call flush() after each write (or bunch of write calls) to ensure that write really did something otherwise I think. I didn't found in the spec of OutputStream that it would be required to call flush(). This should mean that calling flush is not required which in turn leads to the conclusion that write must be synchrous (private threads are forbidden because not specified :)) which in turn leads to the conclusion that flush() is not needed at all... I mean, what if someone would only store in write and do the "real write" in flush() and never else? An application could write in one stream and read on another one (e.g. in bidirectional communication) and would never get anything back, because nothing was actually written because no flush was called? Then someone could even think that on error in some write the data could remain buffered AND throw an exception, retrying to send the data in the next write. Ohh, and if there would be some message number inside, and underlaying write (e.g. a protocol offering InputStream/OutputStream) would check this and throw "DuplicatedMessageNumber" the stream would only throw it again and again beeing unusable... In short: I have no clue how someone could be able to implement an asynchrounos write (which is realiable and correct) without beeing specific to anything which is not specified by OutputStream. Well, I think in the end OutputStream was not intended for such communication or protocol implementations - but to read a local disk file or so. In case of I/O errors usually you can abort your application and change the hard disk :-) oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Bob_Jacobsen at lbl.gov Mon Jun 11 09:32:23 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Mon, 11 Jun 2007 08:32:23 -0700 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611142116.GN10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> Message-ID: At 4:21 PM +0200 6/11/07, Steffen DETTMER wrote: > > Statement concerning "synchronous" nature of the output stream >> is invalid as well. Really synchronous stream does not require >> flush() but OutputStream has it. > >ahh, interesting point! > >I think this is another bug in the API. flush() is wrong. Because >write specifies "The general contract for write is that one byte >is written to the output stream." but not "a byte may be written >or buffered". > >Actually, an application would need to call flush() after each >write (or bunch of write calls) to ensure that write really did >something otherwise I think. OutputStreams don't _have_ to be synchronous or asynchronous, but the OutputStream API was be arranged so that subclasses _can_ be synchronous or asynchronous. Such generality is the hardest part of getting an API right. Hence, if at some point a program using an OutputStream wants to be sure that the data has been pushed all the way out, flush() is available. For some subclasses, e.g. the buffered ones, this has important behavior. Others write the data from each call, and flush() doesn't do anything. You _can_ omit it in programs that are known to use this second type, but there's no requirement that you do so; the interface is general in that way. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From Steffen.DETTMER at ingenico.com Mon Jun 11 12:32:39 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 20:32:39 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> Message-ID: <20070611183239.GT10821@elberon.bln.de.ingenico.com> * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: > >Actually, an application would need to call flush() after each > >write (or bunch of write calls) to ensure that write really did > >something otherwise I think. > OutputStreams don't _have_ to be synchronous or asynchronous, > but the OutputStream API was be arranged so that subclasses > _can_ be synchronous or asynchronous. Ahh, oki. Thanks for the clarificaion. So in short, flush() MUST be called on OutputStream, this is just not documented correctly or so clearly (right?). So the overall usage semantics would be: 1. call write (multiple times if desired) 2. call flush only if both succeeded, write was successful. If flush fails it remains unknown if a part of the data was written and/or will be repeated. So the spec (API doc) is wrong. Correct would be to tell that write behaves as told as long as it is followed by a call to flush, otherwise data may or may not get lost (depending wheter close() is called and calls flush(), which seems not to be guaranteed/required). BTW, I think it is a little bit... erm... interesting to find the specification (java API doc reference) wrong, having a need to conclude it from the presence of some methods with "it would make no sense if they behave exactly as specified, so specification must be wrong (incomplete)". > Such generality is the hardest part of getting an API right. Yes, seems to be proven ;) > Hence, if at some point a program using an OutputStream wants > to be sure that the data has been pushed all the way out, > flush() is available. For some subclasses, e.g. the buffered > ones, this has important behavior. Others write the data from > each call, and flush() doesn't do anything. > You _can_ omit it in programs that are known to use this second > type, but there's no requirement that you do so; the interface > is general in that way. I think, it still it must be called always, otherwise the application could break if passing a different runtime type as OutputStream. I think, if the application/method needs a special "type of OutputStream" then the parameter type must be a subclass but not OutputStream, maybe a PrintStream or so - otherwise the compiler could not detect this error (passing wrong type). Is this correct? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Bob_Jacobsen at lbl.gov Mon Jun 11 13:00:52 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Mon, 11 Jun 2007 12:00:52 -0700 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611183239.GT10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> Message-ID: At 8:32 PM +0200 6/11/07, Steffen DETTMER wrote: >So the spec (API doc) is wrong. Correct would be to tell that >write behaves as told as long as it is followed by a call to >flush, otherwise data may or may not get lost (depending wheter >close() is called and calls flush(), which seems not to be >guaranteed/required). I'm not entirely sure that the spec is wrong, but reasonable people can differ on this. In the 1.5 JavaDocs, all that the docs say for the write methods is that they write to the _output_ _stream_; there is no guarantee of anything beyond that. Only the flush method has any guarantee about the data, which is >Flushes this output stream and forces any buffered output bytes to >be written out. The general contract of flush is that calling it is >an indication that, if any bytes previously written have been >buffered by the implementation of the output stream, such bytes >should immediately be written to their intended destination. People commonly use various OutputStreams without using flush(), and it often works, but it's a bad practice and will eventually bite them. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From netbeans at gatworks.com Mon Jun 11 13:31:57 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 15:31:57 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611183239.GT10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> Message-ID: <466DA32D.1010602@gatworks.com> Steffen DETTMER wrote: > * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: >>> Actually, an application would need to call flush() after each >>> write (or bunch of write calls) to ensure that write really did >>> something otherwise I think. > >> OutputStreams don't _have_ to be synchronous or asynchronous, >> but the OutputStream API was be arranged so that subclasses >> _can_ be synchronous or asynchronous. > > Ahh, oki. Thanks for the clarificaion. > > So in short, flush() MUST be called on OutputStream, this is just > not documented correctly or so clearly (right?). No. Flush can be called to force all current data in java buffer's to be written to the kernel - NOW. A flush() can also *imply* that, besides writing out the buffer's that java employs, may also imply/ask the kernel to write all data thusfar written to the kernel, to be physically placed on the destination device - NOW. For some OS's there is no need to do a kernel flush(), as the I/O is synchronized already. Since this is java, you never know what OS your on. From tjarvi at qbang.org Mon Jun 11 19:28:27 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Jun 2007 19:28:27 -0600 (MDT) Subject: [Rxtx] [OT] select :-) In-Reply-To: <466DA32D.1010602@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: On Mon, 11 Jun 2007, Uncle George wrote: > Steffen DETTMER wrote: >> * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: >>>> Actually, an application would need to call flush() after each >>>> write (or bunch of write calls) to ensure that write really did >>>> something otherwise I think. >> >>> OutputStreams don't _have_ to be synchronous or asynchronous, >>> but the OutputStream API was be arranged so that subclasses >>> _can_ be synchronous or asynchronous. >> >> Ahh, oki. Thanks for the clarificaion. >> >> So in short, flush() MUST be called on OutputStream, this is just >> not documented correctly or so clearly (right?). > No. > Flush can be called to force all current data in java buffer's to be > written to the kernel - NOW. > > A flush() can also *imply* that, besides writing out the buffer's that > java employs, may also imply/ask the kernel to write all data thusfar > written to the kernel, to be physically placed on the destination device > - NOW. > For some OS's there is no need to do a kernel flush(), as the I/O is > synchronized already. Since this is java, you never know what OS your on. To add to the confusion, flush on the C side throws away data. drain makes sure it is written. Looking at the ParallelImp.c we can probably do better. /* we set a timeout because all calls are sequentiell (also with asynchron) this means that the default timeout of unlimited blocks all calls (also close and status request) if the device is down */ GetCommTimeouts( (HANDLE)fd, &timeouts ); timeouts.WriteTotalTimeoutMultiplier = 0; timeouts.WriteTotalTimeoutConstant = 2000; /* 2000 is the min value for the default Windows NT and Windows 2000 driver */ SetCommTimeouts( (HANDLE)fd, &timeouts ); while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } errorCount = 0; bytes += countWritten; count -= countWritten; } LPRPort has some timeout code that appears to be doing nothing but flipping bits back and forth right now. The commapi rxtx follows allows for timeout control from javax.comm.CommPort. The above is a solution that worked in one specific use case. With timeouts in place, the original 'old printer going offline' problem could be solved. That printer code isn't written in stone. In fact it was ajusted from being able to print 'asdf' to a daisy wheel printer to working for one person. BTW, I've finished teaching after hours tonight and will be moving forward with a new rxtx release in my free time. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Jun 11 21:28:04 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 23:28:04 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: <466E12C4.1010305@gatworks.com> > Looking at the ParallelImp.c we can probably do better. > The problem stemmed from the possibility that the writev routine could have written some of the buffer, in chunks, printer pauses, refuses any more chunks, and a timeout occurs. Do you or do you not cause an exception to be thrown? Is there a way to set timeout for a ParallelPort data output stream? I cant find it. From tjarvi at qbang.org Mon Jun 11 22:17:23 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Jun 2007 22:17:23 -0600 (MDT) Subject: [Rxtx] [OT] select :-) In-Reply-To: <466E12C4.1010305@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> <466E12C4.1010305@gatworks.com> Message-ID: On Mon, 11 Jun 2007, Uncle George wrote: >> Looking at the ParallelImp.c we can probably do better. >> > The problem stemmed from the possibility that the writev routine could > have written some of the buffer, in chunks, printer pauses, refuses any > more chunks, and a timeout occurs. Do you or do you not cause an > exception to be thrown? > > Is there a way to set timeout for a ParallelPort data output stream? I > cant find it. hmm I looked again after you asked. The timeouts are only controllable on the receive side. This comes from CommPort; the parent. So what we are talking about is some bytes in memory that rxtx has and is supposed to write. A buffer perhaps? The approach with rxtx in the past has been to ignore output buffer sizes. The assumption is that the library does not know how to best handle buffers. There are buffered output streams that can do buffering on top of rxtx for instance. There is also a question regarding what was actually ment when the API was put together. My suspicion is that it was put together while looking at one OS API and was never ment to be anything more than a hook into that API. The comments are fairly telling combined with reading the w32 API. So looking at the problem again.. The current timeout behavior appears fairly arbitrary. Presumably this is to prevent a program from hanging instead of using a helper thread to write - heavy handed for new programmers. Even so, I don't think the write should timeout at all if it is not configurable. >From the API perspective, "What Timeout?" -- Trent Jarvi tjarvi at qbang.org From Steffen.DETTMER at ingenico.com Tue Jun 12 02:14:48 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 12 Jun 2007 10:14:48 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466DA32D.1010602@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: <20070612081447.GU10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Mon, Jun 11, 2007 at 15:31 -0400: > Steffen DETTMER wrote: > > Ahh, oki. Thanks for the clarificaion. > > > > So in short, flush() MUST be called on OutputStream, this is just > > not documented correctly or so clearly (right?). > No. hum (though now I got it, but...). > Flush can be called to force all current data in java buffer's to be > written to the kernel - NOW. > > A flush() can also *imply* that, besides writing out the > buffer's that java employs, may also imply/ask the kernel to > write all data thusfar written to the kernel, to be physically > placed on the destination device - NOW. > > For some OS's there is no need to do a kernel flush(), as the I/O is > synchronized already. Since this is java, you never know what OS your on. (well, but if you're going to kernel level, even flush cannot guarantee that data will "be physically placed". Maybe you're flushing to a file via NFS (and the client "thinks" that it was written, but maybe it was just buffered by the NFS server) or so... but of course such exceptions of the rules are constructable always.) Well, you tell that depending on the OS it can be that flush is needed or it can be that flush is not needed (beacuse the I/O is synchronized already), right? Also, applications should work on any OS, which includes the OSes that do need flush. Since the application cannot know whether flush is needed or not because it doesn't know what the OS is doing, it has to call flush, hasn't it? I mean, if it would not call flush then it would not work on such OSes (except the written data would not be needed at all, but in this would be an artificial example :)). Since applications are supposed to work this would be wrong, wouldn't it? So would it be correct to say: "Applications, that should work under all OSes (including the OSes where the I/O is not synchronised already), have to call flush on OutputStream to ensure the data is transfered to the kernel." or is this wrong? If so, then I'm afraid I missed the point again :( oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Tue Jun 12 04:46:52 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 12 Jun 2007 06:46:52 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070612081447.GU10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> <20070612081447.GU10821@elberon.bln.de.ingenico.com> Message-ID: <466E799C.7060700@gatworks.com> S > (well, but if you're going to kernel level, even flush cannot > guarantee that data will "be physically placed". Thats true now-a-days because ( from "man 2 sync" ) : > According to the standard specification (e.g., SVID), sync() schedules > the writes, but may return before the actual writing is done. However, > since version 1.3.20 Linux does actually wait. (This still does not > guarantee data integrity: modern disks have large caches.) My disk drive has 8mb cache. Maybe you're > flushing to a file via NFS (and the client "thinks" that it was > written, but maybe it was just buffered by the NFS server) or > so... but of course such exceptions of the rules are > constructable always.) > > Well, you tell that depending on the OS it can be that flush is > needed or it can be that flush is not needed (beacuse the I/O is > synchronized already), right? Also, applications should work on > any OS, which includes the OSes that do need flush. Its not OS's that need flush, its applications that want to have some assurance that data is written to the device that really needs to use flush. If your program ( or thread ) dies then it is in your best interest to write out the critical data as soon as possible, as economical as possible. These are trade-off's that the application programmer makes. A big buffer may mean big loss of data, a small buffer may mean spending too much time writing out data. > > > So would it be correct to say: > > "Applications, that should work under all OSes (including the > OSes where the I/O is not synchronised already), have to call > flush on OutputStream to ensure the data is transfered to the > kernel." > > or is this wrong? If so, then I'm afraid I missed the point again > :( > No that is not wrong. Ensuring that data is transfered to the OS is just about what any application can do. From tjarvi at qbang.org Thu Jun 14 08:16:47 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 14 Jun 2007 08:16:47 -0600 (MDT) Subject: [Rxtx] rxtx and usb-serial solution In-Reply-To: References: Message-ID: On Thu, 14 Jun 2007, Vladimir Kirtchev wrote: > Hi Trent, > > I develop a Java application which communicates with devices which have > USB-to-Serial bridge in them. The target OS is Linux. So for this purpose I > use RXTX. > > But I encountered a strange problem - when reading from the InputStream, I > receive series of zeros. I have this problem under Linux only. Under Windows > it is fine. > Actually this problem is the same as the one described here: > http://marc.info/?l=rxtx&m=109703190731748&w=2. > > > So I searched for the problem in the native code. And found that the root of > the problem is in SerialImp.c, > int configure_port( int fd ) > { > ... > ttyset.c_iflag = INPCK; > ... > } > > This line enables input parity checking, and the data sent from the device > is processed by the OS driver before being read with read(). > In this case the driver detects some problem and sets the received bytes to > zero. > > On the other hand in the Java part a set the serial port parameters with > SerialPort.PARITY_NONE. According to me, except all other things, this > should also disable INPCK in c_iflag. > > So I refactored the method translate_parity(...) to the following: > > int translate_parity( JNIEnv *env, struct termios *ttyset, jint parity ) > { > ENTER( "translate_parity" ); > #ifdef CMSPAR > ttyset->c_cflag &= ~(PARENB | PARODD | CMSPAR ); > #endif /* CMSPAR */ > switch( parity ) { > case JPARITY_NONE: > ttyset->c_iflag &= ~INPCK; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_EVEN: > ttyset->c_cflag |= PARENB; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_ODD: > ttyset->c_cflag |= PARENB | PARODD; > LEAVE( "translate_parity" ); > return 0; > #ifdef CMSPAR > case JPARITY_MARK: > ttyset->c_cflag |= PARENB | PARODD | CMSPAR; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_SPACE: > ttyset->c_cflag |= PARENB | CMSPAR; > LEAVE( "translate_parity" ); > return 0; > #endif /* CMSPAR */ > default: > printf("Parity missed %i\n", (int) parity ); > } > > LEAVE( "translate_parity" ); > /* > For some reason the native exceptions are not being caught. Moving this > to the Java side fixed the issue. taj. > throw_java_exception( env, UNSUPPORTED_COMM_OPERATION, > "", "parity value not supported" ); > */ > return 1; > } > > This modification solved the problem and now it works correctly under Linux. > > I think I will be a nice if this is idea is included in a future release of > RXTX. > > Thanks Vadim, I'll try that out. Forwarding to the rxtx mail-list too. This is probably not going to help USB drivers on windows which I'm sure some are looking for. As far as I can tell, windows USB bluetooth and serial dongles are limited by driver functionality. Some are good and others lack key features. -- Trent Jarvi tjarvi at qbang.org From dan.sandberg.lists at gmail.com Mon Jun 18 14:43:39 2007 From: dan.sandberg.lists at gmail.com (Dan Sandberg) Date: Mon, 18 Jun 2007 13:43:39 -0700 Subject: [Rxtx] Fix for JNI Get/Set Field Errors Message-ID: <4676EE7B.7060800@gmail.com> Hi, I've fixed the problems that cause the following JNI error when extra JNI checking ( -Xjni:check ) is turned on. FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) The problem was basically that GetLong was being used to get ints, and SetInt was used for longs. The patch below fixes this. Please let me know if there are any questions / problems. Cheers, -Dan diff -aur old/SerialImp.c src/SerialImp.c --- old/SerialImp.c 2007-06-18 13:24:33.000000000 -0700 +++ src/SerialImp.c 2007-06-18 06:26:26.000000000 -0700 @@ -1337,7 +1337,7 @@ report("init_threads: get eis\n"); jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); report("init_threads: set eis\n"); - (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); + (*eis->env)->SetLongField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); report("init_threads: stop\n"); report_time_end( ); return( 1 ); @@ -1530,7 +1530,7 @@ jobject jobj, jboolean interrupted ) { int fd = get_java_var( env, jobj,"fd","I" ); - struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var( env, jobj, "eis", "J" ); + struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var_long( env, jobj, "eis", "J" ); int result, count=0; char message[80]; @@ -2939,7 +2939,7 @@ /* TRENT */ int flag, count = 0; struct event_info_struct *eis = ( struct event_info_struct * ) - get_java_var( env, *jobj,"eis","J" ); + get_java_var_long( env, *jobj,"eis","J" ); report_time_start(); flag = eis->eventflags[SPE_DATA_AVAILABLE]; @@ -4873,9 +4873,9 @@ exceptions: none comments: ----------------------------------------------------------*/ -size_t get_java_var( JNIEnv *env, jobject jobj, char *id, char *type ) +long get_java_var_long( JNIEnv *env, jobject jobj, char *id, char *type ) { - int result = 0; + long result = 0; jclass jclazz = (*env)->GetObjectClass( env, jobj ); jfieldID jfd = (*env)->GetFieldID( env, jclazz, id, type ); @@ -4889,7 +4889,11 @@ LEAVE( "get_java_var" ); return result; } - result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); + if ( !strcmp( type, "J" ) ) { + result = (long)( (*env)->GetLongField( env, jobj, jfd ) ); + } else { + result = (int) ( (*env)->GetIntField( env, jobj, jfd ) ); + } /* ct7 & gel * Added DeleteLocalRef */ (*env)->DeleteLocalRef( env, jclazz ); if(!strncmp( "fd",id,2) && result == 0) @@ -4900,6 +4904,10 @@ return result; } +int get_java_var( JNIEnv *env, jobject jobj, char *id, char *type ) { + return (int) get_java_var_long( env, jobj, id, type ); +} + /*---------------------------------------------------------- throw_java_exception diff -aur old/SerialImp.h src/SerialImp.h --- old/SerialImp.h 2007-06-18 13:24:39.000000000 -0700 +++ src/SerialImp.h 2007-06-18 06:23:43.000000000 -0700 @@ -413,7 +413,8 @@ void system_wait(); void finalize_event_info_struct( struct event_info_struct * ); int read_byte_array( JNIEnv *, jobject *, int, unsigned char *, int, int ); -size_t get_java_var( JNIEnv *, jobject, char *, char * ); +int get_java_var( JNIEnv *, jobject, char *, char * ); +long get_java_var_long( JNIEnv *, jobject, char *, char * ); jboolean is_interrupted( struct event_info_struct * ); int send_event(struct event_info_struct *, jint, int ); void dump_termios(char *,struct termios *); From yvespielusenet at free.fr Tue Jun 26 03:41:58 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 11:41:58 +0200 Subject: [Rxtx] [PARALLEL] resource in use Message-ID: <1182850918.3483.10.camel@localhost.localdomain> Hello, So now I want to modify the timeout of the library for parallel port. I have downloaded source code. There is a makefile for migw. SO I have installed mingw on ubuntu and modified the makefile.mingw32 to set it for my system. I have no error but some warnings. The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But When I want to use it the jvm crash :( How can I know what is wrong ? How rxtx windows release has been done ? thanks -- yves piel From yvespielusenet at free.fr Tue Jun 26 07:17:02 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 15:17:02 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182850918.3483.10.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> Message-ID: <1182863822.3483.17.camel@localhost.localdomain> Here is the Makefile I use, the output of the 'make' and the log of the jvm when it crashed : - The Makefile : http://yvespiel.free.fr/rxtx/Makefile - The make output : http://yvespiel.free.fr/rxtx/compile.txt - The crash log : http://yvespiel.free.fr/rxtx/hs_err_pid2100.log I have compiled rxtx under Debian testing with mingw : narma at linimi:/tmp/err$ dpkg -l | grep mingw ii mingw32 3.4.5.20060117.1.dfsg-3 ii mingw32-binutils 2.17.50-20070129.1-1 ii mingw32-runtime 3.12-1 thanks fort help :) Le mardi 26 juin 2007 ? 11:41 +0200, yves pielusenet a ?crit : > Hello, > So now I want to modify the timeout of the library for parallel port. I > have downloaded source code. There is a makefile for migw. SO I have > installed mingw on ubuntu and modified the makefile.mingw32 to set it > for my system. > I have no error but some warnings. > The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But > When I want to use it the jvm crash :( > > How can I know what is wrong ? > > How rxtx windows release has been done ? > > thanks > From yvespielusenet at free.fr Tue Jun 26 07:40:11 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 15:40:11 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182863822.3483.17.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> <1182863822.3483.17.camel@localhost.localdomain> Message-ID: <1182865211.3483.21.camel@localhost.localdomain> I have add the options '--enable-stdcall-fixup' to the 'i586-mingw32msvc-ld' commande. Now I have no warning. But the JVM always crashes :( The output seems more detailled, but I don't understand anything... Here is files : http://yvespiel.free.fr/rxtx/2/ -- yves piel Le mardi 26 juin 2007 ? 15:17 +0200, yves pielusenet a ?crit : > Here is the Makefile I use, the output of the 'make' and the log of the > jvm when it crashed : > > - The Makefile : http://yvespiel.free.fr/rxtx/Makefile > - The make output : http://yvespiel.free.fr/rxtx/compile.txt > - The crash log : http://yvespiel.free.fr/rxtx/hs_err_pid2100.log > > I have compiled rxtx under Debian testing with mingw : > narma at linimi:/tmp/err$ dpkg -l | grep mingw > ii mingw32 3.4.5.20060117.1.dfsg-3 > ii mingw32-binutils 2.17.50-20070129.1-1 > ii mingw32-runtime 3.12-1 > > thanks fort help :) > > > Le mardi 26 juin 2007 ? 11:41 +0200, yves pielusenet a ?crit : > > Hello, > > So now I want to modify the timeout of the library for parallel port. I > > have downloaded source code. There is a makefile for migw. SO I have > > installed mingw on ubuntu and modified the makefile.mingw32 to set it > > for my system. > > I have no error but some warnings. > > The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But > > When I want to use it the jvm crash :( > > > > How can I know what is wrong ? > > > > How rxtx windows release has been done ? > > > > thanks > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From yvespielusenet at free.fr Tue Jun 26 08:27:42 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 16:27:42 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182865211.3483.21.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> <1182863822.3483.17.camel@localhost.localdomain> <1182865211.3483.21.camel@localhost.localdomain> Message-ID: <1182868062.3483.24.camel@localhost.localdomain> I think thant the include files of jdk were not for windows but for linux. So I have copied include/ folder from windows to linux and I modified the Makefile to use those file. It compile fine but the JVM always crash :( http://yvespiel.free.fr/rxtx/3/ Le mardi 26 juin 2007 ? 15:40 +0200, yves pielusenet a ?crit : > I have add the options '--enable-stdcall-fixup' to the > 'i586-mingw32msvc-ld' commande. Now I have no warning. But the JVM > always crashes :( The output seems more detailled, but I don't > understand anything... > Here is files : > http://yvespiel.free.fr/rxtx/2/ > From netbeans at gatworks.com Fri Jun 1 05:38:50 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 07:38:50 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <465F7ADD.1010501@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> Message-ID: <4660054A.2040202@gatworks.com> Manuel Naranjo wrote: In the case of my module, you can > unplug the device but it will not delete the symlink until those apps > that had opened the port has closed it. This is done this way to avoid > kernel panics. What does this mean to user code ? I have tried the alternate route ( other than closing ) which is sleep inbetween the I/O errors ( an unplugged USB device). When the device is plugged back in, The writes to the device still get an I/O error. This would seem to be a lost cause for the application. From netbeans at gatworks.com Fri Jun 1 06:35:48 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 08:35:48 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <465F7ADD.1010501@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> Message-ID: <466012A4.90608@gatworks.com> Manuel Naranjo wrote: In the case of my module, you can > unplug the device but it will not delete the symlink until those apps > that had opened the port has closed it. T Did u also mean for this to happen? USB0 was not closed by application. Apparently USB1 got created when USB device was plugged back in. There is only one USB device on a 4 port USB hub. This also seems to suggest that application recovery to be impossible. > Jun 1 07:10:08 mylaptop kernel: garmin_gps 1-1.4:1.0: Garmin GPS usb/tty converter detected > Jun 1 07:10:08 mylaptop kernel: usb 1-1.4: Garmin GPS usb/tty converter now attached to ttyUSB0 > Jun 1 07:15:17 mylaptop kernel: usb 1-1: USB disconnect, address 4 > Jun 1 07:15:17 mylaptop kernel: usb 1-1.4: USB disconnect, address 5 > Jun 1 07:15:17 mylaptop kernel: garmin_gps 1-1.4:1.0: device disconnected > Jun 1 07:15:26 mylaptop kernel: usb 1-1: new full speed USB device using uhci_hcd and address 6 > Jun 1 07:15:26 mylaptop kernel: hub 1-1:1.0: USB hub found > Jun 1 07:15:26 mylaptop kernel: hub 1-1:1.0: 4 ports detected > Jun 1 07:15:27 mylaptop kernel: usb 1-1.4: new full speed USB device using uhci_hcd and address 7 > Jun 1 07:15:27 mylaptop kernel: garmin_gps 1-1.4:1.0: Garmin GPS usb/tty converter detected > Jun 1 07:15:27 mylaptop kernel: usb 1-1.4: Garmin GPS usb/tty converter now attached to ttyUSB1 From naranjo.manuel at gmail.com Fri Jun 1 09:17:22 2007 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Fri, 01 Jun 2007 12:17:22 -0300 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <466012A4.90608@gatworks.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> <466012A4.90608@gatworks.com> Message-ID: <46603882.5050701@gmail.com> Uncle George escribi?: > Manuel Naranjo wrote: > In the case of my module, you can > >> unplug the device but it will not delete the symlink until those apps >> that had opened the port has closed it. T >> > > Did u also mean for this to happen? USB0 was not closed by application. > > Apparently USB1 got created when USB device was plugged back in. There > is only one USB device on a 4 port USB hub. > > This also seems to suggest that application recovery to be impossible. > Exactly there's a dead symlink (you can read and write to it and nothing will happen) and a new port will be created when a new device is connencted. From netbeans at gatworks.com Fri Jun 1 10:20:46 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 12:20:46 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <46603882.5050701@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> <466012A4.90608@gatworks.com> <46603882.5050701@gmail.com> Message-ID: <4660475E.5090202@gatworks.com> Not sure what u mean by "symlink". U cant read/write to it anymore. U get I/O error. In this scenario the device effectively went dead, and only solution is to close the channel. reconnecting the USB device, although dead, but not closed, will create a second device. This does not seem to be a desirable side-effect. The user will now have ttyUSB1, wondering where did ttyUSB0 go to. The application will also be in a confused state, as well as RXTX, because RXTX wont know about ttyUSB1. Manuel Naranjo wrote: > Uncle George escribi?: >> Manuel Naranjo wrote: >> In the case of my module, you can >> >>> unplug the device but it will not delete the symlink until those apps >>> that had opened the port has closed it. T >>> >> Did u also mean for this to happen? USB0 was not closed by application. >> >> Apparently USB1 got created when USB device was plugged back in. There >> is only one USB device on a 4 port USB hub. >> >> This also seems to suggest that application recovery to be impossible. >> > Exactly there's a dead symlink (you can read and write to it and nothing > will happen) and a new port will be created when a new device is connencted. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From arnab.bhaumik at gmail.com Mon Jun 4 01:40:16 2007 From: arnab.bhaumik at gmail.com (arnab bhaumik) Date: Mon, 4 Jun 2007 13:10:16 +0530 Subject: [Rxtx] full duplex com port with rxtx Message-ID: hi , till now i did half duplex communication with rxtx package on com package. my question is : is it possible to use com port with full duplex mode with rxtx package . ther is example of SimpleRead class and SimpleWrite class. it is clear that if i can use both the class simultaneously then full duplex is possible......... arnab/vu2bpw -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070604/6edb0453/attachment-0002.html From lists at iDIAcomputing.com Mon Jun 4 07:53:17 2007 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Mon, 04 Jun 2007 09:53:17 -0400 Subject: [Rxtx] full duplex com port with rxtx In-Reply-To: References: Message-ID: <4664194D.90301@iDIAcomputing.com> arnab bhaumik wrote: > hi , > > till now i did half duplex communication with rxtx package on com > package. > > my question is : is it possible to use com port with full duplex mode > with rxtx package . > > > ther is example of SimpleRead class and SimpleWrite class. it is > clear that if i can use both the class simultaneously then full duplex > is possible......... I haven't looked at the SimpleRead and SimpleWrite classes (I originally wrote my code for the javax.comm api), but full duplex is certainly possible. My CommReader class requires an object analogous to a OutputStream or Writer. When started, it spawns a thread that reads the comm port and writes to that output device. In this way the input is asynchronous and dependent on the actual input data. For full duplex, I extend that class with CommReaderWriter, which adds synchronous output methods. Hope that helps, George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From supsoop at hotmail.com Mon Jun 4 15:21:06 2007 From: supsoop at hotmail.com (soop soop) Date: Mon, 04 Jun 2007 21:21:06 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- Message-ID: Hi Guys, Looked through the archives but still cannot figure this out. I have a Motorola G24 GPRS/GSM modem that I am connecting to my server running Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not detecting the port, CommPortIdentifier.getPortIdentifiers(). I have added the line to RXTXCommDriver: "ttyACM" // for USB Modems Rxtx still does not seem to find the port. Is there something I am missing to make this port visable? [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control Model driver for USB modems and ISDN adapters I really need your help as I have moved my server from windows to Linux and have been down for a few days because of this .. Thanks so much! _________________________________________________________________ PC Magazine’s 2007 editors’ choice for best Web mail—award-winning Windows Live Hotmail. http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 From tjarvi at qbang.org Mon Jun 4 16:17:35 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Jun 2007 16:17:35 -0600 (MDT) Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: On Mon, 4 Jun 2007, soop soop wrote: > Hi Guys, > > Looked through the archives but still cannot figure this out. I have a > Motorola G24 GPRS/GSM modem that I am connecting to my server running Ubuntu. > I can see my modem as is shows up as ttyACM0, but RXTX is not detecting the > port, CommPortIdentifier.getPortIdentifiers(). > > I have added the line to RXTXCommDriver: > > "ttyACM" // for USB Modems > > Rxtx still does not seem to find the port. Is there something I am missing to > make this port visable? > > [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver > [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device > [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control Model > driver for USB modems and ISDN adapters > > I really need your help as I have moved my server from windows to Linux and > have been down for a few days because of this .. Thanks so much! > You could try the INSTALL documentation that comes with the source for possible solutions. Those usually involve lockfile creation, permissions on the device file or the device is in use by another application (even another session of your application). The usual commands: ls -l /dev/ttyACM0 fuser /dev/ttyACM0 touch /var/lock/LCK.testfile && rm -f /var/lock/LCK.testfile whoami To disable lockfiles: ../configure --disable-lockfiles && make install -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Jun 4 16:22:52 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 04 Jun 2007 18:22:52 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <466490BC.3090801@gatworks.com> soop soop wrote: > I really need your help as I have moved my server from windows to Linux > and have been down for a few days because of this .. Thanks so much! can u open the device ? ie is the file protection/permissions keeping you out? From supsoop at hotmail.com Mon Jun 4 16:44:40 2007 From: supsoop at hotmail.com (soop soop) Date: Mon, 04 Jun 2007 22:44:40 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <466490BC.3090801@gatworks.com> Message-ID: Thanks for the reply, I see no exceptions being thrown, just no detection of the port whats so ever. I will run rxtx in debug mode and log. If this were a permissions issue would I not see some exceptions being thrown? >From: Uncle George >Reply-To: RXTX Developers and Users >To: RXTX Developers and Users >Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >Date: Mon, 04 Jun 2007 18:22:52 -0400 > >soop soop wrote: > > > I really need your help as I have moved my server from windows to Linux > > and have been down for a few days because of this .. Thanks so much! > >can u open the device ? ie is the file protection/permissions keeping >you out? >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ Get a preview of Live Earth, the hottest event this summer - only on MSN http://liveearth.msn.com?source=msntaglineliveearthhm From netbeans at gatworks.com Mon Jun 4 17:06:15 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 04 Jun 2007 19:06:15 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <46649AE7.10405@gatworks.com> Exceptions on what? On startup it wants to lookup all devices in /dev that it is capable of opening ( within the list of specific 'comm' devices ). If it cannot open, then does not get onto list. Part of this process, if configured, will also test if the "LOCK" schema can also be opened for the device. then it gets on the list of avail comm port. soop soop wrote: > Thanks for the reply, > > I see no exceptions being thrown, just no detection of the port whats so > ever. I will run rxtx in debug mode and log. If this were a permissions > issue would I not see some exceptions being thrown? > > >> From: Uncle George >> Reply-To: RXTX Developers and Users >> To: RXTX Developers and Users >> Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >> Date: Mon, 04 Jun 2007 18:22:52 -0400 >> >> soop soop wrote: >> >>> I really need your help as I have moved my server from windows to Linux >>> and have been down for a few days because of this .. Thanks so much! >> can u open the device ? ie is the file protection/permissions keeping >> you out? >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _________________________________________________________________ > Get a preview of Live Earth, the hottest event this summer - only on MSN > http://liveearth.msn.com?source=msntaglineliveearthhm > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From alex.flint at gmail.com Mon Jun 4 21:31:49 2007 From: alex.flint at gmail.com (Alex Flint) Date: Tue, 5 Jun 2007 13:01:49 +0930 Subject: [Rxtx] random EXCEPTION_ACCESS_VIOLATION errors Message-ID: Hi All, I'm running winXP and RXTX 2.1-7r2 (the latest from the webpage as of June 2007). I'm sending sequences of 64 lines (each line has about 15 chars) at various intervals. The strings are sent fine, until I get the following error (from hs_err_pid3316.log, at the end of this email). What can I do to avoid the error? Obviously this is a low-level memory exception, but is there any way I can keep the JVM running after such an error? I noticed the exact same problem here: http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20070129/1180520.html Cheers, Alex # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x100034fb, pid=3316, tid=2400 # # Java VM: Java HotSpot(TM) Client VM (1.6.0_01-b06 mixed mode, sharing) # Problematic frame: # C [rxtxSerial.dll+0x34fb] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # --------------- T H R E A D --------------- Current thread (0x00386400): JavaThread "main" [_thread_in_native, id=2400] siginfo: ExceptionCode=0xc0000005, reading address 0x20726f78 Registers: EAX=0x20726f20, EBX=0x6d8922c0, ECX=0x00000005, EDX=0x20726f20 ESP=0x003efa30, EBP=0x003efb68, ESI=0x269728a0, EDI=0x00386400 EIP=0x100034fb, EFLAGS=0x00010212 Top of Stack: (sp=0x003efa30) 0x003efa30: 003efa3c 003efa64 0000000f ffffffff 0x003efa40: 003efa40 2a97f808 003efa6c 2b190ca8 0x003efa50: 00000000 2b190ec0 003efa90 008e2dd7 0x003efa60: 003efa90 008e2dd7 26977f88 6d815e72 0x003efa70: 00000004 2696eae0 0000008a 003efb0c 0x003efa80: 6d852b4a 2696eae0 00000003 26970930 0x003efa90: 000000cb 2696eae0 6d86b264 00385d40 0x003efaa0: 0000003f 003efb0c 26977f90 2ace65d8 Instructions: (pc=0x100034fb) 0x100034eb: ff ff 8d 76 00 eb 02 89 f6 90 8b 45 f8 8b 55 f8 0x100034fb: 8b 4a 58 83 c9 04 89 48 58 83 c4 f8 8b 45 f8 8b Stack: [0x003a0000,0x003f0000), sp=0x003efa30, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x34fb] Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j gnu.io.RXTXPort.writeArray([BIIZ)V+0 j gnu.io.RXTXPort$SerialOutputStream.write([B)V+76 j com.bjt.media.server.CommLink.send(Ljava/lang/String;)V+48 j com.bjt.media.server.DigitoolConnection.select(I)V+73 j com.bjt.media.server.DigitoolConnection.main([Ljava/lang/String;)V+74 v ~StubRoutines::call_stub --------------- P R O C E S S --------------- Java Threads: ( => current thread ) 0x02a69400 JavaThread "Thread-0" [_thread_in_native, id=3052] 0x02a4d000 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=3920] 0x02a48400 JavaThread "CompilerThread0" daemon [_thread_blocked, id=1968] 0x02a47400 JavaThread "Attach Listener" daemon [_thread_blocked, id=2984] 0x02a46400 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=2660] 0x02a41c00 JavaThread "Finalizer" daemon [_thread_blocked, id=3924] 0x02a3d800 JavaThread "Reference Handler" daemon [_thread_blocked, id=4008] =>0x00386400 JavaThread "main" [_thread_in_native, id=2400] Other Threads: 0x02a34400 VMThread [id=3708] 0x02a4e800 WatcherThread [id=3964] VM state:not at safepoint (normal execution) VM Mutex/Monitor currently owned by a thread: None Heap def new generation total 960K, used 131K [0x22960000, 0x22a60000, 0x22e40000) eden space 896K, 7% used [0x22960000, 0x22970ea8, 0x22a40000) from space 64K, 99% used [0x22a50000, 0x22a5fff8, 0x22a60000) to space 64K, 0% used [0x22a40000, 0x22a40000, 0x22a50000) tenured generation total 4096K, used 76K [0x22e40000, 0x23240000, 0x26960000) the space 4096K, 1% used [0x22e40000, 0x22e53060, 0x22e53200, 0x23240000) compacting perm gen total 12288K, used 137K [0x26960000, 0x27560000, 0x2a960000) the space 12288K, 1% used [0x26960000, 0x26982518, 0x26982600, 0x27560000) ro space 8192K, 62% used [0x2a960000, 0x2ae5e4e8, 0x2ae5e600, 0x2b160000) rw space 12288K, 52% used [0x2b160000, 0x2b7a0e78, 0x2b7a1000, 0x2bd60000) Dynamic libraries: 0x00400000 - 0x00423000 C:\Program Files\Java\jre1.6.0_01\bin\javaw.exe 0x7c900000 - 0x7c9b0000 C:\WINDOWS\system32\ntdll.dll 0x7c800000 - 0x7c8f4000 C:\WINDOWS\system32\kernel32.dll 0x77dd0000 - 0x77e6b000 C:\WINDOWS\system32\ADVAPI32.dll 0x77e70000 - 0x77f01000 C:\WINDOWS\system32\RPCRT4.dll 0x7e410000 - 0x7e4a0000 C:\WINDOWS\system32\USER32.dll 0x77f10000 - 0x77f57000 C:\WINDOWS\system32\GDI32.dll 0x76390000 - 0x763ad000 C:\WINDOWS\system32\IMM32.DLL 0x7c340000 - 0x7c396000 C:\Program Files\Java\jre1.6.0_01\bin\msvcr71.dll 0x6d7c0000 - 0x6da07000 C:\Program Files\Java\jre1.6.0_01\bin\client\jvm.dll 0x76b40000 - 0x76b6d000 C:\WINDOWS\system32\WINMM.dll 0x5cd70000 - 0x5cd77000 C:\WINDOWS\system32\serwvdrv.dll 0x5b0a0000 - 0x5b0a7000 C:\WINDOWS\system32\umdmxfrm.dll 0x6d310000 - 0x6d318000 C:\Program Files\Java\jre1.6.0_01\bin\hpi.dll 0x76bf0000 - 0x76bfb000 C:\WINDOWS\system32\PSAPI.DLL 0x6d770000 - 0x6d77c000 C:\Program Files\Java\jre1.6.0_01\bin\verify.dll 0x6d3b0000 - 0x6d3cf000 C:\Program Files\Java\jre1.6.0_01\bin\java.dll 0x6d7b0000 - 0x6d7bf000 C:\Program Files\Java\jre1.6.0_01\bin\zip.dll 0x10000000 - 0x10012000 C:\Documents and Settings\Alex\workspace\MediaServer\rxtxSerial.dll 0x73d90000 - 0x73db7000 C:\WINDOWS\system32\crtdll.dll VM Arguments: jvm_args: -Djava.library.path=C:\Documents and Settings\Alex\workspace\MediaServer java_command: com.bjt.media.server.DigitoolConnection Launcher Type: SUN_STANDARD Environment Variables: CLASSPATH=.;C:\Program Files\Java\j2re1.4.2_07\lib\ext\QTJava.zip PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\wbem;c:\applications\php;C:\Program Files\MATLAB\R2006a\bin\win32;C:\Roger\Projects\UAV\Bin\Debug;C:\Program Files\Microsoft SQL Server\80\Tools\Binn\;c:\Program Files\Microsoft SQL Server\90\Tools\binn\;C:\Program Files\QuickTime\QTSystem\;C:\Pfps\system;C:\Program Files\Java\jdk1.6.0_01\bin;C:\Program Files\Java\jdk1.6.0_01\jre\bin USERNAME=Alex OS=Windows_NT PROCESSOR_IDENTIFIER=x86 Family 15 Model 4 Stepping 1, GenuineIntel --------------- S Y S T E M --------------- OS: Windows XP Build 2600 Service Pack 2 CPU:total 1 family 15, cmov, cx8, fxsr, mmx, sse, sse2 Memory: 4k page, physical 1046508k(275288k free), swap 2522816k(1909176k free) vm_info: Java HotSpot(TM) Client VM (1.6.0_01-b06) for windows-x86, built on Mar 14 2007 00:24:02 by "java_re" with unknown MS VC++:1310 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070604/c87ae1f0/attachment-0002.html From alwyn.schoeman at gmail.com Tue Jun 5 00:10:19 2007 From: alwyn.schoeman at gmail.com (Alwyn Schoeman) Date: Tue, 5 Jun 2007 08:10:19 +0200 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Hi, I'm using a similar modem. By default rxtx doesn't look for devices that start with ACM, so you need to modify the source code and recompile. Look in RXTXCommDriver and add values for ACM in the registerScannedPorts method in the Linux specific parts. Look for osName.equals("Linux")... On 6/4/07, soop soop wrote: > > Hi Guys, > > Looked through the archives but still cannot figure this out. I have a > Motorola G24 GPRS/GSM modem that I am connecting to my server running > Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not > detecting the port, CommPortIdentifier.getPortIdentifiers(). > > I have added the line to RXTXCommDriver: > > "ttyACM" // for USB Modems > > Rxtx still does not seem to find the port. Is there something I am missing > to make this port visable? > > [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver > [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device > [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control > Model > driver for USB modems and ISDN adapters > > I really need your help as I have moved my server from windows to Linux > and > have been down for a few days because of this .. Thanks so much! > > _________________________________________________________________ > PC Magazine's 2007 editors' choice for best Web mail?award-winning Windows > Live Hotmail. > > http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -- Alwyn Schoeman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/b6cb3053/attachment-0002.html From naranjo.manuel at gmail.com Tue Jun 5 06:48:45 2007 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Tue, 05 Jun 2007 09:48:45 -0300 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> References: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Message-ID: <46655BAD.7010501@gmail.com> That's right, an easier solution is creating symlinks to acm. For example make ttyS70 to 79 point to ACM0 to 9 and that will help you a lot, and doesn't even require compile. > Hi, > > I'm using a similar modem. By default rxtx doesn't look for devices > that start with ACM, so you need to modify the > source code and recompile. > > Look in RXTXCommDriver and add values for ACM in the > registerScannedPorts method in the Linux specific parts. Look for > osName.equals("Linux")... > From juanemc2 at gmail.com Tue Jun 5 07:02:43 2007 From: juanemc2 at gmail.com (Juan) Date: Tue, 5 Jun 2007 10:02:43 -0300 Subject: [Rxtx] Problems with Epson TMU220B POSPrinter using XON/XOFF Flow Control and rxtx jar and dll's with the serial port. Message-ID: Hi!, I?m having trouble printing to the serial port using the latest version of rxtx jar and dll's with an Epson POSPrinter. I`ve switched the printer to work with XON/XOFF Flow Control and have watched the serial port to be sure the printer is sending the XON XOFF stop and go characters. I`ve setted the port like this: CommPortIdentifier commPortIdentifier = CommPortIdentifier.* getPortIdentifier*(_portName); SerialPort serialPort = (SerialPort)commPortIdentifier.open(*this*.getClass().getName(), 2000); serialPort.setSerialPortParams(_baudRate, _dataBits, _stopBits, _parity); serialPort.setFlowControlMode( SerialPort.*FLOWCONTROL_XONXOFF_IN* | SerialPort.*FLOWCONTROL_XONXOFF_OUT*); where the baudRate is 9600 the dataBits is 8 the stopBits is 1 and the parity is 0 It seems as the library isn`t taking into account the XON XOFF setting. I would like to know if I`m setting correctly the Flow Control and if you had had any experiences using XON XOFF flow control and could give me some help to solve my problem. I`m very thankful in advance, Yours, Juan Polero -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/b080995a/attachment-0002.html From ehdez.correo at gmail.com Tue Jun 5 07:12:53 2007 From: ehdez.correo at gmail.com (=?ISO-8859-1?Q?Enrique_Hern=E1ndez?=) Date: Tue, 5 Jun 2007 09:12:53 -0400 Subject: [Rxtx] problem with rxtx Message-ID: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Hello: I doing a simple test to show the serial ports. This is the code: import java.util.Enumeration; import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; public class Show { private Enumeration portList; private CommPortIdentifier portId; private SerialPort port; /** Creates a new instance of Show */ public Show() { } public static void main(String args[]){ Show show = new Show(); show.portList = CommPortIdentifier.getPortIdentifiers(); String tPort = ""; System.out.println("========================================="); while(show.portList.hasMoreElements()){ show.portId = (CommPortIdentifier)show.portList.nextElement(); if(show.portId.getPortType() == CommPortIdentifier.PORT_SERIAL) tPort = "Serial"; else tPort = "Parallel"; System.out.println(show.portId.getName() + " " + tPort); } } } whit The problem is that this code not show the serial ports, this show the no use serial ports. I want to connect whit the modem but when windows open and connect the modem my application don't see the port(COMM3) when it is connect. what I can do? Is that the correct way to know the ports? thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/eedd744b/attachment-0002.html From ehdez.correo at gmail.com Tue Jun 5 07:42:13 2007 From: ehdez.correo at gmail.com (=?ISO-8859-1?Q?Enrique_Hern=E1ndez?=) Date: Tue, 5 Jun 2007 09:42:13 -0400 Subject: [Rxtx] serial port Message-ID: <4a814e1f0706050642p4ce9ac7bka80f9479c524c5ea@mail.gmail.com> Hello: How I can ask to the port what device is connect and information about this device. thanks. bye. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/4d10d26a/attachment-0002.html From supsoop at hotmail.com Tue Jun 5 09:29:00 2007 From: supsoop at hotmail.com (soop soop) Date: Tue, 05 Jun 2007 15:29:00 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Message-ID: Hi Guys, Thanks for all your help. I found the problem. I created a user, Tomcat55, for my tomcat but it did not belong to any group. I then added this user to dialout group to have access to the device ttyACM0. Works perfectly! Again permissions was the issue. This also seems to be persistent as a server reboot does not effect the access. Cheers! >From: "Alwyn Schoeman" >Reply-To: RXTX Developers and Users >To: "RXTX Developers and Users" >Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >Date: Tue, 5 Jun 2007 08:10:19 +0200 > >Hi, > >I'm using a similar modem. By default rxtx doesn't look for devices that >start with ACM, so you need to modify the >source code and recompile. > >Look in RXTXCommDriver and add values for ACM in the registerScannedPorts >method in the Linux specific parts. Look for osName.equals("Linux")... > >On 6/4/07, soop soop wrote: >> >>Hi Guys, >> >>Looked through the archives but still cannot figure this out. I have a >>Motorola G24 GPRS/GSM modem that I am connecting to my server running >>Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not >>detecting the port, CommPortIdentifier.getPortIdentifiers(). >> >>I have added the line to RXTXCommDriver: >> >>"ttyACM" // for USB Modems >> >>Rxtx still does not seem to find the port. Is there something I am missing >>to make this port visable? >> >>[ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver >>[ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device >>[ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control >>Model >>driver for USB modems and ISDN adapters >> >>I really need your help as I have moved my server from windows to Linux >>and >>have been down for a few days because of this .. Thanks so much! >> >>_________________________________________________________________ >>PC Magazine's 2007 editors' choice for best Web mail—award-winning Windows >>Live Hotmail. >> >>http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 >> >> >>_______________________________________________ >>Rxtx mailing list >>Rxtx at qbang.org >>http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > >-- >Alwyn Schoeman >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ Need a break? Find your escape route with Live Search Maps. http://maps.live.com/default.aspx?ss=Restaurants~Hotels~Amusement%20Park&cp=33.832922~-117.915659&style=r&lvl=13&tilt=-90&dir=0&alt=-1000&scene=1118863&encType=1&FORM=MGAC01 From netbeans at gatworks.com Tue Jun 5 09:42:31 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 11:42:31 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <46658467.20101@gatworks.com> soop soop wrote: > > Hi Guys, > > Thanks for all your help. I found the problem. I created a user, > Tomcat55, for my tomcat but it did not belong to any group. I then added Look at man pages for the program udev. From tjarvi at qbang.org Tue Jun 5 18:18:17 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Jun 2007 18:18:17 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Message-ID: On Tue, 5 Jun 2007, Enrique Hern?ndez wrote: > The problem is that this code not show the serial ports, this show the no > use serial ports. I want to connect whit the modem but when windows open and > connect the modem my application don't see the port(COMM3) when it is > connect. > what I can do? > Is that the correct way to know the ports? > Hello, We may have problems understanding each other. On windows, the port will not be an available serial port if another application has the port open. That is just how the library behaves. If you can not see the port in the enumerated list, you could not open it. Also note that enumeration only happens once. If you add a port such as a new USB dongle, the port will not be visible until the next time your application runs. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Tue Jun 5 18:45:01 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 20:45:01 -0400 Subject: [Rxtx] problem with rxtx In-Reply-To: References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Message-ID: <4666038D.8090700@gatworks.com> Trent Jarvi wrote: > > > Also note that enumeration only happens once. If you add a port such as > a new USB dongle, the port will not be visible until the next time your > application runs. Is this written in stone ? somewhere? From tjarvi at qbang.org Tue Jun 5 18:54:36 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Jun 2007 18:54:36 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <4666038D.8090700@gatworks.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> Message-ID: On Tue, 5 Jun 2007, Uncle George wrote: > Trent Jarvi wrote: >> >> >> Also note that enumeration only happens once. If you add a port such as >> a new USB dongle, the port will not be visible until the next time your >> application runs. > > Is this written in stone ? somewhere? It is just the current behavior. There is nothing preventing a fix that allows reenumeration. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Tue Jun 5 19:55:19 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 21:55:19 -0400 Subject: [Rxtx] problem with rxtx In-Reply-To: References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> Message-ID: <46661407.4020308@gatworks.com> >> Is this written in stone ? somewhere? > > It is just the current behavior. There is nothing preventing a fix that > allows reenumeration. With usb, ..... , things come and go. Seems a shame that you have to kill application to get at the device u just plugged in. From joachim at buechse.ch Wed Jun 6 01:50:06 2007 From: joachim at buechse.ch (Joachim Buechse) Date: Wed, 6 Jun 2007 09:50:06 +0200 Subject: [Rxtx] problem with rxtx In-Reply-To: <46661407.4020308@gatworks.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> <46661407.4020308@gatworks.com> Message-ID: <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> On MacOS RXTX's enumeration handling is more flexible. It will find new ports that are added during the lifetime of the application. But this is inherently incompatible with suns javax.comm implementation... Regards, Joachim On 06.06.2007, at 03:55, Uncle George wrote: > >>> Is this written in stone ? somewhere? >> >> It is just the current behavior. There is nothing preventing a >> fix that >> allows reenumeration. > > With usb, ..... , things come and go. Seems a shame that you have to > kill application to get at the device u just plugged in. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Jun 6 06:06:48 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Jun 2007 06:06:48 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> <46661407.4020308@gatworks.com> <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> Message-ID: Sun's javax.comm is not a major concern going forward. As long as we do not break old applications using rxtx, I see no reason to limit rxtx to that convention. We have already rejected version 3 from Sun as a dead end and limited our compatability to version 2. That does not mean we will not try to work with Sun and others but the current javax.comm convention (v3) is not a well conceived path. There has been discussion about doing a JSR which is one valid option. On Wed, 6 Jun 2007, Joachim Buechse wrote: > On MacOS RXTX's enumeration handling is more flexible. It will find > new ports that are added during the lifetime of the application. But > this is inherently incompatible with suns javax.comm implementation... > > Regards, > Joachim > > On 06.06.2007, at 03:55, Uncle George wrote: > >> >>>> Is this written in stone ? somewhere? >>> >>> It is just the current behavior. There is nothing preventing a >>> fix that >>> allows reenumeration. >> >> With usb, ..... , things come and go. Seems a shame that you have to >> kill application to get at the device u just plugged in. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From yvespielusenet at free.fr Wed Jun 6 08:46:35 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 16:46:35 +0200 Subject: [Rxtx] [PARALLEL] resource in use Message-ID: <1181141195.3407.20.camel@localhost.localdomain> Hello, I want to use rxtx in my application. I haveto send data to a very old printer (which have a drum and hammers http://perso.orange.fr/tiie/page00010017.html) This is printer is connecter with centronics. It works well but, while it's writting and I putthe printer off-line, after about 45 seconds, I have this error : ------------------------------------- java.io.IOException: La ressource demand?e est en cours d'utilisation. in writeArray at gnu.io.LPRPort.writeArray(Native Method) at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:292) at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:161) at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:156) at mce.buffer.bufferManager.BufferManager$PrintBuffer.run(BufferManager.java:141) The IOexception means "The wanted resource is in use" ------------------------------------- Here is the line 141 of BufferManager : ------------------------------------- while(send){ try{ fos.write(bb); <=== line 141 send = false; } catch(Exception e){ javax.swing.JOptionPane.showMessageDialog(null, "Erreur d'envoie. Veuillez cliquer sur OK pour relancer l'impression de la vignette.\nV?rifiez votre impression !", "Erreur d'envoie", javax.swing.JOptionPane.WARNING_MESSAGE); e.printStackTrace(System.err); System.err.flush(); System.out.println(e); send = true; } } -------------------------------- 'fos' is an outputstream which contains the rxtx stream (this.os is the rxtx outputstream) : -------------------------------- public void write(byte[] bb) throws IOException{ this.write(bb, 0, bb.length); } public void write(byte[] bb, int off, int len) throws IOException{ while(!imp1.isPrinterSelected() || !imp2.isPrinterSelected()){ } this.os.write(bb, off, len); } -------------------------------- Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( can you help me ? thank you :) -- yves piel From yvespielusenet at free.fr Wed Jun 6 09:11:15 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 17:11:15 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181141195.3407.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> Message-ID: <1181142675.3407.23.camel@localhost.localdomain> I forgot to tell that It's under windows XP and java 1.5. Le mercredi 06 juin 2007 ? 16:46 +0200, yves pielusenet a ?crit : > Hello, > I want to use rxtx in my application. I haveto send data to a very old > printer (which have a drum and hammers > http://perso.orange.fr/tiie/page00010017.html) > This is printer is connecter with centronics. It works well but, while > it's writting and I putthe printer off-line, after about 45 seconds, I > have this error : > ------------------------------------- > java.io.IOException: La ressource demand?e est en cours d'utilisation. > in writeArray > at gnu.io.LPRPort.writeArray(Native Method) > at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:292) > at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:161) > at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:156) > at mce.buffer.bufferManager.BufferManager$PrintBuffer.run(BufferManager.java:141) > > The IOexception means "The wanted resource is in use" > ------------------------------------- > > Here is the line 141 of BufferManager : > > ------------------------------------- > while(send){ > try{ > fos.write(bb); <=== line 141 > send = false; > } > catch(Exception e){ > javax.swing.JOptionPane.showMessageDialog(null, "Erreur d'envoie. Veuillez cliquer sur OK pour relancer l'impression de la vignette.\nV?rifiez votre impression !", "Erreur d'envoie", javax.swing.JOptionPane.WARNING_MESSAGE); > e.printStackTrace(System.err); > System.err.flush(); > System.out.println(e); > send = true; > } > } > -------------------------------- > 'fos' is an outputstream which contains the rxtx stream (this.os is the rxtx outputstream) : > > -------------------------------- > public void write(byte[] bb) throws IOException{ > this.write(bb, 0, bb.length); > } > public void write(byte[] bb, int off, int len) throws IOException{ > while(!imp1.isPrinterSelected() || !imp2.isPrinterSelected()){ > } > this.os.write(bb, off, len); > } > -------------------------------- > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > can you help me ? > > thank you :) > From netbeans at gatworks.com Wed Jun 6 09:21:46 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 11:21:46 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181141195.3407.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> Message-ID: <4666D10A.8000507@gatworks.com> } > -------------------------------- > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > can you help me ? > > thank you :) > windoz or linux? ( I guess windoz ) for windoz, there appears to be a timeout ( as Comments suggest ) of about 40seconds. > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } for linux, there is no implied timeout. > if( write( fd, bytes, count ) < 0 ) > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); From netbeans at gatworks.com Wed Jun 6 09:39:41 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 11:39:41 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666D10A.8000507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> Message-ID: <4666D53D.90000@gatworks.com> Uncle George wrote: > } >> -------------------------------- >> >> Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( >> >> can you help me ? From reading the code, I can see your concern. And it appears you are correct, because some of the data will be sent to the OS printer buffers, and then it will refuse to accept anymore. Unfortunately, writeArray does not return the num of characters written :{ So application has no idea to how many characters were accepted by the OS. I dont do windoz, so I cant say with absolute certainty what windoz will do with an off-line condition. If you have the source, and can compile, then maybe u can increase the loop count to hit 4hours? From yvespielusenet at free.fr Wed Jun 6 09:53:25 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 17:53:25 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666D10A.8000507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> Message-ID: <1181145205.3407.35.camel@localhost.localdomain> Thank you for your explanation :) This timeout comes when no data has been send to the printer after 40seconds if I well understand. But why there is such a timeout ? If I setthe printer offline while it's printing I mustn't have an exception. I don't understand why the "printer should solv all problems like buffer full" in 40 seconds. If I pause the printer the buffer will not be emptied, isn't it ? I not very familiar with C/C++, but it seem that the exception is thrown only when countWritten == 0, that means no data at all has been sent. So Is my code is good since when I intercept this exception I send all my buffer again. There is no way that the printer receive two times same bytes ? thanks ps: yes the application is running on windows XP since I developpe under Debian Le mercredi 06 juin 2007 ? 11:21 -0400, Uncle George a ?crit : > } > > -------------------------------- > > > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > > > can you help me ? > > > > thank you :) > > > > windoz or linux? ( I guess windoz ) > > for windoz, there appears to be a timeout ( as Comments suggest ) of > about 40seconds. > > while( count > 0 ){ > > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > > /* > > this are 20 * 2 seconds, in this time a printer (or other parallel device) > > should solv all problems like buffer full, etc > > */ > > if(errorCount++ < 20){ > > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > > continue; > > } > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > for linux, there is no implied timeout. > > if( write( fd, bytes, count ) < 0 ) > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Wed Jun 6 10:34:24 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 12:34:24 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181145205.3407.35.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> Message-ID: <4666E210.30507@gatworks.com> yves pielusenet wrote: > Thank you for your explanation :) > This timeout comes when no data has been send to the printer after > 40seconds if I well understand. But why there is such a timeout ? If I > setthe printer offline while it's printing I mustn't have an exception. > I don't understand why the "printer should solv all problems like buffer > full" in 40 seconds. If I pause the printer the buffer will not be > emptied, isn't it ? > > I not very familiar with C/C++, but it seem that the exception is thrown > only when countWritten == 0, that means no data at all has been sent. So > Is my code is good since when I intercept this exception I send all my > buffer again. There is no way that the printer receive two times same > bytes ? More technically, the function call returns and reports that 0 characters was written in this call. when 0 characters are written, it will check how many times 0 characters was written. If it has tried LESS than 20 times(errorCount), it will sleep() and try to write again. After 20 times, it wont sleep, but throw you the exception. Now suppose you are writing a 120 character line. you off-lined/paused your printer. The OS has room for 80 more characters in it's printer buffer. The WriteFile() will have a char count of 120, but on return the countWritten = 80. You still have 40 more characters to print. Since countWritten != 0, the counters: bytes += countWritten; count -= countWritten; get updated, and the Writefile now has a count of 40 characters. Since the printer is off-line, the countwritten is 0. And so the loop continues, till 40 seconds is up. As to why it is this way, i dont know ( not a windoz maven ); Also the sleep(20) in the loop is not so intuitive to suggest 2 seconds of sleep. I would have guessed 20seconds, or 20milliseconds. But go figure. BTW: Since your computer sends you error messages in French, does it curse in English? :)))) From yvespielusenet at free.fr Thu Jun 7 02:27:44 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Thu, 07 Jun 2007 10:27:44 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666E210.30507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> Message-ID: <1181204864.3501.10.camel@localhost.localdomain> Maybe in my case I should re-compile rxtx and change the code. Instead of send an exception I should display a dialog box to ask if it's printer problem or if it should trie to send bytes. Something like : while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } if(displayDialogBox("Try again to send datas ??")){ errorCount = 0; } else{ throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } } Le mercredi 06 juin 2007 ? 12:34 -0400, Uncle George a ?crit : > yves pielusenet wrote: > > Thank you for your explanation :) > > This timeout comes when no data has been send to the printer after > > 40seconds if I well understand. But why there is such a timeout ? If I > > setthe printer offline while it's printing I mustn't have an exception. > > I don't understand why the "printer should solv all problems like buffer > > full" in 40 seconds. If I pause the printer the buffer will not be > > emptied, isn't it ? > > > > I not very familiar with C/C++, but it seem that the exception is thrown > > only when countWritten == 0, that means no data at all has been sent. So > > Is my code is good since when I intercept this exception I send all my > > buffer again. There is no way that the printer receive two times same > > bytes ? > More technically, the function call returns and reports that 0 > characters was written in this call. > when 0 characters are written, it will check how many times 0 characters > was written. If it has tried LESS than 20 times(errorCount), it will > sleep() and try to write again. > After 20 times, it wont sleep, but throw you the exception. > > Now suppose you are writing a 120 character line. you off-lined/paused > your printer. The OS has room for 80 more characters in it's printer > buffer. The WriteFile() will have a char count of 120, but on return the > countWritten = 80. You still have 40 more characters to print. > Since countWritten != 0, the counters: > bytes += countWritten; > count -= countWritten; > get updated, and the Writefile now has a count of 40 characters. Since > the printer is off-line, the countwritten is 0. And so the loop > continues, till 40 seconds is up. > > As to why it is this way, i dont know ( not a windoz maven ); > Also the sleep(20) in the loop is not so intuitive to suggest 2 seconds > of sleep. I would have guessed 20seconds, or 20milliseconds. But go figure. > > BTW: Since your computer sends you error messages in French, does it > curse in English? :)))) > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 06:11:43 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 08:11:43 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181204864.3501.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> Message-ID: <4667F5FF.8070903@gatworks.com> your suggestion appears good. I dont know what displayDialogBox exactly will do, so all I can say it that it looks good. But I'd like to wait 10min before first dialog box And a 5 min wait for every dialog box there after. And since these are custom solution/choices, maybe a more exact explanation of what the issue is. if(errorCount++ < 300){ // wait 10min ( 10min * 60sec / 2 ) Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } if(displayDialogBox("Printer has Paused. Retry sending data?")){ errorCount = 150; // Wait for 5 min thereafter continue; } > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } yves pielusenet wrote: > Maybe in my case I should re-compile rxtx and change the code. Instead > of send an exception I should display a dialog box to ask if it's > printer problem or if it should trie to send bytes. Something like : > > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > > if(displayDialogBox("Try again to send datas ??")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > } > From yvespielusenet at free.fr Thu Jun 7 07:17:21 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Thu, 07 Jun 2007 15:17:21 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4667F5FF.8070903@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <4667F5FF.8070903@gatworks.com> Message-ID: <1181222241.3501.20.camel@localhost.localdomain> thank you :) 'displayDialogBox()' I think doesn't exist. It was just for the example :) But I think It should not be so complicated to display a dialog box under windows with YES/NO buttons. When yes is clicked it return 0 other it returns 1. Le jeudi 07 juin 2007 ? 08:11 -0400, Uncle George a ?crit : > your suggestion appears good. I dont know what displayDialogBox exactly > will do, so all I can say it that it looks good. > > But I'd like to wait 10min before first dialog box And a 5 min wait for > every dialog box there after. And since these are custom > solution/choices, maybe a more exact explanation of what the issue is. > > if(errorCount++ < 300){ // wait 10min ( 10min * 60sec / 2 ) > Sleep( 20 ); /* make a small pause to execute all other requests > in all other threads */ > continue; > } > > if(displayDialogBox("Printer has Paused. Retry sending data?")){ > errorCount = 150; // Wait for 5 min thereafter > continue; > } > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > > yves pielusenet wrote: > > Maybe in my case I should re-compile rxtx and change the code. Instead > > of send an exception I should display a dialog box to ask if it's > > printer problem or if it should trie to send bytes. Something like : > > > > while( count > 0 ){ > > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > > /* > > this are 20 * 2 seconds, in this time a printer (or other parallel device) > > should solv all problems like buffer full, etc > > */ > > if(errorCount++ < 20){ > > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > > continue; > > } > > > > if(displayDialogBox("Try again to send datas ??")){ > > errorCount = 0; > > } > > else{ > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > } > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 07:41:43 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 09:41:43 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181222241.3501.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <4667F5FF.8070903@gatworks.com> <1181222241.3501.20.camel@localhost.localdomain> Message-ID: <46680B17.8050109@gatworks.com> yves pielusenet wrote: > thank you :) > 'displayDialogBox()' I think doesn't exist. It was just for the > example :) too bad. Good luck. From rtrout at webbresearch.com Thu Jun 7 11:23:04 2007 From: rtrout at webbresearch.com (Robert Trout) Date: Thu, 07 Jun 2007 13:23:04 -0400 Subject: [Rxtx] Disconnected PortServer TS causes Java to hang Message-ID: <1181236984.14186.33.camel@sisyphus.DinkumSoftware.com> I'm running Linux with sun's Java 1.4.2, Java comm API 2.0, RXTX 2.0-7pre1, and the RealPort digi driver. "/dev/ttyrp00" is a RealPort device. My Java application never returns from a ComPortIdentifier.getPortIdentifier("/dev/ttyrp00") call while the Digi PortServer TS 4 is disconnected from the network. If I later re-connect the PortServer, the call returns about 30 seconds later (it's like a serial port read or write is blocking until the PortServer is re- connected). With the PortServer disconnected, minicom immediately responds with "cannot open /dev/ttyrp00: No such file or directory". I would like my Java application to behave similarly. That is, respond with an error condition instead of hanging when the PortServer is not connected. Since minicom and Java behave differently, I think this "hanging" behavior may be due to RXTX or Java? Has anyone had a similar issue? Solutions? Suggestions? Thanks, Robert From vicnevicne at gmail.com Thu Jun 7 12:16:02 2007 From: vicnevicne at gmail.com (Vicne) Date: Thu, 07 Jun 2007 20:16:02 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181204864.3501.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> Message-ID: <46684B62.7080802@gmail.com> yves pielusenet wrote: > Maybe in my case I should re-compile rxtx and change the code. Instead > of send an exception I should display a dialog box to ask if it's > printer problem or if it should trie to send bytes. Something like : > > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > > if(displayDialogBox("Try again to send datas ??")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > } > Sorry to step in without a specific solution to your problem, but I wanted to share my feeling regarding this proposal. AFAIK, it's generally considered bad practice to pop-up a prompt from a library. The main reason is that in general use, you can't guarantee that someone is actually present behind the console. Imagine a print server in a machine room, connected to a park of printers. In that case, when one printer fails, the logical behaviour would be to use an other one. If you change RxTx the way you propose, the printer queue will simply be stuck with a useless "Try again to send data ?" prompt until an administrator opens a remote connection to the print server's console and clicks "no". Second, it would create a dependency upon the existence of a graphical console (if you go the graphical "dialogBox" way). On many applications (typically server or embedded ones), the JVM is "headless" and if you try to pop-up a dialog, your app would throw an exception (at best) or just wouldn't display the prompt anywhere... Going the "text console" way is not more reliable, because on graphical environments, the text console is hidden unless explicitly requested. My advice would be to think again and find another solution. Ideas are : - make the number of retries a parameter so that you can tune it to what you think is reasonable - throw a more specific exception when the number of retries has been reached, so that a specific prompt can be shown at a higher level Anyway, if you feel that the prompt is the way to go in your case, I would at least make that prompt conditional. The least intrusive way would probably be using a system property, like if("true".equals(System.getProperty("org.rxtx.usePrompt")) && displayDialogBox("Retry sending data ?")){ errorCount = 0; } else{ throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } By default, the behaviour would remain as it is now, but you could force the prompts by defining the property at VM launch if desired. (for example : java.exe -Dorg.rxtx.usePrompt=true myApp) Also, you seemed to say you wanted the printer to start again exactly where is stopped. It would indeed be the best way when the printer is put offline for a few seconds. On the other hand, if the printer is turned off (or the printer runs out of paper, or someone steps on the mains cable), then the only way to go back to a "stable" situation would be by printing the item (page, label, etc.) again from scratch... Just my two cents. Vicne PS : By the way, the dialog box thing is very platform dependant on the C-side, and I think the simplest way would probably be to bridge it to a Java call where you can implement it like you proposed : public boolean displayDialogBox(prompt) { return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); } From netbeans at gatworks.com Thu Jun 7 14:08:24 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 16:08:24 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46684B62.7080802@gmail.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> Message-ID: <466865B8.4060004@gatworks.com> My feeling is that the code that was suggested was for his environs ( his shop ). The issue here is that after a 40+ second wait, an exception will be thrown. But you really dont have a way of 'cancelling' all the WriteFiles() that have already occured before the exception so that your writeArray and the Commapi can backtrack to a position in which they are in sync. The main ( really mine ) concern is not to lose data, or replicate data. After 40seconds, 300 seconds, 55min, no matter how long, data should not be lost or duplicated. But as soon as the exception is thrown, that possibility exists. Maybe an event should be thrown instead? Vicne wrote: > yves pielusenet wrote: >> Maybe in my case I should re-compile rxtx and change the code. Instead >> of send an exception I should display a dialog box to ask if it's >> printer problem or if it should trie to send bytes. Something like : >> >> while( count > 0 ){ >> if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ >> /* >> this are 20 * 2 seconds, in this time a printer (or other parallel device) >> should solv all problems like buffer full, etc >> */ >> if(errorCount++ < 20){ >> Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ >> continue; >> } >> >> if(displayDialogBox("Try again to send datas ??")){ >> errorCount = 0; >> } >> else{ >> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >> break; >> } >> } >> > > Sorry to step in without a specific solution to your problem, but I > wanted to share my feeling regarding this proposal. AFAIK, it's > generally considered bad practice to pop-up a prompt from a library. > The main reason is that in general use, you can't guarantee that > someone is actually present behind the console. Imagine a print server > in a machine room, connected to a park of printers. In that case, when > one printer fails, the logical behaviour would be to use an other one. > If you change RxTx the way you propose, the printer queue will simply be > stuck with a useless "Try again to send data ?" prompt until an > administrator opens a remote connection to the print server's console > and clicks "no". > Second, it would create a dependency upon the existence of a > graphical console (if you go the graphical "dialogBox" way). On many > applications (typically server or embedded ones), the JVM is "headless" > and if you try to pop-up a dialog, your app would throw an exception (at > best) or just wouldn't display the prompt anywhere... Going the "text > console" way is not more reliable, because on graphical environments, > the text console is hidden unless explicitly requested. > > My advice would be to think again and find another solution. Ideas are : > - make the number of retries a parameter so that you can tune it to what > you think is reasonable > - throw a more specific exception when the number of retries has been > reached, so that a specific prompt can be shown at a higher level > > Anyway, if you feel that the prompt is the way to go in your case, I > would at least make that prompt conditional. The least intrusive way > would probably be using a system property, like > > if("true".equals(System.getProperty("org.rxtx.usePrompt")) > && displayDialogBox("Retry sending data ?")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > > > By default, the behaviour would remain as it is now, but you could > force the prompts by defining the property at VM launch if desired. (for > example : java.exe -Dorg.rxtx.usePrompt=true myApp) > > > Also, you seemed to say you wanted the printer to start again > exactly where is stopped. It would indeed be the best way when the > printer is put offline for a few seconds. On the other hand, if the > printer is turned off (or the printer runs out of paper, or someone > steps on the mains cable), then the only way to go back to a "stable" > situation would be by printing the item (page, label, etc.) again from > scratch... > > > Just my two cents. > > > Vicne > > PS : By the way, the dialog box thing is very platform dependant on the > C-side, and I think the simplest way would probably be to bridge it to a > Java call where you can implement it like you proposed : > > public boolean displayDialogBox(prompt) { > return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", > JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); > } > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Thu Jun 7 17:48:11 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 Jun 2007 17:48:11 -0600 (MDT) Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <466865B8.4060004@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> Message-ID: An event is possible. I'm amazed this is the largest problem encountered while using the parallel code. How would the write ever exit if we throw events? Isn't this going to lead to hung applications? On Thu, 7 Jun 2007, Uncle George wrote: > My feeling is that the code that was suggested was for his environs ( > his shop ). > > The issue here is that after a 40+ second wait, an exception will be > thrown. But you really dont have a way of 'cancelling' all the > WriteFiles() that have already occured before the exception so that your > writeArray and the Commapi can backtrack to a position in which they are > in sync. > > The main ( really mine ) concern is not to lose data, or replicate data. > After 40seconds, 300 seconds, 55min, no matter how long, data should > not be lost or duplicated. But as soon as the exception is thrown, that > possibility exists. > > Maybe an event should be thrown instead? > > Vicne wrote: >> yves pielusenet wrote: >>> Maybe in my case I should re-compile rxtx and change the code. Instead >>> of send an exception I should display a dialog box to ask if it's >>> printer problem or if it should trie to send bytes. Something like : >>> >>> while( count > 0 ){ >>> if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ >>> /* >>> this are 20 * 2 seconds, in this time a printer (or other parallel device) >>> should solv all problems like buffer full, etc >>> */ >>> if(errorCount++ < 20){ >>> Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ >>> continue; >>> } >>> >>> if(displayDialogBox("Try again to send datas ??")){ >>> errorCount = 0; >>> } >>> else{ >>> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >>> break; >>> } >>> } >>> >> >> Sorry to step in without a specific solution to your problem, but I >> wanted to share my feeling regarding this proposal. AFAIK, it's >> generally considered bad practice to pop-up a prompt from a library. >> The main reason is that in general use, you can't guarantee that >> someone is actually present behind the console. Imagine a print server >> in a machine room, connected to a park of printers. In that case, when >> one printer fails, the logical behaviour would be to use an other one. >> If you change RxTx the way you propose, the printer queue will simply be >> stuck with a useless "Try again to send data ?" prompt until an >> administrator opens a remote connection to the print server's console >> and clicks "no". >> Second, it would create a dependency upon the existence of a >> graphical console (if you go the graphical "dialogBox" way). On many >> applications (typically server or embedded ones), the JVM is "headless" >> and if you try to pop-up a dialog, your app would throw an exception (at >> best) or just wouldn't display the prompt anywhere... Going the "text >> console" way is not more reliable, because on graphical environments, >> the text console is hidden unless explicitly requested. >> >> My advice would be to think again and find another solution. Ideas are : >> - make the number of retries a parameter so that you can tune it to what >> you think is reasonable >> - throw a more specific exception when the number of retries has been >> reached, so that a specific prompt can be shown at a higher level >> >> Anyway, if you feel that the prompt is the way to go in your case, I >> would at least make that prompt conditional. The least intrusive way >> would probably be using a system property, like >> >> if("true".equals(System.getProperty("org.rxtx.usePrompt")) >> && displayDialogBox("Retry sending data ?")){ >> errorCount = 0; >> } >> else{ >> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >> break; >> } >> >> >> By default, the behaviour would remain as it is now, but you could >> force the prompts by defining the property at VM launch if desired. (for >> example : java.exe -Dorg.rxtx.usePrompt=true myApp) >> >> >> Also, you seemed to say you wanted the printer to start again >> exactly where is stopped. It would indeed be the best way when the >> printer is put offline for a few seconds. On the other hand, if the >> printer is turned off (or the printer runs out of paper, or someone >> steps on the mains cable), then the only way to go back to a "stable" >> situation would be by printing the item (page, label, etc.) again from >> scratch... >> >> >> Just my two cents. >> >> >> Vicne >> >> PS : By the way, the dialog box thing is very platform dependant on the >> C-side, and I think the simplest way would probably be to bridge it to a >> Java call where you can implement it like you proposed : >> >> public boolean displayDialogBox(prompt) { >> return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", >> JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); >> } >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 19:18:51 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 21:18:51 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> Message-ID: <4668AE7B.3060409@gatworks.com> The UNIX version of writeArray is not too great either. It is possible that the write will only process some of the bytes. #else if( write( fd, bytes, count ) < 0 ) throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); #endif -------------------------------- Maybe it might be better to have the native function inform the caller of the # of characters written, then the commapi/output-buffer can be modified to reflect the #of chars written. If an exception is to be thrown, for too many loops of chars written == 0, then exception wont affect the state of the output buffer. Then a ParallelPort.restart() can be called to resume printing whats in the buffer. Trent Jarvi wrote: > An event is possible. I'm amazed this is the largest problem encountered > while using the parallel code. > > How would the write ever exit if we throw events? Isn't this going to > lead to hung applications? Sure. If you dont time out, then there is nothing that will force an EXIT from the write(). Issue is what has the OS done with the write. > > On Thu, 7 Jun 2007, Uncle George wrote: > >> My feeling is that the code that was suggested was for his environs ( >> his shop ). From yvespielusenet at free.fr Fri Jun 8 01:09:01 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Fri, 08 Jun 2007 09:09:01 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4668AE7B.3060409@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> Message-ID: <1181286541.3674.10.camel@localhost.localdomain> It is not possible that the rxtx java method write(byte[], int offset, int length) return anint which contains the number of byte really send to the printer instead of an exception ? So this is the programm which will see if all bytes have been sent. If not it can retry to send the unsended bytes. -------------------------------------------------------- int sended = 0; while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ sended += countWritten; /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } return sended; /*throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break;*/ } ... ... return countWritten; ------------------------------------------------ Le jeudi 07 juin 2007 ? 21:18 -0400, Uncle George a ?crit : > The UNIX version of writeArray is not too great either. It is possible > that the write will only process some of the bytes. > > #else > if( write( fd, bytes, count ) < 0 ) > throw_java_exception_system_msg( env, IO_EXCEPTION, > "writeArray" ); > #endif > -------------------------------- > > Maybe it might be better to have the native function inform the caller > of the # of characters written, then the commapi/output-buffer can be > modified to reflect the #of chars written. If an exception is to be > thrown, for too many loops of chars written == 0, then exception wont > affect the state of the output buffer. Then a ParallelPort.restart() can > be called to resume printing whats in the buffer. > > > Trent Jarvi wrote: > > An event is possible. I'm amazed this is the largest problem encountered > > while using the parallel code. > > > > How would the write ever exit if we throw events? Isn't this going to > > lead to hung applications? > Sure. If you dont time out, then there is nothing that will force an > EXIT from the write(). Issue is what has the OS done with the write. > > > > On Thu, 7 Jun 2007, Uncle George wrote: > > > >> My feeling is that the code that was suggested was for his environs ( > >> his shop ). > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Fri Jun 8 03:45:00 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 11:45:00 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181286541.3674.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> Message-ID: <20070608094500.GC21069@elberon.bln.de.ingenico.com> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > It is not possible that the rxtx java method write(byte[], int offset, > int length) return anint which contains the number of byte really send > to the printer instead of an exception ? > So this is the programm which will see if all bytes have been sent. If > not it can retry to send the unsended bytes. I think write() is void because in Java people love to do this since OutputStream :-) Of course on such interfaces you cannot implement something nice. If you would have a int write, you would not implement the interface and no applications expecting this interface would link/work/compile. oki, Steffen P.S.: (OT) If you propose not to implement the Java interfaces (especially not on JNI level), maybe optionally offering a wrapper that removes e.g. the write return value and so on to downgrade the powerful classic old POSIX read/write style to the modern limited Java style, then I agree :-) Same for read. Instead of things like "int avialable()" it is more powerful to have an approach as select(2) offers (to guarante the caller that read/write will not block [nothing else make sense anyway IMHO] but may read/write less bytes then requested). The caller gets full control and the higher level protocols can care about timeouts, invoking read in some loops and/or implement retransmission. On top of such an implementation, where everything is controlled, defined, guaranteed and reliable, someone could use an InputStream or OutputStream style interface. Or even better: don't use them at all :) just BTW :-) St. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From yvespielusenet at free.fr Fri Jun 8 05:52:45 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Fri, 08 Jun 2007 13:52:45 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <20070608094500.GC21069@elberon.bln.de.ingenico.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> Message-ID: <1181303565.11203.3.camel@localhost.localdomain> So maybe a better way should be to create a new Exception class which has a method "int getWrittenByte()". So the Exception should be use to send again bytes which are not printed yet. yves Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : > * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > > It is not possible that the rxtx java method write(byte[], int offset, > > int length) return anint which contains the number of byte really send > > to the printer instead of an exception ? > > So this is the programm which will see if all bytes have been sent. If > > not it can retry to send the unsended bytes. > > I think write() is void because in Java people love to do this > since OutputStream :-) Of course on such interfaces you cannot > implement something nice. If you would have a int write, you > would not implement the interface and no applications expecting > this interface would link/work/compile. > > oki, > > Steffen > > P.S.: (OT) > If you propose not to implement the Java interfaces (especially > not on JNI level), maybe optionally offering a wrapper that > removes e.g. the write return value and so on to downgrade the > powerful classic old POSIX read/write style to the modern limited > Java style, then I agree :-) Same for read. Instead of things > like "int avialable()" it is more powerful to have an approach as > select(2) offers (to guarante the caller that read/write will not > block [nothing else make sense anyway IMHO] but may read/write > less bytes then requested). The caller gets full control and the > higher level protocols can care about timeouts, invoking read in > some loops and/or implement retransmission. On top of such an > implementation, where everything is controlled, defined, > guaranteed and reliable, someone could use an InputStream or > OutputStream style interface. Or even better: don't use them at > all :) just BTW :-) > St. > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > 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. > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > 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. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Fri Jun 8 06:46:21 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 08:46:21 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181303565.11203.3.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> Message-ID: <46694F9D.5080501@gatworks.com> It seems that with outputstream.write(b[]), you become terribly uncoordinated as soon as an exception is thrown. Docs do not say what happens to the data. Yet from a practicable point of view, one would like to know if the write was accepted in-full, or rejected before any writes. There are no in betweens, as partial writes are not reportable. So for an outputstream.write(), in order for it to return, the full write request has to be taken, and stored in an internal output buffer. If there is no room, the write() is suspended, till there is room. Or throw's an IOException( "no room in buffer") ; As the select() loop for write reports buffer room avail, then more of the internal buffer is sent to the printer. yves pielusenet wrote: > So maybe a better way should be to create a new Exception class which > has a method "int getWrittenByte()". So the Exception should be use to > send again bytes which are not printed yet. > > yves > > Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : >> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: >>> It is not possible that the rxtx java method write(byte[], int offset, >>> int length) return anint which contains the number of byte really send >>> to the printer instead of an exception ? >>> So this is the programm which will see if all bytes have been sent. If >>> not it can retry to send the unsended bytes. >> I think write() is void because in Java people love to do this >> since OutputStream :-) Of course on such interfaces you cannot >> implement something nice. If you would have a int write, you >> would not implement the interface and no applications expecting >> this interface would link/work/compile. >> >> oki, >> >> Steffen >> >> P.S.: (OT) >> If you propose not to implement the Java interfaces (especially >> not on JNI level), maybe optionally offering a wrapper that >> removes e.g. the write return value and so on to downgrade the >> powerful classic old POSIX read/write style to the modern limited >> Java style, then I agree :-) Same for read. Instead of things >> like "int avialable()" it is more powerful to have an approach as >> select(2) offers (to guarante the caller that read/write will not >> block [nothing else make sense anyway IMHO] but may read/write >> less bytes then requested). The caller gets full control and the >> higher level protocols can care about timeouts, invoking read in >> some loops and/or implement retransmission. On top of such an >> implementation, where everything is controlled, defined, >> guaranteed and reliable, someone could use an InputStream or >> OutputStream style interface. Or even better: don't use them at >> all :) just BTW :-) >> St. >> >> About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. >> 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. >> >> About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. >> 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. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From Steffen.DETTMER at ingenico.com Fri Jun 8 08:12:18 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 16:12:18 +0200 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <46694F9D.5080501@gatworks.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: <20070608141218.GE21069@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 08:46 -0400: > It seems that with outputstream.write(b[]), you become terribly > uncoordinated as soon as an exception is thrown. Docs do not say what > happens to the data. (yes, so avoiding it seems to be good :)) > Yet from a practicable point of view, one would like to know if the > write was accepted in-full, or rejected before any writes. There are no > in betweens, as partial writes are not reportable. (which is an artificial API limitation. I never understood how this happend when they invented JDK because the well-known BSD socket API and thus [probably] WinSock does this correct, but anyway) > So for an outputstream.write(), in order for it to return, the full > write request has to be taken, and stored in an internal output buffer. > If there is no room, the write() is suspended, till there is room. Or > throw's an IOException( "no room in buffer") ; As the select() loop for > write reports buffer room avail, then more of the internal buffer is > sent to the printer. yes, might be good in case of a printer. May be horrible in case of PPP/TCP or some other transmission control protocol which may e.g. repeat data or even omit parts of it (e.g. internet realtime radio station broadcasting)... So I think the idea of "int write" (e.g. BSD sockets, linux files and so on) still is the best. A clean API / implementation should guarantee and allow implementations (users) to rely on that; assumptions and automatic background-sending and so on may look pragmatic and may even work on the first look, but may fail in other situations. BTW, if e.g. BSD socket API is known, why not simply copy it (until something better is invented :)) instead of fiddling around with JDK APIs? anyway, have a nice weekend everyone :-) oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Fri Jun 8 08:55:56 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 10:55:56 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070608141218.GE21069@elberon.bln.de.ingenico.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> Message-ID: <46696DFC.7000801@gatworks.com> >> write reports buffer room avail, then more of the internal buffer is >> sent to the printer. > > yes, might be good in case of a printer. May be horrible in case > of PPP/TCP or some other transmission control protocol which > may e.g. repeat data or even omit parts of it (e.g. internet > realtime radio station broadcasting)... So I think the idea of > "int write" (e.g. BSD sockets, linux files and so on) still is > the best. A clean API / implementation should guarantee and allow > implementations (users) to rely on that; assumptions and > automatic background-sending and so on may look pragmatic and may > even work on the first look, but may fail in other situations. > BTW, if e.g. BSD socket API is known, why not simply copy it > (until something better is invented :)) instead of fiddling > around with JDK APIs? But we were talking about the Parallel Port, and the transmission of data over the commapi/parallel-port schema. There isn't much in bi-directional software communication. Its a simple write one byte at a time interface. I'm not looking to change the comm-api. I'm just looking to alter the interaction between the Native ParallelPort functions, and the java ParallelPort functions that call them. This might be more readily doable than to get a committee to re-specify java-API specs. BTW: Whats is off-topic? ( help: not looking for def of off-topic ) From j.kenneth.gentle at acm.org Fri Jun 8 08:58:59 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Fri, 08 Jun 2007 10:58:59 -0400 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <20070608141218.GE21069@elberon.bln.de.ingenico.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> Message-ID: <200706081459.l58Ex5rA019991@qbang.org> Perhaps it is a bit late to jump in on this one, but here goes anyway. If the solutions all seem to "break" the contract with "java.io.outputstream", then, as noted, that may not be the appropriate contract. At the risk of being heretical, JDK1.4 introduced the "nio" package to address some of the compatibility issues with C apis mentioned in previous posts. The interface "java.nio.channels.WriteableByteChannel" defines the following single method: int write(ByteBuffer source); int, strangely enough, is the actual number of bytes written. So, if RXTX as written, against the JavaCOMM api and OutputStream, doesn't do what we want, how about writing a different set of bindings using the java.nio classes and as much of the underlying native code as possible. Note that just because the java.nio.channels.WriteableByteChannel sends back a result, OutputStream.write doesn't have to - and they could both call the same underlying native code. My 2 cents - maybe not worth even that... Ken From netbeans at gatworks.com Fri Jun 8 10:37:28 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 12:37:28 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <200706081459.l58Ex5rA019991@qbang.org> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> Message-ID: <466985C8.8000505@gatworks.com> Ken Gentle wrote: > Perhaps it is a bit late to jump in on this one, but here goes anyway. Common in, the waters fine. > > If the solutions all seem to "break" the contract with > "java.io.outputstream", then, as noted, that may not be the > appropriate contract. > How would the contract be broken? The machinery underneath is handling the contract. From j.kenneth.gentle at acm.org Fri Jun 8 10:48:01 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Fri, 08 Jun 2007 12:48:01 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466985C8.8000505@gatworks.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> Message-ID: <200706081648.l58Gm7YA022904@qbang.org> At 12:37 2007-06-08, you wrote: >Ken Gentle wrote: > > > > If the solutions all seem to "break" the contract with > > "java.io.outputstream", then, as noted, that may not be the > > appropriate contract. > > >How would the contract be broken? The machinery underneath is handling >the contract. It seems that a lot of the discussion has been about not only the timeout and being able to adjust it in the "machinery layer", but also about knowing in the Java layer, in the event of a timeout or exception, how many characters have been written to the device. An OutputStream won't ever do this with out an extension and including a return value "breaks" the contract, right? So, go with a Java IO api that *does* return the number of bytes written, out of the NIO package. I know it doesn't allow for a strict implementation of the JavaCOMM API - however, using NIO classes in place of the IO classes isn't that big a break and would allow those applications that need such information a way to get it. Maybe I'm misunderstanding the problem... Ken From netbeans at gatworks.com Fri Jun 8 11:24:14 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 13:24:14 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <200706081648.l58Gm7YA022904@qbang.org> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> Message-ID: <466990BE.7040100@gatworks.com> Ken Gentle wrote: An > OutputStream won't ever do this with out an extension and including a > return value "breaks" the contract, right? > i was not thinking of change the API to OutputSream. Are there specs for how output stream should work internally? for instance: String data = "Hello this is a line of data"; Outputstream.write( data.getbytes() ); ParallelPort.suspend(); int free = ParallelPort.getoutputbufferfree(); There is a symbiotic relationship between outputstream and the functionality of ParallelPort. From Steffen.DETTMER at ingenico.com Fri Jun 8 11:15:39 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 19:15:39 +0200 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <200706081459.l58Ex5rA019991@qbang.org> References: <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> Message-ID: <20070608171539.GK21069@elberon.bln.de.ingenico.com> * Ken Gentle wrote on Fri, Jun 08, 2007 at 10:58 -0400: > If the solutions all seem to "break" the contract with > "java.io.outputstream", then, as noted, that may not be the > appropriate contract. > > At the risk of being heretical, JDK1.4 introduced the "nio" package > to address some of the compatibility issues with C apis mentioned in > previous posts. The interface > "java.nio.channels.WriteableByteChannel" defines the following single method: > > int write(ByteBuffer source); > > int, strangely enough, is the actual number of bytes written. Yes, AFAIK one of the motivations for the NIO interface was, that the JDK-1.3 APIs (InputStream, e.g.) were not powerfull enough, especially for multi-connection-TCP servers or so. I don't know much about it but I've heard of a project where NIO usage was removed because of stability issues in multi-threaded environments and performance limitations under some circumstances. IIRC the "nio.ByteBuffer" is something very special (namely something you cannot implement in Java, it is "magic" or part of the language itself). Not sure if this is such a great idea (but for performance in the end sometimes heavy prices must be paid) :) > So, if RXTX as written, against the JavaCOMM api and OutputStream, > doesn't do what we want, how about writing a different set of > bindings using the java.nio classes and as much of the underlying > native code as possible. Yes, this would be an idea: use a full-featured interface on JNI, and, if wanted, deliver some wrappers converting this to a less-featured Java-compliant interface. However, powerful things as e.g. "select" are difficult to "emulate" if you are e.g. on some (older?) windows. But if you expose the full-featured APIs, you need to emulate them full-featured, theoretically. In the end it depends what you do on the serial line. If you just want to talk to a modem, then you may not need precise timeouts. But if you need to implement complexer protocols which define response times and timeouts, you may quickly get into difficulties. For instance, AFAIK, rxtx 1.7.2 (?) for windows is very messy with timeouts (there is a maximum, higher values are truncated; resolution is 100ms only; the function may take up to twice the timeout because internally it may be called twice). Probably for most people this is OK, but probably not for all. But having precise timeouts should be OK for all :-) Well, in the end it is nice to wish but somewhat hard to implement (many platforms, connections, USB, BlueTooth, whatever). oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Steffen.DETTMER at ingenico.com Fri Jun 8 11:04:22 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 19:04:22 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <46696DFC.7000801@gatworks.com> References: <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <46696DFC.7000801@gatworks.com> Message-ID: <20070608170422.GJ21069@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 10:55 -0400: > > BTW, if e.g. BSD socket API is known, why not simply copy it > > (until something better is invented :)) instead of fiddling > > around with JDK APIs? > > But we were talking about the Parallel Port, and the > transmission of data over the commapi/parallel-port schema. > There isn't much in bi-directional software communication. Its > a simple write one byte at a time interface. First, there are things like PLIP (http://en.wikipedia.org/wiki/Plip) - well, probably not widely used, sure ;) Second, I think if there is a good simple API known to support all that (with known "best practices") or so and there is no forcing need to invent a new one, why not simply using it? > I'm not looking to change the comm-api. I'm just looking to > alter the interaction between the Native ParallelPort > functions, and the java ParallelPort functions that call them. Ahh, yes. I think this is what I tried to ask. Having an usable JNI interface and on top (in pure java) some wrapper to InputStream or whatever could be done (e.g. by ignoring the return value of write or throwing if != length). Developers could then use the full-featured (non-JAVA-standard) API or select among various wrappers (as InputStream). > This might be more readily doable than to get a committee to > re-specify java-API specs. Yes, of course. I'm afraid that the Java APIs change regularily, but still yet with limited success it seems, so maybe they get it in one of the next iterations; who knows, maybe Java-9 has a BSD-like socket API :) SCNR. > BTW: Whats is off-topic? ( help: not looking for def of > off-topic ) I think I started some "re-specify java-API specs" which was OT probably. oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From lists at iDIAcomputing.com Fri Jun 8 18:48:54 2007 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Fri, 08 Jun 2007 20:48:54 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46684B62.7080802@gmail.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> Message-ID: <4669F8F6.3040101@iDIAcomputing.com> Vicne wrote: > Sorry to step in without a specific solution to your problem, but I > wanted to share my feeling regarding this proposal. AFAIK, it's > generally considered bad practice to pop-up a prompt from a library. ... > > My advice would be to think again and find another solution. Ideas are : > - make the number of retries a parameter so that you can tune it to what > you think is reasonable > - throw a more specific exception when the number of retries has been > reached, so that a specific prompt can be shown at a higher level You could also allow the client code to register a callback class which returns a boolean indicating whether to retry or cancel. This callback class could pop up a dialog, if appropriate, or follow some preset policy, or.... - George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From joachim at buechse.ch Sat Jun 9 09:43:16 2007 From: joachim at buechse.ch (Joachim Buechse) Date: Sat, 9 Jun 2007 17:43:16 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46694F9D.5080501@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: You should not forget, that in the case of an exception it may not even be known what happened to the data. You have a kernel buffer, outgoing chip buffer, incoming chip buffer, etc. So of course, it would be nice to know up to which point data was correctly processed, but this feedback does not exist on the hardware or protocol level and hence can in general not be magicly created on the software level... Regards, Joachim On 08.06.2007, at 14:46, Uncle George wrote: > It seems that with outputstream.write(b[]), you become terribly > uncoordinated as soon as an exception is thrown. Docs do not say what > happens to the data. > > Yet from a practicable point of view, one would like to know if the > write was accepted in-full, or rejected before any writes. There > are no > in betweens, as partial writes are not reportable. > > So for an outputstream.write(), in order for it to return, the full > write request has to be taken, and stored in an internal output > buffer. > If there is no room, the write() is suspended, till there is room. Or > throw's an IOException( "no room in buffer") ; As the select() loop > for > write reports buffer room avail, then more of the internal buffer is > sent to the printer. > > > > yves pielusenet wrote: >> So maybe a better way should be to create a new Exception class which >> has a method "int getWrittenByte()". So the Exception should be >> use to >> send again bytes which are not printed yet. >> >> yves >> >> Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : >>> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: >>>> It is not possible that the rxtx java method write(byte[], int >>>> offset, >>>> int length) return anint which contains the number of byte >>>> really send >>>> to the printer instead of an exception ? >>>> So this is the programm which will see if all bytes have been >>>> sent. If >>>> not it can retry to send the unsended bytes. >>> I think write() is void because in Java people love to do this >>> since OutputStream :-) Of course on such interfaces you cannot >>> implement something nice. If you would have a int write, you >>> would not implement the interface and no applications expecting >>> this interface would link/work/compile. >>> >>> oki, >>> >>> Steffen >>> >>> P.S.: (OT) >>> If you propose not to implement the Java interfaces (especially >>> not on JNI level), maybe optionally offering a wrapper that >>> removes e.g. the write return value and so on to downgrade the >>> powerful classic old POSIX read/write style to the modern limited >>> Java style, then I agree :-) Same for read. Instead of things >>> like "int avialable()" it is more powerful to have an approach as >>> select(2) offers (to guarante the caller that read/write will not >>> block [nothing else make sense anyway IMHO] but may read/write >>> less bytes then requested). The caller gets full control and the >>> higher level protocols can care about timeouts, invoking read in >>> some loops and/or implement retransmission. On top of such an >>> implementation, where everything is controlled, defined, >>> guaranteed and reliable, someone could use an InputStream or >>> OutputStream style interface. Or even better: don't use them at >>> all :) just BTW :-) >>> St. >>> >>> About Ingenico Throughout the world businesses rely on Ingenico >>> for secure and expedient electronic transaction acceptance. >>> Ingenico products leverage proven technology, established >>> standards and unparalleled ergonomics to provide optimal >>> reliability, versatility and usability. This comprehensive range >>> of products is complemented by a global array of services and >>> partnerships, enabling businesses in a number of vertical sectors >>> to accept transactions anywhere their business takes them. >>> 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. >>> >>> About Ingenico Throughout the world businesses rely on Ingenico >>> for secure and expedient electronic transaction acceptance. >>> Ingenico products leverage proven technology, established >>> standards and unparalleled ergonomics to provide optimal >>> reliability, versatility and usability. This comprehensive range >>> of products is complemented by a global array of services and >>> partnerships, enabling businesses in a number of vertical sectors >>> to accept transactions anywhere their business takes them. >>> 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. >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx 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 yvespielusenet at free.fr Mon Jun 11 03:15:12 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Mon, 11 Jun 2007 11:15:12 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: <1181553312.8335.14.camel@localhost.localdomain> So can someone tell a solution for my problem :( Must I say to the user to not put the printer off-line ? I can't since he has to do some pauses, verify print, paper conditioning etc... How do other people ? Before I use the parport librarry to read port status : http://www.geocities.com/Juanga69/parport/ (which doesn't work on windows XP) And I send data into the file LPT1 I use to have no problem when printer was disabled. thanks -- yves piel Le samedi 09 juin 2007 ? 17:43 +0200, Joachim Buechse a ?crit : > You should not forget, that in the case of an exception it may not > even be known what happened to the data. > > You have a kernel buffer, outgoing chip buffer, incoming chip buffer, > etc. So of course, it would be nice to know up to which point data > was correctly processed, but this feedback does not exist on the > hardware or protocol level and hence can in general not be magicly > created on the software level... > > Regards, > Joachim > > On 08.06.2007, at 14:46, Uncle George wrote: > > > It seems that with outputstream.write(b[]), you become terribly > > uncoordinated as soon as an exception is thrown. Docs do not say what > > happens to the data. > > > > Yet from a practicable point of view, one would like to know if the > > write was accepted in-full, or rejected before any writes. There > > are no > > in betweens, as partial writes are not reportable. > > > > So for an outputstream.write(), in order for it to return, the full > > write request has to be taken, and stored in an internal output > > buffer. > > If there is no room, the write() is suspended, till there is room. Or > > throw's an IOException( "no room in buffer") ; As the select() loop > > for > > write reports buffer room avail, then more of the internal buffer is > > sent to the printer. > > > > > > > > yves pielusenet wrote: > >> So maybe a better way should be to create a new Exception class which > >> has a method "int getWrittenByte()". So the Exception should be > >> use to > >> send again bytes which are not printed yet. > >> > >> yves > >> > >> Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : > >>> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > >>>> It is not possible that the rxtx java method write(byte[], int > >>>> offset, > >>>> int length) return anint which contains the number of byte > >>>> really send > >>>> to the printer instead of an exception ? > >>>> So this is the programm which will see if all bytes have been > >>>> sent. If > >>>> not it can retry to send the unsended bytes. > >>> I think write() is void because in Java people love to do this > >>> since OutputStream :-) Of course on such interfaces you cannot > >>> implement something nice. If you would have a int write, you > >>> would not implement the interface and no applications expecting > >>> this interface would link/work/compile. > >>> > >>> oki, > >>> > >>> Steffen > >>> > >>> P.S.: (OT) > >>> If you propose not to implement the Java interfaces (especially > >>> not on JNI level), maybe optionally offering a wrapper that > >>> removes e.g. the write return value and so on to downgrade the > >>> powerful classic old POSIX read/write style to the modern limited > >>> Java style, then I agree :-) Same for read. Instead of things > >>> like "int avialable()" it is more powerful to have an approach as > >>> select(2) offers (to guarante the caller that read/write will not > >>> block [nothing else make sense anyway IMHO] but may read/write > >>> less bytes then requested). The caller gets full control and the > >>> higher level protocols can care about timeouts, invoking read in > >>> some loops and/or implement retransmission. On top of such an > >>> implementation, where everything is controlled, defined, > >>> guaranteed and reliable, someone could use an InputStream or > >>> OutputStream style interface. Or even better: don't use them at > >>> all :) just BTW :-) > >>> St. > >>> > >>> About Ingenico Throughout the world businesses rely on Ingenico > >>> for secure and expedient electronic transaction acceptance. > >>> Ingenico products leverage proven technology, established > >>> standards and unparalleled ergonomics to provide optimal > >>> reliability, versatility and usability. This comprehensive range > >>> of products is complemented by a global array of services and > >>> partnerships, enabling businesses in a number of vertical sectors > >>> to accept transactions anywhere their business takes them. > >>> 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. > >>> > >>> About Ingenico Throughout the world businesses rely on Ingenico > >>> for secure and expedient electronic transaction acceptance. > >>> Ingenico products leverage proven technology, established > >>> standards and unparalleled ergonomics to provide optimal > >>> reliability, versatility and usability. This comprehensive range > >>> of products is complemented by a global array of services and > >>> partnerships, enabling businesses in a number of vertical sectors > >>> to accept transactions anywhere their business takes them. > >>> 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. > >>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx 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 > From Steffen.DETTMER at ingenico.com Mon Jun 11 03:56:18 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 11:56:18 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466990BE.7040100@gatworks.com> References: <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> Message-ID: <20070611095618.GA10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 13:24 -0400: > i was not thinking of change the API to OutputSream. Then I think either someone uses OutputStream (and has no reliable information about incomplete writes) or someone uses somethink else. > Are there specs for how output stream should work internally? > > for instance: > String data = "Hello this is a line of data"; > Outputstream.write( data.getbytes() ); > ParallelPort.suspend(); > int free = ParallelPort.getoutputbufferfree(); > > There is a symbiotic relationship between outputstream and the > functionality of ParallelPort. If you need OutputStream "plus something else", in short you're needing "something else". Personally I dislike the code above a lot. The stream "looks" like if it would be an OutputStream, but in fact it isn't. You need to call getoutputbufferfree later to check if write succeeded (but OutputStream promises that write succeedes synchronous, blocking, or throws an exception). So it is not an OutputStream. No application written for OutputStreams would work without change (because it won't know getoutputbufferfree at all). It is not abstracted from ParallelPort. I think this would be wrong. Then I think an alternative interface instead is better. Let's assume we had some "connection" (to distinguish between OutputStreams and Channels). Then why not working as on a file handle in POSIX: do { // ... select maybe using timer ... readyForWrite = ... if (readyForWrite) { int writtenBytes = connection.write(toWrite); toWrite.remove(0, writtenBytes); } while(readyForWrite && toWrite.length > 0); I think, having such a write isn't the big problem. I think, the difficult thing is around "select" - however this would look like. It should be OO, typesafe, performant, supporting multiple connections/channels/streams in various modes and should be orthogonal to other functionalities. Of course, this heavily depends on what the application is doing; for a simple situation (like reading a small, mandatory file from a local disk) this would be to uncomfortable (and offering unneeded features only). just BTW :) oki, Steffen -- // Modeline for VIM. Please don't remove. // (Help: autoindent, expandtab, shiftwidth=4, tabstop=4, textwidth=75) // vi: set ai et sw=4 ts=4 tw=75 ft=java: About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Mon Jun 11 05:38:33 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 07:38:33 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611095618.GA10821@elberon.bln.de.ingenico.com> References: <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> Message-ID: <466D3439.4020805@gatworks.com> Steffen DETTMER wrote: > (but OutputStream promises that write > succeedes synchronous, blocking, or throws an exception). Where is it so written? From Steffen.DETTMER at ingenico.com Mon Jun 11 06:36:50 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 14:36:50 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466D3439.4020805@gatworks.com> References: <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> <466D3439.4020805@gatworks.com> Message-ID: <20070611123650.GI10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Mon, Jun 11, 2007 at 07:38 -0400: > Steffen DETTMER wrote: > > > (but OutputStream promises that write > > succeedes synchronous, blocking, or throws an exception). > > Where is it so written? Now, as you ask, I think it is not written that clearly but follows from specification. mmm... Am I wrong? I understand the API doc in this way: * http://java.sun.com/j2se/1.4.2/docs/api/java/io/OutputStream.html#write(byte[]) > public void write(byte[] b) > throws IOException > > Writes b.length bytes from the specified byte array to this > output stream. The general contract for write(b) is that > it should have exactly the same effect as the call write(b, > 0, b.length). > > Parameters: > b - the data. > Throws: > IOException - if an I/O error occurs. > See Also: > write(byte[], int, int) and there is: > public void write(byte[] b, > int off, > int len) > throws IOException > > Writes len bytes from the specified byte array starting at > offset off to this output stream. The general contract for > write(b, off, len) is that some of the bytes in the array b > are written to the output stream in order; element b[off] > is the first byte written and b[off+len-1] is the last byte > written by this operation. > > The write method of OutputStream calls the write method of > one argument on each of the bytes to be written out. > Subclasses are encouraged to override this method and > provide a more efficient implementation. > > If b is null, a NullPointerException is thrown. > > If off is negative, or len is negative, or off+len is > greater than the length of the array b, then an > IndexOutOfBoundsException is thrown. > > Parameters: > b - the data. > off - the start offset in the data. > len - the number of bytes to write. > Throws: > IOException - if an I/O error occurs. In particular, an > IOException is thrown if the output stream is closed. In general, any specialisation (derived child class) must comform to this. So write in the end is specified (!) as "The write method ... calls the write method ... on each of the bytes to be written out". This is what must be implemented by ANY OutputStream. Of course, there is: "Subclasses are encouraged to override this method and provide a more efficient implementation." which IMHO does not contradict - the more efficient must behave in exactly the same way of course (just wasting less resources than a simple byte-by-byte write). So it does not matter here I think. The write that finally defines the behavior tells basically: > "Writes the specified byte to this output stream. The general > contract for write is that one byte is written to the output > stream. " > > Throws: > IOException - if an I/O error occurs. which IMHO is another way of saying "write writes the byte immediately and returns on success (only), otherwise an exception is thrown". Especially it cannot happen that zero bytes are written (i.e. the specified byte is NOT written) without an exception. So by this write must be synchronous and blocking, because otherwise it could not reliably know if an asynchronous operation will succeede or not (some getAsyncResult or so would be needed). Since write(byte[]) does this for each byte (or with a behavior beeing exactly the same as if it would do), I think this means that the write(byte[]) succeedes synchronous/blocking or throws an exception. Did I an error in reasoning or confused something or so? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From j.kenneth.gentle at acm.org Mon Jun 11 06:51:25 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 11 Jun 2007 08:51:25 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611123650.GI10821@elberon.bln.de.ingenico.com> References: <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> <466D3439.4020805@gatworks.com> <20070611123650.GI10821@elberon.bln.de.ingenico.com> Message-ID: <200706111251.l5BCpS9T017831@qbang.org> It is as Steffen describes. "InputStream" and "OutputStream" are inherently synchronous (which is why so many java programs resort to threads to use them). Anything outside of this "contract" is *not* an InputStream or OutputStream. That is why there is a new package for things that don't behave like the old *Stream classes - the NIO package. If you look carefully at the IO package, you'll note that almost all the classes are _Decorator_ pattern implementations of the *Stream classes - and the interface presents the _same_ behavior to the calling code in all cases - a synchronous operation that completes successfully or throws an exception (with the one exception of "read" that returns a "-1" on end-of-stream. I know I've read this numerous times - I'd suggest checking the Language Spec or one of the books by Bloch or Gosling. Ken At 08:36 2007-06-11, you wrote: >* Uncle George wrote on Mon, Jun 11, 2007 at 07:38 -0400: > > Steffen DETTMER wrote: > > > > > (but OutputStream promises that write > > > succeedes synchronous, blocking, or throws an exception). > > > > Where is it so written? > >Now, as you ask, I think it is not written that clearly but >follows from specification. mmm... > >Am I wrong? > >I understand the API doc in this way: > >* >http://java.sun.com/j2se/1.4.2/docs/api/java/io/OutputStream.html#write(byte[]) > > public void write(byte[] b) > > throws IOException > > > > Writes b.length bytes from the specified byte array to this > > output stream. The general contract for write(b) is that > > it should have exactly the same effect as the call write(b, > > 0, b.length). > > > > Parameters: > > b - the data. > > Throws: > > IOException - if an I/O error occurs. > > See Also: > > write(byte[], int, int) > > >and there is: > > > > public void write(byte[] b, > > int off, > > int len) > > throws IOException > > > > Writes len bytes from the specified byte array starting at > > offset off to this output stream. The general contract for > > write(b, off, len) is that some of the bytes in the array b > > are written to the output stream in order; element b[off] > > is the first byte written and b[off+len-1] is the last byte > > written by this operation. > > > > The write method of OutputStream calls the write method of > > one argument on each of the bytes to be written out. > > Subclasses are encouraged to override this method and > > provide a more efficient implementation. > > > > If b is null, a NullPointerException is thrown. > > > > If off is negative, or len is negative, or off+len is > > greater than the length of the array b, then an > > IndexOutOfBoundsException is thrown. > > > > Parameters: > > b - the data. > > off - the start offset in the data. > > len - the number of bytes to write. > > Throws: > > IOException - if an I/O error occurs. In particular, an > > IOException is thrown if the output stream is closed. > > >In general, any specialisation (derived child class) must comform >to this. So write in the end is specified (!) as "The write >method ... calls the write method ... on each of the bytes to be >written out". This is what must be implemented by ANY >OutputStream. > >Of course, there is: "Subclasses are encouraged to override this >method and provide a more efficient implementation." which IMHO >does not contradict - the more efficient must behave in exactly >the same way of course (just wasting less resources than a simple >byte-by-byte write). So it does not matter here I think. > > > >The write that finally defines the behavior tells basically: > > > "Writes the specified byte to this output stream. The general > > contract for write is that one byte is written to the output > > stream. " > > > > Throws: > > IOException - if an I/O error occurs. > > >which IMHO is another way of saying "write writes the byte >immediately and returns on success (only), otherwise an exception >is thrown". Especially it cannot happen that zero bytes are >written (i.e. the specified byte is NOT written) without an >exception. So by this write must be synchronous and blocking, >because otherwise it could not reliably know if an asynchronous >operation will succeede or not (some getAsyncResult or so would >be needed). > >Since write(byte[]) does this for each byte (or with a behavior >beeing exactly the same as if it would do), I think this means >that the write(byte[]) succeedes synchronous/blocking or throws >an exception. > >Did I an error in reasoning or confused something or so? > >oki, > >Steffen > >About Ingenico Throughout the world businesses rely on Ingenico for >secure and expedient electronic transaction acceptance. Ingenico >products leverage proven technology, established standards and >unparalleled ergonomics to provide optimal reliability, versatility >and usability. This comprehensive range of products is complemented >by a global array of services and partnerships, enabling businesses >in a number of vertical sectors to accept transactions anywhere >their business takes them. >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. > >About Ingenico Throughout the world businesses rely on Ingenico for >secure and expedient electronic transaction acceptance. Ingenico >products leverage proven technology, established standards and >unparalleled ergonomics to provide optimal reliability, versatility >and usability. This comprehensive range of products is complemented >by a global array of services and partnerships, enabling businesses >in a number of vertical sectors to accept transactions anywhere >their business takes them. >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. > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From alesinskyy at googlemail.com Mon Jun 11 07:25:33 2007 From: alesinskyy at googlemail.com (Oleksandr Alesinskyy) Date: Mon, 11 Jun 2007 15:25:33 +0200 Subject: [Rxtx] [OT] select :-) Message-ID: Sorry, but I have to disagree with following statement: "So write in the end is specified (!) as "The write method ... calls the write method ... on each of the bytes to be written out". This is what must be implemented by ANY OutputStream.". This is not part of the specification or contract, it is just revealed implementation detail of the OutputStream. It is not stated anywhere that behavoiur of derived classes shall conform with this one. Statement concerning "synchronous" nature of the output stream is invalid as well. Really synchronous stream does not require flush() but OutputStream has it. From Steffen.DETTMER at ingenico.com Mon Jun 11 08:21:16 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 16:21:16 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: Message-ID: <20070611142116.GN10821@elberon.bln.de.ingenico.com> * Oleksandr Alesinskyy wrote on Mon, Jun 11, 2007 at 15:25 +0200: > Sorry, but I have to disagree with following statement: > "So write in the end is specified (!) as "The write > method ... calls the write method ... on each of the bytes to be > written out". This is what must be implemented by ANY > OutputStream.". > > This is not part of the specification or contract, it is just > revealed implementation detail of the OutputStream. It is not > stated anywhere that behavoiur of derived classes shall conform > with this one. (I didn't meant that the implementation must really write byte by byte, but that it must "look as if it would do" - because all implementations of OutputStream must "look" in the same way [which is another way of saying "do abstract" I think]) I think the API doc is not "revealing implementation details" but it is the *specification* of that interface and derivations must (should) conform to this specification. Isn't this the idea of interfaces? A function that expects an OutputStream should work on ANY OutputStream, shouldn't it? just kidding: I mean, what would be the point in implementing a checksum function as OutputStream.write which throws its result as IOException? Or which requires to call close() as very first operation to tell that the application is about to transmit confidential data? :-) > Statement concerning "synchronous" nature of the output stream > is invalid as well. Really synchronous stream does not require > flush() but OutputStream has it. ahh, interesting point! I think this is another bug in the API. flush() is wrong. Because write specifies "The general contract for write is that one byte is written to the output stream." but not "a byte may be written or buffered". Actually, an application would need to call flush() after each write (or bunch of write calls) to ensure that write really did something otherwise I think. I didn't found in the spec of OutputStream that it would be required to call flush(). This should mean that calling flush is not required which in turn leads to the conclusion that write must be synchrous (private threads are forbidden because not specified :)) which in turn leads to the conclusion that flush() is not needed at all... I mean, what if someone would only store in write and do the "real write" in flush() and never else? An application could write in one stream and read on another one (e.g. in bidirectional communication) and would never get anything back, because nothing was actually written because no flush was called? Then someone could even think that on error in some write the data could remain buffered AND throw an exception, retrying to send the data in the next write. Ohh, and if there would be some message number inside, and underlaying write (e.g. a protocol offering InputStream/OutputStream) would check this and throw "DuplicatedMessageNumber" the stream would only throw it again and again beeing unusable... In short: I have no clue how someone could be able to implement an asynchrounos write (which is realiable and correct) without beeing specific to anything which is not specified by OutputStream. Well, I think in the end OutputStream was not intended for such communication or protocol implementations - but to read a local disk file or so. In case of I/O errors usually you can abort your application and change the hard disk :-) oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Bob_Jacobsen at lbl.gov Mon Jun 11 09:32:23 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Mon, 11 Jun 2007 08:32:23 -0700 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611142116.GN10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> Message-ID: At 4:21 PM +0200 6/11/07, Steffen DETTMER wrote: > > Statement concerning "synchronous" nature of the output stream >> is invalid as well. Really synchronous stream does not require >> flush() but OutputStream has it. > >ahh, interesting point! > >I think this is another bug in the API. flush() is wrong. Because >write specifies "The general contract for write is that one byte >is written to the output stream." but not "a byte may be written >or buffered". > >Actually, an application would need to call flush() after each >write (or bunch of write calls) to ensure that write really did >something otherwise I think. OutputStreams don't _have_ to be synchronous or asynchronous, but the OutputStream API was be arranged so that subclasses _can_ be synchronous or asynchronous. Such generality is the hardest part of getting an API right. Hence, if at some point a program using an OutputStream wants to be sure that the data has been pushed all the way out, flush() is available. For some subclasses, e.g. the buffered ones, this has important behavior. Others write the data from each call, and flush() doesn't do anything. You _can_ omit it in programs that are known to use this second type, but there's no requirement that you do so; the interface is general in that way. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From Steffen.DETTMER at ingenico.com Mon Jun 11 12:32:39 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 20:32:39 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> Message-ID: <20070611183239.GT10821@elberon.bln.de.ingenico.com> * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: > >Actually, an application would need to call flush() after each > >write (or bunch of write calls) to ensure that write really did > >something otherwise I think. > OutputStreams don't _have_ to be synchronous or asynchronous, > but the OutputStream API was be arranged so that subclasses > _can_ be synchronous or asynchronous. Ahh, oki. Thanks for the clarificaion. So in short, flush() MUST be called on OutputStream, this is just not documented correctly or so clearly (right?). So the overall usage semantics would be: 1. call write (multiple times if desired) 2. call flush only if both succeeded, write was successful. If flush fails it remains unknown if a part of the data was written and/or will be repeated. So the spec (API doc) is wrong. Correct would be to tell that write behaves as told as long as it is followed by a call to flush, otherwise data may or may not get lost (depending wheter close() is called and calls flush(), which seems not to be guaranteed/required). BTW, I think it is a little bit... erm... interesting to find the specification (java API doc reference) wrong, having a need to conclude it from the presence of some methods with "it would make no sense if they behave exactly as specified, so specification must be wrong (incomplete)". > Such generality is the hardest part of getting an API right. Yes, seems to be proven ;) > Hence, if at some point a program using an OutputStream wants > to be sure that the data has been pushed all the way out, > flush() is available. For some subclasses, e.g. the buffered > ones, this has important behavior. Others write the data from > each call, and flush() doesn't do anything. > You _can_ omit it in programs that are known to use this second > type, but there's no requirement that you do so; the interface > is general in that way. I think, it still it must be called always, otherwise the application could break if passing a different runtime type as OutputStream. I think, if the application/method needs a special "type of OutputStream" then the parameter type must be a subclass but not OutputStream, maybe a PrintStream or so - otherwise the compiler could not detect this error (passing wrong type). Is this correct? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Bob_Jacobsen at lbl.gov Mon Jun 11 13:00:52 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Mon, 11 Jun 2007 12:00:52 -0700 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611183239.GT10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> Message-ID: At 8:32 PM +0200 6/11/07, Steffen DETTMER wrote: >So the spec (API doc) is wrong. Correct would be to tell that >write behaves as told as long as it is followed by a call to >flush, otherwise data may or may not get lost (depending wheter >close() is called and calls flush(), which seems not to be >guaranteed/required). I'm not entirely sure that the spec is wrong, but reasonable people can differ on this. In the 1.5 JavaDocs, all that the docs say for the write methods is that they write to the _output_ _stream_; there is no guarantee of anything beyond that. Only the flush method has any guarantee about the data, which is >Flushes this output stream and forces any buffered output bytes to >be written out. The general contract of flush is that calling it is >an indication that, if any bytes previously written have been >buffered by the implementation of the output stream, such bytes >should immediately be written to their intended destination. People commonly use various OutputStreams without using flush(), and it often works, but it's a bad practice and will eventually bite them. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From netbeans at gatworks.com Mon Jun 11 13:31:57 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 15:31:57 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611183239.GT10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> Message-ID: <466DA32D.1010602@gatworks.com> Steffen DETTMER wrote: > * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: >>> Actually, an application would need to call flush() after each >>> write (or bunch of write calls) to ensure that write really did >>> something otherwise I think. > >> OutputStreams don't _have_ to be synchronous or asynchronous, >> but the OutputStream API was be arranged so that subclasses >> _can_ be synchronous or asynchronous. > > Ahh, oki. Thanks for the clarificaion. > > So in short, flush() MUST be called on OutputStream, this is just > not documented correctly or so clearly (right?). No. Flush can be called to force all current data in java buffer's to be written to the kernel - NOW. A flush() can also *imply* that, besides writing out the buffer's that java employs, may also imply/ask the kernel to write all data thusfar written to the kernel, to be physically placed on the destination device - NOW. For some OS's there is no need to do a kernel flush(), as the I/O is synchronized already. Since this is java, you never know what OS your on. From tjarvi at qbang.org Mon Jun 11 19:28:27 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Jun 2007 19:28:27 -0600 (MDT) Subject: [Rxtx] [OT] select :-) In-Reply-To: <466DA32D.1010602@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: On Mon, 11 Jun 2007, Uncle George wrote: > Steffen DETTMER wrote: >> * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: >>>> Actually, an application would need to call flush() after each >>>> write (or bunch of write calls) to ensure that write really did >>>> something otherwise I think. >> >>> OutputStreams don't _have_ to be synchronous or asynchronous, >>> but the OutputStream API was be arranged so that subclasses >>> _can_ be synchronous or asynchronous. >> >> Ahh, oki. Thanks for the clarificaion. >> >> So in short, flush() MUST be called on OutputStream, this is just >> not documented correctly or so clearly (right?). > No. > Flush can be called to force all current data in java buffer's to be > written to the kernel - NOW. > > A flush() can also *imply* that, besides writing out the buffer's that > java employs, may also imply/ask the kernel to write all data thusfar > written to the kernel, to be physically placed on the destination device > - NOW. > For some OS's there is no need to do a kernel flush(), as the I/O is > synchronized already. Since this is java, you never know what OS your on. To add to the confusion, flush on the C side throws away data. drain makes sure it is written. Looking at the ParallelImp.c we can probably do better. /* we set a timeout because all calls are sequentiell (also with asynchron) this means that the default timeout of unlimited blocks all calls (also close and status request) if the device is down */ GetCommTimeouts( (HANDLE)fd, &timeouts ); timeouts.WriteTotalTimeoutMultiplier = 0; timeouts.WriteTotalTimeoutConstant = 2000; /* 2000 is the min value for the default Windows NT and Windows 2000 driver */ SetCommTimeouts( (HANDLE)fd, &timeouts ); while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } errorCount = 0; bytes += countWritten; count -= countWritten; } LPRPort has some timeout code that appears to be doing nothing but flipping bits back and forth right now. The commapi rxtx follows allows for timeout control from javax.comm.CommPort. The above is a solution that worked in one specific use case. With timeouts in place, the original 'old printer going offline' problem could be solved. That printer code isn't written in stone. In fact it was ajusted from being able to print 'asdf' to a daisy wheel printer to working for one person. BTW, I've finished teaching after hours tonight and will be moving forward with a new rxtx release in my free time. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Jun 11 21:28:04 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 23:28:04 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: <466E12C4.1010305@gatworks.com> > Looking at the ParallelImp.c we can probably do better. > The problem stemmed from the possibility that the writev routine could have written some of the buffer, in chunks, printer pauses, refuses any more chunks, and a timeout occurs. Do you or do you not cause an exception to be thrown? Is there a way to set timeout for a ParallelPort data output stream? I cant find it. From tjarvi at qbang.org Mon Jun 11 22:17:23 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Jun 2007 22:17:23 -0600 (MDT) Subject: [Rxtx] [OT] select :-) In-Reply-To: <466E12C4.1010305@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> <466E12C4.1010305@gatworks.com> Message-ID: On Mon, 11 Jun 2007, Uncle George wrote: >> Looking at the ParallelImp.c we can probably do better. >> > The problem stemmed from the possibility that the writev routine could > have written some of the buffer, in chunks, printer pauses, refuses any > more chunks, and a timeout occurs. Do you or do you not cause an > exception to be thrown? > > Is there a way to set timeout for a ParallelPort data output stream? I > cant find it. hmm I looked again after you asked. The timeouts are only controllable on the receive side. This comes from CommPort; the parent. So what we are talking about is some bytes in memory that rxtx has and is supposed to write. A buffer perhaps? The approach with rxtx in the past has been to ignore output buffer sizes. The assumption is that the library does not know how to best handle buffers. There are buffered output streams that can do buffering on top of rxtx for instance. There is also a question regarding what was actually ment when the API was put together. My suspicion is that it was put together while looking at one OS API and was never ment to be anything more than a hook into that API. The comments are fairly telling combined with reading the w32 API. So looking at the problem again.. The current timeout behavior appears fairly arbitrary. Presumably this is to prevent a program from hanging instead of using a helper thread to write - heavy handed for new programmers. Even so, I don't think the write should timeout at all if it is not configurable. >From the API perspective, "What Timeout?" -- Trent Jarvi tjarvi at qbang.org From Steffen.DETTMER at ingenico.com Tue Jun 12 02:14:48 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 12 Jun 2007 10:14:48 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466DA32D.1010602@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: <20070612081447.GU10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Mon, Jun 11, 2007 at 15:31 -0400: > Steffen DETTMER wrote: > > Ahh, oki. Thanks for the clarificaion. > > > > So in short, flush() MUST be called on OutputStream, this is just > > not documented correctly or so clearly (right?). > No. hum (though now I got it, but...). > Flush can be called to force all current data in java buffer's to be > written to the kernel - NOW. > > A flush() can also *imply* that, besides writing out the > buffer's that java employs, may also imply/ask the kernel to > write all data thusfar written to the kernel, to be physically > placed on the destination device - NOW. > > For some OS's there is no need to do a kernel flush(), as the I/O is > synchronized already. Since this is java, you never know what OS your on. (well, but if you're going to kernel level, even flush cannot guarantee that data will "be physically placed". Maybe you're flushing to a file via NFS (and the client "thinks" that it was written, but maybe it was just buffered by the NFS server) or so... but of course such exceptions of the rules are constructable always.) Well, you tell that depending on the OS it can be that flush is needed or it can be that flush is not needed (beacuse the I/O is synchronized already), right? Also, applications should work on any OS, which includes the OSes that do need flush. Since the application cannot know whether flush is needed or not because it doesn't know what the OS is doing, it has to call flush, hasn't it? I mean, if it would not call flush then it would not work on such OSes (except the written data would not be needed at all, but in this would be an artificial example :)). Since applications are supposed to work this would be wrong, wouldn't it? So would it be correct to say: "Applications, that should work under all OSes (including the OSes where the I/O is not synchronised already), have to call flush on OutputStream to ensure the data is transfered to the kernel." or is this wrong? If so, then I'm afraid I missed the point again :( oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Tue Jun 12 04:46:52 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 12 Jun 2007 06:46:52 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070612081447.GU10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> <20070612081447.GU10821@elberon.bln.de.ingenico.com> Message-ID: <466E799C.7060700@gatworks.com> S > (well, but if you're going to kernel level, even flush cannot > guarantee that data will "be physically placed". Thats true now-a-days because ( from "man 2 sync" ) : > According to the standard specification (e.g., SVID), sync() schedules > the writes, but may return before the actual writing is done. However, > since version 1.3.20 Linux does actually wait. (This still does not > guarantee data integrity: modern disks have large caches.) My disk drive has 8mb cache. Maybe you're > flushing to a file via NFS (and the client "thinks" that it was > written, but maybe it was just buffered by the NFS server) or > so... but of course such exceptions of the rules are > constructable always.) > > Well, you tell that depending on the OS it can be that flush is > needed or it can be that flush is not needed (beacuse the I/O is > synchronized already), right? Also, applications should work on > any OS, which includes the OSes that do need flush. Its not OS's that need flush, its applications that want to have some assurance that data is written to the device that really needs to use flush. If your program ( or thread ) dies then it is in your best interest to write out the critical data as soon as possible, as economical as possible. These are trade-off's that the application programmer makes. A big buffer may mean big loss of data, a small buffer may mean spending too much time writing out data. > > > So would it be correct to say: > > "Applications, that should work under all OSes (including the > OSes where the I/O is not synchronised already), have to call > flush on OutputStream to ensure the data is transfered to the > kernel." > > or is this wrong? If so, then I'm afraid I missed the point again > :( > No that is not wrong. Ensuring that data is transfered to the OS is just about what any application can do. From tjarvi at qbang.org Thu Jun 14 08:16:47 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 14 Jun 2007 08:16:47 -0600 (MDT) Subject: [Rxtx] rxtx and usb-serial solution In-Reply-To: References: Message-ID: On Thu, 14 Jun 2007, Vladimir Kirtchev wrote: > Hi Trent, > > I develop a Java application which communicates with devices which have > USB-to-Serial bridge in them. The target OS is Linux. So for this purpose I > use RXTX. > > But I encountered a strange problem - when reading from the InputStream, I > receive series of zeros. I have this problem under Linux only. Under Windows > it is fine. > Actually this problem is the same as the one described here: > http://marc.info/?l=rxtx&m=109703190731748&w=2. > > > So I searched for the problem in the native code. And found that the root of > the problem is in SerialImp.c, > int configure_port( int fd ) > { > ... > ttyset.c_iflag = INPCK; > ... > } > > This line enables input parity checking, and the data sent from the device > is processed by the OS driver before being read with read(). > In this case the driver detects some problem and sets the received bytes to > zero. > > On the other hand in the Java part a set the serial port parameters with > SerialPort.PARITY_NONE. According to me, except all other things, this > should also disable INPCK in c_iflag. > > So I refactored the method translate_parity(...) to the following: > > int translate_parity( JNIEnv *env, struct termios *ttyset, jint parity ) > { > ENTER( "translate_parity" ); > #ifdef CMSPAR > ttyset->c_cflag &= ~(PARENB | PARODD | CMSPAR ); > #endif /* CMSPAR */ > switch( parity ) { > case JPARITY_NONE: > ttyset->c_iflag &= ~INPCK; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_EVEN: > ttyset->c_cflag |= PARENB; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_ODD: > ttyset->c_cflag |= PARENB | PARODD; > LEAVE( "translate_parity" ); > return 0; > #ifdef CMSPAR > case JPARITY_MARK: > ttyset->c_cflag |= PARENB | PARODD | CMSPAR; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_SPACE: > ttyset->c_cflag |= PARENB | CMSPAR; > LEAVE( "translate_parity" ); > return 0; > #endif /* CMSPAR */ > default: > printf("Parity missed %i\n", (int) parity ); > } > > LEAVE( "translate_parity" ); > /* > For some reason the native exceptions are not being caught. Moving this > to the Java side fixed the issue. taj. > throw_java_exception( env, UNSUPPORTED_COMM_OPERATION, > "", "parity value not supported" ); > */ > return 1; > } > > This modification solved the problem and now it works correctly under Linux. > > I think I will be a nice if this is idea is included in a future release of > RXTX. > > Thanks Vadim, I'll try that out. Forwarding to the rxtx mail-list too. This is probably not going to help USB drivers on windows which I'm sure some are looking for. As far as I can tell, windows USB bluetooth and serial dongles are limited by driver functionality. Some are good and others lack key features. -- Trent Jarvi tjarvi at qbang.org From dan.sandberg.lists at gmail.com Mon Jun 18 14:43:39 2007 From: dan.sandberg.lists at gmail.com (Dan Sandberg) Date: Mon, 18 Jun 2007 13:43:39 -0700 Subject: [Rxtx] Fix for JNI Get/Set Field Errors Message-ID: <4676EE7B.7060800@gmail.com> Hi, I've fixed the problems that cause the following JNI error when extra JNI checking ( -Xjni:check ) is turned on. FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) The problem was basically that GetLong was being used to get ints, and SetInt was used for longs. The patch below fixes this. Please let me know if there are any questions / problems. Cheers, -Dan diff -aur old/SerialImp.c src/SerialImp.c --- old/SerialImp.c 2007-06-18 13:24:33.000000000 -0700 +++ src/SerialImp.c 2007-06-18 06:26:26.000000000 -0700 @@ -1337,7 +1337,7 @@ report("init_threads: get eis\n"); jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); report("init_threads: set eis\n"); - (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); + (*eis->env)->SetLongField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); report("init_threads: stop\n"); report_time_end( ); return( 1 ); @@ -1530,7 +1530,7 @@ jobject jobj, jboolean interrupted ) { int fd = get_java_var( env, jobj,"fd","I" ); - struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var( env, jobj, "eis", "J" ); + struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var_long( env, jobj, "eis", "J" ); int result, count=0; char message[80]; @@ -2939,7 +2939,7 @@ /* TRENT */ int flag, count = 0; struct event_info_struct *eis = ( struct event_info_struct * ) - get_java_var( env, *jobj,"eis","J" ); + get_java_var_long( env, *jobj,"eis","J" ); report_time_start(); flag = eis->eventflags[SPE_DATA_AVAILABLE]; @@ -4873,9 +4873,9 @@ exceptions: none comments: ----------------------------------------------------------*/ -size_t get_java_var( JNIEnv *env, jobject jobj, char *id, char *type ) +long get_java_var_long( JNIEnv *env, jobject jobj, char *id, char *type ) { - int result = 0; + long result = 0; jclass jclazz = (*env)->GetObjectClass( env, jobj ); jfieldID jfd = (*env)->GetFieldID( env, jclazz, id, type ); @@ -4889,7 +4889,11 @@ LEAVE( "get_java_var" ); return result; } - result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); + if ( !strcmp( type, "J" ) ) { + result = (long)( (*env)->GetLongField( env, jobj, jfd ) ); + } else { + result = (int) ( (*env)->GetIntField( env, jobj, jfd ) ); + } /* ct7 & gel * Added DeleteLocalRef */ (*env)->DeleteLocalRef( env, jclazz ); if(!strncmp( "fd",id,2) && result == 0) @@ -4900,6 +4904,10 @@ return result; } +int get_java_var( JNIEnv *env, jobject jobj, char *id, char *type ) { + return (int) get_java_var_long( env, jobj, id, type ); +} + /*---------------------------------------------------------- throw_java_exception diff -aur old/SerialImp.h src/SerialImp.h --- old/SerialImp.h 2007-06-18 13:24:39.000000000 -0700 +++ src/SerialImp.h 2007-06-18 06:23:43.000000000 -0700 @@ -413,7 +413,8 @@ void system_wait(); void finalize_event_info_struct( struct event_info_struct * ); int read_byte_array( JNIEnv *, jobject *, int, unsigned char *, int, int ); -size_t get_java_var( JNIEnv *, jobject, char *, char * ); +int get_java_var( JNIEnv *, jobject, char *, char * ); +long get_java_var_long( JNIEnv *, jobject, char *, char * ); jboolean is_interrupted( struct event_info_struct * ); int send_event(struct event_info_struct *, jint, int ); void dump_termios(char *,struct termios *); From yvespielusenet at free.fr Tue Jun 26 03:41:58 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 11:41:58 +0200 Subject: [Rxtx] [PARALLEL] resource in use Message-ID: <1182850918.3483.10.camel@localhost.localdomain> Hello, So now I want to modify the timeout of the library for parallel port. I have downloaded source code. There is a makefile for migw. SO I have installed mingw on ubuntu and modified the makefile.mingw32 to set it for my system. I have no error but some warnings. The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But When I want to use it the jvm crash :( How can I know what is wrong ? How rxtx windows release has been done ? thanks -- yves piel From yvespielusenet at free.fr Tue Jun 26 07:17:02 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 15:17:02 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182850918.3483.10.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> Message-ID: <1182863822.3483.17.camel@localhost.localdomain> Here is the Makefile I use, the output of the 'make' and the log of the jvm when it crashed : - The Makefile : http://yvespiel.free.fr/rxtx/Makefile - The make output : http://yvespiel.free.fr/rxtx/compile.txt - The crash log : http://yvespiel.free.fr/rxtx/hs_err_pid2100.log I have compiled rxtx under Debian testing with mingw : narma at linimi:/tmp/err$ dpkg -l | grep mingw ii mingw32 3.4.5.20060117.1.dfsg-3 ii mingw32-binutils 2.17.50-20070129.1-1 ii mingw32-runtime 3.12-1 thanks fort help :) Le mardi 26 juin 2007 ? 11:41 +0200, yves pielusenet a ?crit : > Hello, > So now I want to modify the timeout of the library for parallel port. I > have downloaded source code. There is a makefile for migw. SO I have > installed mingw on ubuntu and modified the makefile.mingw32 to set it > for my system. > I have no error but some warnings. > The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But > When I want to use it the jvm crash :( > > How can I know what is wrong ? > > How rxtx windows release has been done ? > > thanks > From yvespielusenet at free.fr Tue Jun 26 07:40:11 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 15:40:11 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182863822.3483.17.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> <1182863822.3483.17.camel@localhost.localdomain> Message-ID: <1182865211.3483.21.camel@localhost.localdomain> I have add the options '--enable-stdcall-fixup' to the 'i586-mingw32msvc-ld' commande. Now I have no warning. But the JVM always crashes :( The output seems more detailled, but I don't understand anything... Here is files : http://yvespiel.free.fr/rxtx/2/ -- yves piel Le mardi 26 juin 2007 ? 15:17 +0200, yves pielusenet a ?crit : > Here is the Makefile I use, the output of the 'make' and the log of the > jvm when it crashed : > > - The Makefile : http://yvespiel.free.fr/rxtx/Makefile > - The make output : http://yvespiel.free.fr/rxtx/compile.txt > - The crash log : http://yvespiel.free.fr/rxtx/hs_err_pid2100.log > > I have compiled rxtx under Debian testing with mingw : > narma at linimi:/tmp/err$ dpkg -l | grep mingw > ii mingw32 3.4.5.20060117.1.dfsg-3 > ii mingw32-binutils 2.17.50-20070129.1-1 > ii mingw32-runtime 3.12-1 > > thanks fort help :) > > > Le mardi 26 juin 2007 ? 11:41 +0200, yves pielusenet a ?crit : > > Hello, > > So now I want to modify the timeout of the library for parallel port. I > > have downloaded source code. There is a makefile for migw. SO I have > > installed mingw on ubuntu and modified the makefile.mingw32 to set it > > for my system. > > I have no error but some warnings. > > The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But > > When I want to use it the jvm crash :( > > > > How can I know what is wrong ? > > > > How rxtx windows release has been done ? > > > > thanks > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From yvespielusenet at free.fr Tue Jun 26 08:27:42 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 16:27:42 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182865211.3483.21.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> <1182863822.3483.17.camel@localhost.localdomain> <1182865211.3483.21.camel@localhost.localdomain> Message-ID: <1182868062.3483.24.camel@localhost.localdomain> I think thant the include files of jdk were not for windows but for linux. So I have copied include/ folder from windows to linux and I modified the Makefile to use those file. It compile fine but the JVM always crash :( http://yvespiel.free.fr/rxtx/3/ Le mardi 26 juin 2007 ? 15:40 +0200, yves pielusenet a ?crit : > I have add the options '--enable-stdcall-fixup' to the > 'i586-mingw32msvc-ld' commande. Now I have no warning. But the JVM > always crashes :( The output seems more detailled, but I don't > understand anything... > Here is files : > http://yvespiel.free.fr/rxtx/2/ > From netbeans at gatworks.com Fri Jun 1 05:38:50 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 07:38:50 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <465F7ADD.1010501@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> Message-ID: <4660054A.2040202@gatworks.com> Manuel Naranjo wrote: In the case of my module, you can > unplug the device but it will not delete the symlink until those apps > that had opened the port has closed it. This is done this way to avoid > kernel panics. What does this mean to user code ? I have tried the alternate route ( other than closing ) which is sleep inbetween the I/O errors ( an unplugged USB device). When the device is plugged back in, The writes to the device still get an I/O error. This would seem to be a lost cause for the application. From netbeans at gatworks.com Fri Jun 1 06:35:48 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 08:35:48 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <465F7ADD.1010501@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> Message-ID: <466012A4.90608@gatworks.com> Manuel Naranjo wrote: In the case of my module, you can > unplug the device but it will not delete the symlink until those apps > that had opened the port has closed it. T Did u also mean for this to happen? USB0 was not closed by application. Apparently USB1 got created when USB device was plugged back in. There is only one USB device on a 4 port USB hub. This also seems to suggest that application recovery to be impossible. > Jun 1 07:10:08 mylaptop kernel: garmin_gps 1-1.4:1.0: Garmin GPS usb/tty converter detected > Jun 1 07:10:08 mylaptop kernel: usb 1-1.4: Garmin GPS usb/tty converter now attached to ttyUSB0 > Jun 1 07:15:17 mylaptop kernel: usb 1-1: USB disconnect, address 4 > Jun 1 07:15:17 mylaptop kernel: usb 1-1.4: USB disconnect, address 5 > Jun 1 07:15:17 mylaptop kernel: garmin_gps 1-1.4:1.0: device disconnected > Jun 1 07:15:26 mylaptop kernel: usb 1-1: new full speed USB device using uhci_hcd and address 6 > Jun 1 07:15:26 mylaptop kernel: hub 1-1:1.0: USB hub found > Jun 1 07:15:26 mylaptop kernel: hub 1-1:1.0: 4 ports detected > Jun 1 07:15:27 mylaptop kernel: usb 1-1.4: new full speed USB device using uhci_hcd and address 7 > Jun 1 07:15:27 mylaptop kernel: garmin_gps 1-1.4:1.0: Garmin GPS usb/tty converter detected > Jun 1 07:15:27 mylaptop kernel: usb 1-1.4: Garmin GPS usb/tty converter now attached to ttyUSB1 From naranjo.manuel at gmail.com Fri Jun 1 09:17:22 2007 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Fri, 01 Jun 2007 12:17:22 -0300 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <466012A4.90608@gatworks.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> <466012A4.90608@gatworks.com> Message-ID: <46603882.5050701@gmail.com> Uncle George escribi?: > Manuel Naranjo wrote: > In the case of my module, you can > >> unplug the device but it will not delete the symlink until those apps >> that had opened the port has closed it. T >> > > Did u also mean for this to happen? USB0 was not closed by application. > > Apparently USB1 got created when USB device was plugged back in. There > is only one USB device on a 4 port USB hub. > > This also seems to suggest that application recovery to be impossible. > Exactly there's a dead symlink (you can read and write to it and nothing will happen) and a new port will be created when a new device is connencted. From netbeans at gatworks.com Fri Jun 1 10:20:46 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 12:20:46 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <46603882.5050701@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> <466012A4.90608@gatworks.com> <46603882.5050701@gmail.com> Message-ID: <4660475E.5090202@gatworks.com> Not sure what u mean by "symlink". U cant read/write to it anymore. U get I/O error. In this scenario the device effectively went dead, and only solution is to close the channel. reconnecting the USB device, although dead, but not closed, will create a second device. This does not seem to be a desirable side-effect. The user will now have ttyUSB1, wondering where did ttyUSB0 go to. The application will also be in a confused state, as well as RXTX, because RXTX wont know about ttyUSB1. Manuel Naranjo wrote: > Uncle George escribi?: >> Manuel Naranjo wrote: >> In the case of my module, you can >> >>> unplug the device but it will not delete the symlink until those apps >>> that had opened the port has closed it. T >>> >> Did u also mean for this to happen? USB0 was not closed by application. >> >> Apparently USB1 got created when USB device was plugged back in. There >> is only one USB device on a 4 port USB hub. >> >> This also seems to suggest that application recovery to be impossible. >> > Exactly there's a dead symlink (you can read and write to it and nothing > will happen) and a new port will be created when a new device is connencted. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From arnab.bhaumik at gmail.com Mon Jun 4 01:40:16 2007 From: arnab.bhaumik at gmail.com (arnab bhaumik) Date: Mon, 4 Jun 2007 13:10:16 +0530 Subject: [Rxtx] full duplex com port with rxtx Message-ID: hi , till now i did half duplex communication with rxtx package on com package. my question is : is it possible to use com port with full duplex mode with rxtx package . ther is example of SimpleRead class and SimpleWrite class. it is clear that if i can use both the class simultaneously then full duplex is possible......... arnab/vu2bpw -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070604/6edb0453/attachment-0003.html From lists at iDIAcomputing.com Mon Jun 4 07:53:17 2007 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Mon, 04 Jun 2007 09:53:17 -0400 Subject: [Rxtx] full duplex com port with rxtx In-Reply-To: References: Message-ID: <4664194D.90301@iDIAcomputing.com> arnab bhaumik wrote: > hi , > > till now i did half duplex communication with rxtx package on com > package. > > my question is : is it possible to use com port with full duplex mode > with rxtx package . > > > ther is example of SimpleRead class and SimpleWrite class. it is > clear that if i can use both the class simultaneously then full duplex > is possible......... I haven't looked at the SimpleRead and SimpleWrite classes (I originally wrote my code for the javax.comm api), but full duplex is certainly possible. My CommReader class requires an object analogous to a OutputStream or Writer. When started, it spawns a thread that reads the comm port and writes to that output device. In this way the input is asynchronous and dependent on the actual input data. For full duplex, I extend that class with CommReaderWriter, which adds synchronous output methods. Hope that helps, George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From supsoop at hotmail.com Mon Jun 4 15:21:06 2007 From: supsoop at hotmail.com (soop soop) Date: Mon, 04 Jun 2007 21:21:06 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- Message-ID: Hi Guys, Looked through the archives but still cannot figure this out. I have a Motorola G24 GPRS/GSM modem that I am connecting to my server running Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not detecting the port, CommPortIdentifier.getPortIdentifiers(). I have added the line to RXTXCommDriver: "ttyACM" // for USB Modems Rxtx still does not seem to find the port. Is there something I am missing to make this port visable? [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control Model driver for USB modems and ISDN adapters I really need your help as I have moved my server from windows to Linux and have been down for a few days because of this .. Thanks so much! _________________________________________________________________ PC Magazine’s 2007 editors’ choice for best Web mail—award-winning Windows Live Hotmail. http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 From tjarvi at qbang.org Mon Jun 4 16:17:35 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Jun 2007 16:17:35 -0600 (MDT) Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: On Mon, 4 Jun 2007, soop soop wrote: > Hi Guys, > > Looked through the archives but still cannot figure this out. I have a > Motorola G24 GPRS/GSM modem that I am connecting to my server running Ubuntu. > I can see my modem as is shows up as ttyACM0, but RXTX is not detecting the > port, CommPortIdentifier.getPortIdentifiers(). > > I have added the line to RXTXCommDriver: > > "ttyACM" // for USB Modems > > Rxtx still does not seem to find the port. Is there something I am missing to > make this port visable? > > [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver > [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device > [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control Model > driver for USB modems and ISDN adapters > > I really need your help as I have moved my server from windows to Linux and > have been down for a few days because of this .. Thanks so much! > You could try the INSTALL documentation that comes with the source for possible solutions. Those usually involve lockfile creation, permissions on the device file or the device is in use by another application (even another session of your application). The usual commands: ls -l /dev/ttyACM0 fuser /dev/ttyACM0 touch /var/lock/LCK.testfile && rm -f /var/lock/LCK.testfile whoami To disable lockfiles: ../configure --disable-lockfiles && make install -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Jun 4 16:22:52 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 04 Jun 2007 18:22:52 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <466490BC.3090801@gatworks.com> soop soop wrote: > I really need your help as I have moved my server from windows to Linux > and have been down for a few days because of this .. Thanks so much! can u open the device ? ie is the file protection/permissions keeping you out? From supsoop at hotmail.com Mon Jun 4 16:44:40 2007 From: supsoop at hotmail.com (soop soop) Date: Mon, 04 Jun 2007 22:44:40 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <466490BC.3090801@gatworks.com> Message-ID: Thanks for the reply, I see no exceptions being thrown, just no detection of the port whats so ever. I will run rxtx in debug mode and log. If this were a permissions issue would I not see some exceptions being thrown? >From: Uncle George >Reply-To: RXTX Developers and Users >To: RXTX Developers and Users >Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >Date: Mon, 04 Jun 2007 18:22:52 -0400 > >soop soop wrote: > > > I really need your help as I have moved my server from windows to Linux > > and have been down for a few days because of this .. Thanks so much! > >can u open the device ? ie is the file protection/permissions keeping >you out? >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ Get a preview of Live Earth, the hottest event this summer - only on MSN http://liveearth.msn.com?source=msntaglineliveearthhm From netbeans at gatworks.com Mon Jun 4 17:06:15 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 04 Jun 2007 19:06:15 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <46649AE7.10405@gatworks.com> Exceptions on what? On startup it wants to lookup all devices in /dev that it is capable of opening ( within the list of specific 'comm' devices ). If it cannot open, then does not get onto list. Part of this process, if configured, will also test if the "LOCK" schema can also be opened for the device. then it gets on the list of avail comm port. soop soop wrote: > Thanks for the reply, > > I see no exceptions being thrown, just no detection of the port whats so > ever. I will run rxtx in debug mode and log. If this were a permissions > issue would I not see some exceptions being thrown? > > >> From: Uncle George >> Reply-To: RXTX Developers and Users >> To: RXTX Developers and Users >> Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >> Date: Mon, 04 Jun 2007 18:22:52 -0400 >> >> soop soop wrote: >> >>> I really need your help as I have moved my server from windows to Linux >>> and have been down for a few days because of this .. Thanks so much! >> can u open the device ? ie is the file protection/permissions keeping >> you out? >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _________________________________________________________________ > Get a preview of Live Earth, the hottest event this summer - only on MSN > http://liveearth.msn.com?source=msntaglineliveearthhm > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From alex.flint at gmail.com Mon Jun 4 21:31:49 2007 From: alex.flint at gmail.com (Alex Flint) Date: Tue, 5 Jun 2007 13:01:49 +0930 Subject: [Rxtx] random EXCEPTION_ACCESS_VIOLATION errors Message-ID: Hi All, I'm running winXP and RXTX 2.1-7r2 (the latest from the webpage as of June 2007). I'm sending sequences of 64 lines (each line has about 15 chars) at various intervals. The strings are sent fine, until I get the following error (from hs_err_pid3316.log, at the end of this email). What can I do to avoid the error? Obviously this is a low-level memory exception, but is there any way I can keep the JVM running after such an error? I noticed the exact same problem here: http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20070129/1180520.html Cheers, Alex # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x100034fb, pid=3316, tid=2400 # # Java VM: Java HotSpot(TM) Client VM (1.6.0_01-b06 mixed mode, sharing) # Problematic frame: # C [rxtxSerial.dll+0x34fb] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # --------------- T H R E A D --------------- Current thread (0x00386400): JavaThread "main" [_thread_in_native, id=2400] siginfo: ExceptionCode=0xc0000005, reading address 0x20726f78 Registers: EAX=0x20726f20, EBX=0x6d8922c0, ECX=0x00000005, EDX=0x20726f20 ESP=0x003efa30, EBP=0x003efb68, ESI=0x269728a0, EDI=0x00386400 EIP=0x100034fb, EFLAGS=0x00010212 Top of Stack: (sp=0x003efa30) 0x003efa30: 003efa3c 003efa64 0000000f ffffffff 0x003efa40: 003efa40 2a97f808 003efa6c 2b190ca8 0x003efa50: 00000000 2b190ec0 003efa90 008e2dd7 0x003efa60: 003efa90 008e2dd7 26977f88 6d815e72 0x003efa70: 00000004 2696eae0 0000008a 003efb0c 0x003efa80: 6d852b4a 2696eae0 00000003 26970930 0x003efa90: 000000cb 2696eae0 6d86b264 00385d40 0x003efaa0: 0000003f 003efb0c 26977f90 2ace65d8 Instructions: (pc=0x100034fb) 0x100034eb: ff ff 8d 76 00 eb 02 89 f6 90 8b 45 f8 8b 55 f8 0x100034fb: 8b 4a 58 83 c9 04 89 48 58 83 c4 f8 8b 45 f8 8b Stack: [0x003a0000,0x003f0000), sp=0x003efa30, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x34fb] Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j gnu.io.RXTXPort.writeArray([BIIZ)V+0 j gnu.io.RXTXPort$SerialOutputStream.write([B)V+76 j com.bjt.media.server.CommLink.send(Ljava/lang/String;)V+48 j com.bjt.media.server.DigitoolConnection.select(I)V+73 j com.bjt.media.server.DigitoolConnection.main([Ljava/lang/String;)V+74 v ~StubRoutines::call_stub --------------- P R O C E S S --------------- Java Threads: ( => current thread ) 0x02a69400 JavaThread "Thread-0" [_thread_in_native, id=3052] 0x02a4d000 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=3920] 0x02a48400 JavaThread "CompilerThread0" daemon [_thread_blocked, id=1968] 0x02a47400 JavaThread "Attach Listener" daemon [_thread_blocked, id=2984] 0x02a46400 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=2660] 0x02a41c00 JavaThread "Finalizer" daemon [_thread_blocked, id=3924] 0x02a3d800 JavaThread "Reference Handler" daemon [_thread_blocked, id=4008] =>0x00386400 JavaThread "main" [_thread_in_native, id=2400] Other Threads: 0x02a34400 VMThread [id=3708] 0x02a4e800 WatcherThread [id=3964] VM state:not at safepoint (normal execution) VM Mutex/Monitor currently owned by a thread: None Heap def new generation total 960K, used 131K [0x22960000, 0x22a60000, 0x22e40000) eden space 896K, 7% used [0x22960000, 0x22970ea8, 0x22a40000) from space 64K, 99% used [0x22a50000, 0x22a5fff8, 0x22a60000) to space 64K, 0% used [0x22a40000, 0x22a40000, 0x22a50000) tenured generation total 4096K, used 76K [0x22e40000, 0x23240000, 0x26960000) the space 4096K, 1% used [0x22e40000, 0x22e53060, 0x22e53200, 0x23240000) compacting perm gen total 12288K, used 137K [0x26960000, 0x27560000, 0x2a960000) the space 12288K, 1% used [0x26960000, 0x26982518, 0x26982600, 0x27560000) ro space 8192K, 62% used [0x2a960000, 0x2ae5e4e8, 0x2ae5e600, 0x2b160000) rw space 12288K, 52% used [0x2b160000, 0x2b7a0e78, 0x2b7a1000, 0x2bd60000) Dynamic libraries: 0x00400000 - 0x00423000 C:\Program Files\Java\jre1.6.0_01\bin\javaw.exe 0x7c900000 - 0x7c9b0000 C:\WINDOWS\system32\ntdll.dll 0x7c800000 - 0x7c8f4000 C:\WINDOWS\system32\kernel32.dll 0x77dd0000 - 0x77e6b000 C:\WINDOWS\system32\ADVAPI32.dll 0x77e70000 - 0x77f01000 C:\WINDOWS\system32\RPCRT4.dll 0x7e410000 - 0x7e4a0000 C:\WINDOWS\system32\USER32.dll 0x77f10000 - 0x77f57000 C:\WINDOWS\system32\GDI32.dll 0x76390000 - 0x763ad000 C:\WINDOWS\system32\IMM32.DLL 0x7c340000 - 0x7c396000 C:\Program Files\Java\jre1.6.0_01\bin\msvcr71.dll 0x6d7c0000 - 0x6da07000 C:\Program Files\Java\jre1.6.0_01\bin\client\jvm.dll 0x76b40000 - 0x76b6d000 C:\WINDOWS\system32\WINMM.dll 0x5cd70000 - 0x5cd77000 C:\WINDOWS\system32\serwvdrv.dll 0x5b0a0000 - 0x5b0a7000 C:\WINDOWS\system32\umdmxfrm.dll 0x6d310000 - 0x6d318000 C:\Program Files\Java\jre1.6.0_01\bin\hpi.dll 0x76bf0000 - 0x76bfb000 C:\WINDOWS\system32\PSAPI.DLL 0x6d770000 - 0x6d77c000 C:\Program Files\Java\jre1.6.0_01\bin\verify.dll 0x6d3b0000 - 0x6d3cf000 C:\Program Files\Java\jre1.6.0_01\bin\java.dll 0x6d7b0000 - 0x6d7bf000 C:\Program Files\Java\jre1.6.0_01\bin\zip.dll 0x10000000 - 0x10012000 C:\Documents and Settings\Alex\workspace\MediaServer\rxtxSerial.dll 0x73d90000 - 0x73db7000 C:\WINDOWS\system32\crtdll.dll VM Arguments: jvm_args: -Djava.library.path=C:\Documents and Settings\Alex\workspace\MediaServer java_command: com.bjt.media.server.DigitoolConnection Launcher Type: SUN_STANDARD Environment Variables: CLASSPATH=.;C:\Program Files\Java\j2re1.4.2_07\lib\ext\QTJava.zip PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\wbem;c:\applications\php;C:\Program Files\MATLAB\R2006a\bin\win32;C:\Roger\Projects\UAV\Bin\Debug;C:\Program Files\Microsoft SQL Server\80\Tools\Binn\;c:\Program Files\Microsoft SQL Server\90\Tools\binn\;C:\Program Files\QuickTime\QTSystem\;C:\Pfps\system;C:\Program Files\Java\jdk1.6.0_01\bin;C:\Program Files\Java\jdk1.6.0_01\jre\bin USERNAME=Alex OS=Windows_NT PROCESSOR_IDENTIFIER=x86 Family 15 Model 4 Stepping 1, GenuineIntel --------------- S Y S T E M --------------- OS: Windows XP Build 2600 Service Pack 2 CPU:total 1 family 15, cmov, cx8, fxsr, mmx, sse, sse2 Memory: 4k page, physical 1046508k(275288k free), swap 2522816k(1909176k free) vm_info: Java HotSpot(TM) Client VM (1.6.0_01-b06) for windows-x86, built on Mar 14 2007 00:24:02 by "java_re" with unknown MS VC++:1310 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070604/c87ae1f0/attachment-0003.html From alwyn.schoeman at gmail.com Tue Jun 5 00:10:19 2007 From: alwyn.schoeman at gmail.com (Alwyn Schoeman) Date: Tue, 5 Jun 2007 08:10:19 +0200 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Hi, I'm using a similar modem. By default rxtx doesn't look for devices that start with ACM, so you need to modify the source code and recompile. Look in RXTXCommDriver and add values for ACM in the registerScannedPorts method in the Linux specific parts. Look for osName.equals("Linux")... On 6/4/07, soop soop wrote: > > Hi Guys, > > Looked through the archives but still cannot figure this out. I have a > Motorola G24 GPRS/GSM modem that I am connecting to my server running > Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not > detecting the port, CommPortIdentifier.getPortIdentifiers(). > > I have added the line to RXTXCommDriver: > > "ttyACM" // for USB Modems > > Rxtx still does not seem to find the port. Is there something I am missing > to make this port visable? > > [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver > [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device > [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control > Model > driver for USB modems and ISDN adapters > > I really need your help as I have moved my server from windows to Linux > and > have been down for a few days because of this .. Thanks so much! > > _________________________________________________________________ > PC Magazine's 2007 editors' choice for best Web mail?award-winning Windows > Live Hotmail. > > http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -- Alwyn Schoeman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/b6cb3053/attachment-0003.html From naranjo.manuel at gmail.com Tue Jun 5 06:48:45 2007 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Tue, 05 Jun 2007 09:48:45 -0300 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> References: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Message-ID: <46655BAD.7010501@gmail.com> That's right, an easier solution is creating symlinks to acm. For example make ttyS70 to 79 point to ACM0 to 9 and that will help you a lot, and doesn't even require compile. > Hi, > > I'm using a similar modem. By default rxtx doesn't look for devices > that start with ACM, so you need to modify the > source code and recompile. > > Look in RXTXCommDriver and add values for ACM in the > registerScannedPorts method in the Linux specific parts. Look for > osName.equals("Linux")... > From juanemc2 at gmail.com Tue Jun 5 07:02:43 2007 From: juanemc2 at gmail.com (Juan) Date: Tue, 5 Jun 2007 10:02:43 -0300 Subject: [Rxtx] Problems with Epson TMU220B POSPrinter using XON/XOFF Flow Control and rxtx jar and dll's with the serial port. Message-ID: Hi!, I?m having trouble printing to the serial port using the latest version of rxtx jar and dll's with an Epson POSPrinter. I`ve switched the printer to work with XON/XOFF Flow Control and have watched the serial port to be sure the printer is sending the XON XOFF stop and go characters. I`ve setted the port like this: CommPortIdentifier commPortIdentifier = CommPortIdentifier.* getPortIdentifier*(_portName); SerialPort serialPort = (SerialPort)commPortIdentifier.open(*this*.getClass().getName(), 2000); serialPort.setSerialPortParams(_baudRate, _dataBits, _stopBits, _parity); serialPort.setFlowControlMode( SerialPort.*FLOWCONTROL_XONXOFF_IN* | SerialPort.*FLOWCONTROL_XONXOFF_OUT*); where the baudRate is 9600 the dataBits is 8 the stopBits is 1 and the parity is 0 It seems as the library isn`t taking into account the XON XOFF setting. I would like to know if I`m setting correctly the Flow Control and if you had had any experiences using XON XOFF flow control and could give me some help to solve my problem. I`m very thankful in advance, Yours, Juan Polero -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/b080995a/attachment-0003.html From ehdez.correo at gmail.com Tue Jun 5 07:12:53 2007 From: ehdez.correo at gmail.com (=?ISO-8859-1?Q?Enrique_Hern=E1ndez?=) Date: Tue, 5 Jun 2007 09:12:53 -0400 Subject: [Rxtx] problem with rxtx Message-ID: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Hello: I doing a simple test to show the serial ports. This is the code: import java.util.Enumeration; import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; public class Show { private Enumeration portList; private CommPortIdentifier portId; private SerialPort port; /** Creates a new instance of Show */ public Show() { } public static void main(String args[]){ Show show = new Show(); show.portList = CommPortIdentifier.getPortIdentifiers(); String tPort = ""; System.out.println("========================================="); while(show.portList.hasMoreElements()){ show.portId = (CommPortIdentifier)show.portList.nextElement(); if(show.portId.getPortType() == CommPortIdentifier.PORT_SERIAL) tPort = "Serial"; else tPort = "Parallel"; System.out.println(show.portId.getName() + " " + tPort); } } } whit The problem is that this code not show the serial ports, this show the no use serial ports. I want to connect whit the modem but when windows open and connect the modem my application don't see the port(COMM3) when it is connect. what I can do? Is that the correct way to know the ports? thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/eedd744b/attachment-0003.html From ehdez.correo at gmail.com Tue Jun 5 07:42:13 2007 From: ehdez.correo at gmail.com (=?ISO-8859-1?Q?Enrique_Hern=E1ndez?=) Date: Tue, 5 Jun 2007 09:42:13 -0400 Subject: [Rxtx] serial port Message-ID: <4a814e1f0706050642p4ce9ac7bka80f9479c524c5ea@mail.gmail.com> Hello: How I can ask to the port what device is connect and information about this device. thanks. bye. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/4d10d26a/attachment-0003.html From supsoop at hotmail.com Tue Jun 5 09:29:00 2007 From: supsoop at hotmail.com (soop soop) Date: Tue, 05 Jun 2007 15:29:00 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Message-ID: Hi Guys, Thanks for all your help. I found the problem. I created a user, Tomcat55, for my tomcat but it did not belong to any group. I then added this user to dialout group to have access to the device ttyACM0. Works perfectly! Again permissions was the issue. This also seems to be persistent as a server reboot does not effect the access. Cheers! >From: "Alwyn Schoeman" >Reply-To: RXTX Developers and Users >To: "RXTX Developers and Users" >Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >Date: Tue, 5 Jun 2007 08:10:19 +0200 > >Hi, > >I'm using a similar modem. By default rxtx doesn't look for devices that >start with ACM, so you need to modify the >source code and recompile. > >Look in RXTXCommDriver and add values for ACM in the registerScannedPorts >method in the Linux specific parts. Look for osName.equals("Linux")... > >On 6/4/07, soop soop wrote: >> >>Hi Guys, >> >>Looked through the archives but still cannot figure this out. I have a >>Motorola G24 GPRS/GSM modem that I am connecting to my server running >>Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not >>detecting the port, CommPortIdentifier.getPortIdentifiers(). >> >>I have added the line to RXTXCommDriver: >> >>"ttyACM" // for USB Modems >> >>Rxtx still does not seem to find the port. Is there something I am missing >>to make this port visable? >> >>[ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver >>[ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device >>[ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control >>Model >>driver for USB modems and ISDN adapters >> >>I really need your help as I have moved my server from windows to Linux >>and >>have been down for a few days because of this .. Thanks so much! >> >>_________________________________________________________________ >>PC Magazine's 2007 editors' choice for best Web mail—award-winning Windows >>Live Hotmail. >> >>http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 >> >> >>_______________________________________________ >>Rxtx mailing list >>Rxtx at qbang.org >>http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > >-- >Alwyn Schoeman >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ Need a break? Find your escape route with Live Search Maps. http://maps.live.com/default.aspx?ss=Restaurants~Hotels~Amusement%20Park&cp=33.832922~-117.915659&style=r&lvl=13&tilt=-90&dir=0&alt=-1000&scene=1118863&encType=1&FORM=MGAC01 From netbeans at gatworks.com Tue Jun 5 09:42:31 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 11:42:31 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <46658467.20101@gatworks.com> soop soop wrote: > > Hi Guys, > > Thanks for all your help. I found the problem. I created a user, > Tomcat55, for my tomcat but it did not belong to any group. I then added Look at man pages for the program udev. From tjarvi at qbang.org Tue Jun 5 18:18:17 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Jun 2007 18:18:17 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Message-ID: On Tue, 5 Jun 2007, Enrique Hern?ndez wrote: > The problem is that this code not show the serial ports, this show the no > use serial ports. I want to connect whit the modem but when windows open and > connect the modem my application don't see the port(COMM3) when it is > connect. > what I can do? > Is that the correct way to know the ports? > Hello, We may have problems understanding each other. On windows, the port will not be an available serial port if another application has the port open. That is just how the library behaves. If you can not see the port in the enumerated list, you could not open it. Also note that enumeration only happens once. If you add a port such as a new USB dongle, the port will not be visible until the next time your application runs. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Tue Jun 5 18:45:01 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 20:45:01 -0400 Subject: [Rxtx] problem with rxtx In-Reply-To: References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Message-ID: <4666038D.8090700@gatworks.com> Trent Jarvi wrote: > > > Also note that enumeration only happens once. If you add a port such as > a new USB dongle, the port will not be visible until the next time your > application runs. Is this written in stone ? somewhere? From tjarvi at qbang.org Tue Jun 5 18:54:36 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Jun 2007 18:54:36 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <4666038D.8090700@gatworks.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> Message-ID: On Tue, 5 Jun 2007, Uncle George wrote: > Trent Jarvi wrote: >> >> >> Also note that enumeration only happens once. If you add a port such as >> a new USB dongle, the port will not be visible until the next time your >> application runs. > > Is this written in stone ? somewhere? It is just the current behavior. There is nothing preventing a fix that allows reenumeration. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Tue Jun 5 19:55:19 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 21:55:19 -0400 Subject: [Rxtx] problem with rxtx In-Reply-To: References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> Message-ID: <46661407.4020308@gatworks.com> >> Is this written in stone ? somewhere? > > It is just the current behavior. There is nothing preventing a fix that > allows reenumeration. With usb, ..... , things come and go. Seems a shame that you have to kill application to get at the device u just plugged in. From joachim at buechse.ch Wed Jun 6 01:50:06 2007 From: joachim at buechse.ch (Joachim Buechse) Date: Wed, 6 Jun 2007 09:50:06 +0200 Subject: [Rxtx] problem with rxtx In-Reply-To: <46661407.4020308@gatworks.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> <46661407.4020308@gatworks.com> Message-ID: <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> On MacOS RXTX's enumeration handling is more flexible. It will find new ports that are added during the lifetime of the application. But this is inherently incompatible with suns javax.comm implementation... Regards, Joachim On 06.06.2007, at 03:55, Uncle George wrote: > >>> Is this written in stone ? somewhere? >> >> It is just the current behavior. There is nothing preventing a >> fix that >> allows reenumeration. > > With usb, ..... , things come and go. Seems a shame that you have to > kill application to get at the device u just plugged in. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Jun 6 06:06:48 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Jun 2007 06:06:48 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> <46661407.4020308@gatworks.com> <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> Message-ID: Sun's javax.comm is not a major concern going forward. As long as we do not break old applications using rxtx, I see no reason to limit rxtx to that convention. We have already rejected version 3 from Sun as a dead end and limited our compatability to version 2. That does not mean we will not try to work with Sun and others but the current javax.comm convention (v3) is not a well conceived path. There has been discussion about doing a JSR which is one valid option. On Wed, 6 Jun 2007, Joachim Buechse wrote: > On MacOS RXTX's enumeration handling is more flexible. It will find > new ports that are added during the lifetime of the application. But > this is inherently incompatible with suns javax.comm implementation... > > Regards, > Joachim > > On 06.06.2007, at 03:55, Uncle George wrote: > >> >>>> Is this written in stone ? somewhere? >>> >>> It is just the current behavior. There is nothing preventing a >>> fix that >>> allows reenumeration. >> >> With usb, ..... , things come and go. Seems a shame that you have to >> kill application to get at the device u just plugged in. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From yvespielusenet at free.fr Wed Jun 6 08:46:35 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 16:46:35 +0200 Subject: [Rxtx] [PARALLEL] resource in use Message-ID: <1181141195.3407.20.camel@localhost.localdomain> Hello, I want to use rxtx in my application. I haveto send data to a very old printer (which have a drum and hammers http://perso.orange.fr/tiie/page00010017.html) This is printer is connecter with centronics. It works well but, while it's writting and I putthe printer off-line, after about 45 seconds, I have this error : ------------------------------------- java.io.IOException: La ressource demand?e est en cours d'utilisation. in writeArray at gnu.io.LPRPort.writeArray(Native Method) at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:292) at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:161) at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:156) at mce.buffer.bufferManager.BufferManager$PrintBuffer.run(BufferManager.java:141) The IOexception means "The wanted resource is in use" ------------------------------------- Here is the line 141 of BufferManager : ------------------------------------- while(send){ try{ fos.write(bb); <=== line 141 send = false; } catch(Exception e){ javax.swing.JOptionPane.showMessageDialog(null, "Erreur d'envoie. Veuillez cliquer sur OK pour relancer l'impression de la vignette.\nV?rifiez votre impression !", "Erreur d'envoie", javax.swing.JOptionPane.WARNING_MESSAGE); e.printStackTrace(System.err); System.err.flush(); System.out.println(e); send = true; } } -------------------------------- 'fos' is an outputstream which contains the rxtx stream (this.os is the rxtx outputstream) : -------------------------------- public void write(byte[] bb) throws IOException{ this.write(bb, 0, bb.length); } public void write(byte[] bb, int off, int len) throws IOException{ while(!imp1.isPrinterSelected() || !imp2.isPrinterSelected()){ } this.os.write(bb, off, len); } -------------------------------- Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( can you help me ? thank you :) -- yves piel From yvespielusenet at free.fr Wed Jun 6 09:11:15 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 17:11:15 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181141195.3407.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> Message-ID: <1181142675.3407.23.camel@localhost.localdomain> I forgot to tell that It's under windows XP and java 1.5. Le mercredi 06 juin 2007 ? 16:46 +0200, yves pielusenet a ?crit : > Hello, > I want to use rxtx in my application. I haveto send data to a very old > printer (which have a drum and hammers > http://perso.orange.fr/tiie/page00010017.html) > This is printer is connecter with centronics. It works well but, while > it's writting and I putthe printer off-line, after about 45 seconds, I > have this error : > ------------------------------------- > java.io.IOException: La ressource demand?e est en cours d'utilisation. > in writeArray > at gnu.io.LPRPort.writeArray(Native Method) > at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:292) > at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:161) > at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:156) > at mce.buffer.bufferManager.BufferManager$PrintBuffer.run(BufferManager.java:141) > > The IOexception means "The wanted resource is in use" > ------------------------------------- > > Here is the line 141 of BufferManager : > > ------------------------------------- > while(send){ > try{ > fos.write(bb); <=== line 141 > send = false; > } > catch(Exception e){ > javax.swing.JOptionPane.showMessageDialog(null, "Erreur d'envoie. Veuillez cliquer sur OK pour relancer l'impression de la vignette.\nV?rifiez votre impression !", "Erreur d'envoie", javax.swing.JOptionPane.WARNING_MESSAGE); > e.printStackTrace(System.err); > System.err.flush(); > System.out.println(e); > send = true; > } > } > -------------------------------- > 'fos' is an outputstream which contains the rxtx stream (this.os is the rxtx outputstream) : > > -------------------------------- > public void write(byte[] bb) throws IOException{ > this.write(bb, 0, bb.length); > } > public void write(byte[] bb, int off, int len) throws IOException{ > while(!imp1.isPrinterSelected() || !imp2.isPrinterSelected()){ > } > this.os.write(bb, off, len); > } > -------------------------------- > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > can you help me ? > > thank you :) > From netbeans at gatworks.com Wed Jun 6 09:21:46 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 11:21:46 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181141195.3407.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> Message-ID: <4666D10A.8000507@gatworks.com> } > -------------------------------- > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > can you help me ? > > thank you :) > windoz or linux? ( I guess windoz ) for windoz, there appears to be a timeout ( as Comments suggest ) of about 40seconds. > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } for linux, there is no implied timeout. > if( write( fd, bytes, count ) < 0 ) > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); From netbeans at gatworks.com Wed Jun 6 09:39:41 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 11:39:41 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666D10A.8000507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> Message-ID: <4666D53D.90000@gatworks.com> Uncle George wrote: > } >> -------------------------------- >> >> Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( >> >> can you help me ? From reading the code, I can see your concern. And it appears you are correct, because some of the data will be sent to the OS printer buffers, and then it will refuse to accept anymore. Unfortunately, writeArray does not return the num of characters written :{ So application has no idea to how many characters were accepted by the OS. I dont do windoz, so I cant say with absolute certainty what windoz will do with an off-line condition. If you have the source, and can compile, then maybe u can increase the loop count to hit 4hours? From yvespielusenet at free.fr Wed Jun 6 09:53:25 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 17:53:25 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666D10A.8000507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> Message-ID: <1181145205.3407.35.camel@localhost.localdomain> Thank you for your explanation :) This timeout comes when no data has been send to the printer after 40seconds if I well understand. But why there is such a timeout ? If I setthe printer offline while it's printing I mustn't have an exception. I don't understand why the "printer should solv all problems like buffer full" in 40 seconds. If I pause the printer the buffer will not be emptied, isn't it ? I not very familiar with C/C++, but it seem that the exception is thrown only when countWritten == 0, that means no data at all has been sent. So Is my code is good since when I intercept this exception I send all my buffer again. There is no way that the printer receive two times same bytes ? thanks ps: yes the application is running on windows XP since I developpe under Debian Le mercredi 06 juin 2007 ? 11:21 -0400, Uncle George a ?crit : > } > > -------------------------------- > > > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > > > can you help me ? > > > > thank you :) > > > > windoz or linux? ( I guess windoz ) > > for windoz, there appears to be a timeout ( as Comments suggest ) of > about 40seconds. > > while( count > 0 ){ > > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > > /* > > this are 20 * 2 seconds, in this time a printer (or other parallel device) > > should solv all problems like buffer full, etc > > */ > > if(errorCount++ < 20){ > > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > > continue; > > } > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > for linux, there is no implied timeout. > > if( write( fd, bytes, count ) < 0 ) > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Wed Jun 6 10:34:24 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 12:34:24 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181145205.3407.35.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> Message-ID: <4666E210.30507@gatworks.com> yves pielusenet wrote: > Thank you for your explanation :) > This timeout comes when no data has been send to the printer after > 40seconds if I well understand. But why there is such a timeout ? If I > setthe printer offline while it's printing I mustn't have an exception. > I don't understand why the "printer should solv all problems like buffer > full" in 40 seconds. If I pause the printer the buffer will not be > emptied, isn't it ? > > I not very familiar with C/C++, but it seem that the exception is thrown > only when countWritten == 0, that means no data at all has been sent. So > Is my code is good since when I intercept this exception I send all my > buffer again. There is no way that the printer receive two times same > bytes ? More technically, the function call returns and reports that 0 characters was written in this call. when 0 characters are written, it will check how many times 0 characters was written. If it has tried LESS than 20 times(errorCount), it will sleep() and try to write again. After 20 times, it wont sleep, but throw you the exception. Now suppose you are writing a 120 character line. you off-lined/paused your printer. The OS has room for 80 more characters in it's printer buffer. The WriteFile() will have a char count of 120, but on return the countWritten = 80. You still have 40 more characters to print. Since countWritten != 0, the counters: bytes += countWritten; count -= countWritten; get updated, and the Writefile now has a count of 40 characters. Since the printer is off-line, the countwritten is 0. And so the loop continues, till 40 seconds is up. As to why it is this way, i dont know ( not a windoz maven ); Also the sleep(20) in the loop is not so intuitive to suggest 2 seconds of sleep. I would have guessed 20seconds, or 20milliseconds. But go figure. BTW: Since your computer sends you error messages in French, does it curse in English? :)))) From yvespielusenet at free.fr Thu Jun 7 02:27:44 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Thu, 07 Jun 2007 10:27:44 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666E210.30507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> Message-ID: <1181204864.3501.10.camel@localhost.localdomain> Maybe in my case I should re-compile rxtx and change the code. Instead of send an exception I should display a dialog box to ask if it's printer problem or if it should trie to send bytes. Something like : while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } if(displayDialogBox("Try again to send datas ??")){ errorCount = 0; } else{ throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } } Le mercredi 06 juin 2007 ? 12:34 -0400, Uncle George a ?crit : > yves pielusenet wrote: > > Thank you for your explanation :) > > This timeout comes when no data has been send to the printer after > > 40seconds if I well understand. But why there is such a timeout ? If I > > setthe printer offline while it's printing I mustn't have an exception. > > I don't understand why the "printer should solv all problems like buffer > > full" in 40 seconds. If I pause the printer the buffer will not be > > emptied, isn't it ? > > > > I not very familiar with C/C++, but it seem that the exception is thrown > > only when countWritten == 0, that means no data at all has been sent. So > > Is my code is good since when I intercept this exception I send all my > > buffer again. There is no way that the printer receive two times same > > bytes ? > More technically, the function call returns and reports that 0 > characters was written in this call. > when 0 characters are written, it will check how many times 0 characters > was written. If it has tried LESS than 20 times(errorCount), it will > sleep() and try to write again. > After 20 times, it wont sleep, but throw you the exception. > > Now suppose you are writing a 120 character line. you off-lined/paused > your printer. The OS has room for 80 more characters in it's printer > buffer. The WriteFile() will have a char count of 120, but on return the > countWritten = 80. You still have 40 more characters to print. > Since countWritten != 0, the counters: > bytes += countWritten; > count -= countWritten; > get updated, and the Writefile now has a count of 40 characters. Since > the printer is off-line, the countwritten is 0. And so the loop > continues, till 40 seconds is up. > > As to why it is this way, i dont know ( not a windoz maven ); > Also the sleep(20) in the loop is not so intuitive to suggest 2 seconds > of sleep. I would have guessed 20seconds, or 20milliseconds. But go figure. > > BTW: Since your computer sends you error messages in French, does it > curse in English? :)))) > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 06:11:43 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 08:11:43 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181204864.3501.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> Message-ID: <4667F5FF.8070903@gatworks.com> your suggestion appears good. I dont know what displayDialogBox exactly will do, so all I can say it that it looks good. But I'd like to wait 10min before first dialog box And a 5 min wait for every dialog box there after. And since these are custom solution/choices, maybe a more exact explanation of what the issue is. if(errorCount++ < 300){ // wait 10min ( 10min * 60sec / 2 ) Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } if(displayDialogBox("Printer has Paused. Retry sending data?")){ errorCount = 150; // Wait for 5 min thereafter continue; } > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } yves pielusenet wrote: > Maybe in my case I should re-compile rxtx and change the code. Instead > of send an exception I should display a dialog box to ask if it's > printer problem or if it should trie to send bytes. Something like : > > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > > if(displayDialogBox("Try again to send datas ??")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > } > From yvespielusenet at free.fr Thu Jun 7 07:17:21 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Thu, 07 Jun 2007 15:17:21 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4667F5FF.8070903@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <4667F5FF.8070903@gatworks.com> Message-ID: <1181222241.3501.20.camel@localhost.localdomain> thank you :) 'displayDialogBox()' I think doesn't exist. It was just for the example :) But I think It should not be so complicated to display a dialog box under windows with YES/NO buttons. When yes is clicked it return 0 other it returns 1. Le jeudi 07 juin 2007 ? 08:11 -0400, Uncle George a ?crit : > your suggestion appears good. I dont know what displayDialogBox exactly > will do, so all I can say it that it looks good. > > But I'd like to wait 10min before first dialog box And a 5 min wait for > every dialog box there after. And since these are custom > solution/choices, maybe a more exact explanation of what the issue is. > > if(errorCount++ < 300){ // wait 10min ( 10min * 60sec / 2 ) > Sleep( 20 ); /* make a small pause to execute all other requests > in all other threads */ > continue; > } > > if(displayDialogBox("Printer has Paused. Retry sending data?")){ > errorCount = 150; // Wait for 5 min thereafter > continue; > } > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > > yves pielusenet wrote: > > Maybe in my case I should re-compile rxtx and change the code. Instead > > of send an exception I should display a dialog box to ask if it's > > printer problem or if it should trie to send bytes. Something like : > > > > while( count > 0 ){ > > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > > /* > > this are 20 * 2 seconds, in this time a printer (or other parallel device) > > should solv all problems like buffer full, etc > > */ > > if(errorCount++ < 20){ > > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > > continue; > > } > > > > if(displayDialogBox("Try again to send datas ??")){ > > errorCount = 0; > > } > > else{ > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > } > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 07:41:43 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 09:41:43 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181222241.3501.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <4667F5FF.8070903@gatworks.com> <1181222241.3501.20.camel@localhost.localdomain> Message-ID: <46680B17.8050109@gatworks.com> yves pielusenet wrote: > thank you :) > 'displayDialogBox()' I think doesn't exist. It was just for the > example :) too bad. Good luck. From rtrout at webbresearch.com Thu Jun 7 11:23:04 2007 From: rtrout at webbresearch.com (Robert Trout) Date: Thu, 07 Jun 2007 13:23:04 -0400 Subject: [Rxtx] Disconnected PortServer TS causes Java to hang Message-ID: <1181236984.14186.33.camel@sisyphus.DinkumSoftware.com> I'm running Linux with sun's Java 1.4.2, Java comm API 2.0, RXTX 2.0-7pre1, and the RealPort digi driver. "/dev/ttyrp00" is a RealPort device. My Java application never returns from a ComPortIdentifier.getPortIdentifier("/dev/ttyrp00") call while the Digi PortServer TS 4 is disconnected from the network. If I later re-connect the PortServer, the call returns about 30 seconds later (it's like a serial port read or write is blocking until the PortServer is re- connected). With the PortServer disconnected, minicom immediately responds with "cannot open /dev/ttyrp00: No such file or directory". I would like my Java application to behave similarly. That is, respond with an error condition instead of hanging when the PortServer is not connected. Since minicom and Java behave differently, I think this "hanging" behavior may be due to RXTX or Java? Has anyone had a similar issue? Solutions? Suggestions? Thanks, Robert From vicnevicne at gmail.com Thu Jun 7 12:16:02 2007 From: vicnevicne at gmail.com (Vicne) Date: Thu, 07 Jun 2007 20:16:02 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181204864.3501.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> Message-ID: <46684B62.7080802@gmail.com> yves pielusenet wrote: > Maybe in my case I should re-compile rxtx and change the code. Instead > of send an exception I should display a dialog box to ask if it's > printer problem or if it should trie to send bytes. Something like : > > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > > if(displayDialogBox("Try again to send datas ??")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > } > Sorry to step in without a specific solution to your problem, but I wanted to share my feeling regarding this proposal. AFAIK, it's generally considered bad practice to pop-up a prompt from a library. The main reason is that in general use, you can't guarantee that someone is actually present behind the console. Imagine a print server in a machine room, connected to a park of printers. In that case, when one printer fails, the logical behaviour would be to use an other one. If you change RxTx the way you propose, the printer queue will simply be stuck with a useless "Try again to send data ?" prompt until an administrator opens a remote connection to the print server's console and clicks "no". Second, it would create a dependency upon the existence of a graphical console (if you go the graphical "dialogBox" way). On many applications (typically server or embedded ones), the JVM is "headless" and if you try to pop-up a dialog, your app would throw an exception (at best) or just wouldn't display the prompt anywhere... Going the "text console" way is not more reliable, because on graphical environments, the text console is hidden unless explicitly requested. My advice would be to think again and find another solution. Ideas are : - make the number of retries a parameter so that you can tune it to what you think is reasonable - throw a more specific exception when the number of retries has been reached, so that a specific prompt can be shown at a higher level Anyway, if you feel that the prompt is the way to go in your case, I would at least make that prompt conditional. The least intrusive way would probably be using a system property, like if("true".equals(System.getProperty("org.rxtx.usePrompt")) && displayDialogBox("Retry sending data ?")){ errorCount = 0; } else{ throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } By default, the behaviour would remain as it is now, but you could force the prompts by defining the property at VM launch if desired. (for example : java.exe -Dorg.rxtx.usePrompt=true myApp) Also, you seemed to say you wanted the printer to start again exactly where is stopped. It would indeed be the best way when the printer is put offline for a few seconds. On the other hand, if the printer is turned off (or the printer runs out of paper, or someone steps on the mains cable), then the only way to go back to a "stable" situation would be by printing the item (page, label, etc.) again from scratch... Just my two cents. Vicne PS : By the way, the dialog box thing is very platform dependant on the C-side, and I think the simplest way would probably be to bridge it to a Java call where you can implement it like you proposed : public boolean displayDialogBox(prompt) { return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); } From netbeans at gatworks.com Thu Jun 7 14:08:24 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 16:08:24 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46684B62.7080802@gmail.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> Message-ID: <466865B8.4060004@gatworks.com> My feeling is that the code that was suggested was for his environs ( his shop ). The issue here is that after a 40+ second wait, an exception will be thrown. But you really dont have a way of 'cancelling' all the WriteFiles() that have already occured before the exception so that your writeArray and the Commapi can backtrack to a position in which they are in sync. The main ( really mine ) concern is not to lose data, or replicate data. After 40seconds, 300 seconds, 55min, no matter how long, data should not be lost or duplicated. But as soon as the exception is thrown, that possibility exists. Maybe an event should be thrown instead? Vicne wrote: > yves pielusenet wrote: >> Maybe in my case I should re-compile rxtx and change the code. Instead >> of send an exception I should display a dialog box to ask if it's >> printer problem or if it should trie to send bytes. Something like : >> >> while( count > 0 ){ >> if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ >> /* >> this are 20 * 2 seconds, in this time a printer (or other parallel device) >> should solv all problems like buffer full, etc >> */ >> if(errorCount++ < 20){ >> Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ >> continue; >> } >> >> if(displayDialogBox("Try again to send datas ??")){ >> errorCount = 0; >> } >> else{ >> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >> break; >> } >> } >> > > Sorry to step in without a specific solution to your problem, but I > wanted to share my feeling regarding this proposal. AFAIK, it's > generally considered bad practice to pop-up a prompt from a library. > The main reason is that in general use, you can't guarantee that > someone is actually present behind the console. Imagine a print server > in a machine room, connected to a park of printers. In that case, when > one printer fails, the logical behaviour would be to use an other one. > If you change RxTx the way you propose, the printer queue will simply be > stuck with a useless "Try again to send data ?" prompt until an > administrator opens a remote connection to the print server's console > and clicks "no". > Second, it would create a dependency upon the existence of a > graphical console (if you go the graphical "dialogBox" way). On many > applications (typically server or embedded ones), the JVM is "headless" > and if you try to pop-up a dialog, your app would throw an exception (at > best) or just wouldn't display the prompt anywhere... Going the "text > console" way is not more reliable, because on graphical environments, > the text console is hidden unless explicitly requested. > > My advice would be to think again and find another solution. Ideas are : > - make the number of retries a parameter so that you can tune it to what > you think is reasonable > - throw a more specific exception when the number of retries has been > reached, so that a specific prompt can be shown at a higher level > > Anyway, if you feel that the prompt is the way to go in your case, I > would at least make that prompt conditional. The least intrusive way > would probably be using a system property, like > > if("true".equals(System.getProperty("org.rxtx.usePrompt")) > && displayDialogBox("Retry sending data ?")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > > > By default, the behaviour would remain as it is now, but you could > force the prompts by defining the property at VM launch if desired. (for > example : java.exe -Dorg.rxtx.usePrompt=true myApp) > > > Also, you seemed to say you wanted the printer to start again > exactly where is stopped. It would indeed be the best way when the > printer is put offline for a few seconds. On the other hand, if the > printer is turned off (or the printer runs out of paper, or someone > steps on the mains cable), then the only way to go back to a "stable" > situation would be by printing the item (page, label, etc.) again from > scratch... > > > Just my two cents. > > > Vicne > > PS : By the way, the dialog box thing is very platform dependant on the > C-side, and I think the simplest way would probably be to bridge it to a > Java call where you can implement it like you proposed : > > public boolean displayDialogBox(prompt) { > return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", > JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); > } > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Thu Jun 7 17:48:11 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 Jun 2007 17:48:11 -0600 (MDT) Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <466865B8.4060004@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> Message-ID: An event is possible. I'm amazed this is the largest problem encountered while using the parallel code. How would the write ever exit if we throw events? Isn't this going to lead to hung applications? On Thu, 7 Jun 2007, Uncle George wrote: > My feeling is that the code that was suggested was for his environs ( > his shop ). > > The issue here is that after a 40+ second wait, an exception will be > thrown. But you really dont have a way of 'cancelling' all the > WriteFiles() that have already occured before the exception so that your > writeArray and the Commapi can backtrack to a position in which they are > in sync. > > The main ( really mine ) concern is not to lose data, or replicate data. > After 40seconds, 300 seconds, 55min, no matter how long, data should > not be lost or duplicated. But as soon as the exception is thrown, that > possibility exists. > > Maybe an event should be thrown instead? > > Vicne wrote: >> yves pielusenet wrote: >>> Maybe in my case I should re-compile rxtx and change the code. Instead >>> of send an exception I should display a dialog box to ask if it's >>> printer problem or if it should trie to send bytes. Something like : >>> >>> while( count > 0 ){ >>> if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ >>> /* >>> this are 20 * 2 seconds, in this time a printer (or other parallel device) >>> should solv all problems like buffer full, etc >>> */ >>> if(errorCount++ < 20){ >>> Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ >>> continue; >>> } >>> >>> if(displayDialogBox("Try again to send datas ??")){ >>> errorCount = 0; >>> } >>> else{ >>> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >>> break; >>> } >>> } >>> >> >> Sorry to step in without a specific solution to your problem, but I >> wanted to share my feeling regarding this proposal. AFAIK, it's >> generally considered bad practice to pop-up a prompt from a library. >> The main reason is that in general use, you can't guarantee that >> someone is actually present behind the console. Imagine a print server >> in a machine room, connected to a park of printers. In that case, when >> one printer fails, the logical behaviour would be to use an other one. >> If you change RxTx the way you propose, the printer queue will simply be >> stuck with a useless "Try again to send data ?" prompt until an >> administrator opens a remote connection to the print server's console >> and clicks "no". >> Second, it would create a dependency upon the existence of a >> graphical console (if you go the graphical "dialogBox" way). On many >> applications (typically server or embedded ones), the JVM is "headless" >> and if you try to pop-up a dialog, your app would throw an exception (at >> best) or just wouldn't display the prompt anywhere... Going the "text >> console" way is not more reliable, because on graphical environments, >> the text console is hidden unless explicitly requested. >> >> My advice would be to think again and find another solution. Ideas are : >> - make the number of retries a parameter so that you can tune it to what >> you think is reasonable >> - throw a more specific exception when the number of retries has been >> reached, so that a specific prompt can be shown at a higher level >> >> Anyway, if you feel that the prompt is the way to go in your case, I >> would at least make that prompt conditional. The least intrusive way >> would probably be using a system property, like >> >> if("true".equals(System.getProperty("org.rxtx.usePrompt")) >> && displayDialogBox("Retry sending data ?")){ >> errorCount = 0; >> } >> else{ >> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >> break; >> } >> >> >> By default, the behaviour would remain as it is now, but you could >> force the prompts by defining the property at VM launch if desired. (for >> example : java.exe -Dorg.rxtx.usePrompt=true myApp) >> >> >> Also, you seemed to say you wanted the printer to start again >> exactly where is stopped. It would indeed be the best way when the >> printer is put offline for a few seconds. On the other hand, if the >> printer is turned off (or the printer runs out of paper, or someone >> steps on the mains cable), then the only way to go back to a "stable" >> situation would be by printing the item (page, label, etc.) again from >> scratch... >> >> >> Just my two cents. >> >> >> Vicne >> >> PS : By the way, the dialog box thing is very platform dependant on the >> C-side, and I think the simplest way would probably be to bridge it to a >> Java call where you can implement it like you proposed : >> >> public boolean displayDialogBox(prompt) { >> return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", >> JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); >> } >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 19:18:51 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 21:18:51 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> Message-ID: <4668AE7B.3060409@gatworks.com> The UNIX version of writeArray is not too great either. It is possible that the write will only process some of the bytes. #else if( write( fd, bytes, count ) < 0 ) throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); #endif -------------------------------- Maybe it might be better to have the native function inform the caller of the # of characters written, then the commapi/output-buffer can be modified to reflect the #of chars written. If an exception is to be thrown, for too many loops of chars written == 0, then exception wont affect the state of the output buffer. Then a ParallelPort.restart() can be called to resume printing whats in the buffer. Trent Jarvi wrote: > An event is possible. I'm amazed this is the largest problem encountered > while using the parallel code. > > How would the write ever exit if we throw events? Isn't this going to > lead to hung applications? Sure. If you dont time out, then there is nothing that will force an EXIT from the write(). Issue is what has the OS done with the write. > > On Thu, 7 Jun 2007, Uncle George wrote: > >> My feeling is that the code that was suggested was for his environs ( >> his shop ). From yvespielusenet at free.fr Fri Jun 8 01:09:01 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Fri, 08 Jun 2007 09:09:01 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4668AE7B.3060409@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> Message-ID: <1181286541.3674.10.camel@localhost.localdomain> It is not possible that the rxtx java method write(byte[], int offset, int length) return anint which contains the number of byte really send to the printer instead of an exception ? So this is the programm which will see if all bytes have been sent. If not it can retry to send the unsended bytes. -------------------------------------------------------- int sended = 0; while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ sended += countWritten; /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } return sended; /*throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break;*/ } ... ... return countWritten; ------------------------------------------------ Le jeudi 07 juin 2007 ? 21:18 -0400, Uncle George a ?crit : > The UNIX version of writeArray is not too great either. It is possible > that the write will only process some of the bytes. > > #else > if( write( fd, bytes, count ) < 0 ) > throw_java_exception_system_msg( env, IO_EXCEPTION, > "writeArray" ); > #endif > -------------------------------- > > Maybe it might be better to have the native function inform the caller > of the # of characters written, then the commapi/output-buffer can be > modified to reflect the #of chars written. If an exception is to be > thrown, for too many loops of chars written == 0, then exception wont > affect the state of the output buffer. Then a ParallelPort.restart() can > be called to resume printing whats in the buffer. > > > Trent Jarvi wrote: > > An event is possible. I'm amazed this is the largest problem encountered > > while using the parallel code. > > > > How would the write ever exit if we throw events? Isn't this going to > > lead to hung applications? > Sure. If you dont time out, then there is nothing that will force an > EXIT from the write(). Issue is what has the OS done with the write. > > > > On Thu, 7 Jun 2007, Uncle George wrote: > > > >> My feeling is that the code that was suggested was for his environs ( > >> his shop ). > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Fri Jun 8 03:45:00 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 11:45:00 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181286541.3674.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> Message-ID: <20070608094500.GC21069@elberon.bln.de.ingenico.com> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > It is not possible that the rxtx java method write(byte[], int offset, > int length) return anint which contains the number of byte really send > to the printer instead of an exception ? > So this is the programm which will see if all bytes have been sent. If > not it can retry to send the unsended bytes. I think write() is void because in Java people love to do this since OutputStream :-) Of course on such interfaces you cannot implement something nice. If you would have a int write, you would not implement the interface and no applications expecting this interface would link/work/compile. oki, Steffen P.S.: (OT) If you propose not to implement the Java interfaces (especially not on JNI level), maybe optionally offering a wrapper that removes e.g. the write return value and so on to downgrade the powerful classic old POSIX read/write style to the modern limited Java style, then I agree :-) Same for read. Instead of things like "int avialable()" it is more powerful to have an approach as select(2) offers (to guarante the caller that read/write will not block [nothing else make sense anyway IMHO] but may read/write less bytes then requested). The caller gets full control and the higher level protocols can care about timeouts, invoking read in some loops and/or implement retransmission. On top of such an implementation, where everything is controlled, defined, guaranteed and reliable, someone could use an InputStream or OutputStream style interface. Or even better: don't use them at all :) just BTW :-) St. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From yvespielusenet at free.fr Fri Jun 8 05:52:45 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Fri, 08 Jun 2007 13:52:45 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <20070608094500.GC21069@elberon.bln.de.ingenico.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> Message-ID: <1181303565.11203.3.camel@localhost.localdomain> So maybe a better way should be to create a new Exception class which has a method "int getWrittenByte()". So the Exception should be use to send again bytes which are not printed yet. yves Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : > * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > > It is not possible that the rxtx java method write(byte[], int offset, > > int length) return anint which contains the number of byte really send > > to the printer instead of an exception ? > > So this is the programm which will see if all bytes have been sent. If > > not it can retry to send the unsended bytes. > > I think write() is void because in Java people love to do this > since OutputStream :-) Of course on such interfaces you cannot > implement something nice. If you would have a int write, you > would not implement the interface and no applications expecting > this interface would link/work/compile. > > oki, > > Steffen > > P.S.: (OT) > If you propose not to implement the Java interfaces (especially > not on JNI level), maybe optionally offering a wrapper that > removes e.g. the write return value and so on to downgrade the > powerful classic old POSIX read/write style to the modern limited > Java style, then I agree :-) Same for read. Instead of things > like "int avialable()" it is more powerful to have an approach as > select(2) offers (to guarante the caller that read/write will not > block [nothing else make sense anyway IMHO] but may read/write > less bytes then requested). The caller gets full control and the > higher level protocols can care about timeouts, invoking read in > some loops and/or implement retransmission. On top of such an > implementation, where everything is controlled, defined, > guaranteed and reliable, someone could use an InputStream or > OutputStream style interface. Or even better: don't use them at > all :) just BTW :-) > St. > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > 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. > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > 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. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Fri Jun 8 06:46:21 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 08:46:21 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181303565.11203.3.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> Message-ID: <46694F9D.5080501@gatworks.com> It seems that with outputstream.write(b[]), you become terribly uncoordinated as soon as an exception is thrown. Docs do not say what happens to the data. Yet from a practicable point of view, one would like to know if the write was accepted in-full, or rejected before any writes. There are no in betweens, as partial writes are not reportable. So for an outputstream.write(), in order for it to return, the full write request has to be taken, and stored in an internal output buffer. If there is no room, the write() is suspended, till there is room. Or throw's an IOException( "no room in buffer") ; As the select() loop for write reports buffer room avail, then more of the internal buffer is sent to the printer. yves pielusenet wrote: > So maybe a better way should be to create a new Exception class which > has a method "int getWrittenByte()". So the Exception should be use to > send again bytes which are not printed yet. > > yves > > Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : >> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: >>> It is not possible that the rxtx java method write(byte[], int offset, >>> int length) return anint which contains the number of byte really send >>> to the printer instead of an exception ? >>> So this is the programm which will see if all bytes have been sent. If >>> not it can retry to send the unsended bytes. >> I think write() is void because in Java people love to do this >> since OutputStream :-) Of course on such interfaces you cannot >> implement something nice. If you would have a int write, you >> would not implement the interface and no applications expecting >> this interface would link/work/compile. >> >> oki, >> >> Steffen >> >> P.S.: (OT) >> If you propose not to implement the Java interfaces (especially >> not on JNI level), maybe optionally offering a wrapper that >> removes e.g. the write return value and so on to downgrade the >> powerful classic old POSIX read/write style to the modern limited >> Java style, then I agree :-) Same for read. Instead of things >> like "int avialable()" it is more powerful to have an approach as >> select(2) offers (to guarante the caller that read/write will not >> block [nothing else make sense anyway IMHO] but may read/write >> less bytes then requested). The caller gets full control and the >> higher level protocols can care about timeouts, invoking read in >> some loops and/or implement retransmission. On top of such an >> implementation, where everything is controlled, defined, >> guaranteed and reliable, someone could use an InputStream or >> OutputStream style interface. Or even better: don't use them at >> all :) just BTW :-) >> St. >> >> About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. >> 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. >> >> About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. >> 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. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From Steffen.DETTMER at ingenico.com Fri Jun 8 08:12:18 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 16:12:18 +0200 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <46694F9D.5080501@gatworks.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: <20070608141218.GE21069@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 08:46 -0400: > It seems that with outputstream.write(b[]), you become terribly > uncoordinated as soon as an exception is thrown. Docs do not say what > happens to the data. (yes, so avoiding it seems to be good :)) > Yet from a practicable point of view, one would like to know if the > write was accepted in-full, or rejected before any writes. There are no > in betweens, as partial writes are not reportable. (which is an artificial API limitation. I never understood how this happend when they invented JDK because the well-known BSD socket API and thus [probably] WinSock does this correct, but anyway) > So for an outputstream.write(), in order for it to return, the full > write request has to be taken, and stored in an internal output buffer. > If there is no room, the write() is suspended, till there is room. Or > throw's an IOException( "no room in buffer") ; As the select() loop for > write reports buffer room avail, then more of the internal buffer is > sent to the printer. yes, might be good in case of a printer. May be horrible in case of PPP/TCP or some other transmission control protocol which may e.g. repeat data or even omit parts of it (e.g. internet realtime radio station broadcasting)... So I think the idea of "int write" (e.g. BSD sockets, linux files and so on) still is the best. A clean API / implementation should guarantee and allow implementations (users) to rely on that; assumptions and automatic background-sending and so on may look pragmatic and may even work on the first look, but may fail in other situations. BTW, if e.g. BSD socket API is known, why not simply copy it (until something better is invented :)) instead of fiddling around with JDK APIs? anyway, have a nice weekend everyone :-) oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Fri Jun 8 08:55:56 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 10:55:56 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070608141218.GE21069@elberon.bln.de.ingenico.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> Message-ID: <46696DFC.7000801@gatworks.com> >> write reports buffer room avail, then more of the internal buffer is >> sent to the printer. > > yes, might be good in case of a printer. May be horrible in case > of PPP/TCP or some other transmission control protocol which > may e.g. repeat data or even omit parts of it (e.g. internet > realtime radio station broadcasting)... So I think the idea of > "int write" (e.g. BSD sockets, linux files and so on) still is > the best. A clean API / implementation should guarantee and allow > implementations (users) to rely on that; assumptions and > automatic background-sending and so on may look pragmatic and may > even work on the first look, but may fail in other situations. > BTW, if e.g. BSD socket API is known, why not simply copy it > (until something better is invented :)) instead of fiddling > around with JDK APIs? But we were talking about the Parallel Port, and the transmission of data over the commapi/parallel-port schema. There isn't much in bi-directional software communication. Its a simple write one byte at a time interface. I'm not looking to change the comm-api. I'm just looking to alter the interaction between the Native ParallelPort functions, and the java ParallelPort functions that call them. This might be more readily doable than to get a committee to re-specify java-API specs. BTW: Whats is off-topic? ( help: not looking for def of off-topic ) From j.kenneth.gentle at acm.org Fri Jun 8 08:58:59 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Fri, 08 Jun 2007 10:58:59 -0400 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <20070608141218.GE21069@elberon.bln.de.ingenico.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> Message-ID: <200706081459.l58Ex5rA019991@qbang.org> Perhaps it is a bit late to jump in on this one, but here goes anyway. If the solutions all seem to "break" the contract with "java.io.outputstream", then, as noted, that may not be the appropriate contract. At the risk of being heretical, JDK1.4 introduced the "nio" package to address some of the compatibility issues with C apis mentioned in previous posts. The interface "java.nio.channels.WriteableByteChannel" defines the following single method: int write(ByteBuffer source); int, strangely enough, is the actual number of bytes written. So, if RXTX as written, against the JavaCOMM api and OutputStream, doesn't do what we want, how about writing a different set of bindings using the java.nio classes and as much of the underlying native code as possible. Note that just because the java.nio.channels.WriteableByteChannel sends back a result, OutputStream.write doesn't have to - and they could both call the same underlying native code. My 2 cents - maybe not worth even that... Ken From netbeans at gatworks.com Fri Jun 8 10:37:28 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 12:37:28 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <200706081459.l58Ex5rA019991@qbang.org> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> Message-ID: <466985C8.8000505@gatworks.com> Ken Gentle wrote: > Perhaps it is a bit late to jump in on this one, but here goes anyway. Common in, the waters fine. > > If the solutions all seem to "break" the contract with > "java.io.outputstream", then, as noted, that may not be the > appropriate contract. > How would the contract be broken? The machinery underneath is handling the contract. From j.kenneth.gentle at acm.org Fri Jun 8 10:48:01 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Fri, 08 Jun 2007 12:48:01 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466985C8.8000505@gatworks.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> Message-ID: <200706081648.l58Gm7YA022904@qbang.org> At 12:37 2007-06-08, you wrote: >Ken Gentle wrote: > > > > If the solutions all seem to "break" the contract with > > "java.io.outputstream", then, as noted, that may not be the > > appropriate contract. > > >How would the contract be broken? The machinery underneath is handling >the contract. It seems that a lot of the discussion has been about not only the timeout and being able to adjust it in the "machinery layer", but also about knowing in the Java layer, in the event of a timeout or exception, how many characters have been written to the device. An OutputStream won't ever do this with out an extension and including a return value "breaks" the contract, right? So, go with a Java IO api that *does* return the number of bytes written, out of the NIO package. I know it doesn't allow for a strict implementation of the JavaCOMM API - however, using NIO classes in place of the IO classes isn't that big a break and would allow those applications that need such information a way to get it. Maybe I'm misunderstanding the problem... Ken From netbeans at gatworks.com Fri Jun 8 11:24:14 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 13:24:14 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <200706081648.l58Gm7YA022904@qbang.org> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> Message-ID: <466990BE.7040100@gatworks.com> Ken Gentle wrote: An > OutputStream won't ever do this with out an extension and including a > return value "breaks" the contract, right? > i was not thinking of change the API to OutputSream. Are there specs for how output stream should work internally? for instance: String data = "Hello this is a line of data"; Outputstream.write( data.getbytes() ); ParallelPort.suspend(); int free = ParallelPort.getoutputbufferfree(); There is a symbiotic relationship between outputstream and the functionality of ParallelPort. From Steffen.DETTMER at ingenico.com Fri Jun 8 11:15:39 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 19:15:39 +0200 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <200706081459.l58Ex5rA019991@qbang.org> References: <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> Message-ID: <20070608171539.GK21069@elberon.bln.de.ingenico.com> * Ken Gentle wrote on Fri, Jun 08, 2007 at 10:58 -0400: > If the solutions all seem to "break" the contract with > "java.io.outputstream", then, as noted, that may not be the > appropriate contract. > > At the risk of being heretical, JDK1.4 introduced the "nio" package > to address some of the compatibility issues with C apis mentioned in > previous posts. The interface > "java.nio.channels.WriteableByteChannel" defines the following single method: > > int write(ByteBuffer source); > > int, strangely enough, is the actual number of bytes written. Yes, AFAIK one of the motivations for the NIO interface was, that the JDK-1.3 APIs (InputStream, e.g.) were not powerfull enough, especially for multi-connection-TCP servers or so. I don't know much about it but I've heard of a project where NIO usage was removed because of stability issues in multi-threaded environments and performance limitations under some circumstances. IIRC the "nio.ByteBuffer" is something very special (namely something you cannot implement in Java, it is "magic" or part of the language itself). Not sure if this is such a great idea (but for performance in the end sometimes heavy prices must be paid) :) > So, if RXTX as written, against the JavaCOMM api and OutputStream, > doesn't do what we want, how about writing a different set of > bindings using the java.nio classes and as much of the underlying > native code as possible. Yes, this would be an idea: use a full-featured interface on JNI, and, if wanted, deliver some wrappers converting this to a less-featured Java-compliant interface. However, powerful things as e.g. "select" are difficult to "emulate" if you are e.g. on some (older?) windows. But if you expose the full-featured APIs, you need to emulate them full-featured, theoretically. In the end it depends what you do on the serial line. If you just want to talk to a modem, then you may not need precise timeouts. But if you need to implement complexer protocols which define response times and timeouts, you may quickly get into difficulties. For instance, AFAIK, rxtx 1.7.2 (?) for windows is very messy with timeouts (there is a maximum, higher values are truncated; resolution is 100ms only; the function may take up to twice the timeout because internally it may be called twice). Probably for most people this is OK, but probably not for all. But having precise timeouts should be OK for all :-) Well, in the end it is nice to wish but somewhat hard to implement (many platforms, connections, USB, BlueTooth, whatever). oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Steffen.DETTMER at ingenico.com Fri Jun 8 11:04:22 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 19:04:22 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <46696DFC.7000801@gatworks.com> References: <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <46696DFC.7000801@gatworks.com> Message-ID: <20070608170422.GJ21069@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 10:55 -0400: > > BTW, if e.g. BSD socket API is known, why not simply copy it > > (until something better is invented :)) instead of fiddling > > around with JDK APIs? > > But we were talking about the Parallel Port, and the > transmission of data over the commapi/parallel-port schema. > There isn't much in bi-directional software communication. Its > a simple write one byte at a time interface. First, there are things like PLIP (http://en.wikipedia.org/wiki/Plip) - well, probably not widely used, sure ;) Second, I think if there is a good simple API known to support all that (with known "best practices") or so and there is no forcing need to invent a new one, why not simply using it? > I'm not looking to change the comm-api. I'm just looking to > alter the interaction between the Native ParallelPort > functions, and the java ParallelPort functions that call them. Ahh, yes. I think this is what I tried to ask. Having an usable JNI interface and on top (in pure java) some wrapper to InputStream or whatever could be done (e.g. by ignoring the return value of write or throwing if != length). Developers could then use the full-featured (non-JAVA-standard) API or select among various wrappers (as InputStream). > This might be more readily doable than to get a committee to > re-specify java-API specs. Yes, of course. I'm afraid that the Java APIs change regularily, but still yet with limited success it seems, so maybe they get it in one of the next iterations; who knows, maybe Java-9 has a BSD-like socket API :) SCNR. > BTW: Whats is off-topic? ( help: not looking for def of > off-topic ) I think I started some "re-specify java-API specs" which was OT probably. oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From lists at iDIAcomputing.com Fri Jun 8 18:48:54 2007 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Fri, 08 Jun 2007 20:48:54 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46684B62.7080802@gmail.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> Message-ID: <4669F8F6.3040101@iDIAcomputing.com> Vicne wrote: > Sorry to step in without a specific solution to your problem, but I > wanted to share my feeling regarding this proposal. AFAIK, it's > generally considered bad practice to pop-up a prompt from a library. ... > > My advice would be to think again and find another solution. Ideas are : > - make the number of retries a parameter so that you can tune it to what > you think is reasonable > - throw a more specific exception when the number of retries has been > reached, so that a specific prompt can be shown at a higher level You could also allow the client code to register a callback class which returns a boolean indicating whether to retry or cancel. This callback class could pop up a dialog, if appropriate, or follow some preset policy, or.... - George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From joachim at buechse.ch Sat Jun 9 09:43:16 2007 From: joachim at buechse.ch (Joachim Buechse) Date: Sat, 9 Jun 2007 17:43:16 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46694F9D.5080501@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: You should not forget, that in the case of an exception it may not even be known what happened to the data. You have a kernel buffer, outgoing chip buffer, incoming chip buffer, etc. So of course, it would be nice to know up to which point data was correctly processed, but this feedback does not exist on the hardware or protocol level and hence can in general not be magicly created on the software level... Regards, Joachim On 08.06.2007, at 14:46, Uncle George wrote: > It seems that with outputstream.write(b[]), you become terribly > uncoordinated as soon as an exception is thrown. Docs do not say what > happens to the data. > > Yet from a practicable point of view, one would like to know if the > write was accepted in-full, or rejected before any writes. There > are no > in betweens, as partial writes are not reportable. > > So for an outputstream.write(), in order for it to return, the full > write request has to be taken, and stored in an internal output > buffer. > If there is no room, the write() is suspended, till there is room. Or > throw's an IOException( "no room in buffer") ; As the select() loop > for > write reports buffer room avail, then more of the internal buffer is > sent to the printer. > > > > yves pielusenet wrote: >> So maybe a better way should be to create a new Exception class which >> has a method "int getWrittenByte()". So the Exception should be >> use to >> send again bytes which are not printed yet. >> >> yves >> >> Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : >>> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: >>>> It is not possible that the rxtx java method write(byte[], int >>>> offset, >>>> int length) return anint which contains the number of byte >>>> really send >>>> to the printer instead of an exception ? >>>> So this is the programm which will see if all bytes have been >>>> sent. If >>>> not it can retry to send the unsended bytes. >>> I think write() is void because in Java people love to do this >>> since OutputStream :-) Of course on such interfaces you cannot >>> implement something nice. If you would have a int write, you >>> would not implement the interface and no applications expecting >>> this interface would link/work/compile. >>> >>> oki, >>> >>> Steffen >>> >>> P.S.: (OT) >>> If you propose not to implement the Java interfaces (especially >>> not on JNI level), maybe optionally offering a wrapper that >>> removes e.g. the write return value and so on to downgrade the >>> powerful classic old POSIX read/write style to the modern limited >>> Java style, then I agree :-) Same for read. Instead of things >>> like "int avialable()" it is more powerful to have an approach as >>> select(2) offers (to guarante the caller that read/write will not >>> block [nothing else make sense anyway IMHO] but may read/write >>> less bytes then requested). The caller gets full control and the >>> higher level protocols can care about timeouts, invoking read in >>> some loops and/or implement retransmission. On top of such an >>> implementation, where everything is controlled, defined, >>> guaranteed and reliable, someone could use an InputStream or >>> OutputStream style interface. Or even better: don't use them at >>> all :) just BTW :-) >>> St. >>> >>> About Ingenico Throughout the world businesses rely on Ingenico >>> for secure and expedient electronic transaction acceptance. >>> Ingenico products leverage proven technology, established >>> standards and unparalleled ergonomics to provide optimal >>> reliability, versatility and usability. This comprehensive range >>> of products is complemented by a global array of services and >>> partnerships, enabling businesses in a number of vertical sectors >>> to accept transactions anywhere their business takes them. >>> 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. >>> >>> About Ingenico Throughout the world businesses rely on Ingenico >>> for secure and expedient electronic transaction acceptance. >>> Ingenico products leverage proven technology, established >>> standards and unparalleled ergonomics to provide optimal >>> reliability, versatility and usability. This comprehensive range >>> of products is complemented by a global array of services and >>> partnerships, enabling businesses in a number of vertical sectors >>> to accept transactions anywhere their business takes them. >>> 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. >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx 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 yvespielusenet at free.fr Mon Jun 11 03:15:12 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Mon, 11 Jun 2007 11:15:12 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: <1181553312.8335.14.camel@localhost.localdomain> So can someone tell a solution for my problem :( Must I say to the user to not put the printer off-line ? I can't since he has to do some pauses, verify print, paper conditioning etc... How do other people ? Before I use the parport librarry to read port status : http://www.geocities.com/Juanga69/parport/ (which doesn't work on windows XP) And I send data into the file LPT1 I use to have no problem when printer was disabled. thanks -- yves piel Le samedi 09 juin 2007 ? 17:43 +0200, Joachim Buechse a ?crit : > You should not forget, that in the case of an exception it may not > even be known what happened to the data. > > You have a kernel buffer, outgoing chip buffer, incoming chip buffer, > etc. So of course, it would be nice to know up to which point data > was correctly processed, but this feedback does not exist on the > hardware or protocol level and hence can in general not be magicly > created on the software level... > > Regards, > Joachim > > On 08.06.2007, at 14:46, Uncle George wrote: > > > It seems that with outputstream.write(b[]), you become terribly > > uncoordinated as soon as an exception is thrown. Docs do not say what > > happens to the data. > > > > Yet from a practicable point of view, one would like to know if the > > write was accepted in-full, or rejected before any writes. There > > are no > > in betweens, as partial writes are not reportable. > > > > So for an outputstream.write(), in order for it to return, the full > > write request has to be taken, and stored in an internal output > > buffer. > > If there is no room, the write() is suspended, till there is room. Or > > throw's an IOException( "no room in buffer") ; As the select() loop > > for > > write reports buffer room avail, then more of the internal buffer is > > sent to the printer. > > > > > > > > yves pielusenet wrote: > >> So maybe a better way should be to create a new Exception class which > >> has a method "int getWrittenByte()". So the Exception should be > >> use to > >> send again bytes which are not printed yet. > >> > >> yves > >> > >> Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : > >>> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > >>>> It is not possible that the rxtx java method write(byte[], int > >>>> offset, > >>>> int length) return anint which contains the number of byte > >>>> really send > >>>> to the printer instead of an exception ? > >>>> So this is the programm which will see if all bytes have been > >>>> sent. If > >>>> not it can retry to send the unsended bytes. > >>> I think write() is void because in Java people love to do this > >>> since OutputStream :-) Of course on such interfaces you cannot > >>> implement something nice. If you would have a int write, you > >>> would not implement the interface and no applications expecting > >>> this interface would link/work/compile. > >>> > >>> oki, > >>> > >>> Steffen > >>> > >>> P.S.: (OT) > >>> If you propose not to implement the Java interfaces (especially > >>> not on JNI level), maybe optionally offering a wrapper that > >>> removes e.g. the write return value and so on to downgrade the > >>> powerful classic old POSIX read/write style to the modern limited > >>> Java style, then I agree :-) Same for read. Instead of things > >>> like "int avialable()" it is more powerful to have an approach as > >>> select(2) offers (to guarante the caller that read/write will not > >>> block [nothing else make sense anyway IMHO] but may read/write > >>> less bytes then requested). The caller gets full control and the > >>> higher level protocols can care about timeouts, invoking read in > >>> some loops and/or implement retransmission. On top of such an > >>> implementation, where everything is controlled, defined, > >>> guaranteed and reliable, someone could use an InputStream or > >>> OutputStream style interface. Or even better: don't use them at > >>> all :) just BTW :-) > >>> St. > >>> > >>> About Ingenico Throughout the world businesses rely on Ingenico > >>> for secure and expedient electronic transaction acceptance. > >>> Ingenico products leverage proven technology, established > >>> standards and unparalleled ergonomics to provide optimal > >>> reliability, versatility and usability. This comprehensive range > >>> of products is complemented by a global array of services and > >>> partnerships, enabling businesses in a number of vertical sectors > >>> to accept transactions anywhere their business takes them. > >>> 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. > >>> > >>> About Ingenico Throughout the world businesses rely on Ingenico > >>> for secure and expedient electronic transaction acceptance. > >>> Ingenico products leverage proven technology, established > >>> standards and unparalleled ergonomics to provide optimal > >>> reliability, versatility and usability. This comprehensive range > >>> of products is complemented by a global array of services and > >>> partnerships, enabling businesses in a number of vertical sectors > >>> to accept transactions anywhere their business takes them. > >>> 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. > >>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx 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 > From Steffen.DETTMER at ingenico.com Mon Jun 11 03:56:18 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 11:56:18 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466990BE.7040100@gatworks.com> References: <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> Message-ID: <20070611095618.GA10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 13:24 -0400: > i was not thinking of change the API to OutputSream. Then I think either someone uses OutputStream (and has no reliable information about incomplete writes) or someone uses somethink else. > Are there specs for how output stream should work internally? > > for instance: > String data = "Hello this is a line of data"; > Outputstream.write( data.getbytes() ); > ParallelPort.suspend(); > int free = ParallelPort.getoutputbufferfree(); > > There is a symbiotic relationship between outputstream and the > functionality of ParallelPort. If you need OutputStream "plus something else", in short you're needing "something else". Personally I dislike the code above a lot. The stream "looks" like if it would be an OutputStream, but in fact it isn't. You need to call getoutputbufferfree later to check if write succeeded (but OutputStream promises that write succeedes synchronous, blocking, or throws an exception). So it is not an OutputStream. No application written for OutputStreams would work without change (because it won't know getoutputbufferfree at all). It is not abstracted from ParallelPort. I think this would be wrong. Then I think an alternative interface instead is better. Let's assume we had some "connection" (to distinguish between OutputStreams and Channels). Then why not working as on a file handle in POSIX: do { // ... select maybe using timer ... readyForWrite = ... if (readyForWrite) { int writtenBytes = connection.write(toWrite); toWrite.remove(0, writtenBytes); } while(readyForWrite && toWrite.length > 0); I think, having such a write isn't the big problem. I think, the difficult thing is around "select" - however this would look like. It should be OO, typesafe, performant, supporting multiple connections/channels/streams in various modes and should be orthogonal to other functionalities. Of course, this heavily depends on what the application is doing; for a simple situation (like reading a small, mandatory file from a local disk) this would be to uncomfortable (and offering unneeded features only). just BTW :) oki, Steffen -- // Modeline for VIM. Please don't remove. // (Help: autoindent, expandtab, shiftwidth=4, tabstop=4, textwidth=75) // vi: set ai et sw=4 ts=4 tw=75 ft=java: About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Mon Jun 11 05:38:33 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 07:38:33 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611095618.GA10821@elberon.bln.de.ingenico.com> References: <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> Message-ID: <466D3439.4020805@gatworks.com> Steffen DETTMER wrote: > (but OutputStream promises that write > succeedes synchronous, blocking, or throws an exception). Where is it so written? From Steffen.DETTMER at ingenico.com Mon Jun 11 06:36:50 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 14:36:50 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466D3439.4020805@gatworks.com> References: <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> <466D3439.4020805@gatworks.com> Message-ID: <20070611123650.GI10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Mon, Jun 11, 2007 at 07:38 -0400: > Steffen DETTMER wrote: > > > (but OutputStream promises that write > > succeedes synchronous, blocking, or throws an exception). > > Where is it so written? Now, as you ask, I think it is not written that clearly but follows from specification. mmm... Am I wrong? I understand the API doc in this way: * http://java.sun.com/j2se/1.4.2/docs/api/java/io/OutputStream.html#write(byte[]) > public void write(byte[] b) > throws IOException > > Writes b.length bytes from the specified byte array to this > output stream. The general contract for write(b) is that > it should have exactly the same effect as the call write(b, > 0, b.length). > > Parameters: > b - the data. > Throws: > IOException - if an I/O error occurs. > See Also: > write(byte[], int, int) and there is: > public void write(byte[] b, > int off, > int len) > throws IOException > > Writes len bytes from the specified byte array starting at > offset off to this output stream. The general contract for > write(b, off, len) is that some of the bytes in the array b > are written to the output stream in order; element b[off] > is the first byte written and b[off+len-1] is the last byte > written by this operation. > > The write method of OutputStream calls the write method of > one argument on each of the bytes to be written out. > Subclasses are encouraged to override this method and > provide a more efficient implementation. > > If b is null, a NullPointerException is thrown. > > If off is negative, or len is negative, or off+len is > greater than the length of the array b, then an > IndexOutOfBoundsException is thrown. > > Parameters: > b - the data. > off - the start offset in the data. > len - the number of bytes to write. > Throws: > IOException - if an I/O error occurs. In particular, an > IOException is thrown if the output stream is closed. In general, any specialisation (derived child class) must comform to this. So write in the end is specified (!) as "The write method ... calls the write method ... on each of the bytes to be written out". This is what must be implemented by ANY OutputStream. Of course, there is: "Subclasses are encouraged to override this method and provide a more efficient implementation." which IMHO does not contradict - the more efficient must behave in exactly the same way of course (just wasting less resources than a simple byte-by-byte write). So it does not matter here I think. The write that finally defines the behavior tells basically: > "Writes the specified byte to this output stream. The general > contract for write is that one byte is written to the output > stream. " > > Throws: > IOException - if an I/O error occurs. which IMHO is another way of saying "write writes the byte immediately and returns on success (only), otherwise an exception is thrown". Especially it cannot happen that zero bytes are written (i.e. the specified byte is NOT written) without an exception. So by this write must be synchronous and blocking, because otherwise it could not reliably know if an asynchronous operation will succeede or not (some getAsyncResult or so would be needed). Since write(byte[]) does this for each byte (or with a behavior beeing exactly the same as if it would do), I think this means that the write(byte[]) succeedes synchronous/blocking or throws an exception. Did I an error in reasoning or confused something or so? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From j.kenneth.gentle at acm.org Mon Jun 11 06:51:25 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 11 Jun 2007 08:51:25 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611123650.GI10821@elberon.bln.de.ingenico.com> References: <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> <466D3439.4020805@gatworks.com> <20070611123650.GI10821@elberon.bln.de.ingenico.com> Message-ID: <200706111251.l5BCpS9T017831@qbang.org> It is as Steffen describes. "InputStream" and "OutputStream" are inherently synchronous (which is why so many java programs resort to threads to use them). Anything outside of this "contract" is *not* an InputStream or OutputStream. That is why there is a new package for things that don't behave like the old *Stream classes - the NIO package. If you look carefully at the IO package, you'll note that almost all the classes are _Decorator_ pattern implementations of the *Stream classes - and the interface presents the _same_ behavior to the calling code in all cases - a synchronous operation that completes successfully or throws an exception (with the one exception of "read" that returns a "-1" on end-of-stream. I know I've read this numerous times - I'd suggest checking the Language Spec or one of the books by Bloch or Gosling. Ken At 08:36 2007-06-11, you wrote: >* Uncle George wrote on Mon, Jun 11, 2007 at 07:38 -0400: > > Steffen DETTMER wrote: > > > > > (but OutputStream promises that write > > > succeedes synchronous, blocking, or throws an exception). > > > > Where is it so written? > >Now, as you ask, I think it is not written that clearly but >follows from specification. mmm... > >Am I wrong? > >I understand the API doc in this way: > >* >http://java.sun.com/j2se/1.4.2/docs/api/java/io/OutputStream.html#write(byte[]) > > public void write(byte[] b) > > throws IOException > > > > Writes b.length bytes from the specified byte array to this > > output stream. The general contract for write(b) is that > > it should have exactly the same effect as the call write(b, > > 0, b.length). > > > > Parameters: > > b - the data. > > Throws: > > IOException - if an I/O error occurs. > > See Also: > > write(byte[], int, int) > > >and there is: > > > > public void write(byte[] b, > > int off, > > int len) > > throws IOException > > > > Writes len bytes from the specified byte array starting at > > offset off to this output stream. The general contract for > > write(b, off, len) is that some of the bytes in the array b > > are written to the output stream in order; element b[off] > > is the first byte written and b[off+len-1] is the last byte > > written by this operation. > > > > The write method of OutputStream calls the write method of > > one argument on each of the bytes to be written out. > > Subclasses are encouraged to override this method and > > provide a more efficient implementation. > > > > If b is null, a NullPointerException is thrown. > > > > If off is negative, or len is negative, or off+len is > > greater than the length of the array b, then an > > IndexOutOfBoundsException is thrown. > > > > Parameters: > > b - the data. > > off - the start offset in the data. > > len - the number of bytes to write. > > Throws: > > IOException - if an I/O error occurs. In particular, an > > IOException is thrown if the output stream is closed. > > >In general, any specialisation (derived child class) must comform >to this. So write in the end is specified (!) as "The write >method ... calls the write method ... on each of the bytes to be >written out". This is what must be implemented by ANY >OutputStream. > >Of course, there is: "Subclasses are encouraged to override this >method and provide a more efficient implementation." which IMHO >does not contradict - the more efficient must behave in exactly >the same way of course (just wasting less resources than a simple >byte-by-byte write). So it does not matter here I think. > > > >The write that finally defines the behavior tells basically: > > > "Writes the specified byte to this output stream. The general > > contract for write is that one byte is written to the output > > stream. " > > > > Throws: > > IOException - if an I/O error occurs. > > >which IMHO is another way of saying "write writes the byte >immediately and returns on success (only), otherwise an exception >is thrown". Especially it cannot happen that zero bytes are >written (i.e. the specified byte is NOT written) without an >exception. So by this write must be synchronous and blocking, >because otherwise it could not reliably know if an asynchronous >operation will succeede or not (some getAsyncResult or so would >be needed). > >Since write(byte[]) does this for each byte (or with a behavior >beeing exactly the same as if it would do), I think this means >that the write(byte[]) succeedes synchronous/blocking or throws >an exception. > >Did I an error in reasoning or confused something or so? > >oki, > >Steffen > >About Ingenico Throughout the world businesses rely on Ingenico for >secure and expedient electronic transaction acceptance. Ingenico >products leverage proven technology, established standards and >unparalleled ergonomics to provide optimal reliability, versatility >and usability. This comprehensive range of products is complemented >by a global array of services and partnerships, enabling businesses >in a number of vertical sectors to accept transactions anywhere >their business takes them. >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. > >About Ingenico Throughout the world businesses rely on Ingenico for >secure and expedient electronic transaction acceptance. Ingenico >products leverage proven technology, established standards and >unparalleled ergonomics to provide optimal reliability, versatility >and usability. This comprehensive range of products is complemented >by a global array of services and partnerships, enabling businesses >in a number of vertical sectors to accept transactions anywhere >their business takes them. >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. > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From alesinskyy at googlemail.com Mon Jun 11 07:25:33 2007 From: alesinskyy at googlemail.com (Oleksandr Alesinskyy) Date: Mon, 11 Jun 2007 15:25:33 +0200 Subject: [Rxtx] [OT] select :-) Message-ID: Sorry, but I have to disagree with following statement: "So write in the end is specified (!) as "The write method ... calls the write method ... on each of the bytes to be written out". This is what must be implemented by ANY OutputStream.". This is not part of the specification or contract, it is just revealed implementation detail of the OutputStream. It is not stated anywhere that behavoiur of derived classes shall conform with this one. Statement concerning "synchronous" nature of the output stream is invalid as well. Really synchronous stream does not require flush() but OutputStream has it. From Steffen.DETTMER at ingenico.com Mon Jun 11 08:21:16 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 16:21:16 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: Message-ID: <20070611142116.GN10821@elberon.bln.de.ingenico.com> * Oleksandr Alesinskyy wrote on Mon, Jun 11, 2007 at 15:25 +0200: > Sorry, but I have to disagree with following statement: > "So write in the end is specified (!) as "The write > method ... calls the write method ... on each of the bytes to be > written out". This is what must be implemented by ANY > OutputStream.". > > This is not part of the specification or contract, it is just > revealed implementation detail of the OutputStream. It is not > stated anywhere that behavoiur of derived classes shall conform > with this one. (I didn't meant that the implementation must really write byte by byte, but that it must "look as if it would do" - because all implementations of OutputStream must "look" in the same way [which is another way of saying "do abstract" I think]) I think the API doc is not "revealing implementation details" but it is the *specification* of that interface and derivations must (should) conform to this specification. Isn't this the idea of interfaces? A function that expects an OutputStream should work on ANY OutputStream, shouldn't it? just kidding: I mean, what would be the point in implementing a checksum function as OutputStream.write which throws its result as IOException? Or which requires to call close() as very first operation to tell that the application is about to transmit confidential data? :-) > Statement concerning "synchronous" nature of the output stream > is invalid as well. Really synchronous stream does not require > flush() but OutputStream has it. ahh, interesting point! I think this is another bug in the API. flush() is wrong. Because write specifies "The general contract for write is that one byte is written to the output stream." but not "a byte may be written or buffered". Actually, an application would need to call flush() after each write (or bunch of write calls) to ensure that write really did something otherwise I think. I didn't found in the spec of OutputStream that it would be required to call flush(). This should mean that calling flush is not required which in turn leads to the conclusion that write must be synchrous (private threads are forbidden because not specified :)) which in turn leads to the conclusion that flush() is not needed at all... I mean, what if someone would only store in write and do the "real write" in flush() and never else? An application could write in one stream and read on another one (e.g. in bidirectional communication) and would never get anything back, because nothing was actually written because no flush was called? Then someone could even think that on error in some write the data could remain buffered AND throw an exception, retrying to send the data in the next write. Ohh, and if there would be some message number inside, and underlaying write (e.g. a protocol offering InputStream/OutputStream) would check this and throw "DuplicatedMessageNumber" the stream would only throw it again and again beeing unusable... In short: I have no clue how someone could be able to implement an asynchrounos write (which is realiable and correct) without beeing specific to anything which is not specified by OutputStream. Well, I think in the end OutputStream was not intended for such communication or protocol implementations - but to read a local disk file or so. In case of I/O errors usually you can abort your application and change the hard disk :-) oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Bob_Jacobsen at lbl.gov Mon Jun 11 09:32:23 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Mon, 11 Jun 2007 08:32:23 -0700 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611142116.GN10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> Message-ID: At 4:21 PM +0200 6/11/07, Steffen DETTMER wrote: > > Statement concerning "synchronous" nature of the output stream >> is invalid as well. Really synchronous stream does not require >> flush() but OutputStream has it. > >ahh, interesting point! > >I think this is another bug in the API. flush() is wrong. Because >write specifies "The general contract for write is that one byte >is written to the output stream." but not "a byte may be written >or buffered". > >Actually, an application would need to call flush() after each >write (or bunch of write calls) to ensure that write really did >something otherwise I think. OutputStreams don't _have_ to be synchronous or asynchronous, but the OutputStream API was be arranged so that subclasses _can_ be synchronous or asynchronous. Such generality is the hardest part of getting an API right. Hence, if at some point a program using an OutputStream wants to be sure that the data has been pushed all the way out, flush() is available. For some subclasses, e.g. the buffered ones, this has important behavior. Others write the data from each call, and flush() doesn't do anything. You _can_ omit it in programs that are known to use this second type, but there's no requirement that you do so; the interface is general in that way. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From Steffen.DETTMER at ingenico.com Mon Jun 11 12:32:39 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 20:32:39 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> Message-ID: <20070611183239.GT10821@elberon.bln.de.ingenico.com> * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: > >Actually, an application would need to call flush() after each > >write (or bunch of write calls) to ensure that write really did > >something otherwise I think. > OutputStreams don't _have_ to be synchronous or asynchronous, > but the OutputStream API was be arranged so that subclasses > _can_ be synchronous or asynchronous. Ahh, oki. Thanks for the clarificaion. So in short, flush() MUST be called on OutputStream, this is just not documented correctly or so clearly (right?). So the overall usage semantics would be: 1. call write (multiple times if desired) 2. call flush only if both succeeded, write was successful. If flush fails it remains unknown if a part of the data was written and/or will be repeated. So the spec (API doc) is wrong. Correct would be to tell that write behaves as told as long as it is followed by a call to flush, otherwise data may or may not get lost (depending wheter close() is called and calls flush(), which seems not to be guaranteed/required). BTW, I think it is a little bit... erm... interesting to find the specification (java API doc reference) wrong, having a need to conclude it from the presence of some methods with "it would make no sense if they behave exactly as specified, so specification must be wrong (incomplete)". > Such generality is the hardest part of getting an API right. Yes, seems to be proven ;) > Hence, if at some point a program using an OutputStream wants > to be sure that the data has been pushed all the way out, > flush() is available. For some subclasses, e.g. the buffered > ones, this has important behavior. Others write the data from > each call, and flush() doesn't do anything. > You _can_ omit it in programs that are known to use this second > type, but there's no requirement that you do so; the interface > is general in that way. I think, it still it must be called always, otherwise the application could break if passing a different runtime type as OutputStream. I think, if the application/method needs a special "type of OutputStream" then the parameter type must be a subclass but not OutputStream, maybe a PrintStream or so - otherwise the compiler could not detect this error (passing wrong type). Is this correct? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Bob_Jacobsen at lbl.gov Mon Jun 11 13:00:52 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Mon, 11 Jun 2007 12:00:52 -0700 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611183239.GT10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> Message-ID: At 8:32 PM +0200 6/11/07, Steffen DETTMER wrote: >So the spec (API doc) is wrong. Correct would be to tell that >write behaves as told as long as it is followed by a call to >flush, otherwise data may or may not get lost (depending wheter >close() is called and calls flush(), which seems not to be >guaranteed/required). I'm not entirely sure that the spec is wrong, but reasonable people can differ on this. In the 1.5 JavaDocs, all that the docs say for the write methods is that they write to the _output_ _stream_; there is no guarantee of anything beyond that. Only the flush method has any guarantee about the data, which is >Flushes this output stream and forces any buffered output bytes to >be written out. The general contract of flush is that calling it is >an indication that, if any bytes previously written have been >buffered by the implementation of the output stream, such bytes >should immediately be written to their intended destination. People commonly use various OutputStreams without using flush(), and it often works, but it's a bad practice and will eventually bite them. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From netbeans at gatworks.com Mon Jun 11 13:31:57 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 15:31:57 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611183239.GT10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> Message-ID: <466DA32D.1010602@gatworks.com> Steffen DETTMER wrote: > * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: >>> Actually, an application would need to call flush() after each >>> write (or bunch of write calls) to ensure that write really did >>> something otherwise I think. > >> OutputStreams don't _have_ to be synchronous or asynchronous, >> but the OutputStream API was be arranged so that subclasses >> _can_ be synchronous or asynchronous. > > Ahh, oki. Thanks for the clarificaion. > > So in short, flush() MUST be called on OutputStream, this is just > not documented correctly or so clearly (right?). No. Flush can be called to force all current data in java buffer's to be written to the kernel - NOW. A flush() can also *imply* that, besides writing out the buffer's that java employs, may also imply/ask the kernel to write all data thusfar written to the kernel, to be physically placed on the destination device - NOW. For some OS's there is no need to do a kernel flush(), as the I/O is synchronized already. Since this is java, you never know what OS your on. From tjarvi at qbang.org Mon Jun 11 19:28:27 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Jun 2007 19:28:27 -0600 (MDT) Subject: [Rxtx] [OT] select :-) In-Reply-To: <466DA32D.1010602@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: On Mon, 11 Jun 2007, Uncle George wrote: > Steffen DETTMER wrote: >> * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: >>>> Actually, an application would need to call flush() after each >>>> write (or bunch of write calls) to ensure that write really did >>>> something otherwise I think. >> >>> OutputStreams don't _have_ to be synchronous or asynchronous, >>> but the OutputStream API was be arranged so that subclasses >>> _can_ be synchronous or asynchronous. >> >> Ahh, oki. Thanks for the clarificaion. >> >> So in short, flush() MUST be called on OutputStream, this is just >> not documented correctly or so clearly (right?). > No. > Flush can be called to force all current data in java buffer's to be > written to the kernel - NOW. > > A flush() can also *imply* that, besides writing out the buffer's that > java employs, may also imply/ask the kernel to write all data thusfar > written to the kernel, to be physically placed on the destination device > - NOW. > For some OS's there is no need to do a kernel flush(), as the I/O is > synchronized already. Since this is java, you never know what OS your on. To add to the confusion, flush on the C side throws away data. drain makes sure it is written. Looking at the ParallelImp.c we can probably do better. /* we set a timeout because all calls are sequentiell (also with asynchron) this means that the default timeout of unlimited blocks all calls (also close and status request) if the device is down */ GetCommTimeouts( (HANDLE)fd, &timeouts ); timeouts.WriteTotalTimeoutMultiplier = 0; timeouts.WriteTotalTimeoutConstant = 2000; /* 2000 is the min value for the default Windows NT and Windows 2000 driver */ SetCommTimeouts( (HANDLE)fd, &timeouts ); while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } errorCount = 0; bytes += countWritten; count -= countWritten; } LPRPort has some timeout code that appears to be doing nothing but flipping bits back and forth right now. The commapi rxtx follows allows for timeout control from javax.comm.CommPort. The above is a solution that worked in one specific use case. With timeouts in place, the original 'old printer going offline' problem could be solved. That printer code isn't written in stone. In fact it was ajusted from being able to print 'asdf' to a daisy wheel printer to working for one person. BTW, I've finished teaching after hours tonight and will be moving forward with a new rxtx release in my free time. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Jun 11 21:28:04 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 23:28:04 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: <466E12C4.1010305@gatworks.com> > Looking at the ParallelImp.c we can probably do better. > The problem stemmed from the possibility that the writev routine could have written some of the buffer, in chunks, printer pauses, refuses any more chunks, and a timeout occurs. Do you or do you not cause an exception to be thrown? Is there a way to set timeout for a ParallelPort data output stream? I cant find it. From tjarvi at qbang.org Mon Jun 11 22:17:23 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Jun 2007 22:17:23 -0600 (MDT) Subject: [Rxtx] [OT] select :-) In-Reply-To: <466E12C4.1010305@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> <466E12C4.1010305@gatworks.com> Message-ID: On Mon, 11 Jun 2007, Uncle George wrote: >> Looking at the ParallelImp.c we can probably do better. >> > The problem stemmed from the possibility that the writev routine could > have written some of the buffer, in chunks, printer pauses, refuses any > more chunks, and a timeout occurs. Do you or do you not cause an > exception to be thrown? > > Is there a way to set timeout for a ParallelPort data output stream? I > cant find it. hmm I looked again after you asked. The timeouts are only controllable on the receive side. This comes from CommPort; the parent. So what we are talking about is some bytes in memory that rxtx has and is supposed to write. A buffer perhaps? The approach with rxtx in the past has been to ignore output buffer sizes. The assumption is that the library does not know how to best handle buffers. There are buffered output streams that can do buffering on top of rxtx for instance. There is also a question regarding what was actually ment when the API was put together. My suspicion is that it was put together while looking at one OS API and was never ment to be anything more than a hook into that API. The comments are fairly telling combined with reading the w32 API. So looking at the problem again.. The current timeout behavior appears fairly arbitrary. Presumably this is to prevent a program from hanging instead of using a helper thread to write - heavy handed for new programmers. Even so, I don't think the write should timeout at all if it is not configurable. >From the API perspective, "What Timeout?" -- Trent Jarvi tjarvi at qbang.org From Steffen.DETTMER at ingenico.com Tue Jun 12 02:14:48 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 12 Jun 2007 10:14:48 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466DA32D.1010602@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: <20070612081447.GU10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Mon, Jun 11, 2007 at 15:31 -0400: > Steffen DETTMER wrote: > > Ahh, oki. Thanks for the clarificaion. > > > > So in short, flush() MUST be called on OutputStream, this is just > > not documented correctly or so clearly (right?). > No. hum (though now I got it, but...). > Flush can be called to force all current data in java buffer's to be > written to the kernel - NOW. > > A flush() can also *imply* that, besides writing out the > buffer's that java employs, may also imply/ask the kernel to > write all data thusfar written to the kernel, to be physically > placed on the destination device - NOW. > > For some OS's there is no need to do a kernel flush(), as the I/O is > synchronized already. Since this is java, you never know what OS your on. (well, but if you're going to kernel level, even flush cannot guarantee that data will "be physically placed". Maybe you're flushing to a file via NFS (and the client "thinks" that it was written, but maybe it was just buffered by the NFS server) or so... but of course such exceptions of the rules are constructable always.) Well, you tell that depending on the OS it can be that flush is needed or it can be that flush is not needed (beacuse the I/O is synchronized already), right? Also, applications should work on any OS, which includes the OSes that do need flush. Since the application cannot know whether flush is needed or not because it doesn't know what the OS is doing, it has to call flush, hasn't it? I mean, if it would not call flush then it would not work on such OSes (except the written data would not be needed at all, but in this would be an artificial example :)). Since applications are supposed to work this would be wrong, wouldn't it? So would it be correct to say: "Applications, that should work under all OSes (including the OSes where the I/O is not synchronised already), have to call flush on OutputStream to ensure the data is transfered to the kernel." or is this wrong? If so, then I'm afraid I missed the point again :( oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Tue Jun 12 04:46:52 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 12 Jun 2007 06:46:52 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070612081447.GU10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> <20070612081447.GU10821@elberon.bln.de.ingenico.com> Message-ID: <466E799C.7060700@gatworks.com> S > (well, but if you're going to kernel level, even flush cannot > guarantee that data will "be physically placed". Thats true now-a-days because ( from "man 2 sync" ) : > According to the standard specification (e.g., SVID), sync() schedules > the writes, but may return before the actual writing is done. However, > since version 1.3.20 Linux does actually wait. (This still does not > guarantee data integrity: modern disks have large caches.) My disk drive has 8mb cache. Maybe you're > flushing to a file via NFS (and the client "thinks" that it was > written, but maybe it was just buffered by the NFS server) or > so... but of course such exceptions of the rules are > constructable always.) > > Well, you tell that depending on the OS it can be that flush is > needed or it can be that flush is not needed (beacuse the I/O is > synchronized already), right? Also, applications should work on > any OS, which includes the OSes that do need flush. Its not OS's that need flush, its applications that want to have some assurance that data is written to the device that really needs to use flush. If your program ( or thread ) dies then it is in your best interest to write out the critical data as soon as possible, as economical as possible. These are trade-off's that the application programmer makes. A big buffer may mean big loss of data, a small buffer may mean spending too much time writing out data. > > > So would it be correct to say: > > "Applications, that should work under all OSes (including the > OSes where the I/O is not synchronised already), have to call > flush on OutputStream to ensure the data is transfered to the > kernel." > > or is this wrong? If so, then I'm afraid I missed the point again > :( > No that is not wrong. Ensuring that data is transfered to the OS is just about what any application can do. From tjarvi at qbang.org Thu Jun 14 08:16:47 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 14 Jun 2007 08:16:47 -0600 (MDT) Subject: [Rxtx] rxtx and usb-serial solution In-Reply-To: References: Message-ID: On Thu, 14 Jun 2007, Vladimir Kirtchev wrote: > Hi Trent, > > I develop a Java application which communicates with devices which have > USB-to-Serial bridge in them. The target OS is Linux. So for this purpose I > use RXTX. > > But I encountered a strange problem - when reading from the InputStream, I > receive series of zeros. I have this problem under Linux only. Under Windows > it is fine. > Actually this problem is the same as the one described here: > http://marc.info/?l=rxtx&m=109703190731748&w=2. > > > So I searched for the problem in the native code. And found that the root of > the problem is in SerialImp.c, > int configure_port( int fd ) > { > ... > ttyset.c_iflag = INPCK; > ... > } > > This line enables input parity checking, and the data sent from the device > is processed by the OS driver before being read with read(). > In this case the driver detects some problem and sets the received bytes to > zero. > > On the other hand in the Java part a set the serial port parameters with > SerialPort.PARITY_NONE. According to me, except all other things, this > should also disable INPCK in c_iflag. > > So I refactored the method translate_parity(...) to the following: > > int translate_parity( JNIEnv *env, struct termios *ttyset, jint parity ) > { > ENTER( "translate_parity" ); > #ifdef CMSPAR > ttyset->c_cflag &= ~(PARENB | PARODD | CMSPAR ); > #endif /* CMSPAR */ > switch( parity ) { > case JPARITY_NONE: > ttyset->c_iflag &= ~INPCK; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_EVEN: > ttyset->c_cflag |= PARENB; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_ODD: > ttyset->c_cflag |= PARENB | PARODD; > LEAVE( "translate_parity" ); > return 0; > #ifdef CMSPAR > case JPARITY_MARK: > ttyset->c_cflag |= PARENB | PARODD | CMSPAR; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_SPACE: > ttyset->c_cflag |= PARENB | CMSPAR; > LEAVE( "translate_parity" ); > return 0; > #endif /* CMSPAR */ > default: > printf("Parity missed %i\n", (int) parity ); > } > > LEAVE( "translate_parity" ); > /* > For some reason the native exceptions are not being caught. Moving this > to the Java side fixed the issue. taj. > throw_java_exception( env, UNSUPPORTED_COMM_OPERATION, > "", "parity value not supported" ); > */ > return 1; > } > > This modification solved the problem and now it works correctly under Linux. > > I think I will be a nice if this is idea is included in a future release of > RXTX. > > Thanks Vadim, I'll try that out. Forwarding to the rxtx mail-list too. This is probably not going to help USB drivers on windows which I'm sure some are looking for. As far as I can tell, windows USB bluetooth and serial dongles are limited by driver functionality. Some are good and others lack key features. -- Trent Jarvi tjarvi at qbang.org From dan.sandberg.lists at gmail.com Mon Jun 18 14:43:39 2007 From: dan.sandberg.lists at gmail.com (Dan Sandberg) Date: Mon, 18 Jun 2007 13:43:39 -0700 Subject: [Rxtx] Fix for JNI Get/Set Field Errors Message-ID: <4676EE7B.7060800@gmail.com> Hi, I've fixed the problems that cause the following JNI error when extra JNI checking ( -Xjni:check ) is turned on. FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) The problem was basically that GetLong was being used to get ints, and SetInt was used for longs. The patch below fixes this. Please let me know if there are any questions / problems. Cheers, -Dan diff -aur old/SerialImp.c src/SerialImp.c --- old/SerialImp.c 2007-06-18 13:24:33.000000000 -0700 +++ src/SerialImp.c 2007-06-18 06:26:26.000000000 -0700 @@ -1337,7 +1337,7 @@ report("init_threads: get eis\n"); jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); report("init_threads: set eis\n"); - (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); + (*eis->env)->SetLongField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); report("init_threads: stop\n"); report_time_end( ); return( 1 ); @@ -1530,7 +1530,7 @@ jobject jobj, jboolean interrupted ) { int fd = get_java_var( env, jobj,"fd","I" ); - struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var( env, jobj, "eis", "J" ); + struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var_long( env, jobj, "eis", "J" ); int result, count=0; char message[80]; @@ -2939,7 +2939,7 @@ /* TRENT */ int flag, count = 0; struct event_info_struct *eis = ( struct event_info_struct * ) - get_java_var( env, *jobj,"eis","J" ); + get_java_var_long( env, *jobj,"eis","J" ); report_time_start(); flag = eis->eventflags[SPE_DATA_AVAILABLE]; @@ -4873,9 +4873,9 @@ exceptions: none comments: ----------------------------------------------------------*/ -size_t get_java_var( JNIEnv *env, jobject jobj, char *id, char *type ) +long get_java_var_long( JNIEnv *env, jobject jobj, char *id, char *type ) { - int result = 0; + long result = 0; jclass jclazz = (*env)->GetObjectClass( env, jobj ); jfieldID jfd = (*env)->GetFieldID( env, jclazz, id, type ); @@ -4889,7 +4889,11 @@ LEAVE( "get_java_var" ); return result; } - result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); + if ( !strcmp( type, "J" ) ) { + result = (long)( (*env)->GetLongField( env, jobj, jfd ) ); + } else { + result = (int) ( (*env)->GetIntField( env, jobj, jfd ) ); + } /* ct7 & gel * Added DeleteLocalRef */ (*env)->DeleteLocalRef( env, jclazz ); if(!strncmp( "fd",id,2) && result == 0) @@ -4900,6 +4904,10 @@ return result; } +int get_java_var( JNIEnv *env, jobject jobj, char *id, char *type ) { + return (int) get_java_var_long( env, jobj, id, type ); +} + /*---------------------------------------------------------- throw_java_exception diff -aur old/SerialImp.h src/SerialImp.h --- old/SerialImp.h 2007-06-18 13:24:39.000000000 -0700 +++ src/SerialImp.h 2007-06-18 06:23:43.000000000 -0700 @@ -413,7 +413,8 @@ void system_wait(); void finalize_event_info_struct( struct event_info_struct * ); int read_byte_array( JNIEnv *, jobject *, int, unsigned char *, int, int ); -size_t get_java_var( JNIEnv *, jobject, char *, char * ); +int get_java_var( JNIEnv *, jobject, char *, char * ); +long get_java_var_long( JNIEnv *, jobject, char *, char * ); jboolean is_interrupted( struct event_info_struct * ); int send_event(struct event_info_struct *, jint, int ); void dump_termios(char *,struct termios *); From yvespielusenet at free.fr Tue Jun 26 03:41:58 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 11:41:58 +0200 Subject: [Rxtx] [PARALLEL] resource in use Message-ID: <1182850918.3483.10.camel@localhost.localdomain> Hello, So now I want to modify the timeout of the library for parallel port. I have downloaded source code. There is a makefile for migw. SO I have installed mingw on ubuntu and modified the makefile.mingw32 to set it for my system. I have no error but some warnings. The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But When I want to use it the jvm crash :( How can I know what is wrong ? How rxtx windows release has been done ? thanks -- yves piel From yvespielusenet at free.fr Tue Jun 26 07:17:02 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 15:17:02 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182850918.3483.10.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> Message-ID: <1182863822.3483.17.camel@localhost.localdomain> Here is the Makefile I use, the output of the 'make' and the log of the jvm when it crashed : - The Makefile : http://yvespiel.free.fr/rxtx/Makefile - The make output : http://yvespiel.free.fr/rxtx/compile.txt - The crash log : http://yvespiel.free.fr/rxtx/hs_err_pid2100.log I have compiled rxtx under Debian testing with mingw : narma at linimi:/tmp/err$ dpkg -l | grep mingw ii mingw32 3.4.5.20060117.1.dfsg-3 ii mingw32-binutils 2.17.50-20070129.1-1 ii mingw32-runtime 3.12-1 thanks fort help :) Le mardi 26 juin 2007 ? 11:41 +0200, yves pielusenet a ?crit : > Hello, > So now I want to modify the timeout of the library for parallel port. I > have downloaded source code. There is a makefile for migw. SO I have > installed mingw on ubuntu and modified the makefile.mingw32 to set it > for my system. > I have no error but some warnings. > The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But > When I want to use it the jvm crash :( > > How can I know what is wrong ? > > How rxtx windows release has been done ? > > thanks > From yvespielusenet at free.fr Tue Jun 26 07:40:11 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 15:40:11 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182863822.3483.17.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> <1182863822.3483.17.camel@localhost.localdomain> Message-ID: <1182865211.3483.21.camel@localhost.localdomain> I have add the options '--enable-stdcall-fixup' to the 'i586-mingw32msvc-ld' commande. Now I have no warning. But the JVM always crashes :( The output seems more detailled, but I don't understand anything... Here is files : http://yvespiel.free.fr/rxtx/2/ -- yves piel Le mardi 26 juin 2007 ? 15:17 +0200, yves pielusenet a ?crit : > Here is the Makefile I use, the output of the 'make' and the log of the > jvm when it crashed : > > - The Makefile : http://yvespiel.free.fr/rxtx/Makefile > - The make output : http://yvespiel.free.fr/rxtx/compile.txt > - The crash log : http://yvespiel.free.fr/rxtx/hs_err_pid2100.log > > I have compiled rxtx under Debian testing with mingw : > narma at linimi:/tmp/err$ dpkg -l | grep mingw > ii mingw32 3.4.5.20060117.1.dfsg-3 > ii mingw32-binutils 2.17.50-20070129.1-1 > ii mingw32-runtime 3.12-1 > > thanks fort help :) > > > Le mardi 26 juin 2007 ? 11:41 +0200, yves pielusenet a ?crit : > > Hello, > > So now I want to modify the timeout of the library for parallel port. I > > have downloaded source code. There is a makefile for migw. SO I have > > installed mingw on ubuntu and modified the makefile.mingw32 to set it > > for my system. > > I have no error but some warnings. > > The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But > > When I want to use it the jvm crash :( > > > > How can I know what is wrong ? > > > > How rxtx windows release has been done ? > > > > thanks > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From yvespielusenet at free.fr Tue Jun 26 08:27:42 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 16:27:42 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182865211.3483.21.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> <1182863822.3483.17.camel@localhost.localdomain> <1182865211.3483.21.camel@localhost.localdomain> Message-ID: <1182868062.3483.24.camel@localhost.localdomain> I think thant the include files of jdk were not for windows but for linux. So I have copied include/ folder from windows to linux and I modified the Makefile to use those file. It compile fine but the JVM always crash :( http://yvespiel.free.fr/rxtx/3/ Le mardi 26 juin 2007 ? 15:40 +0200, yves pielusenet a ?crit : > I have add the options '--enable-stdcall-fixup' to the > 'i586-mingw32msvc-ld' commande. Now I have no warning. But the JVM > always crashes :( The output seems more detailled, but I don't > understand anything... > Here is files : > http://yvespiel.free.fr/rxtx/2/ > From netbeans at gatworks.com Fri Jun 1 05:38:50 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 07:38:50 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <465F7ADD.1010501@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> Message-ID: <4660054A.2040202@gatworks.com> Manuel Naranjo wrote: In the case of my module, you can > unplug the device but it will not delete the symlink until those apps > that had opened the port has closed it. This is done this way to avoid > kernel panics. What does this mean to user code ? I have tried the alternate route ( other than closing ) which is sleep inbetween the I/O errors ( an unplugged USB device). When the device is plugged back in, The writes to the device still get an I/O error. This would seem to be a lost cause for the application. From netbeans at gatworks.com Fri Jun 1 06:35:48 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 08:35:48 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <465F7ADD.1010501@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> Message-ID: <466012A4.90608@gatworks.com> Manuel Naranjo wrote: In the case of my module, you can > unplug the device but it will not delete the symlink until those apps > that had opened the port has closed it. T Did u also mean for this to happen? USB0 was not closed by application. Apparently USB1 got created when USB device was plugged back in. There is only one USB device on a 4 port USB hub. This also seems to suggest that application recovery to be impossible. > Jun 1 07:10:08 mylaptop kernel: garmin_gps 1-1.4:1.0: Garmin GPS usb/tty converter detected > Jun 1 07:10:08 mylaptop kernel: usb 1-1.4: Garmin GPS usb/tty converter now attached to ttyUSB0 > Jun 1 07:15:17 mylaptop kernel: usb 1-1: USB disconnect, address 4 > Jun 1 07:15:17 mylaptop kernel: usb 1-1.4: USB disconnect, address 5 > Jun 1 07:15:17 mylaptop kernel: garmin_gps 1-1.4:1.0: device disconnected > Jun 1 07:15:26 mylaptop kernel: usb 1-1: new full speed USB device using uhci_hcd and address 6 > Jun 1 07:15:26 mylaptop kernel: hub 1-1:1.0: USB hub found > Jun 1 07:15:26 mylaptop kernel: hub 1-1:1.0: 4 ports detected > Jun 1 07:15:27 mylaptop kernel: usb 1-1.4: new full speed USB device using uhci_hcd and address 7 > Jun 1 07:15:27 mylaptop kernel: garmin_gps 1-1.4:1.0: Garmin GPS usb/tty converter detected > Jun 1 07:15:27 mylaptop kernel: usb 1-1.4: Garmin GPS usb/tty converter now attached to ttyUSB1 From naranjo.manuel at gmail.com Fri Jun 1 09:17:22 2007 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Fri, 01 Jun 2007 12:17:22 -0300 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <466012A4.90608@gatworks.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> <466012A4.90608@gatworks.com> Message-ID: <46603882.5050701@gmail.com> Uncle George escribi?: > Manuel Naranjo wrote: > In the case of my module, you can > >> unplug the device but it will not delete the symlink until those apps >> that had opened the port has closed it. T >> > > Did u also mean for this to happen? USB0 was not closed by application. > > Apparently USB1 got created when USB device was plugged back in. There > is only one USB device on a 4 port USB hub. > > This also seems to suggest that application recovery to be impossible. > Exactly there's a dead symlink (you can read and write to it and nothing will happen) and a new port will be created when a new device is connencted. From netbeans at gatworks.com Fri Jun 1 10:20:46 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 12:20:46 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <46603882.5050701@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> <466012A4.90608@gatworks.com> <46603882.5050701@gmail.com> Message-ID: <4660475E.5090202@gatworks.com> Not sure what u mean by "symlink". U cant read/write to it anymore. U get I/O error. In this scenario the device effectively went dead, and only solution is to close the channel. reconnecting the USB device, although dead, but not closed, will create a second device. This does not seem to be a desirable side-effect. The user will now have ttyUSB1, wondering where did ttyUSB0 go to. The application will also be in a confused state, as well as RXTX, because RXTX wont know about ttyUSB1. Manuel Naranjo wrote: > Uncle George escribi?: >> Manuel Naranjo wrote: >> In the case of my module, you can >> >>> unplug the device but it will not delete the symlink until those apps >>> that had opened the port has closed it. T >>> >> Did u also mean for this to happen? USB0 was not closed by application. >> >> Apparently USB1 got created when USB device was plugged back in. There >> is only one USB device on a 4 port USB hub. >> >> This also seems to suggest that application recovery to be impossible. >> > Exactly there's a dead symlink (you can read and write to it and nothing > will happen) and a new port will be created when a new device is connencted. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From arnab.bhaumik at gmail.com Mon Jun 4 01:40:16 2007 From: arnab.bhaumik at gmail.com (arnab bhaumik) Date: Mon, 4 Jun 2007 13:10:16 +0530 Subject: [Rxtx] full duplex com port with rxtx Message-ID: hi , till now i did half duplex communication with rxtx package on com package. my question is : is it possible to use com port with full duplex mode with rxtx package . ther is example of SimpleRead class and SimpleWrite class. it is clear that if i can use both the class simultaneously then full duplex is possible......... arnab/vu2bpw -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070604/6edb0453/attachment-0004.html From lists at iDIAcomputing.com Mon Jun 4 07:53:17 2007 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Mon, 04 Jun 2007 09:53:17 -0400 Subject: [Rxtx] full duplex com port with rxtx In-Reply-To: References: Message-ID: <4664194D.90301@iDIAcomputing.com> arnab bhaumik wrote: > hi , > > till now i did half duplex communication with rxtx package on com > package. > > my question is : is it possible to use com port with full duplex mode > with rxtx package . > > > ther is example of SimpleRead class and SimpleWrite class. it is > clear that if i can use both the class simultaneously then full duplex > is possible......... I haven't looked at the SimpleRead and SimpleWrite classes (I originally wrote my code for the javax.comm api), but full duplex is certainly possible. My CommReader class requires an object analogous to a OutputStream or Writer. When started, it spawns a thread that reads the comm port and writes to that output device. In this way the input is asynchronous and dependent on the actual input data. For full duplex, I extend that class with CommReaderWriter, which adds synchronous output methods. Hope that helps, George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From supsoop at hotmail.com Mon Jun 4 15:21:06 2007 From: supsoop at hotmail.com (soop soop) Date: Mon, 04 Jun 2007 21:21:06 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- Message-ID: Hi Guys, Looked through the archives but still cannot figure this out. I have a Motorola G24 GPRS/GSM modem that I am connecting to my server running Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not detecting the port, CommPortIdentifier.getPortIdentifiers(). I have added the line to RXTXCommDriver: "ttyACM" // for USB Modems Rxtx still does not seem to find the port. Is there something I am missing to make this port visable? [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control Model driver for USB modems and ISDN adapters I really need your help as I have moved my server from windows to Linux and have been down for a few days because of this .. Thanks so much! _________________________________________________________________ PC Magazine’s 2007 editors’ choice for best Web mail—award-winning Windows Live Hotmail. http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 From tjarvi at qbang.org Mon Jun 4 16:17:35 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Jun 2007 16:17:35 -0600 (MDT) Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: On Mon, 4 Jun 2007, soop soop wrote: > Hi Guys, > > Looked through the archives but still cannot figure this out. I have a > Motorola G24 GPRS/GSM modem that I am connecting to my server running Ubuntu. > I can see my modem as is shows up as ttyACM0, but RXTX is not detecting the > port, CommPortIdentifier.getPortIdentifiers(). > > I have added the line to RXTXCommDriver: > > "ttyACM" // for USB Modems > > Rxtx still does not seem to find the port. Is there something I am missing to > make this port visable? > > [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver > [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device > [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control Model > driver for USB modems and ISDN adapters > > I really need your help as I have moved my server from windows to Linux and > have been down for a few days because of this .. Thanks so much! > You could try the INSTALL documentation that comes with the source for possible solutions. Those usually involve lockfile creation, permissions on the device file or the device is in use by another application (even another session of your application). The usual commands: ls -l /dev/ttyACM0 fuser /dev/ttyACM0 touch /var/lock/LCK.testfile && rm -f /var/lock/LCK.testfile whoami To disable lockfiles: ../configure --disable-lockfiles && make install -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Jun 4 16:22:52 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 04 Jun 2007 18:22:52 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <466490BC.3090801@gatworks.com> soop soop wrote: > I really need your help as I have moved my server from windows to Linux > and have been down for a few days because of this .. Thanks so much! can u open the device ? ie is the file protection/permissions keeping you out? From supsoop at hotmail.com Mon Jun 4 16:44:40 2007 From: supsoop at hotmail.com (soop soop) Date: Mon, 04 Jun 2007 22:44:40 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <466490BC.3090801@gatworks.com> Message-ID: Thanks for the reply, I see no exceptions being thrown, just no detection of the port whats so ever. I will run rxtx in debug mode and log. If this were a permissions issue would I not see some exceptions being thrown? >From: Uncle George >Reply-To: RXTX Developers and Users >To: RXTX Developers and Users >Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >Date: Mon, 04 Jun 2007 18:22:52 -0400 > >soop soop wrote: > > > I really need your help as I have moved my server from windows to Linux > > and have been down for a few days because of this .. Thanks so much! > >can u open the device ? ie is the file protection/permissions keeping >you out? >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ Get a preview of Live Earth, the hottest event this summer - only on MSN http://liveearth.msn.com?source=msntaglineliveearthhm From netbeans at gatworks.com Mon Jun 4 17:06:15 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 04 Jun 2007 19:06:15 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <46649AE7.10405@gatworks.com> Exceptions on what? On startup it wants to lookup all devices in /dev that it is capable of opening ( within the list of specific 'comm' devices ). If it cannot open, then does not get onto list. Part of this process, if configured, will also test if the "LOCK" schema can also be opened for the device. then it gets on the list of avail comm port. soop soop wrote: > Thanks for the reply, > > I see no exceptions being thrown, just no detection of the port whats so > ever. I will run rxtx in debug mode and log. If this were a permissions > issue would I not see some exceptions being thrown? > > >> From: Uncle George >> Reply-To: RXTX Developers and Users >> To: RXTX Developers and Users >> Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >> Date: Mon, 04 Jun 2007 18:22:52 -0400 >> >> soop soop wrote: >> >>> I really need your help as I have moved my server from windows to Linux >>> and have been down for a few days because of this .. Thanks so much! >> can u open the device ? ie is the file protection/permissions keeping >> you out? >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _________________________________________________________________ > Get a preview of Live Earth, the hottest event this summer - only on MSN > http://liveearth.msn.com?source=msntaglineliveearthhm > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From alex.flint at gmail.com Mon Jun 4 21:31:49 2007 From: alex.flint at gmail.com (Alex Flint) Date: Tue, 5 Jun 2007 13:01:49 +0930 Subject: [Rxtx] random EXCEPTION_ACCESS_VIOLATION errors Message-ID: Hi All, I'm running winXP and RXTX 2.1-7r2 (the latest from the webpage as of June 2007). I'm sending sequences of 64 lines (each line has about 15 chars) at various intervals. The strings are sent fine, until I get the following error (from hs_err_pid3316.log, at the end of this email). What can I do to avoid the error? Obviously this is a low-level memory exception, but is there any way I can keep the JVM running after such an error? I noticed the exact same problem here: http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20070129/1180520.html Cheers, Alex # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x100034fb, pid=3316, tid=2400 # # Java VM: Java HotSpot(TM) Client VM (1.6.0_01-b06 mixed mode, sharing) # Problematic frame: # C [rxtxSerial.dll+0x34fb] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # --------------- T H R E A D --------------- Current thread (0x00386400): JavaThread "main" [_thread_in_native, id=2400] siginfo: ExceptionCode=0xc0000005, reading address 0x20726f78 Registers: EAX=0x20726f20, EBX=0x6d8922c0, ECX=0x00000005, EDX=0x20726f20 ESP=0x003efa30, EBP=0x003efb68, ESI=0x269728a0, EDI=0x00386400 EIP=0x100034fb, EFLAGS=0x00010212 Top of Stack: (sp=0x003efa30) 0x003efa30: 003efa3c 003efa64 0000000f ffffffff 0x003efa40: 003efa40 2a97f808 003efa6c 2b190ca8 0x003efa50: 00000000 2b190ec0 003efa90 008e2dd7 0x003efa60: 003efa90 008e2dd7 26977f88 6d815e72 0x003efa70: 00000004 2696eae0 0000008a 003efb0c 0x003efa80: 6d852b4a 2696eae0 00000003 26970930 0x003efa90: 000000cb 2696eae0 6d86b264 00385d40 0x003efaa0: 0000003f 003efb0c 26977f90 2ace65d8 Instructions: (pc=0x100034fb) 0x100034eb: ff ff 8d 76 00 eb 02 89 f6 90 8b 45 f8 8b 55 f8 0x100034fb: 8b 4a 58 83 c9 04 89 48 58 83 c4 f8 8b 45 f8 8b Stack: [0x003a0000,0x003f0000), sp=0x003efa30, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x34fb] Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j gnu.io.RXTXPort.writeArray([BIIZ)V+0 j gnu.io.RXTXPort$SerialOutputStream.write([B)V+76 j com.bjt.media.server.CommLink.send(Ljava/lang/String;)V+48 j com.bjt.media.server.DigitoolConnection.select(I)V+73 j com.bjt.media.server.DigitoolConnection.main([Ljava/lang/String;)V+74 v ~StubRoutines::call_stub --------------- P R O C E S S --------------- Java Threads: ( => current thread ) 0x02a69400 JavaThread "Thread-0" [_thread_in_native, id=3052] 0x02a4d000 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=3920] 0x02a48400 JavaThread "CompilerThread0" daemon [_thread_blocked, id=1968] 0x02a47400 JavaThread "Attach Listener" daemon [_thread_blocked, id=2984] 0x02a46400 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=2660] 0x02a41c00 JavaThread "Finalizer" daemon [_thread_blocked, id=3924] 0x02a3d800 JavaThread "Reference Handler" daemon [_thread_blocked, id=4008] =>0x00386400 JavaThread "main" [_thread_in_native, id=2400] Other Threads: 0x02a34400 VMThread [id=3708] 0x02a4e800 WatcherThread [id=3964] VM state:not at safepoint (normal execution) VM Mutex/Monitor currently owned by a thread: None Heap def new generation total 960K, used 131K [0x22960000, 0x22a60000, 0x22e40000) eden space 896K, 7% used [0x22960000, 0x22970ea8, 0x22a40000) from space 64K, 99% used [0x22a50000, 0x22a5fff8, 0x22a60000) to space 64K, 0% used [0x22a40000, 0x22a40000, 0x22a50000) tenured generation total 4096K, used 76K [0x22e40000, 0x23240000, 0x26960000) the space 4096K, 1% used [0x22e40000, 0x22e53060, 0x22e53200, 0x23240000) compacting perm gen total 12288K, used 137K [0x26960000, 0x27560000, 0x2a960000) the space 12288K, 1% used [0x26960000, 0x26982518, 0x26982600, 0x27560000) ro space 8192K, 62% used [0x2a960000, 0x2ae5e4e8, 0x2ae5e600, 0x2b160000) rw space 12288K, 52% used [0x2b160000, 0x2b7a0e78, 0x2b7a1000, 0x2bd60000) Dynamic libraries: 0x00400000 - 0x00423000 C:\Program Files\Java\jre1.6.0_01\bin\javaw.exe 0x7c900000 - 0x7c9b0000 C:\WINDOWS\system32\ntdll.dll 0x7c800000 - 0x7c8f4000 C:\WINDOWS\system32\kernel32.dll 0x77dd0000 - 0x77e6b000 C:\WINDOWS\system32\ADVAPI32.dll 0x77e70000 - 0x77f01000 C:\WINDOWS\system32\RPCRT4.dll 0x7e410000 - 0x7e4a0000 C:\WINDOWS\system32\USER32.dll 0x77f10000 - 0x77f57000 C:\WINDOWS\system32\GDI32.dll 0x76390000 - 0x763ad000 C:\WINDOWS\system32\IMM32.DLL 0x7c340000 - 0x7c396000 C:\Program Files\Java\jre1.6.0_01\bin\msvcr71.dll 0x6d7c0000 - 0x6da07000 C:\Program Files\Java\jre1.6.0_01\bin\client\jvm.dll 0x76b40000 - 0x76b6d000 C:\WINDOWS\system32\WINMM.dll 0x5cd70000 - 0x5cd77000 C:\WINDOWS\system32\serwvdrv.dll 0x5b0a0000 - 0x5b0a7000 C:\WINDOWS\system32\umdmxfrm.dll 0x6d310000 - 0x6d318000 C:\Program Files\Java\jre1.6.0_01\bin\hpi.dll 0x76bf0000 - 0x76bfb000 C:\WINDOWS\system32\PSAPI.DLL 0x6d770000 - 0x6d77c000 C:\Program Files\Java\jre1.6.0_01\bin\verify.dll 0x6d3b0000 - 0x6d3cf000 C:\Program Files\Java\jre1.6.0_01\bin\java.dll 0x6d7b0000 - 0x6d7bf000 C:\Program Files\Java\jre1.6.0_01\bin\zip.dll 0x10000000 - 0x10012000 C:\Documents and Settings\Alex\workspace\MediaServer\rxtxSerial.dll 0x73d90000 - 0x73db7000 C:\WINDOWS\system32\crtdll.dll VM Arguments: jvm_args: -Djava.library.path=C:\Documents and Settings\Alex\workspace\MediaServer java_command: com.bjt.media.server.DigitoolConnection Launcher Type: SUN_STANDARD Environment Variables: CLASSPATH=.;C:\Program Files\Java\j2re1.4.2_07\lib\ext\QTJava.zip PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\wbem;c:\applications\php;C:\Program Files\MATLAB\R2006a\bin\win32;C:\Roger\Projects\UAV\Bin\Debug;C:\Program Files\Microsoft SQL Server\80\Tools\Binn\;c:\Program Files\Microsoft SQL Server\90\Tools\binn\;C:\Program Files\QuickTime\QTSystem\;C:\Pfps\system;C:\Program Files\Java\jdk1.6.0_01\bin;C:\Program Files\Java\jdk1.6.0_01\jre\bin USERNAME=Alex OS=Windows_NT PROCESSOR_IDENTIFIER=x86 Family 15 Model 4 Stepping 1, GenuineIntel --------------- S Y S T E M --------------- OS: Windows XP Build 2600 Service Pack 2 CPU:total 1 family 15, cmov, cx8, fxsr, mmx, sse, sse2 Memory: 4k page, physical 1046508k(275288k free), swap 2522816k(1909176k free) vm_info: Java HotSpot(TM) Client VM (1.6.0_01-b06) for windows-x86, built on Mar 14 2007 00:24:02 by "java_re" with unknown MS VC++:1310 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070604/c87ae1f0/attachment-0004.html From alwyn.schoeman at gmail.com Tue Jun 5 00:10:19 2007 From: alwyn.schoeman at gmail.com (Alwyn Schoeman) Date: Tue, 5 Jun 2007 08:10:19 +0200 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Hi, I'm using a similar modem. By default rxtx doesn't look for devices that start with ACM, so you need to modify the source code and recompile. Look in RXTXCommDriver and add values for ACM in the registerScannedPorts method in the Linux specific parts. Look for osName.equals("Linux")... On 6/4/07, soop soop wrote: > > Hi Guys, > > Looked through the archives but still cannot figure this out. I have a > Motorola G24 GPRS/GSM modem that I am connecting to my server running > Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not > detecting the port, CommPortIdentifier.getPortIdentifiers(). > > I have added the line to RXTXCommDriver: > > "ttyACM" // for USB Modems > > Rxtx still does not seem to find the port. Is there something I am missing > to make this port visable? > > [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver > [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device > [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control > Model > driver for USB modems and ISDN adapters > > I really need your help as I have moved my server from windows to Linux > and > have been down for a few days because of this .. Thanks so much! > > _________________________________________________________________ > PC Magazine's 2007 editors' choice for best Web mail?award-winning Windows > Live Hotmail. > > http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -- Alwyn Schoeman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/b6cb3053/attachment-0004.html From naranjo.manuel at gmail.com Tue Jun 5 06:48:45 2007 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Tue, 05 Jun 2007 09:48:45 -0300 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> References: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Message-ID: <46655BAD.7010501@gmail.com> That's right, an easier solution is creating symlinks to acm. For example make ttyS70 to 79 point to ACM0 to 9 and that will help you a lot, and doesn't even require compile. > Hi, > > I'm using a similar modem. By default rxtx doesn't look for devices > that start with ACM, so you need to modify the > source code and recompile. > > Look in RXTXCommDriver and add values for ACM in the > registerScannedPorts method in the Linux specific parts. Look for > osName.equals("Linux")... > From juanemc2 at gmail.com Tue Jun 5 07:02:43 2007 From: juanemc2 at gmail.com (Juan) Date: Tue, 5 Jun 2007 10:02:43 -0300 Subject: [Rxtx] Problems with Epson TMU220B POSPrinter using XON/XOFF Flow Control and rxtx jar and dll's with the serial port. Message-ID: Hi!, I?m having trouble printing to the serial port using the latest version of rxtx jar and dll's with an Epson POSPrinter. I`ve switched the printer to work with XON/XOFF Flow Control and have watched the serial port to be sure the printer is sending the XON XOFF stop and go characters. I`ve setted the port like this: CommPortIdentifier commPortIdentifier = CommPortIdentifier.* getPortIdentifier*(_portName); SerialPort serialPort = (SerialPort)commPortIdentifier.open(*this*.getClass().getName(), 2000); serialPort.setSerialPortParams(_baudRate, _dataBits, _stopBits, _parity); serialPort.setFlowControlMode( SerialPort.*FLOWCONTROL_XONXOFF_IN* | SerialPort.*FLOWCONTROL_XONXOFF_OUT*); where the baudRate is 9600 the dataBits is 8 the stopBits is 1 and the parity is 0 It seems as the library isn`t taking into account the XON XOFF setting. I would like to know if I`m setting correctly the Flow Control and if you had had any experiences using XON XOFF flow control and could give me some help to solve my problem. I`m very thankful in advance, Yours, Juan Polero -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/b080995a/attachment-0004.html From ehdez.correo at gmail.com Tue Jun 5 07:12:53 2007 From: ehdez.correo at gmail.com (=?ISO-8859-1?Q?Enrique_Hern=E1ndez?=) Date: Tue, 5 Jun 2007 09:12:53 -0400 Subject: [Rxtx] problem with rxtx Message-ID: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Hello: I doing a simple test to show the serial ports. This is the code: import java.util.Enumeration; import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; public class Show { private Enumeration portList; private CommPortIdentifier portId; private SerialPort port; /** Creates a new instance of Show */ public Show() { } public static void main(String args[]){ Show show = new Show(); show.portList = CommPortIdentifier.getPortIdentifiers(); String tPort = ""; System.out.println("========================================="); while(show.portList.hasMoreElements()){ show.portId = (CommPortIdentifier)show.portList.nextElement(); if(show.portId.getPortType() == CommPortIdentifier.PORT_SERIAL) tPort = "Serial"; else tPort = "Parallel"; System.out.println(show.portId.getName() + " " + tPort); } } } whit The problem is that this code not show the serial ports, this show the no use serial ports. I want to connect whit the modem but when windows open and connect the modem my application don't see the port(COMM3) when it is connect. what I can do? Is that the correct way to know the ports? thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/eedd744b/attachment-0004.html From ehdez.correo at gmail.com Tue Jun 5 07:42:13 2007 From: ehdez.correo at gmail.com (=?ISO-8859-1?Q?Enrique_Hern=E1ndez?=) Date: Tue, 5 Jun 2007 09:42:13 -0400 Subject: [Rxtx] serial port Message-ID: <4a814e1f0706050642p4ce9ac7bka80f9479c524c5ea@mail.gmail.com> Hello: How I can ask to the port what device is connect and information about this device. thanks. bye. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/4d10d26a/attachment-0004.html From supsoop at hotmail.com Tue Jun 5 09:29:00 2007 From: supsoop at hotmail.com (soop soop) Date: Tue, 05 Jun 2007 15:29:00 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Message-ID: Hi Guys, Thanks for all your help. I found the problem. I created a user, Tomcat55, for my tomcat but it did not belong to any group. I then added this user to dialout group to have access to the device ttyACM0. Works perfectly! Again permissions was the issue. This also seems to be persistent as a server reboot does not effect the access. Cheers! >From: "Alwyn Schoeman" >Reply-To: RXTX Developers and Users >To: "RXTX Developers and Users" >Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >Date: Tue, 5 Jun 2007 08:10:19 +0200 > >Hi, > >I'm using a similar modem. By default rxtx doesn't look for devices that >start with ACM, so you need to modify the >source code and recompile. > >Look in RXTXCommDriver and add values for ACM in the registerScannedPorts >method in the Linux specific parts. Look for osName.equals("Linux")... > >On 6/4/07, soop soop wrote: >> >>Hi Guys, >> >>Looked through the archives but still cannot figure this out. I have a >>Motorola G24 GPRS/GSM modem that I am connecting to my server running >>Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not >>detecting the port, CommPortIdentifier.getPortIdentifiers(). >> >>I have added the line to RXTXCommDriver: >> >>"ttyACM" // for USB Modems >> >>Rxtx still does not seem to find the port. Is there something I am missing >>to make this port visable? >> >>[ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver >>[ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device >>[ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control >>Model >>driver for USB modems and ISDN adapters >> >>I really need your help as I have moved my server from windows to Linux >>and >>have been down for a few days because of this .. Thanks so much! >> >>_________________________________________________________________ >>PC Magazine's 2007 editors' choice for best Web mail—award-winning Windows >>Live Hotmail. >> >>http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 >> >> >>_______________________________________________ >>Rxtx mailing list >>Rxtx at qbang.org >>http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > >-- >Alwyn Schoeman >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ Need a break? Find your escape route with Live Search Maps. http://maps.live.com/default.aspx?ss=Restaurants~Hotels~Amusement%20Park&cp=33.832922~-117.915659&style=r&lvl=13&tilt=-90&dir=0&alt=-1000&scene=1118863&encType=1&FORM=MGAC01 From netbeans at gatworks.com Tue Jun 5 09:42:31 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 11:42:31 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <46658467.20101@gatworks.com> soop soop wrote: > > Hi Guys, > > Thanks for all your help. I found the problem. I created a user, > Tomcat55, for my tomcat but it did not belong to any group. I then added Look at man pages for the program udev. From tjarvi at qbang.org Tue Jun 5 18:18:17 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Jun 2007 18:18:17 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Message-ID: On Tue, 5 Jun 2007, Enrique Hern?ndez wrote: > The problem is that this code not show the serial ports, this show the no > use serial ports. I want to connect whit the modem but when windows open and > connect the modem my application don't see the port(COMM3) when it is > connect. > what I can do? > Is that the correct way to know the ports? > Hello, We may have problems understanding each other. On windows, the port will not be an available serial port if another application has the port open. That is just how the library behaves. If you can not see the port in the enumerated list, you could not open it. Also note that enumeration only happens once. If you add a port such as a new USB dongle, the port will not be visible until the next time your application runs. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Tue Jun 5 18:45:01 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 20:45:01 -0400 Subject: [Rxtx] problem with rxtx In-Reply-To: References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Message-ID: <4666038D.8090700@gatworks.com> Trent Jarvi wrote: > > > Also note that enumeration only happens once. If you add a port such as > a new USB dongle, the port will not be visible until the next time your > application runs. Is this written in stone ? somewhere? From tjarvi at qbang.org Tue Jun 5 18:54:36 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Jun 2007 18:54:36 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <4666038D.8090700@gatworks.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> Message-ID: On Tue, 5 Jun 2007, Uncle George wrote: > Trent Jarvi wrote: >> >> >> Also note that enumeration only happens once. If you add a port such as >> a new USB dongle, the port will not be visible until the next time your >> application runs. > > Is this written in stone ? somewhere? It is just the current behavior. There is nothing preventing a fix that allows reenumeration. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Tue Jun 5 19:55:19 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 21:55:19 -0400 Subject: [Rxtx] problem with rxtx In-Reply-To: References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> Message-ID: <46661407.4020308@gatworks.com> >> Is this written in stone ? somewhere? > > It is just the current behavior. There is nothing preventing a fix that > allows reenumeration. With usb, ..... , things come and go. Seems a shame that you have to kill application to get at the device u just plugged in. From joachim at buechse.ch Wed Jun 6 01:50:06 2007 From: joachim at buechse.ch (Joachim Buechse) Date: Wed, 6 Jun 2007 09:50:06 +0200 Subject: [Rxtx] problem with rxtx In-Reply-To: <46661407.4020308@gatworks.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> <46661407.4020308@gatworks.com> Message-ID: <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> On MacOS RXTX's enumeration handling is more flexible. It will find new ports that are added during the lifetime of the application. But this is inherently incompatible with suns javax.comm implementation... Regards, Joachim On 06.06.2007, at 03:55, Uncle George wrote: > >>> Is this written in stone ? somewhere? >> >> It is just the current behavior. There is nothing preventing a >> fix that >> allows reenumeration. > > With usb, ..... , things come and go. Seems a shame that you have to > kill application to get at the device u just plugged in. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Jun 6 06:06:48 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Jun 2007 06:06:48 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> <46661407.4020308@gatworks.com> <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> Message-ID: Sun's javax.comm is not a major concern going forward. As long as we do not break old applications using rxtx, I see no reason to limit rxtx to that convention. We have already rejected version 3 from Sun as a dead end and limited our compatability to version 2. That does not mean we will not try to work with Sun and others but the current javax.comm convention (v3) is not a well conceived path. There has been discussion about doing a JSR which is one valid option. On Wed, 6 Jun 2007, Joachim Buechse wrote: > On MacOS RXTX's enumeration handling is more flexible. It will find > new ports that are added during the lifetime of the application. But > this is inherently incompatible with suns javax.comm implementation... > > Regards, > Joachim > > On 06.06.2007, at 03:55, Uncle George wrote: > >> >>>> Is this written in stone ? somewhere? >>> >>> It is just the current behavior. There is nothing preventing a >>> fix that >>> allows reenumeration. >> >> With usb, ..... , things come and go. Seems a shame that you have to >> kill application to get at the device u just plugged in. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From yvespielusenet at free.fr Wed Jun 6 08:46:35 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 16:46:35 +0200 Subject: [Rxtx] [PARALLEL] resource in use Message-ID: <1181141195.3407.20.camel@localhost.localdomain> Hello, I want to use rxtx in my application. I haveto send data to a very old printer (which have a drum and hammers http://perso.orange.fr/tiie/page00010017.html) This is printer is connecter with centronics. It works well but, while it's writting and I putthe printer off-line, after about 45 seconds, I have this error : ------------------------------------- java.io.IOException: La ressource demand?e est en cours d'utilisation. in writeArray at gnu.io.LPRPort.writeArray(Native Method) at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:292) at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:161) at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:156) at mce.buffer.bufferManager.BufferManager$PrintBuffer.run(BufferManager.java:141) The IOexception means "The wanted resource is in use" ------------------------------------- Here is the line 141 of BufferManager : ------------------------------------- while(send){ try{ fos.write(bb); <=== line 141 send = false; } catch(Exception e){ javax.swing.JOptionPane.showMessageDialog(null, "Erreur d'envoie. Veuillez cliquer sur OK pour relancer l'impression de la vignette.\nV?rifiez votre impression !", "Erreur d'envoie", javax.swing.JOptionPane.WARNING_MESSAGE); e.printStackTrace(System.err); System.err.flush(); System.out.println(e); send = true; } } -------------------------------- 'fos' is an outputstream which contains the rxtx stream (this.os is the rxtx outputstream) : -------------------------------- public void write(byte[] bb) throws IOException{ this.write(bb, 0, bb.length); } public void write(byte[] bb, int off, int len) throws IOException{ while(!imp1.isPrinterSelected() || !imp2.isPrinterSelected()){ } this.os.write(bb, off, len); } -------------------------------- Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( can you help me ? thank you :) -- yves piel From yvespielusenet at free.fr Wed Jun 6 09:11:15 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 17:11:15 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181141195.3407.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> Message-ID: <1181142675.3407.23.camel@localhost.localdomain> I forgot to tell that It's under windows XP and java 1.5. Le mercredi 06 juin 2007 ? 16:46 +0200, yves pielusenet a ?crit : > Hello, > I want to use rxtx in my application. I haveto send data to a very old > printer (which have a drum and hammers > http://perso.orange.fr/tiie/page00010017.html) > This is printer is connecter with centronics. It works well but, while > it's writting and I putthe printer off-line, after about 45 seconds, I > have this error : > ------------------------------------- > java.io.IOException: La ressource demand?e est en cours d'utilisation. > in writeArray > at gnu.io.LPRPort.writeArray(Native Method) > at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:292) > at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:161) > at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:156) > at mce.buffer.bufferManager.BufferManager$PrintBuffer.run(BufferManager.java:141) > > The IOexception means "The wanted resource is in use" > ------------------------------------- > > Here is the line 141 of BufferManager : > > ------------------------------------- > while(send){ > try{ > fos.write(bb); <=== line 141 > send = false; > } > catch(Exception e){ > javax.swing.JOptionPane.showMessageDialog(null, "Erreur d'envoie. Veuillez cliquer sur OK pour relancer l'impression de la vignette.\nV?rifiez votre impression !", "Erreur d'envoie", javax.swing.JOptionPane.WARNING_MESSAGE); > e.printStackTrace(System.err); > System.err.flush(); > System.out.println(e); > send = true; > } > } > -------------------------------- > 'fos' is an outputstream which contains the rxtx stream (this.os is the rxtx outputstream) : > > -------------------------------- > public void write(byte[] bb) throws IOException{ > this.write(bb, 0, bb.length); > } > public void write(byte[] bb, int off, int len) throws IOException{ > while(!imp1.isPrinterSelected() || !imp2.isPrinterSelected()){ > } > this.os.write(bb, off, len); > } > -------------------------------- > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > can you help me ? > > thank you :) > From netbeans at gatworks.com Wed Jun 6 09:21:46 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 11:21:46 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181141195.3407.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> Message-ID: <4666D10A.8000507@gatworks.com> } > -------------------------------- > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > can you help me ? > > thank you :) > windoz or linux? ( I guess windoz ) for windoz, there appears to be a timeout ( as Comments suggest ) of about 40seconds. > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } for linux, there is no implied timeout. > if( write( fd, bytes, count ) < 0 ) > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); From netbeans at gatworks.com Wed Jun 6 09:39:41 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 11:39:41 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666D10A.8000507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> Message-ID: <4666D53D.90000@gatworks.com> Uncle George wrote: > } >> -------------------------------- >> >> Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( >> >> can you help me ? From reading the code, I can see your concern. And it appears you are correct, because some of the data will be sent to the OS printer buffers, and then it will refuse to accept anymore. Unfortunately, writeArray does not return the num of characters written :{ So application has no idea to how many characters were accepted by the OS. I dont do windoz, so I cant say with absolute certainty what windoz will do with an off-line condition. If you have the source, and can compile, then maybe u can increase the loop count to hit 4hours? From yvespielusenet at free.fr Wed Jun 6 09:53:25 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 17:53:25 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666D10A.8000507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> Message-ID: <1181145205.3407.35.camel@localhost.localdomain> Thank you for your explanation :) This timeout comes when no data has been send to the printer after 40seconds if I well understand. But why there is such a timeout ? If I setthe printer offline while it's printing I mustn't have an exception. I don't understand why the "printer should solv all problems like buffer full" in 40 seconds. If I pause the printer the buffer will not be emptied, isn't it ? I not very familiar with C/C++, but it seem that the exception is thrown only when countWritten == 0, that means no data at all has been sent. So Is my code is good since when I intercept this exception I send all my buffer again. There is no way that the printer receive two times same bytes ? thanks ps: yes the application is running on windows XP since I developpe under Debian Le mercredi 06 juin 2007 ? 11:21 -0400, Uncle George a ?crit : > } > > -------------------------------- > > > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > > > can you help me ? > > > > thank you :) > > > > windoz or linux? ( I guess windoz ) > > for windoz, there appears to be a timeout ( as Comments suggest ) of > about 40seconds. > > while( count > 0 ){ > > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > > /* > > this are 20 * 2 seconds, in this time a printer (or other parallel device) > > should solv all problems like buffer full, etc > > */ > > if(errorCount++ < 20){ > > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > > continue; > > } > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > for linux, there is no implied timeout. > > if( write( fd, bytes, count ) < 0 ) > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Wed Jun 6 10:34:24 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 12:34:24 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181145205.3407.35.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> Message-ID: <4666E210.30507@gatworks.com> yves pielusenet wrote: > Thank you for your explanation :) > This timeout comes when no data has been send to the printer after > 40seconds if I well understand. But why there is such a timeout ? If I > setthe printer offline while it's printing I mustn't have an exception. > I don't understand why the "printer should solv all problems like buffer > full" in 40 seconds. If I pause the printer the buffer will not be > emptied, isn't it ? > > I not very familiar with C/C++, but it seem that the exception is thrown > only when countWritten == 0, that means no data at all has been sent. So > Is my code is good since when I intercept this exception I send all my > buffer again. There is no way that the printer receive two times same > bytes ? More technically, the function call returns and reports that 0 characters was written in this call. when 0 characters are written, it will check how many times 0 characters was written. If it has tried LESS than 20 times(errorCount), it will sleep() and try to write again. After 20 times, it wont sleep, but throw you the exception. Now suppose you are writing a 120 character line. you off-lined/paused your printer. The OS has room for 80 more characters in it's printer buffer. The WriteFile() will have a char count of 120, but on return the countWritten = 80. You still have 40 more characters to print. Since countWritten != 0, the counters: bytes += countWritten; count -= countWritten; get updated, and the Writefile now has a count of 40 characters. Since the printer is off-line, the countwritten is 0. And so the loop continues, till 40 seconds is up. As to why it is this way, i dont know ( not a windoz maven ); Also the sleep(20) in the loop is not so intuitive to suggest 2 seconds of sleep. I would have guessed 20seconds, or 20milliseconds. But go figure. BTW: Since your computer sends you error messages in French, does it curse in English? :)))) From yvespielusenet at free.fr Thu Jun 7 02:27:44 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Thu, 07 Jun 2007 10:27:44 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666E210.30507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> Message-ID: <1181204864.3501.10.camel@localhost.localdomain> Maybe in my case I should re-compile rxtx and change the code. Instead of send an exception I should display a dialog box to ask if it's printer problem or if it should trie to send bytes. Something like : while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } if(displayDialogBox("Try again to send datas ??")){ errorCount = 0; } else{ throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } } Le mercredi 06 juin 2007 ? 12:34 -0400, Uncle George a ?crit : > yves pielusenet wrote: > > Thank you for your explanation :) > > This timeout comes when no data has been send to the printer after > > 40seconds if I well understand. But why there is such a timeout ? If I > > setthe printer offline while it's printing I mustn't have an exception. > > I don't understand why the "printer should solv all problems like buffer > > full" in 40 seconds. If I pause the printer the buffer will not be > > emptied, isn't it ? > > > > I not very familiar with C/C++, but it seem that the exception is thrown > > only when countWritten == 0, that means no data at all has been sent. So > > Is my code is good since when I intercept this exception I send all my > > buffer again. There is no way that the printer receive two times same > > bytes ? > More technically, the function call returns and reports that 0 > characters was written in this call. > when 0 characters are written, it will check how many times 0 characters > was written. If it has tried LESS than 20 times(errorCount), it will > sleep() and try to write again. > After 20 times, it wont sleep, but throw you the exception. > > Now suppose you are writing a 120 character line. you off-lined/paused > your printer. The OS has room for 80 more characters in it's printer > buffer. The WriteFile() will have a char count of 120, but on return the > countWritten = 80. You still have 40 more characters to print. > Since countWritten != 0, the counters: > bytes += countWritten; > count -= countWritten; > get updated, and the Writefile now has a count of 40 characters. Since > the printer is off-line, the countwritten is 0. And so the loop > continues, till 40 seconds is up. > > As to why it is this way, i dont know ( not a windoz maven ); > Also the sleep(20) in the loop is not so intuitive to suggest 2 seconds > of sleep. I would have guessed 20seconds, or 20milliseconds. But go figure. > > BTW: Since your computer sends you error messages in French, does it > curse in English? :)))) > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 06:11:43 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 08:11:43 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181204864.3501.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> Message-ID: <4667F5FF.8070903@gatworks.com> your suggestion appears good. I dont know what displayDialogBox exactly will do, so all I can say it that it looks good. But I'd like to wait 10min before first dialog box And a 5 min wait for every dialog box there after. And since these are custom solution/choices, maybe a more exact explanation of what the issue is. if(errorCount++ < 300){ // wait 10min ( 10min * 60sec / 2 ) Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } if(displayDialogBox("Printer has Paused. Retry sending data?")){ errorCount = 150; // Wait for 5 min thereafter continue; } > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } yves pielusenet wrote: > Maybe in my case I should re-compile rxtx and change the code. Instead > of send an exception I should display a dialog box to ask if it's > printer problem or if it should trie to send bytes. Something like : > > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > > if(displayDialogBox("Try again to send datas ??")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > } > From yvespielusenet at free.fr Thu Jun 7 07:17:21 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Thu, 07 Jun 2007 15:17:21 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4667F5FF.8070903@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <4667F5FF.8070903@gatworks.com> Message-ID: <1181222241.3501.20.camel@localhost.localdomain> thank you :) 'displayDialogBox()' I think doesn't exist. It was just for the example :) But I think It should not be so complicated to display a dialog box under windows with YES/NO buttons. When yes is clicked it return 0 other it returns 1. Le jeudi 07 juin 2007 ? 08:11 -0400, Uncle George a ?crit : > your suggestion appears good. I dont know what displayDialogBox exactly > will do, so all I can say it that it looks good. > > But I'd like to wait 10min before first dialog box And a 5 min wait for > every dialog box there after. And since these are custom > solution/choices, maybe a more exact explanation of what the issue is. > > if(errorCount++ < 300){ // wait 10min ( 10min * 60sec / 2 ) > Sleep( 20 ); /* make a small pause to execute all other requests > in all other threads */ > continue; > } > > if(displayDialogBox("Printer has Paused. Retry sending data?")){ > errorCount = 150; // Wait for 5 min thereafter > continue; > } > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > > yves pielusenet wrote: > > Maybe in my case I should re-compile rxtx and change the code. Instead > > of send an exception I should display a dialog box to ask if it's > > printer problem or if it should trie to send bytes. Something like : > > > > while( count > 0 ){ > > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > > /* > > this are 20 * 2 seconds, in this time a printer (or other parallel device) > > should solv all problems like buffer full, etc > > */ > > if(errorCount++ < 20){ > > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > > continue; > > } > > > > if(displayDialogBox("Try again to send datas ??")){ > > errorCount = 0; > > } > > else{ > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > } > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 07:41:43 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 09:41:43 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181222241.3501.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <4667F5FF.8070903@gatworks.com> <1181222241.3501.20.camel@localhost.localdomain> Message-ID: <46680B17.8050109@gatworks.com> yves pielusenet wrote: > thank you :) > 'displayDialogBox()' I think doesn't exist. It was just for the > example :) too bad. Good luck. From rtrout at webbresearch.com Thu Jun 7 11:23:04 2007 From: rtrout at webbresearch.com (Robert Trout) Date: Thu, 07 Jun 2007 13:23:04 -0400 Subject: [Rxtx] Disconnected PortServer TS causes Java to hang Message-ID: <1181236984.14186.33.camel@sisyphus.DinkumSoftware.com> I'm running Linux with sun's Java 1.4.2, Java comm API 2.0, RXTX 2.0-7pre1, and the RealPort digi driver. "/dev/ttyrp00" is a RealPort device. My Java application never returns from a ComPortIdentifier.getPortIdentifier("/dev/ttyrp00") call while the Digi PortServer TS 4 is disconnected from the network. If I later re-connect the PortServer, the call returns about 30 seconds later (it's like a serial port read or write is blocking until the PortServer is re- connected). With the PortServer disconnected, minicom immediately responds with "cannot open /dev/ttyrp00: No such file or directory". I would like my Java application to behave similarly. That is, respond with an error condition instead of hanging when the PortServer is not connected. Since minicom and Java behave differently, I think this "hanging" behavior may be due to RXTX or Java? Has anyone had a similar issue? Solutions? Suggestions? Thanks, Robert From vicnevicne at gmail.com Thu Jun 7 12:16:02 2007 From: vicnevicne at gmail.com (Vicne) Date: Thu, 07 Jun 2007 20:16:02 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181204864.3501.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> Message-ID: <46684B62.7080802@gmail.com> yves pielusenet wrote: > Maybe in my case I should re-compile rxtx and change the code. Instead > of send an exception I should display a dialog box to ask if it's > printer problem or if it should trie to send bytes. Something like : > > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > > if(displayDialogBox("Try again to send datas ??")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > } > Sorry to step in without a specific solution to your problem, but I wanted to share my feeling regarding this proposal. AFAIK, it's generally considered bad practice to pop-up a prompt from a library. The main reason is that in general use, you can't guarantee that someone is actually present behind the console. Imagine a print server in a machine room, connected to a park of printers. In that case, when one printer fails, the logical behaviour would be to use an other one. If you change RxTx the way you propose, the printer queue will simply be stuck with a useless "Try again to send data ?" prompt until an administrator opens a remote connection to the print server's console and clicks "no". Second, it would create a dependency upon the existence of a graphical console (if you go the graphical "dialogBox" way). On many applications (typically server or embedded ones), the JVM is "headless" and if you try to pop-up a dialog, your app would throw an exception (at best) or just wouldn't display the prompt anywhere... Going the "text console" way is not more reliable, because on graphical environments, the text console is hidden unless explicitly requested. My advice would be to think again and find another solution. Ideas are : - make the number of retries a parameter so that you can tune it to what you think is reasonable - throw a more specific exception when the number of retries has been reached, so that a specific prompt can be shown at a higher level Anyway, if you feel that the prompt is the way to go in your case, I would at least make that prompt conditional. The least intrusive way would probably be using a system property, like if("true".equals(System.getProperty("org.rxtx.usePrompt")) && displayDialogBox("Retry sending data ?")){ errorCount = 0; } else{ throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } By default, the behaviour would remain as it is now, but you could force the prompts by defining the property at VM launch if desired. (for example : java.exe -Dorg.rxtx.usePrompt=true myApp) Also, you seemed to say you wanted the printer to start again exactly where is stopped. It would indeed be the best way when the printer is put offline for a few seconds. On the other hand, if the printer is turned off (or the printer runs out of paper, or someone steps on the mains cable), then the only way to go back to a "stable" situation would be by printing the item (page, label, etc.) again from scratch... Just my two cents. Vicne PS : By the way, the dialog box thing is very platform dependant on the C-side, and I think the simplest way would probably be to bridge it to a Java call where you can implement it like you proposed : public boolean displayDialogBox(prompt) { return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); } From netbeans at gatworks.com Thu Jun 7 14:08:24 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 16:08:24 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46684B62.7080802@gmail.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> Message-ID: <466865B8.4060004@gatworks.com> My feeling is that the code that was suggested was for his environs ( his shop ). The issue here is that after a 40+ second wait, an exception will be thrown. But you really dont have a way of 'cancelling' all the WriteFiles() that have already occured before the exception so that your writeArray and the Commapi can backtrack to a position in which they are in sync. The main ( really mine ) concern is not to lose data, or replicate data. After 40seconds, 300 seconds, 55min, no matter how long, data should not be lost or duplicated. But as soon as the exception is thrown, that possibility exists. Maybe an event should be thrown instead? Vicne wrote: > yves pielusenet wrote: >> Maybe in my case I should re-compile rxtx and change the code. Instead >> of send an exception I should display a dialog box to ask if it's >> printer problem or if it should trie to send bytes. Something like : >> >> while( count > 0 ){ >> if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ >> /* >> this are 20 * 2 seconds, in this time a printer (or other parallel device) >> should solv all problems like buffer full, etc >> */ >> if(errorCount++ < 20){ >> Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ >> continue; >> } >> >> if(displayDialogBox("Try again to send datas ??")){ >> errorCount = 0; >> } >> else{ >> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >> break; >> } >> } >> > > Sorry to step in without a specific solution to your problem, but I > wanted to share my feeling regarding this proposal. AFAIK, it's > generally considered bad practice to pop-up a prompt from a library. > The main reason is that in general use, you can't guarantee that > someone is actually present behind the console. Imagine a print server > in a machine room, connected to a park of printers. In that case, when > one printer fails, the logical behaviour would be to use an other one. > If you change RxTx the way you propose, the printer queue will simply be > stuck with a useless "Try again to send data ?" prompt until an > administrator opens a remote connection to the print server's console > and clicks "no". > Second, it would create a dependency upon the existence of a > graphical console (if you go the graphical "dialogBox" way). On many > applications (typically server or embedded ones), the JVM is "headless" > and if you try to pop-up a dialog, your app would throw an exception (at > best) or just wouldn't display the prompt anywhere... Going the "text > console" way is not more reliable, because on graphical environments, > the text console is hidden unless explicitly requested. > > My advice would be to think again and find another solution. Ideas are : > - make the number of retries a parameter so that you can tune it to what > you think is reasonable > - throw a more specific exception when the number of retries has been > reached, so that a specific prompt can be shown at a higher level > > Anyway, if you feel that the prompt is the way to go in your case, I > would at least make that prompt conditional. The least intrusive way > would probably be using a system property, like > > if("true".equals(System.getProperty("org.rxtx.usePrompt")) > && displayDialogBox("Retry sending data ?")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > > > By default, the behaviour would remain as it is now, but you could > force the prompts by defining the property at VM launch if desired. (for > example : java.exe -Dorg.rxtx.usePrompt=true myApp) > > > Also, you seemed to say you wanted the printer to start again > exactly where is stopped. It would indeed be the best way when the > printer is put offline for a few seconds. On the other hand, if the > printer is turned off (or the printer runs out of paper, or someone > steps on the mains cable), then the only way to go back to a "stable" > situation would be by printing the item (page, label, etc.) again from > scratch... > > > Just my two cents. > > > Vicne > > PS : By the way, the dialog box thing is very platform dependant on the > C-side, and I think the simplest way would probably be to bridge it to a > Java call where you can implement it like you proposed : > > public boolean displayDialogBox(prompt) { > return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", > JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); > } > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Thu Jun 7 17:48:11 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 Jun 2007 17:48:11 -0600 (MDT) Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <466865B8.4060004@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> Message-ID: An event is possible. I'm amazed this is the largest problem encountered while using the parallel code. How would the write ever exit if we throw events? Isn't this going to lead to hung applications? On Thu, 7 Jun 2007, Uncle George wrote: > My feeling is that the code that was suggested was for his environs ( > his shop ). > > The issue here is that after a 40+ second wait, an exception will be > thrown. But you really dont have a way of 'cancelling' all the > WriteFiles() that have already occured before the exception so that your > writeArray and the Commapi can backtrack to a position in which they are > in sync. > > The main ( really mine ) concern is not to lose data, or replicate data. > After 40seconds, 300 seconds, 55min, no matter how long, data should > not be lost or duplicated. But as soon as the exception is thrown, that > possibility exists. > > Maybe an event should be thrown instead? > > Vicne wrote: >> yves pielusenet wrote: >>> Maybe in my case I should re-compile rxtx and change the code. Instead >>> of send an exception I should display a dialog box to ask if it's >>> printer problem or if it should trie to send bytes. Something like : >>> >>> while( count > 0 ){ >>> if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ >>> /* >>> this are 20 * 2 seconds, in this time a printer (or other parallel device) >>> should solv all problems like buffer full, etc >>> */ >>> if(errorCount++ < 20){ >>> Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ >>> continue; >>> } >>> >>> if(displayDialogBox("Try again to send datas ??")){ >>> errorCount = 0; >>> } >>> else{ >>> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >>> break; >>> } >>> } >>> >> >> Sorry to step in without a specific solution to your problem, but I >> wanted to share my feeling regarding this proposal. AFAIK, it's >> generally considered bad practice to pop-up a prompt from a library. >> The main reason is that in general use, you can't guarantee that >> someone is actually present behind the console. Imagine a print server >> in a machine room, connected to a park of printers. In that case, when >> one printer fails, the logical behaviour would be to use an other one. >> If you change RxTx the way you propose, the printer queue will simply be >> stuck with a useless "Try again to send data ?" prompt until an >> administrator opens a remote connection to the print server's console >> and clicks "no". >> Second, it would create a dependency upon the existence of a >> graphical console (if you go the graphical "dialogBox" way). On many >> applications (typically server or embedded ones), the JVM is "headless" >> and if you try to pop-up a dialog, your app would throw an exception (at >> best) or just wouldn't display the prompt anywhere... Going the "text >> console" way is not more reliable, because on graphical environments, >> the text console is hidden unless explicitly requested. >> >> My advice would be to think again and find another solution. Ideas are : >> - make the number of retries a parameter so that you can tune it to what >> you think is reasonable >> - throw a more specific exception when the number of retries has been >> reached, so that a specific prompt can be shown at a higher level >> >> Anyway, if you feel that the prompt is the way to go in your case, I >> would at least make that prompt conditional. The least intrusive way >> would probably be using a system property, like >> >> if("true".equals(System.getProperty("org.rxtx.usePrompt")) >> && displayDialogBox("Retry sending data ?")){ >> errorCount = 0; >> } >> else{ >> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >> break; >> } >> >> >> By default, the behaviour would remain as it is now, but you could >> force the prompts by defining the property at VM launch if desired. (for >> example : java.exe -Dorg.rxtx.usePrompt=true myApp) >> >> >> Also, you seemed to say you wanted the printer to start again >> exactly where is stopped. It would indeed be the best way when the >> printer is put offline for a few seconds. On the other hand, if the >> printer is turned off (or the printer runs out of paper, or someone >> steps on the mains cable), then the only way to go back to a "stable" >> situation would be by printing the item (page, label, etc.) again from >> scratch... >> >> >> Just my two cents. >> >> >> Vicne >> >> PS : By the way, the dialog box thing is very platform dependant on the >> C-side, and I think the simplest way would probably be to bridge it to a >> Java call where you can implement it like you proposed : >> >> public boolean displayDialogBox(prompt) { >> return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", >> JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); >> } >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 19:18:51 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 21:18:51 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> Message-ID: <4668AE7B.3060409@gatworks.com> The UNIX version of writeArray is not too great either. It is possible that the write will only process some of the bytes. #else if( write( fd, bytes, count ) < 0 ) throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); #endif -------------------------------- Maybe it might be better to have the native function inform the caller of the # of characters written, then the commapi/output-buffer can be modified to reflect the #of chars written. If an exception is to be thrown, for too many loops of chars written == 0, then exception wont affect the state of the output buffer. Then a ParallelPort.restart() can be called to resume printing whats in the buffer. Trent Jarvi wrote: > An event is possible. I'm amazed this is the largest problem encountered > while using the parallel code. > > How would the write ever exit if we throw events? Isn't this going to > lead to hung applications? Sure. If you dont time out, then there is nothing that will force an EXIT from the write(). Issue is what has the OS done with the write. > > On Thu, 7 Jun 2007, Uncle George wrote: > >> My feeling is that the code that was suggested was for his environs ( >> his shop ). From yvespielusenet at free.fr Fri Jun 8 01:09:01 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Fri, 08 Jun 2007 09:09:01 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4668AE7B.3060409@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> Message-ID: <1181286541.3674.10.camel@localhost.localdomain> It is not possible that the rxtx java method write(byte[], int offset, int length) return anint which contains the number of byte really send to the printer instead of an exception ? So this is the programm which will see if all bytes have been sent. If not it can retry to send the unsended bytes. -------------------------------------------------------- int sended = 0; while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ sended += countWritten; /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } return sended; /*throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break;*/ } ... ... return countWritten; ------------------------------------------------ Le jeudi 07 juin 2007 ? 21:18 -0400, Uncle George a ?crit : > The UNIX version of writeArray is not too great either. It is possible > that the write will only process some of the bytes. > > #else > if( write( fd, bytes, count ) < 0 ) > throw_java_exception_system_msg( env, IO_EXCEPTION, > "writeArray" ); > #endif > -------------------------------- > > Maybe it might be better to have the native function inform the caller > of the # of characters written, then the commapi/output-buffer can be > modified to reflect the #of chars written. If an exception is to be > thrown, for too many loops of chars written == 0, then exception wont > affect the state of the output buffer. Then a ParallelPort.restart() can > be called to resume printing whats in the buffer. > > > Trent Jarvi wrote: > > An event is possible. I'm amazed this is the largest problem encountered > > while using the parallel code. > > > > How would the write ever exit if we throw events? Isn't this going to > > lead to hung applications? > Sure. If you dont time out, then there is nothing that will force an > EXIT from the write(). Issue is what has the OS done with the write. > > > > On Thu, 7 Jun 2007, Uncle George wrote: > > > >> My feeling is that the code that was suggested was for his environs ( > >> his shop ). > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Fri Jun 8 03:45:00 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 11:45:00 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181286541.3674.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> Message-ID: <20070608094500.GC21069@elberon.bln.de.ingenico.com> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > It is not possible that the rxtx java method write(byte[], int offset, > int length) return anint which contains the number of byte really send > to the printer instead of an exception ? > So this is the programm which will see if all bytes have been sent. If > not it can retry to send the unsended bytes. I think write() is void because in Java people love to do this since OutputStream :-) Of course on such interfaces you cannot implement something nice. If you would have a int write, you would not implement the interface and no applications expecting this interface would link/work/compile. oki, Steffen P.S.: (OT) If you propose not to implement the Java interfaces (especially not on JNI level), maybe optionally offering a wrapper that removes e.g. the write return value and so on to downgrade the powerful classic old POSIX read/write style to the modern limited Java style, then I agree :-) Same for read. Instead of things like "int avialable()" it is more powerful to have an approach as select(2) offers (to guarante the caller that read/write will not block [nothing else make sense anyway IMHO] but may read/write less bytes then requested). The caller gets full control and the higher level protocols can care about timeouts, invoking read in some loops and/or implement retransmission. On top of such an implementation, where everything is controlled, defined, guaranteed and reliable, someone could use an InputStream or OutputStream style interface. Or even better: don't use them at all :) just BTW :-) St. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From yvespielusenet at free.fr Fri Jun 8 05:52:45 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Fri, 08 Jun 2007 13:52:45 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <20070608094500.GC21069@elberon.bln.de.ingenico.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> Message-ID: <1181303565.11203.3.camel@localhost.localdomain> So maybe a better way should be to create a new Exception class which has a method "int getWrittenByte()". So the Exception should be use to send again bytes which are not printed yet. yves Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : > * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > > It is not possible that the rxtx java method write(byte[], int offset, > > int length) return anint which contains the number of byte really send > > to the printer instead of an exception ? > > So this is the programm which will see if all bytes have been sent. If > > not it can retry to send the unsended bytes. > > I think write() is void because in Java people love to do this > since OutputStream :-) Of course on such interfaces you cannot > implement something nice. If you would have a int write, you > would not implement the interface and no applications expecting > this interface would link/work/compile. > > oki, > > Steffen > > P.S.: (OT) > If you propose not to implement the Java interfaces (especially > not on JNI level), maybe optionally offering a wrapper that > removes e.g. the write return value and so on to downgrade the > powerful classic old POSIX read/write style to the modern limited > Java style, then I agree :-) Same for read. Instead of things > like "int avialable()" it is more powerful to have an approach as > select(2) offers (to guarante the caller that read/write will not > block [nothing else make sense anyway IMHO] but may read/write > less bytes then requested). The caller gets full control and the > higher level protocols can care about timeouts, invoking read in > some loops and/or implement retransmission. On top of such an > implementation, where everything is controlled, defined, > guaranteed and reliable, someone could use an InputStream or > OutputStream style interface. Or even better: don't use them at > all :) just BTW :-) > St. > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > 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. > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > 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. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Fri Jun 8 06:46:21 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 08:46:21 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181303565.11203.3.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> Message-ID: <46694F9D.5080501@gatworks.com> It seems that with outputstream.write(b[]), you become terribly uncoordinated as soon as an exception is thrown. Docs do not say what happens to the data. Yet from a practicable point of view, one would like to know if the write was accepted in-full, or rejected before any writes. There are no in betweens, as partial writes are not reportable. So for an outputstream.write(), in order for it to return, the full write request has to be taken, and stored in an internal output buffer. If there is no room, the write() is suspended, till there is room. Or throw's an IOException( "no room in buffer") ; As the select() loop for write reports buffer room avail, then more of the internal buffer is sent to the printer. yves pielusenet wrote: > So maybe a better way should be to create a new Exception class which > has a method "int getWrittenByte()". So the Exception should be use to > send again bytes which are not printed yet. > > yves > > Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : >> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: >>> It is not possible that the rxtx java method write(byte[], int offset, >>> int length) return anint which contains the number of byte really send >>> to the printer instead of an exception ? >>> So this is the programm which will see if all bytes have been sent. If >>> not it can retry to send the unsended bytes. >> I think write() is void because in Java people love to do this >> since OutputStream :-) Of course on such interfaces you cannot >> implement something nice. If you would have a int write, you >> would not implement the interface and no applications expecting >> this interface would link/work/compile. >> >> oki, >> >> Steffen >> >> P.S.: (OT) >> If you propose not to implement the Java interfaces (especially >> not on JNI level), maybe optionally offering a wrapper that >> removes e.g. the write return value and so on to downgrade the >> powerful classic old POSIX read/write style to the modern limited >> Java style, then I agree :-) Same for read. Instead of things >> like "int avialable()" it is more powerful to have an approach as >> select(2) offers (to guarante the caller that read/write will not >> block [nothing else make sense anyway IMHO] but may read/write >> less bytes then requested). The caller gets full control and the >> higher level protocols can care about timeouts, invoking read in >> some loops and/or implement retransmission. On top of such an >> implementation, where everything is controlled, defined, >> guaranteed and reliable, someone could use an InputStream or >> OutputStream style interface. Or even better: don't use them at >> all :) just BTW :-) >> St. >> >> About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. >> 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. >> >> About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. >> 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. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From Steffen.DETTMER at ingenico.com Fri Jun 8 08:12:18 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 16:12:18 +0200 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <46694F9D.5080501@gatworks.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: <20070608141218.GE21069@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 08:46 -0400: > It seems that with outputstream.write(b[]), you become terribly > uncoordinated as soon as an exception is thrown. Docs do not say what > happens to the data. (yes, so avoiding it seems to be good :)) > Yet from a practicable point of view, one would like to know if the > write was accepted in-full, or rejected before any writes. There are no > in betweens, as partial writes are not reportable. (which is an artificial API limitation. I never understood how this happend when they invented JDK because the well-known BSD socket API and thus [probably] WinSock does this correct, but anyway) > So for an outputstream.write(), in order for it to return, the full > write request has to be taken, and stored in an internal output buffer. > If there is no room, the write() is suspended, till there is room. Or > throw's an IOException( "no room in buffer") ; As the select() loop for > write reports buffer room avail, then more of the internal buffer is > sent to the printer. yes, might be good in case of a printer. May be horrible in case of PPP/TCP or some other transmission control protocol which may e.g. repeat data or even omit parts of it (e.g. internet realtime radio station broadcasting)... So I think the idea of "int write" (e.g. BSD sockets, linux files and so on) still is the best. A clean API / implementation should guarantee and allow implementations (users) to rely on that; assumptions and automatic background-sending and so on may look pragmatic and may even work on the first look, but may fail in other situations. BTW, if e.g. BSD socket API is known, why not simply copy it (until something better is invented :)) instead of fiddling around with JDK APIs? anyway, have a nice weekend everyone :-) oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Fri Jun 8 08:55:56 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 10:55:56 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070608141218.GE21069@elberon.bln.de.ingenico.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> Message-ID: <46696DFC.7000801@gatworks.com> >> write reports buffer room avail, then more of the internal buffer is >> sent to the printer. > > yes, might be good in case of a printer. May be horrible in case > of PPP/TCP or some other transmission control protocol which > may e.g. repeat data or even omit parts of it (e.g. internet > realtime radio station broadcasting)... So I think the idea of > "int write" (e.g. BSD sockets, linux files and so on) still is > the best. A clean API / implementation should guarantee and allow > implementations (users) to rely on that; assumptions and > automatic background-sending and so on may look pragmatic and may > even work on the first look, but may fail in other situations. > BTW, if e.g. BSD socket API is known, why not simply copy it > (until something better is invented :)) instead of fiddling > around with JDK APIs? But we were talking about the Parallel Port, and the transmission of data over the commapi/parallel-port schema. There isn't much in bi-directional software communication. Its a simple write one byte at a time interface. I'm not looking to change the comm-api. I'm just looking to alter the interaction between the Native ParallelPort functions, and the java ParallelPort functions that call them. This might be more readily doable than to get a committee to re-specify java-API specs. BTW: Whats is off-topic? ( help: not looking for def of off-topic ) From j.kenneth.gentle at acm.org Fri Jun 8 08:58:59 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Fri, 08 Jun 2007 10:58:59 -0400 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <20070608141218.GE21069@elberon.bln.de.ingenico.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> Message-ID: <200706081459.l58Ex5rA019991@qbang.org> Perhaps it is a bit late to jump in on this one, but here goes anyway. If the solutions all seem to "break" the contract with "java.io.outputstream", then, as noted, that may not be the appropriate contract. At the risk of being heretical, JDK1.4 introduced the "nio" package to address some of the compatibility issues with C apis mentioned in previous posts. The interface "java.nio.channels.WriteableByteChannel" defines the following single method: int write(ByteBuffer source); int, strangely enough, is the actual number of bytes written. So, if RXTX as written, against the JavaCOMM api and OutputStream, doesn't do what we want, how about writing a different set of bindings using the java.nio classes and as much of the underlying native code as possible. Note that just because the java.nio.channels.WriteableByteChannel sends back a result, OutputStream.write doesn't have to - and they could both call the same underlying native code. My 2 cents - maybe not worth even that... Ken From netbeans at gatworks.com Fri Jun 8 10:37:28 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 12:37:28 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <200706081459.l58Ex5rA019991@qbang.org> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> Message-ID: <466985C8.8000505@gatworks.com> Ken Gentle wrote: > Perhaps it is a bit late to jump in on this one, but here goes anyway. Common in, the waters fine. > > If the solutions all seem to "break" the contract with > "java.io.outputstream", then, as noted, that may not be the > appropriate contract. > How would the contract be broken? The machinery underneath is handling the contract. From j.kenneth.gentle at acm.org Fri Jun 8 10:48:01 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Fri, 08 Jun 2007 12:48:01 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466985C8.8000505@gatworks.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> Message-ID: <200706081648.l58Gm7YA022904@qbang.org> At 12:37 2007-06-08, you wrote: >Ken Gentle wrote: > > > > If the solutions all seem to "break" the contract with > > "java.io.outputstream", then, as noted, that may not be the > > appropriate contract. > > >How would the contract be broken? The machinery underneath is handling >the contract. It seems that a lot of the discussion has been about not only the timeout and being able to adjust it in the "machinery layer", but also about knowing in the Java layer, in the event of a timeout or exception, how many characters have been written to the device. An OutputStream won't ever do this with out an extension and including a return value "breaks" the contract, right? So, go with a Java IO api that *does* return the number of bytes written, out of the NIO package. I know it doesn't allow for a strict implementation of the JavaCOMM API - however, using NIO classes in place of the IO classes isn't that big a break and would allow those applications that need such information a way to get it. Maybe I'm misunderstanding the problem... Ken From netbeans at gatworks.com Fri Jun 8 11:24:14 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 13:24:14 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <200706081648.l58Gm7YA022904@qbang.org> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> Message-ID: <466990BE.7040100@gatworks.com> Ken Gentle wrote: An > OutputStream won't ever do this with out an extension and including a > return value "breaks" the contract, right? > i was not thinking of change the API to OutputSream. Are there specs for how output stream should work internally? for instance: String data = "Hello this is a line of data"; Outputstream.write( data.getbytes() ); ParallelPort.suspend(); int free = ParallelPort.getoutputbufferfree(); There is a symbiotic relationship between outputstream and the functionality of ParallelPort. From Steffen.DETTMER at ingenico.com Fri Jun 8 11:15:39 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 19:15:39 +0200 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <200706081459.l58Ex5rA019991@qbang.org> References: <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> Message-ID: <20070608171539.GK21069@elberon.bln.de.ingenico.com> * Ken Gentle wrote on Fri, Jun 08, 2007 at 10:58 -0400: > If the solutions all seem to "break" the contract with > "java.io.outputstream", then, as noted, that may not be the > appropriate contract. > > At the risk of being heretical, JDK1.4 introduced the "nio" package > to address some of the compatibility issues with C apis mentioned in > previous posts. The interface > "java.nio.channels.WriteableByteChannel" defines the following single method: > > int write(ByteBuffer source); > > int, strangely enough, is the actual number of bytes written. Yes, AFAIK one of the motivations for the NIO interface was, that the JDK-1.3 APIs (InputStream, e.g.) were not powerfull enough, especially for multi-connection-TCP servers or so. I don't know much about it but I've heard of a project where NIO usage was removed because of stability issues in multi-threaded environments and performance limitations under some circumstances. IIRC the "nio.ByteBuffer" is something very special (namely something you cannot implement in Java, it is "magic" or part of the language itself). Not sure if this is such a great idea (but for performance in the end sometimes heavy prices must be paid) :) > So, if RXTX as written, against the JavaCOMM api and OutputStream, > doesn't do what we want, how about writing a different set of > bindings using the java.nio classes and as much of the underlying > native code as possible. Yes, this would be an idea: use a full-featured interface on JNI, and, if wanted, deliver some wrappers converting this to a less-featured Java-compliant interface. However, powerful things as e.g. "select" are difficult to "emulate" if you are e.g. on some (older?) windows. But if you expose the full-featured APIs, you need to emulate them full-featured, theoretically. In the end it depends what you do on the serial line. If you just want to talk to a modem, then you may not need precise timeouts. But if you need to implement complexer protocols which define response times and timeouts, you may quickly get into difficulties. For instance, AFAIK, rxtx 1.7.2 (?) for windows is very messy with timeouts (there is a maximum, higher values are truncated; resolution is 100ms only; the function may take up to twice the timeout because internally it may be called twice). Probably for most people this is OK, but probably not for all. But having precise timeouts should be OK for all :-) Well, in the end it is nice to wish but somewhat hard to implement (many platforms, connections, USB, BlueTooth, whatever). oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Steffen.DETTMER at ingenico.com Fri Jun 8 11:04:22 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 19:04:22 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <46696DFC.7000801@gatworks.com> References: <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <46696DFC.7000801@gatworks.com> Message-ID: <20070608170422.GJ21069@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 10:55 -0400: > > BTW, if e.g. BSD socket API is known, why not simply copy it > > (until something better is invented :)) instead of fiddling > > around with JDK APIs? > > But we were talking about the Parallel Port, and the > transmission of data over the commapi/parallel-port schema. > There isn't much in bi-directional software communication. Its > a simple write one byte at a time interface. First, there are things like PLIP (http://en.wikipedia.org/wiki/Plip) - well, probably not widely used, sure ;) Second, I think if there is a good simple API known to support all that (with known "best practices") or so and there is no forcing need to invent a new one, why not simply using it? > I'm not looking to change the comm-api. I'm just looking to > alter the interaction between the Native ParallelPort > functions, and the java ParallelPort functions that call them. Ahh, yes. I think this is what I tried to ask. Having an usable JNI interface and on top (in pure java) some wrapper to InputStream or whatever could be done (e.g. by ignoring the return value of write or throwing if != length). Developers could then use the full-featured (non-JAVA-standard) API or select among various wrappers (as InputStream). > This might be more readily doable than to get a committee to > re-specify java-API specs. Yes, of course. I'm afraid that the Java APIs change regularily, but still yet with limited success it seems, so maybe they get it in one of the next iterations; who knows, maybe Java-9 has a BSD-like socket API :) SCNR. > BTW: Whats is off-topic? ( help: not looking for def of > off-topic ) I think I started some "re-specify java-API specs" which was OT probably. oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From lists at iDIAcomputing.com Fri Jun 8 18:48:54 2007 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Fri, 08 Jun 2007 20:48:54 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46684B62.7080802@gmail.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> Message-ID: <4669F8F6.3040101@iDIAcomputing.com> Vicne wrote: > Sorry to step in without a specific solution to your problem, but I > wanted to share my feeling regarding this proposal. AFAIK, it's > generally considered bad practice to pop-up a prompt from a library. ... > > My advice would be to think again and find another solution. Ideas are : > - make the number of retries a parameter so that you can tune it to what > you think is reasonable > - throw a more specific exception when the number of retries has been > reached, so that a specific prompt can be shown at a higher level You could also allow the client code to register a callback class which returns a boolean indicating whether to retry or cancel. This callback class could pop up a dialog, if appropriate, or follow some preset policy, or.... - George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From joachim at buechse.ch Sat Jun 9 09:43:16 2007 From: joachim at buechse.ch (Joachim Buechse) Date: Sat, 9 Jun 2007 17:43:16 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46694F9D.5080501@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: You should not forget, that in the case of an exception it may not even be known what happened to the data. You have a kernel buffer, outgoing chip buffer, incoming chip buffer, etc. So of course, it would be nice to know up to which point data was correctly processed, but this feedback does not exist on the hardware or protocol level and hence can in general not be magicly created on the software level... Regards, Joachim On 08.06.2007, at 14:46, Uncle George wrote: > It seems that with outputstream.write(b[]), you become terribly > uncoordinated as soon as an exception is thrown. Docs do not say what > happens to the data. > > Yet from a practicable point of view, one would like to know if the > write was accepted in-full, or rejected before any writes. There > are no > in betweens, as partial writes are not reportable. > > So for an outputstream.write(), in order for it to return, the full > write request has to be taken, and stored in an internal output > buffer. > If there is no room, the write() is suspended, till there is room. Or > throw's an IOException( "no room in buffer") ; As the select() loop > for > write reports buffer room avail, then more of the internal buffer is > sent to the printer. > > > > yves pielusenet wrote: >> So maybe a better way should be to create a new Exception class which >> has a method "int getWrittenByte()". So the Exception should be >> use to >> send again bytes which are not printed yet. >> >> yves >> >> Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : >>> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: >>>> It is not possible that the rxtx java method write(byte[], int >>>> offset, >>>> int length) return anint which contains the number of byte >>>> really send >>>> to the printer instead of an exception ? >>>> So this is the programm which will see if all bytes have been >>>> sent. If >>>> not it can retry to send the unsended bytes. >>> I think write() is void because in Java people love to do this >>> since OutputStream :-) Of course on such interfaces you cannot >>> implement something nice. If you would have a int write, you >>> would not implement the interface and no applications expecting >>> this interface would link/work/compile. >>> >>> oki, >>> >>> Steffen >>> >>> P.S.: (OT) >>> If you propose not to implement the Java interfaces (especially >>> not on JNI level), maybe optionally offering a wrapper that >>> removes e.g. the write return value and so on to downgrade the >>> powerful classic old POSIX read/write style to the modern limited >>> Java style, then I agree :-) Same for read. Instead of things >>> like "int avialable()" it is more powerful to have an approach as >>> select(2) offers (to guarante the caller that read/write will not >>> block [nothing else make sense anyway IMHO] but may read/write >>> less bytes then requested). The caller gets full control and the >>> higher level protocols can care about timeouts, invoking read in >>> some loops and/or implement retransmission. On top of such an >>> implementation, where everything is controlled, defined, >>> guaranteed and reliable, someone could use an InputStream or >>> OutputStream style interface. Or even better: don't use them at >>> all :) just BTW :-) >>> St. >>> >>> About Ingenico Throughout the world businesses rely on Ingenico >>> for secure and expedient electronic transaction acceptance. >>> Ingenico products leverage proven technology, established >>> standards and unparalleled ergonomics to provide optimal >>> reliability, versatility and usability. This comprehensive range >>> of products is complemented by a global array of services and >>> partnerships, enabling businesses in a number of vertical sectors >>> to accept transactions anywhere their business takes them. >>> 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. >>> >>> About Ingenico Throughout the world businesses rely on Ingenico >>> for secure and expedient electronic transaction acceptance. >>> Ingenico products leverage proven technology, established >>> standards and unparalleled ergonomics to provide optimal >>> reliability, versatility and usability. This comprehensive range >>> of products is complemented by a global array of services and >>> partnerships, enabling businesses in a number of vertical sectors >>> to accept transactions anywhere their business takes them. >>> 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. >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx 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 yvespielusenet at free.fr Mon Jun 11 03:15:12 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Mon, 11 Jun 2007 11:15:12 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: <1181553312.8335.14.camel@localhost.localdomain> So can someone tell a solution for my problem :( Must I say to the user to not put the printer off-line ? I can't since he has to do some pauses, verify print, paper conditioning etc... How do other people ? Before I use the parport librarry to read port status : http://www.geocities.com/Juanga69/parport/ (which doesn't work on windows XP) And I send data into the file LPT1 I use to have no problem when printer was disabled. thanks -- yves piel Le samedi 09 juin 2007 ? 17:43 +0200, Joachim Buechse a ?crit : > You should not forget, that in the case of an exception it may not > even be known what happened to the data. > > You have a kernel buffer, outgoing chip buffer, incoming chip buffer, > etc. So of course, it would be nice to know up to which point data > was correctly processed, but this feedback does not exist on the > hardware or protocol level and hence can in general not be magicly > created on the software level... > > Regards, > Joachim > > On 08.06.2007, at 14:46, Uncle George wrote: > > > It seems that with outputstream.write(b[]), you become terribly > > uncoordinated as soon as an exception is thrown. Docs do not say what > > happens to the data. > > > > Yet from a practicable point of view, one would like to know if the > > write was accepted in-full, or rejected before any writes. There > > are no > > in betweens, as partial writes are not reportable. > > > > So for an outputstream.write(), in order for it to return, the full > > write request has to be taken, and stored in an internal output > > buffer. > > If there is no room, the write() is suspended, till there is room. Or > > throw's an IOException( "no room in buffer") ; As the select() loop > > for > > write reports buffer room avail, then more of the internal buffer is > > sent to the printer. > > > > > > > > yves pielusenet wrote: > >> So maybe a better way should be to create a new Exception class which > >> has a method "int getWrittenByte()". So the Exception should be > >> use to > >> send again bytes which are not printed yet. > >> > >> yves > >> > >> Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : > >>> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > >>>> It is not possible that the rxtx java method write(byte[], int > >>>> offset, > >>>> int length) return anint which contains the number of byte > >>>> really send > >>>> to the printer instead of an exception ? > >>>> So this is the programm which will see if all bytes have been > >>>> sent. If > >>>> not it can retry to send the unsended bytes. > >>> I think write() is void because in Java people love to do this > >>> since OutputStream :-) Of course on such interfaces you cannot > >>> implement something nice. If you would have a int write, you > >>> would not implement the interface and no applications expecting > >>> this interface would link/work/compile. > >>> > >>> oki, > >>> > >>> Steffen > >>> > >>> P.S.: (OT) > >>> If you propose not to implement the Java interfaces (especially > >>> not on JNI level), maybe optionally offering a wrapper that > >>> removes e.g. the write return value and so on to downgrade the > >>> powerful classic old POSIX read/write style to the modern limited > >>> Java style, then I agree :-) Same for read. Instead of things > >>> like "int avialable()" it is more powerful to have an approach as > >>> select(2) offers (to guarante the caller that read/write will not > >>> block [nothing else make sense anyway IMHO] but may read/write > >>> less bytes then requested). The caller gets full control and the > >>> higher level protocols can care about timeouts, invoking read in > >>> some loops and/or implement retransmission. On top of such an > >>> implementation, where everything is controlled, defined, > >>> guaranteed and reliable, someone could use an InputStream or > >>> OutputStream style interface. Or even better: don't use them at > >>> all :) just BTW :-) > >>> St. > >>> > >>> About Ingenico Throughout the world businesses rely on Ingenico > >>> for secure and expedient electronic transaction acceptance. > >>> Ingenico products leverage proven technology, established > >>> standards and unparalleled ergonomics to provide optimal > >>> reliability, versatility and usability. This comprehensive range > >>> of products is complemented by a global array of services and > >>> partnerships, enabling businesses in a number of vertical sectors > >>> to accept transactions anywhere their business takes them. > >>> 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. > >>> > >>> About Ingenico Throughout the world businesses rely on Ingenico > >>> for secure and expedient electronic transaction acceptance. > >>> Ingenico products leverage proven technology, established > >>> standards and unparalleled ergonomics to provide optimal > >>> reliability, versatility and usability. This comprehensive range > >>> of products is complemented by a global array of services and > >>> partnerships, enabling businesses in a number of vertical sectors > >>> to accept transactions anywhere their business takes them. > >>> 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. > >>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx 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 > From Steffen.DETTMER at ingenico.com Mon Jun 11 03:56:18 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 11:56:18 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466990BE.7040100@gatworks.com> References: <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> Message-ID: <20070611095618.GA10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 13:24 -0400: > i was not thinking of change the API to OutputSream. Then I think either someone uses OutputStream (and has no reliable information about incomplete writes) or someone uses somethink else. > Are there specs for how output stream should work internally? > > for instance: > String data = "Hello this is a line of data"; > Outputstream.write( data.getbytes() ); > ParallelPort.suspend(); > int free = ParallelPort.getoutputbufferfree(); > > There is a symbiotic relationship between outputstream and the > functionality of ParallelPort. If you need OutputStream "plus something else", in short you're needing "something else". Personally I dislike the code above a lot. The stream "looks" like if it would be an OutputStream, but in fact it isn't. You need to call getoutputbufferfree later to check if write succeeded (but OutputStream promises that write succeedes synchronous, blocking, or throws an exception). So it is not an OutputStream. No application written for OutputStreams would work without change (because it won't know getoutputbufferfree at all). It is not abstracted from ParallelPort. I think this would be wrong. Then I think an alternative interface instead is better. Let's assume we had some "connection" (to distinguish between OutputStreams and Channels). Then why not working as on a file handle in POSIX: do { // ... select maybe using timer ... readyForWrite = ... if (readyForWrite) { int writtenBytes = connection.write(toWrite); toWrite.remove(0, writtenBytes); } while(readyForWrite && toWrite.length > 0); I think, having such a write isn't the big problem. I think, the difficult thing is around "select" - however this would look like. It should be OO, typesafe, performant, supporting multiple connections/channels/streams in various modes and should be orthogonal to other functionalities. Of course, this heavily depends on what the application is doing; for a simple situation (like reading a small, mandatory file from a local disk) this would be to uncomfortable (and offering unneeded features only). just BTW :) oki, Steffen -- // Modeline for VIM. Please don't remove. // (Help: autoindent, expandtab, shiftwidth=4, tabstop=4, textwidth=75) // vi: set ai et sw=4 ts=4 tw=75 ft=java: About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Mon Jun 11 05:38:33 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 07:38:33 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611095618.GA10821@elberon.bln.de.ingenico.com> References: <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> Message-ID: <466D3439.4020805@gatworks.com> Steffen DETTMER wrote: > (but OutputStream promises that write > succeedes synchronous, blocking, or throws an exception). Where is it so written? From Steffen.DETTMER at ingenico.com Mon Jun 11 06:36:50 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 14:36:50 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466D3439.4020805@gatworks.com> References: <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> <466D3439.4020805@gatworks.com> Message-ID: <20070611123650.GI10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Mon, Jun 11, 2007 at 07:38 -0400: > Steffen DETTMER wrote: > > > (but OutputStream promises that write > > succeedes synchronous, blocking, or throws an exception). > > Where is it so written? Now, as you ask, I think it is not written that clearly but follows from specification. mmm... Am I wrong? I understand the API doc in this way: * http://java.sun.com/j2se/1.4.2/docs/api/java/io/OutputStream.html#write(byte[]) > public void write(byte[] b) > throws IOException > > Writes b.length bytes from the specified byte array to this > output stream. The general contract for write(b) is that > it should have exactly the same effect as the call write(b, > 0, b.length). > > Parameters: > b - the data. > Throws: > IOException - if an I/O error occurs. > See Also: > write(byte[], int, int) and there is: > public void write(byte[] b, > int off, > int len) > throws IOException > > Writes len bytes from the specified byte array starting at > offset off to this output stream. The general contract for > write(b, off, len) is that some of the bytes in the array b > are written to the output stream in order; element b[off] > is the first byte written and b[off+len-1] is the last byte > written by this operation. > > The write method of OutputStream calls the write method of > one argument on each of the bytes to be written out. > Subclasses are encouraged to override this method and > provide a more efficient implementation. > > If b is null, a NullPointerException is thrown. > > If off is negative, or len is negative, or off+len is > greater than the length of the array b, then an > IndexOutOfBoundsException is thrown. > > Parameters: > b - the data. > off - the start offset in the data. > len - the number of bytes to write. > Throws: > IOException - if an I/O error occurs. In particular, an > IOException is thrown if the output stream is closed. In general, any specialisation (derived child class) must comform to this. So write in the end is specified (!) as "The write method ... calls the write method ... on each of the bytes to be written out". This is what must be implemented by ANY OutputStream. Of course, there is: "Subclasses are encouraged to override this method and provide a more efficient implementation." which IMHO does not contradict - the more efficient must behave in exactly the same way of course (just wasting less resources than a simple byte-by-byte write). So it does not matter here I think. The write that finally defines the behavior tells basically: > "Writes the specified byte to this output stream. The general > contract for write is that one byte is written to the output > stream. " > > Throws: > IOException - if an I/O error occurs. which IMHO is another way of saying "write writes the byte immediately and returns on success (only), otherwise an exception is thrown". Especially it cannot happen that zero bytes are written (i.e. the specified byte is NOT written) without an exception. So by this write must be synchronous and blocking, because otherwise it could not reliably know if an asynchronous operation will succeede or not (some getAsyncResult or so would be needed). Since write(byte[]) does this for each byte (or with a behavior beeing exactly the same as if it would do), I think this means that the write(byte[]) succeedes synchronous/blocking or throws an exception. Did I an error in reasoning or confused something or so? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From j.kenneth.gentle at acm.org Mon Jun 11 06:51:25 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 11 Jun 2007 08:51:25 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611123650.GI10821@elberon.bln.de.ingenico.com> References: <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> <466D3439.4020805@gatworks.com> <20070611123650.GI10821@elberon.bln.de.ingenico.com> Message-ID: <200706111251.l5BCpS9T017831@qbang.org> It is as Steffen describes. "InputStream" and "OutputStream" are inherently synchronous (which is why so many java programs resort to threads to use them). Anything outside of this "contract" is *not* an InputStream or OutputStream. That is why there is a new package for things that don't behave like the old *Stream classes - the NIO package. If you look carefully at the IO package, you'll note that almost all the classes are _Decorator_ pattern implementations of the *Stream classes - and the interface presents the _same_ behavior to the calling code in all cases - a synchronous operation that completes successfully or throws an exception (with the one exception of "read" that returns a "-1" on end-of-stream. I know I've read this numerous times - I'd suggest checking the Language Spec or one of the books by Bloch or Gosling. Ken At 08:36 2007-06-11, you wrote: >* Uncle George wrote on Mon, Jun 11, 2007 at 07:38 -0400: > > Steffen DETTMER wrote: > > > > > (but OutputStream promises that write > > > succeedes synchronous, blocking, or throws an exception). > > > > Where is it so written? > >Now, as you ask, I think it is not written that clearly but >follows from specification. mmm... > >Am I wrong? > >I understand the API doc in this way: > >* >http://java.sun.com/j2se/1.4.2/docs/api/java/io/OutputStream.html#write(byte[]) > > public void write(byte[] b) > > throws IOException > > > > Writes b.length bytes from the specified byte array to this > > output stream. The general contract for write(b) is that > > it should have exactly the same effect as the call write(b, > > 0, b.length). > > > > Parameters: > > b - the data. > > Throws: > > IOException - if an I/O error occurs. > > See Also: > > write(byte[], int, int) > > >and there is: > > > > public void write(byte[] b, > > int off, > > int len) > > throws IOException > > > > Writes len bytes from the specified byte array starting at > > offset off to this output stream. The general contract for > > write(b, off, len) is that some of the bytes in the array b > > are written to the output stream in order; element b[off] > > is the first byte written and b[off+len-1] is the last byte > > written by this operation. > > > > The write method of OutputStream calls the write method of > > one argument on each of the bytes to be written out. > > Subclasses are encouraged to override this method and > > provide a more efficient implementation. > > > > If b is null, a NullPointerException is thrown. > > > > If off is negative, or len is negative, or off+len is > > greater than the length of the array b, then an > > IndexOutOfBoundsException is thrown. > > > > Parameters: > > b - the data. > > off - the start offset in the data. > > len - the number of bytes to write. > > Throws: > > IOException - if an I/O error occurs. In particular, an > > IOException is thrown if the output stream is closed. > > >In general, any specialisation (derived child class) must comform >to this. So write in the end is specified (!) as "The write >method ... calls the write method ... on each of the bytes to be >written out". This is what must be implemented by ANY >OutputStream. > >Of course, there is: "Subclasses are encouraged to override this >method and provide a more efficient implementation." which IMHO >does not contradict - the more efficient must behave in exactly >the same way of course (just wasting less resources than a simple >byte-by-byte write). So it does not matter here I think. > > > >The write that finally defines the behavior tells basically: > > > "Writes the specified byte to this output stream. The general > > contract for write is that one byte is written to the output > > stream. " > > > > Throws: > > IOException - if an I/O error occurs. > > >which IMHO is another way of saying "write writes the byte >immediately and returns on success (only), otherwise an exception >is thrown". Especially it cannot happen that zero bytes are >written (i.e. the specified byte is NOT written) without an >exception. So by this write must be synchronous and blocking, >because otherwise it could not reliably know if an asynchronous >operation will succeede or not (some getAsyncResult or so would >be needed). > >Since write(byte[]) does this for each byte (or with a behavior >beeing exactly the same as if it would do), I think this means >that the write(byte[]) succeedes synchronous/blocking or throws >an exception. > >Did I an error in reasoning or confused something or so? > >oki, > >Steffen > >About Ingenico Throughout the world businesses rely on Ingenico for >secure and expedient electronic transaction acceptance. Ingenico >products leverage proven technology, established standards and >unparalleled ergonomics to provide optimal reliability, versatility >and usability. This comprehensive range of products is complemented >by a global array of services and partnerships, enabling businesses >in a number of vertical sectors to accept transactions anywhere >their business takes them. >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. > >About Ingenico Throughout the world businesses rely on Ingenico for >secure and expedient electronic transaction acceptance. Ingenico >products leverage proven technology, established standards and >unparalleled ergonomics to provide optimal reliability, versatility >and usability. This comprehensive range of products is complemented >by a global array of services and partnerships, enabling businesses >in a number of vertical sectors to accept transactions anywhere >their business takes them. >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. > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From alesinskyy at googlemail.com Mon Jun 11 07:25:33 2007 From: alesinskyy at googlemail.com (Oleksandr Alesinskyy) Date: Mon, 11 Jun 2007 15:25:33 +0200 Subject: [Rxtx] [OT] select :-) Message-ID: Sorry, but I have to disagree with following statement: "So write in the end is specified (!) as "The write method ... calls the write method ... on each of the bytes to be written out". This is what must be implemented by ANY OutputStream.". This is not part of the specification or contract, it is just revealed implementation detail of the OutputStream. It is not stated anywhere that behavoiur of derived classes shall conform with this one. Statement concerning "synchronous" nature of the output stream is invalid as well. Really synchronous stream does not require flush() but OutputStream has it. From Steffen.DETTMER at ingenico.com Mon Jun 11 08:21:16 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 16:21:16 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: Message-ID: <20070611142116.GN10821@elberon.bln.de.ingenico.com> * Oleksandr Alesinskyy wrote on Mon, Jun 11, 2007 at 15:25 +0200: > Sorry, but I have to disagree with following statement: > "So write in the end is specified (!) as "The write > method ... calls the write method ... on each of the bytes to be > written out". This is what must be implemented by ANY > OutputStream.". > > This is not part of the specification or contract, it is just > revealed implementation detail of the OutputStream. It is not > stated anywhere that behavoiur of derived classes shall conform > with this one. (I didn't meant that the implementation must really write byte by byte, but that it must "look as if it would do" - because all implementations of OutputStream must "look" in the same way [which is another way of saying "do abstract" I think]) I think the API doc is not "revealing implementation details" but it is the *specification* of that interface and derivations must (should) conform to this specification. Isn't this the idea of interfaces? A function that expects an OutputStream should work on ANY OutputStream, shouldn't it? just kidding: I mean, what would be the point in implementing a checksum function as OutputStream.write which throws its result as IOException? Or which requires to call close() as very first operation to tell that the application is about to transmit confidential data? :-) > Statement concerning "synchronous" nature of the output stream > is invalid as well. Really synchronous stream does not require > flush() but OutputStream has it. ahh, interesting point! I think this is another bug in the API. flush() is wrong. Because write specifies "The general contract for write is that one byte is written to the output stream." but not "a byte may be written or buffered". Actually, an application would need to call flush() after each write (or bunch of write calls) to ensure that write really did something otherwise I think. I didn't found in the spec of OutputStream that it would be required to call flush(). This should mean that calling flush is not required which in turn leads to the conclusion that write must be synchrous (private threads are forbidden because not specified :)) which in turn leads to the conclusion that flush() is not needed at all... I mean, what if someone would only store in write and do the "real write" in flush() and never else? An application could write in one stream and read on another one (e.g. in bidirectional communication) and would never get anything back, because nothing was actually written because no flush was called? Then someone could even think that on error in some write the data could remain buffered AND throw an exception, retrying to send the data in the next write. Ohh, and if there would be some message number inside, and underlaying write (e.g. a protocol offering InputStream/OutputStream) would check this and throw "DuplicatedMessageNumber" the stream would only throw it again and again beeing unusable... In short: I have no clue how someone could be able to implement an asynchrounos write (which is realiable and correct) without beeing specific to anything which is not specified by OutputStream. Well, I think in the end OutputStream was not intended for such communication or protocol implementations - but to read a local disk file or so. In case of I/O errors usually you can abort your application and change the hard disk :-) oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Bob_Jacobsen at lbl.gov Mon Jun 11 09:32:23 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Mon, 11 Jun 2007 08:32:23 -0700 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611142116.GN10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> Message-ID: At 4:21 PM +0200 6/11/07, Steffen DETTMER wrote: > > Statement concerning "synchronous" nature of the output stream >> is invalid as well. Really synchronous stream does not require >> flush() but OutputStream has it. > >ahh, interesting point! > >I think this is another bug in the API. flush() is wrong. Because >write specifies "The general contract for write is that one byte >is written to the output stream." but not "a byte may be written >or buffered". > >Actually, an application would need to call flush() after each >write (or bunch of write calls) to ensure that write really did >something otherwise I think. OutputStreams don't _have_ to be synchronous or asynchronous, but the OutputStream API was be arranged so that subclasses _can_ be synchronous or asynchronous. Such generality is the hardest part of getting an API right. Hence, if at some point a program using an OutputStream wants to be sure that the data has been pushed all the way out, flush() is available. For some subclasses, e.g. the buffered ones, this has important behavior. Others write the data from each call, and flush() doesn't do anything. You _can_ omit it in programs that are known to use this second type, but there's no requirement that you do so; the interface is general in that way. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From Steffen.DETTMER at ingenico.com Mon Jun 11 12:32:39 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 20:32:39 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> Message-ID: <20070611183239.GT10821@elberon.bln.de.ingenico.com> * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: > >Actually, an application would need to call flush() after each > >write (or bunch of write calls) to ensure that write really did > >something otherwise I think. > OutputStreams don't _have_ to be synchronous or asynchronous, > but the OutputStream API was be arranged so that subclasses > _can_ be synchronous or asynchronous. Ahh, oki. Thanks for the clarificaion. So in short, flush() MUST be called on OutputStream, this is just not documented correctly or so clearly (right?). So the overall usage semantics would be: 1. call write (multiple times if desired) 2. call flush only if both succeeded, write was successful. If flush fails it remains unknown if a part of the data was written and/or will be repeated. So the spec (API doc) is wrong. Correct would be to tell that write behaves as told as long as it is followed by a call to flush, otherwise data may or may not get lost (depending wheter close() is called and calls flush(), which seems not to be guaranteed/required). BTW, I think it is a little bit... erm... interesting to find the specification (java API doc reference) wrong, having a need to conclude it from the presence of some methods with "it would make no sense if they behave exactly as specified, so specification must be wrong (incomplete)". > Such generality is the hardest part of getting an API right. Yes, seems to be proven ;) > Hence, if at some point a program using an OutputStream wants > to be sure that the data has been pushed all the way out, > flush() is available. For some subclasses, e.g. the buffered > ones, this has important behavior. Others write the data from > each call, and flush() doesn't do anything. > You _can_ omit it in programs that are known to use this second > type, but there's no requirement that you do so; the interface > is general in that way. I think, it still it must be called always, otherwise the application could break if passing a different runtime type as OutputStream. I think, if the application/method needs a special "type of OutputStream" then the parameter type must be a subclass but not OutputStream, maybe a PrintStream or so - otherwise the compiler could not detect this error (passing wrong type). Is this correct? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Bob_Jacobsen at lbl.gov Mon Jun 11 13:00:52 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Mon, 11 Jun 2007 12:00:52 -0700 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611183239.GT10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> Message-ID: At 8:32 PM +0200 6/11/07, Steffen DETTMER wrote: >So the spec (API doc) is wrong. Correct would be to tell that >write behaves as told as long as it is followed by a call to >flush, otherwise data may or may not get lost (depending wheter >close() is called and calls flush(), which seems not to be >guaranteed/required). I'm not entirely sure that the spec is wrong, but reasonable people can differ on this. In the 1.5 JavaDocs, all that the docs say for the write methods is that they write to the _output_ _stream_; there is no guarantee of anything beyond that. Only the flush method has any guarantee about the data, which is >Flushes this output stream and forces any buffered output bytes to >be written out. The general contract of flush is that calling it is >an indication that, if any bytes previously written have been >buffered by the implementation of the output stream, such bytes >should immediately be written to their intended destination. People commonly use various OutputStreams without using flush(), and it often works, but it's a bad practice and will eventually bite them. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From netbeans at gatworks.com Mon Jun 11 13:31:57 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 15:31:57 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611183239.GT10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> Message-ID: <466DA32D.1010602@gatworks.com> Steffen DETTMER wrote: > * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: >>> Actually, an application would need to call flush() after each >>> write (or bunch of write calls) to ensure that write really did >>> something otherwise I think. > >> OutputStreams don't _have_ to be synchronous or asynchronous, >> but the OutputStream API was be arranged so that subclasses >> _can_ be synchronous or asynchronous. > > Ahh, oki. Thanks for the clarificaion. > > So in short, flush() MUST be called on OutputStream, this is just > not documented correctly or so clearly (right?). No. Flush can be called to force all current data in java buffer's to be written to the kernel - NOW. A flush() can also *imply* that, besides writing out the buffer's that java employs, may also imply/ask the kernel to write all data thusfar written to the kernel, to be physically placed on the destination device - NOW. For some OS's there is no need to do a kernel flush(), as the I/O is synchronized already. Since this is java, you never know what OS your on. From tjarvi at qbang.org Mon Jun 11 19:28:27 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Jun 2007 19:28:27 -0600 (MDT) Subject: [Rxtx] [OT] select :-) In-Reply-To: <466DA32D.1010602@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: On Mon, 11 Jun 2007, Uncle George wrote: > Steffen DETTMER wrote: >> * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: >>>> Actually, an application would need to call flush() after each >>>> write (or bunch of write calls) to ensure that write really did >>>> something otherwise I think. >> >>> OutputStreams don't _have_ to be synchronous or asynchronous, >>> but the OutputStream API was be arranged so that subclasses >>> _can_ be synchronous or asynchronous. >> >> Ahh, oki. Thanks for the clarificaion. >> >> So in short, flush() MUST be called on OutputStream, this is just >> not documented correctly or so clearly (right?). > No. > Flush can be called to force all current data in java buffer's to be > written to the kernel - NOW. > > A flush() can also *imply* that, besides writing out the buffer's that > java employs, may also imply/ask the kernel to write all data thusfar > written to the kernel, to be physically placed on the destination device > - NOW. > For some OS's there is no need to do a kernel flush(), as the I/O is > synchronized already. Since this is java, you never know what OS your on. To add to the confusion, flush on the C side throws away data. drain makes sure it is written. Looking at the ParallelImp.c we can probably do better. /* we set a timeout because all calls are sequentiell (also with asynchron) this means that the default timeout of unlimited blocks all calls (also close and status request) if the device is down */ GetCommTimeouts( (HANDLE)fd, &timeouts ); timeouts.WriteTotalTimeoutMultiplier = 0; timeouts.WriteTotalTimeoutConstant = 2000; /* 2000 is the min value for the default Windows NT and Windows 2000 driver */ SetCommTimeouts( (HANDLE)fd, &timeouts ); while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } errorCount = 0; bytes += countWritten; count -= countWritten; } LPRPort has some timeout code that appears to be doing nothing but flipping bits back and forth right now. The commapi rxtx follows allows for timeout control from javax.comm.CommPort. The above is a solution that worked in one specific use case. With timeouts in place, the original 'old printer going offline' problem could be solved. That printer code isn't written in stone. In fact it was ajusted from being able to print 'asdf' to a daisy wheel printer to working for one person. BTW, I've finished teaching after hours tonight and will be moving forward with a new rxtx release in my free time. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Jun 11 21:28:04 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 23:28:04 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: <466E12C4.1010305@gatworks.com> > Looking at the ParallelImp.c we can probably do better. > The problem stemmed from the possibility that the writev routine could have written some of the buffer, in chunks, printer pauses, refuses any more chunks, and a timeout occurs. Do you or do you not cause an exception to be thrown? Is there a way to set timeout for a ParallelPort data output stream? I cant find it. From tjarvi at qbang.org Mon Jun 11 22:17:23 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Jun 2007 22:17:23 -0600 (MDT) Subject: [Rxtx] [OT] select :-) In-Reply-To: <466E12C4.1010305@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> <466E12C4.1010305@gatworks.com> Message-ID: On Mon, 11 Jun 2007, Uncle George wrote: >> Looking at the ParallelImp.c we can probably do better. >> > The problem stemmed from the possibility that the writev routine could > have written some of the buffer, in chunks, printer pauses, refuses any > more chunks, and a timeout occurs. Do you or do you not cause an > exception to be thrown? > > Is there a way to set timeout for a ParallelPort data output stream? I > cant find it. hmm I looked again after you asked. The timeouts are only controllable on the receive side. This comes from CommPort; the parent. So what we are talking about is some bytes in memory that rxtx has and is supposed to write. A buffer perhaps? The approach with rxtx in the past has been to ignore output buffer sizes. The assumption is that the library does not know how to best handle buffers. There are buffered output streams that can do buffering on top of rxtx for instance. There is also a question regarding what was actually ment when the API was put together. My suspicion is that it was put together while looking at one OS API and was never ment to be anything more than a hook into that API. The comments are fairly telling combined with reading the w32 API. So looking at the problem again.. The current timeout behavior appears fairly arbitrary. Presumably this is to prevent a program from hanging instead of using a helper thread to write - heavy handed for new programmers. Even so, I don't think the write should timeout at all if it is not configurable. >From the API perspective, "What Timeout?" -- Trent Jarvi tjarvi at qbang.org From Steffen.DETTMER at ingenico.com Tue Jun 12 02:14:48 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 12 Jun 2007 10:14:48 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466DA32D.1010602@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: <20070612081447.GU10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Mon, Jun 11, 2007 at 15:31 -0400: > Steffen DETTMER wrote: > > Ahh, oki. Thanks for the clarificaion. > > > > So in short, flush() MUST be called on OutputStream, this is just > > not documented correctly or so clearly (right?). > No. hum (though now I got it, but...). > Flush can be called to force all current data in java buffer's to be > written to the kernel - NOW. > > A flush() can also *imply* that, besides writing out the > buffer's that java employs, may also imply/ask the kernel to > write all data thusfar written to the kernel, to be physically > placed on the destination device - NOW. > > For some OS's there is no need to do a kernel flush(), as the I/O is > synchronized already. Since this is java, you never know what OS your on. (well, but if you're going to kernel level, even flush cannot guarantee that data will "be physically placed". Maybe you're flushing to a file via NFS (and the client "thinks" that it was written, but maybe it was just buffered by the NFS server) or so... but of course such exceptions of the rules are constructable always.) Well, you tell that depending on the OS it can be that flush is needed or it can be that flush is not needed (beacuse the I/O is synchronized already), right? Also, applications should work on any OS, which includes the OSes that do need flush. Since the application cannot know whether flush is needed or not because it doesn't know what the OS is doing, it has to call flush, hasn't it? I mean, if it would not call flush then it would not work on such OSes (except the written data would not be needed at all, but in this would be an artificial example :)). Since applications are supposed to work this would be wrong, wouldn't it? So would it be correct to say: "Applications, that should work under all OSes (including the OSes where the I/O is not synchronised already), have to call flush on OutputStream to ensure the data is transfered to the kernel." or is this wrong? If so, then I'm afraid I missed the point again :( oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Tue Jun 12 04:46:52 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 12 Jun 2007 06:46:52 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070612081447.GU10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> <20070612081447.GU10821@elberon.bln.de.ingenico.com> Message-ID: <466E799C.7060700@gatworks.com> S > (well, but if you're going to kernel level, even flush cannot > guarantee that data will "be physically placed". Thats true now-a-days because ( from "man 2 sync" ) : > According to the standard specification (e.g., SVID), sync() schedules > the writes, but may return before the actual writing is done. However, > since version 1.3.20 Linux does actually wait. (This still does not > guarantee data integrity: modern disks have large caches.) My disk drive has 8mb cache. Maybe you're > flushing to a file via NFS (and the client "thinks" that it was > written, but maybe it was just buffered by the NFS server) or > so... but of course such exceptions of the rules are > constructable always.) > > Well, you tell that depending on the OS it can be that flush is > needed or it can be that flush is not needed (beacuse the I/O is > synchronized already), right? Also, applications should work on > any OS, which includes the OSes that do need flush. Its not OS's that need flush, its applications that want to have some assurance that data is written to the device that really needs to use flush. If your program ( or thread ) dies then it is in your best interest to write out the critical data as soon as possible, as economical as possible. These are trade-off's that the application programmer makes. A big buffer may mean big loss of data, a small buffer may mean spending too much time writing out data. > > > So would it be correct to say: > > "Applications, that should work under all OSes (including the > OSes where the I/O is not synchronised already), have to call > flush on OutputStream to ensure the data is transfered to the > kernel." > > or is this wrong? If so, then I'm afraid I missed the point again > :( > No that is not wrong. Ensuring that data is transfered to the OS is just about what any application can do. From tjarvi at qbang.org Thu Jun 14 08:16:47 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 14 Jun 2007 08:16:47 -0600 (MDT) Subject: [Rxtx] rxtx and usb-serial solution In-Reply-To: References: Message-ID: On Thu, 14 Jun 2007, Vladimir Kirtchev wrote: > Hi Trent, > > I develop a Java application which communicates with devices which have > USB-to-Serial bridge in them. The target OS is Linux. So for this purpose I > use RXTX. > > But I encountered a strange problem - when reading from the InputStream, I > receive series of zeros. I have this problem under Linux only. Under Windows > it is fine. > Actually this problem is the same as the one described here: > http://marc.info/?l=rxtx&m=109703190731748&w=2. > > > So I searched for the problem in the native code. And found that the root of > the problem is in SerialImp.c, > int configure_port( int fd ) > { > ... > ttyset.c_iflag = INPCK; > ... > } > > This line enables input parity checking, and the data sent from the device > is processed by the OS driver before being read with read(). > In this case the driver detects some problem and sets the received bytes to > zero. > > On the other hand in the Java part a set the serial port parameters with > SerialPort.PARITY_NONE. According to me, except all other things, this > should also disable INPCK in c_iflag. > > So I refactored the method translate_parity(...) to the following: > > int translate_parity( JNIEnv *env, struct termios *ttyset, jint parity ) > { > ENTER( "translate_parity" ); > #ifdef CMSPAR > ttyset->c_cflag &= ~(PARENB | PARODD | CMSPAR ); > #endif /* CMSPAR */ > switch( parity ) { > case JPARITY_NONE: > ttyset->c_iflag &= ~INPCK; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_EVEN: > ttyset->c_cflag |= PARENB; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_ODD: > ttyset->c_cflag |= PARENB | PARODD; > LEAVE( "translate_parity" ); > return 0; > #ifdef CMSPAR > case JPARITY_MARK: > ttyset->c_cflag |= PARENB | PARODD | CMSPAR; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_SPACE: > ttyset->c_cflag |= PARENB | CMSPAR; > LEAVE( "translate_parity" ); > return 0; > #endif /* CMSPAR */ > default: > printf("Parity missed %i\n", (int) parity ); > } > > LEAVE( "translate_parity" ); > /* > For some reason the native exceptions are not being caught. Moving this > to the Java side fixed the issue. taj. > throw_java_exception( env, UNSUPPORTED_COMM_OPERATION, > "", "parity value not supported" ); > */ > return 1; > } > > This modification solved the problem and now it works correctly under Linux. > > I think I will be a nice if this is idea is included in a future release of > RXTX. > > Thanks Vadim, I'll try that out. Forwarding to the rxtx mail-list too. This is probably not going to help USB drivers on windows which I'm sure some are looking for. As far as I can tell, windows USB bluetooth and serial dongles are limited by driver functionality. Some are good and others lack key features. -- Trent Jarvi tjarvi at qbang.org From dan.sandberg.lists at gmail.com Mon Jun 18 14:43:39 2007 From: dan.sandberg.lists at gmail.com (Dan Sandberg) Date: Mon, 18 Jun 2007 13:43:39 -0700 Subject: [Rxtx] Fix for JNI Get/Set Field Errors Message-ID: <4676EE7B.7060800@gmail.com> Hi, I've fixed the problems that cause the following JNI error when extra JNI checking ( -Xjni:check ) is turned on. FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) The problem was basically that GetLong was being used to get ints, and SetInt was used for longs. The patch below fixes this. Please let me know if there are any questions / problems. Cheers, -Dan diff -aur old/SerialImp.c src/SerialImp.c --- old/SerialImp.c 2007-06-18 13:24:33.000000000 -0700 +++ src/SerialImp.c 2007-06-18 06:26:26.000000000 -0700 @@ -1337,7 +1337,7 @@ report("init_threads: get eis\n"); jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); report("init_threads: set eis\n"); - (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); + (*eis->env)->SetLongField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); report("init_threads: stop\n"); report_time_end( ); return( 1 ); @@ -1530,7 +1530,7 @@ jobject jobj, jboolean interrupted ) { int fd = get_java_var( env, jobj,"fd","I" ); - struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var( env, jobj, "eis", "J" ); + struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var_long( env, jobj, "eis", "J" ); int result, count=0; char message[80]; @@ -2939,7 +2939,7 @@ /* TRENT */ int flag, count = 0; struct event_info_struct *eis = ( struct event_info_struct * ) - get_java_var( env, *jobj,"eis","J" ); + get_java_var_long( env, *jobj,"eis","J" ); report_time_start(); flag = eis->eventflags[SPE_DATA_AVAILABLE]; @@ -4873,9 +4873,9 @@ exceptions: none comments: ----------------------------------------------------------*/ -size_t get_java_var( JNIEnv *env, jobject jobj, char *id, char *type ) +long get_java_var_long( JNIEnv *env, jobject jobj, char *id, char *type ) { - int result = 0; + long result = 0; jclass jclazz = (*env)->GetObjectClass( env, jobj ); jfieldID jfd = (*env)->GetFieldID( env, jclazz, id, type ); @@ -4889,7 +4889,11 @@ LEAVE( "get_java_var" ); return result; } - result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); + if ( !strcmp( type, "J" ) ) { + result = (long)( (*env)->GetLongField( env, jobj, jfd ) ); + } else { + result = (int) ( (*env)->GetIntField( env, jobj, jfd ) ); + } /* ct7 & gel * Added DeleteLocalRef */ (*env)->DeleteLocalRef( env, jclazz ); if(!strncmp( "fd",id,2) && result == 0) @@ -4900,6 +4904,10 @@ return result; } +int get_java_var( JNIEnv *env, jobject jobj, char *id, char *type ) { + return (int) get_java_var_long( env, jobj, id, type ); +} + /*---------------------------------------------------------- throw_java_exception diff -aur old/SerialImp.h src/SerialImp.h --- old/SerialImp.h 2007-06-18 13:24:39.000000000 -0700 +++ src/SerialImp.h 2007-06-18 06:23:43.000000000 -0700 @@ -413,7 +413,8 @@ void system_wait(); void finalize_event_info_struct( struct event_info_struct * ); int read_byte_array( JNIEnv *, jobject *, int, unsigned char *, int, int ); -size_t get_java_var( JNIEnv *, jobject, char *, char * ); +int get_java_var( JNIEnv *, jobject, char *, char * ); +long get_java_var_long( JNIEnv *, jobject, char *, char * ); jboolean is_interrupted( struct event_info_struct * ); int send_event(struct event_info_struct *, jint, int ); void dump_termios(char *,struct termios *); From yvespielusenet at free.fr Tue Jun 26 03:41:58 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 11:41:58 +0200 Subject: [Rxtx] [PARALLEL] resource in use Message-ID: <1182850918.3483.10.camel@localhost.localdomain> Hello, So now I want to modify the timeout of the library for parallel port. I have downloaded source code. There is a makefile for migw. SO I have installed mingw on ubuntu and modified the makefile.mingw32 to set it for my system. I have no error but some warnings. The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But When I want to use it the jvm crash :( How can I know what is wrong ? How rxtx windows release has been done ? thanks -- yves piel From yvespielusenet at free.fr Tue Jun 26 07:17:02 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 15:17:02 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182850918.3483.10.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> Message-ID: <1182863822.3483.17.camel@localhost.localdomain> Here is the Makefile I use, the output of the 'make' and the log of the jvm when it crashed : - The Makefile : http://yvespiel.free.fr/rxtx/Makefile - The make output : http://yvespiel.free.fr/rxtx/compile.txt - The crash log : http://yvespiel.free.fr/rxtx/hs_err_pid2100.log I have compiled rxtx under Debian testing with mingw : narma at linimi:/tmp/err$ dpkg -l | grep mingw ii mingw32 3.4.5.20060117.1.dfsg-3 ii mingw32-binutils 2.17.50-20070129.1-1 ii mingw32-runtime 3.12-1 thanks fort help :) Le mardi 26 juin 2007 ? 11:41 +0200, yves pielusenet a ?crit : > Hello, > So now I want to modify the timeout of the library for parallel port. I > have downloaded source code. There is a makefile for migw. SO I have > installed mingw on ubuntu and modified the makefile.mingw32 to set it > for my system. > I have no error but some warnings. > The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But > When I want to use it the jvm crash :( > > How can I know what is wrong ? > > How rxtx windows release has been done ? > > thanks > From yvespielusenet at free.fr Tue Jun 26 07:40:11 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 15:40:11 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182863822.3483.17.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> <1182863822.3483.17.camel@localhost.localdomain> Message-ID: <1182865211.3483.21.camel@localhost.localdomain> I have add the options '--enable-stdcall-fixup' to the 'i586-mingw32msvc-ld' commande. Now I have no warning. But the JVM always crashes :( The output seems more detailled, but I don't understand anything... Here is files : http://yvespiel.free.fr/rxtx/2/ -- yves piel Le mardi 26 juin 2007 ? 15:17 +0200, yves pielusenet a ?crit : > Here is the Makefile I use, the output of the 'make' and the log of the > jvm when it crashed : > > - The Makefile : http://yvespiel.free.fr/rxtx/Makefile > - The make output : http://yvespiel.free.fr/rxtx/compile.txt > - The crash log : http://yvespiel.free.fr/rxtx/hs_err_pid2100.log > > I have compiled rxtx under Debian testing with mingw : > narma at linimi:/tmp/err$ dpkg -l | grep mingw > ii mingw32 3.4.5.20060117.1.dfsg-3 > ii mingw32-binutils 2.17.50-20070129.1-1 > ii mingw32-runtime 3.12-1 > > thanks fort help :) > > > Le mardi 26 juin 2007 ? 11:41 +0200, yves pielusenet a ?crit : > > Hello, > > So now I want to modify the timeout of the library for parallel port. I > > have downloaded source code. There is a makefile for migw. SO I have > > installed mingw on ubuntu and modified the makefile.mingw32 to set it > > for my system. > > I have no error but some warnings. > > The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But > > When I want to use it the jvm crash :( > > > > How can I know what is wrong ? > > > > How rxtx windows release has been done ? > > > > thanks > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From yvespielusenet at free.fr Tue Jun 26 08:27:42 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 16:27:42 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182865211.3483.21.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> <1182863822.3483.17.camel@localhost.localdomain> <1182865211.3483.21.camel@localhost.localdomain> Message-ID: <1182868062.3483.24.camel@localhost.localdomain> I think thant the include files of jdk were not for windows but for linux. So I have copied include/ folder from windows to linux and I modified the Makefile to use those file. It compile fine but the JVM always crash :( http://yvespiel.free.fr/rxtx/3/ Le mardi 26 juin 2007 ? 15:40 +0200, yves pielusenet a ?crit : > I have add the options '--enable-stdcall-fixup' to the > 'i586-mingw32msvc-ld' commande. Now I have no warning. But the JVM > always crashes :( The output seems more detailled, but I don't > understand anything... > Here is files : > http://yvespiel.free.fr/rxtx/2/ > From netbeans at gatworks.com Fri Jun 1 05:38:50 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 07:38:50 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <465F7ADD.1010501@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> Message-ID: <4660054A.2040202@gatworks.com> Manuel Naranjo wrote: In the case of my module, you can > unplug the device but it will not delete the symlink until those apps > that had opened the port has closed it. This is done this way to avoid > kernel panics. What does this mean to user code ? I have tried the alternate route ( other than closing ) which is sleep inbetween the I/O errors ( an unplugged USB device). When the device is plugged back in, The writes to the device still get an I/O error. This would seem to be a lost cause for the application. From netbeans at gatworks.com Fri Jun 1 06:35:48 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 08:35:48 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <465F7ADD.1010501@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> Message-ID: <466012A4.90608@gatworks.com> Manuel Naranjo wrote: In the case of my module, you can > unplug the device but it will not delete the symlink until those apps > that had opened the port has closed it. T Did u also mean for this to happen? USB0 was not closed by application. Apparently USB1 got created when USB device was plugged back in. There is only one USB device on a 4 port USB hub. This also seems to suggest that application recovery to be impossible. > Jun 1 07:10:08 mylaptop kernel: garmin_gps 1-1.4:1.0: Garmin GPS usb/tty converter detected > Jun 1 07:10:08 mylaptop kernel: usb 1-1.4: Garmin GPS usb/tty converter now attached to ttyUSB0 > Jun 1 07:15:17 mylaptop kernel: usb 1-1: USB disconnect, address 4 > Jun 1 07:15:17 mylaptop kernel: usb 1-1.4: USB disconnect, address 5 > Jun 1 07:15:17 mylaptop kernel: garmin_gps 1-1.4:1.0: device disconnected > Jun 1 07:15:26 mylaptop kernel: usb 1-1: new full speed USB device using uhci_hcd and address 6 > Jun 1 07:15:26 mylaptop kernel: hub 1-1:1.0: USB hub found > Jun 1 07:15:26 mylaptop kernel: hub 1-1:1.0: 4 ports detected > Jun 1 07:15:27 mylaptop kernel: usb 1-1.4: new full speed USB device using uhci_hcd and address 7 > Jun 1 07:15:27 mylaptop kernel: garmin_gps 1-1.4:1.0: Garmin GPS usb/tty converter detected > Jun 1 07:15:27 mylaptop kernel: usb 1-1.4: Garmin GPS usb/tty converter now attached to ttyUSB1 From naranjo.manuel at gmail.com Fri Jun 1 09:17:22 2007 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Fri, 01 Jun 2007 12:17:22 -0300 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <466012A4.90608@gatworks.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> <466012A4.90608@gatworks.com> Message-ID: <46603882.5050701@gmail.com> Uncle George escribi?: > Manuel Naranjo wrote: > In the case of my module, you can > >> unplug the device but it will not delete the symlink until those apps >> that had opened the port has closed it. T >> > > Did u also mean for this to happen? USB0 was not closed by application. > > Apparently USB1 got created when USB device was plugged back in. There > is only one USB device on a 4 port USB hub. > > This also seems to suggest that application recovery to be impossible. > Exactly there's a dead symlink (you can read and write to it and nothing will happen) and a new port will be created when a new device is connencted. From netbeans at gatworks.com Fri Jun 1 10:20:46 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 12:20:46 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <46603882.5050701@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> <466012A4.90608@gatworks.com> <46603882.5050701@gmail.com> Message-ID: <4660475E.5090202@gatworks.com> Not sure what u mean by "symlink". U cant read/write to it anymore. U get I/O error. In this scenario the device effectively went dead, and only solution is to close the channel. reconnecting the USB device, although dead, but not closed, will create a second device. This does not seem to be a desirable side-effect. The user will now have ttyUSB1, wondering where did ttyUSB0 go to. The application will also be in a confused state, as well as RXTX, because RXTX wont know about ttyUSB1. Manuel Naranjo wrote: > Uncle George escribi?: >> Manuel Naranjo wrote: >> In the case of my module, you can >> >>> unplug the device but it will not delete the symlink until those apps >>> that had opened the port has closed it. T >>> >> Did u also mean for this to happen? USB0 was not closed by application. >> >> Apparently USB1 got created when USB device was plugged back in. There >> is only one USB device on a 4 port USB hub. >> >> This also seems to suggest that application recovery to be impossible. >> > Exactly there's a dead symlink (you can read and write to it and nothing > will happen) and a new port will be created when a new device is connencted. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From arnab.bhaumik at gmail.com Mon Jun 4 01:40:16 2007 From: arnab.bhaumik at gmail.com (arnab bhaumik) Date: Mon, 4 Jun 2007 13:10:16 +0530 Subject: [Rxtx] full duplex com port with rxtx Message-ID: hi , till now i did half duplex communication with rxtx package on com package. my question is : is it possible to use com port with full duplex mode with rxtx package . ther is example of SimpleRead class and SimpleWrite class. it is clear that if i can use both the class simultaneously then full duplex is possible......... arnab/vu2bpw -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070604/6edb0453/attachment-0005.html From lists at iDIAcomputing.com Mon Jun 4 07:53:17 2007 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Mon, 04 Jun 2007 09:53:17 -0400 Subject: [Rxtx] full duplex com port with rxtx In-Reply-To: References: Message-ID: <4664194D.90301@iDIAcomputing.com> arnab bhaumik wrote: > hi , > > till now i did half duplex communication with rxtx package on com > package. > > my question is : is it possible to use com port with full duplex mode > with rxtx package . > > > ther is example of SimpleRead class and SimpleWrite class. it is > clear that if i can use both the class simultaneously then full duplex > is possible......... I haven't looked at the SimpleRead and SimpleWrite classes (I originally wrote my code for the javax.comm api), but full duplex is certainly possible. My CommReader class requires an object analogous to a OutputStream or Writer. When started, it spawns a thread that reads the comm port and writes to that output device. In this way the input is asynchronous and dependent on the actual input data. For full duplex, I extend that class with CommReaderWriter, which adds synchronous output methods. Hope that helps, George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From supsoop at hotmail.com Mon Jun 4 15:21:06 2007 From: supsoop at hotmail.com (soop soop) Date: Mon, 04 Jun 2007 21:21:06 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- Message-ID: Hi Guys, Looked through the archives but still cannot figure this out. I have a Motorola G24 GPRS/GSM modem that I am connecting to my server running Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not detecting the port, CommPortIdentifier.getPortIdentifiers(). I have added the line to RXTXCommDriver: "ttyACM" // for USB Modems Rxtx still does not seem to find the port. Is there something I am missing to make this port visable? [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control Model driver for USB modems and ISDN adapters I really need your help as I have moved my server from windows to Linux and have been down for a few days because of this .. Thanks so much! _________________________________________________________________ PC Magazine’s 2007 editors’ choice for best Web mail—award-winning Windows Live Hotmail. http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 From tjarvi at qbang.org Mon Jun 4 16:17:35 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Jun 2007 16:17:35 -0600 (MDT) Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: On Mon, 4 Jun 2007, soop soop wrote: > Hi Guys, > > Looked through the archives but still cannot figure this out. I have a > Motorola G24 GPRS/GSM modem that I am connecting to my server running Ubuntu. > I can see my modem as is shows up as ttyACM0, but RXTX is not detecting the > port, CommPortIdentifier.getPortIdentifiers(). > > I have added the line to RXTXCommDriver: > > "ttyACM" // for USB Modems > > Rxtx still does not seem to find the port. Is there something I am missing to > make this port visable? > > [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver > [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device > [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control Model > driver for USB modems and ISDN adapters > > I really need your help as I have moved my server from windows to Linux and > have been down for a few days because of this .. Thanks so much! > You could try the INSTALL documentation that comes with the source for possible solutions. Those usually involve lockfile creation, permissions on the device file or the device is in use by another application (even another session of your application). The usual commands: ls -l /dev/ttyACM0 fuser /dev/ttyACM0 touch /var/lock/LCK.testfile && rm -f /var/lock/LCK.testfile whoami To disable lockfiles: ../configure --disable-lockfiles && make install -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Jun 4 16:22:52 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 04 Jun 2007 18:22:52 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <466490BC.3090801@gatworks.com> soop soop wrote: > I really need your help as I have moved my server from windows to Linux > and have been down for a few days because of this .. Thanks so much! can u open the device ? ie is the file protection/permissions keeping you out? From supsoop at hotmail.com Mon Jun 4 16:44:40 2007 From: supsoop at hotmail.com (soop soop) Date: Mon, 04 Jun 2007 22:44:40 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <466490BC.3090801@gatworks.com> Message-ID: Thanks for the reply, I see no exceptions being thrown, just no detection of the port whats so ever. I will run rxtx in debug mode and log. If this were a permissions issue would I not see some exceptions being thrown? >From: Uncle George >Reply-To: RXTX Developers and Users >To: RXTX Developers and Users >Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >Date: Mon, 04 Jun 2007 18:22:52 -0400 > >soop soop wrote: > > > I really need your help as I have moved my server from windows to Linux > > and have been down for a few days because of this .. Thanks so much! > >can u open the device ? ie is the file protection/permissions keeping >you out? >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ Get a preview of Live Earth, the hottest event this summer - only on MSN http://liveearth.msn.com?source=msntaglineliveearthhm From netbeans at gatworks.com Mon Jun 4 17:06:15 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 04 Jun 2007 19:06:15 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <46649AE7.10405@gatworks.com> Exceptions on what? On startup it wants to lookup all devices in /dev that it is capable of opening ( within the list of specific 'comm' devices ). If it cannot open, then does not get onto list. Part of this process, if configured, will also test if the "LOCK" schema can also be opened for the device. then it gets on the list of avail comm port. soop soop wrote: > Thanks for the reply, > > I see no exceptions being thrown, just no detection of the port whats so > ever. I will run rxtx in debug mode and log. If this were a permissions > issue would I not see some exceptions being thrown? > > >> From: Uncle George >> Reply-To: RXTX Developers and Users >> To: RXTX Developers and Users >> Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >> Date: Mon, 04 Jun 2007 18:22:52 -0400 >> >> soop soop wrote: >> >>> I really need your help as I have moved my server from windows to Linux >>> and have been down for a few days because of this .. Thanks so much! >> can u open the device ? ie is the file protection/permissions keeping >> you out? >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _________________________________________________________________ > Get a preview of Live Earth, the hottest event this summer - only on MSN > http://liveearth.msn.com?source=msntaglineliveearthhm > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From alex.flint at gmail.com Mon Jun 4 21:31:49 2007 From: alex.flint at gmail.com (Alex Flint) Date: Tue, 5 Jun 2007 13:01:49 +0930 Subject: [Rxtx] random EXCEPTION_ACCESS_VIOLATION errors Message-ID: Hi All, I'm running winXP and RXTX 2.1-7r2 (the latest from the webpage as of June 2007). I'm sending sequences of 64 lines (each line has about 15 chars) at various intervals. The strings are sent fine, until I get the following error (from hs_err_pid3316.log, at the end of this email). What can I do to avoid the error? Obviously this is a low-level memory exception, but is there any way I can keep the JVM running after such an error? I noticed the exact same problem here: http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20070129/1180520.html Cheers, Alex # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x100034fb, pid=3316, tid=2400 # # Java VM: Java HotSpot(TM) Client VM (1.6.0_01-b06 mixed mode, sharing) # Problematic frame: # C [rxtxSerial.dll+0x34fb] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # --------------- T H R E A D --------------- Current thread (0x00386400): JavaThread "main" [_thread_in_native, id=2400] siginfo: ExceptionCode=0xc0000005, reading address 0x20726f78 Registers: EAX=0x20726f20, EBX=0x6d8922c0, ECX=0x00000005, EDX=0x20726f20 ESP=0x003efa30, EBP=0x003efb68, ESI=0x269728a0, EDI=0x00386400 EIP=0x100034fb, EFLAGS=0x00010212 Top of Stack: (sp=0x003efa30) 0x003efa30: 003efa3c 003efa64 0000000f ffffffff 0x003efa40: 003efa40 2a97f808 003efa6c 2b190ca8 0x003efa50: 00000000 2b190ec0 003efa90 008e2dd7 0x003efa60: 003efa90 008e2dd7 26977f88 6d815e72 0x003efa70: 00000004 2696eae0 0000008a 003efb0c 0x003efa80: 6d852b4a 2696eae0 00000003 26970930 0x003efa90: 000000cb 2696eae0 6d86b264 00385d40 0x003efaa0: 0000003f 003efb0c 26977f90 2ace65d8 Instructions: (pc=0x100034fb) 0x100034eb: ff ff 8d 76 00 eb 02 89 f6 90 8b 45 f8 8b 55 f8 0x100034fb: 8b 4a 58 83 c9 04 89 48 58 83 c4 f8 8b 45 f8 8b Stack: [0x003a0000,0x003f0000), sp=0x003efa30, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x34fb] Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j gnu.io.RXTXPort.writeArray([BIIZ)V+0 j gnu.io.RXTXPort$SerialOutputStream.write([B)V+76 j com.bjt.media.server.CommLink.send(Ljava/lang/String;)V+48 j com.bjt.media.server.DigitoolConnection.select(I)V+73 j com.bjt.media.server.DigitoolConnection.main([Ljava/lang/String;)V+74 v ~StubRoutines::call_stub --------------- P R O C E S S --------------- Java Threads: ( => current thread ) 0x02a69400 JavaThread "Thread-0" [_thread_in_native, id=3052] 0x02a4d000 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=3920] 0x02a48400 JavaThread "CompilerThread0" daemon [_thread_blocked, id=1968] 0x02a47400 JavaThread "Attach Listener" daemon [_thread_blocked, id=2984] 0x02a46400 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=2660] 0x02a41c00 JavaThread "Finalizer" daemon [_thread_blocked, id=3924] 0x02a3d800 JavaThread "Reference Handler" daemon [_thread_blocked, id=4008] =>0x00386400 JavaThread "main" [_thread_in_native, id=2400] Other Threads: 0x02a34400 VMThread [id=3708] 0x02a4e800 WatcherThread [id=3964] VM state:not at safepoint (normal execution) VM Mutex/Monitor currently owned by a thread: None Heap def new generation total 960K, used 131K [0x22960000, 0x22a60000, 0x22e40000) eden space 896K, 7% used [0x22960000, 0x22970ea8, 0x22a40000) from space 64K, 99% used [0x22a50000, 0x22a5fff8, 0x22a60000) to space 64K, 0% used [0x22a40000, 0x22a40000, 0x22a50000) tenured generation total 4096K, used 76K [0x22e40000, 0x23240000, 0x26960000) the space 4096K, 1% used [0x22e40000, 0x22e53060, 0x22e53200, 0x23240000) compacting perm gen total 12288K, used 137K [0x26960000, 0x27560000, 0x2a960000) the space 12288K, 1% used [0x26960000, 0x26982518, 0x26982600, 0x27560000) ro space 8192K, 62% used [0x2a960000, 0x2ae5e4e8, 0x2ae5e600, 0x2b160000) rw space 12288K, 52% used [0x2b160000, 0x2b7a0e78, 0x2b7a1000, 0x2bd60000) Dynamic libraries: 0x00400000 - 0x00423000 C:\Program Files\Java\jre1.6.0_01\bin\javaw.exe 0x7c900000 - 0x7c9b0000 C:\WINDOWS\system32\ntdll.dll 0x7c800000 - 0x7c8f4000 C:\WINDOWS\system32\kernel32.dll 0x77dd0000 - 0x77e6b000 C:\WINDOWS\system32\ADVAPI32.dll 0x77e70000 - 0x77f01000 C:\WINDOWS\system32\RPCRT4.dll 0x7e410000 - 0x7e4a0000 C:\WINDOWS\system32\USER32.dll 0x77f10000 - 0x77f57000 C:\WINDOWS\system32\GDI32.dll 0x76390000 - 0x763ad000 C:\WINDOWS\system32\IMM32.DLL 0x7c340000 - 0x7c396000 C:\Program Files\Java\jre1.6.0_01\bin\msvcr71.dll 0x6d7c0000 - 0x6da07000 C:\Program Files\Java\jre1.6.0_01\bin\client\jvm.dll 0x76b40000 - 0x76b6d000 C:\WINDOWS\system32\WINMM.dll 0x5cd70000 - 0x5cd77000 C:\WINDOWS\system32\serwvdrv.dll 0x5b0a0000 - 0x5b0a7000 C:\WINDOWS\system32\umdmxfrm.dll 0x6d310000 - 0x6d318000 C:\Program Files\Java\jre1.6.0_01\bin\hpi.dll 0x76bf0000 - 0x76bfb000 C:\WINDOWS\system32\PSAPI.DLL 0x6d770000 - 0x6d77c000 C:\Program Files\Java\jre1.6.0_01\bin\verify.dll 0x6d3b0000 - 0x6d3cf000 C:\Program Files\Java\jre1.6.0_01\bin\java.dll 0x6d7b0000 - 0x6d7bf000 C:\Program Files\Java\jre1.6.0_01\bin\zip.dll 0x10000000 - 0x10012000 C:\Documents and Settings\Alex\workspace\MediaServer\rxtxSerial.dll 0x73d90000 - 0x73db7000 C:\WINDOWS\system32\crtdll.dll VM Arguments: jvm_args: -Djava.library.path=C:\Documents and Settings\Alex\workspace\MediaServer java_command: com.bjt.media.server.DigitoolConnection Launcher Type: SUN_STANDARD Environment Variables: CLASSPATH=.;C:\Program Files\Java\j2re1.4.2_07\lib\ext\QTJava.zip PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\wbem;c:\applications\php;C:\Program Files\MATLAB\R2006a\bin\win32;C:\Roger\Projects\UAV\Bin\Debug;C:\Program Files\Microsoft SQL Server\80\Tools\Binn\;c:\Program Files\Microsoft SQL Server\90\Tools\binn\;C:\Program Files\QuickTime\QTSystem\;C:\Pfps\system;C:\Program Files\Java\jdk1.6.0_01\bin;C:\Program Files\Java\jdk1.6.0_01\jre\bin USERNAME=Alex OS=Windows_NT PROCESSOR_IDENTIFIER=x86 Family 15 Model 4 Stepping 1, GenuineIntel --------------- S Y S T E M --------------- OS: Windows XP Build 2600 Service Pack 2 CPU:total 1 family 15, cmov, cx8, fxsr, mmx, sse, sse2 Memory: 4k page, physical 1046508k(275288k free), swap 2522816k(1909176k free) vm_info: Java HotSpot(TM) Client VM (1.6.0_01-b06) for windows-x86, built on Mar 14 2007 00:24:02 by "java_re" with unknown MS VC++:1310 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070604/c87ae1f0/attachment-0005.html From alwyn.schoeman at gmail.com Tue Jun 5 00:10:19 2007 From: alwyn.schoeman at gmail.com (Alwyn Schoeman) Date: Tue, 5 Jun 2007 08:10:19 +0200 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Hi, I'm using a similar modem. By default rxtx doesn't look for devices that start with ACM, so you need to modify the source code and recompile. Look in RXTXCommDriver and add values for ACM in the registerScannedPorts method in the Linux specific parts. Look for osName.equals("Linux")... On 6/4/07, soop soop wrote: > > Hi Guys, > > Looked through the archives but still cannot figure this out. I have a > Motorola G24 GPRS/GSM modem that I am connecting to my server running > Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not > detecting the port, CommPortIdentifier.getPortIdentifiers(). > > I have added the line to RXTXCommDriver: > > "ttyACM" // for USB Modems > > Rxtx still does not seem to find the port. Is there something I am missing > to make this port visable? > > [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver > [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device > [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control > Model > driver for USB modems and ISDN adapters > > I really need your help as I have moved my server from windows to Linux > and > have been down for a few days because of this .. Thanks so much! > > _________________________________________________________________ > PC Magazine's 2007 editors' choice for best Web mail?award-winning Windows > Live Hotmail. > > http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -- Alwyn Schoeman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/b6cb3053/attachment-0005.html From naranjo.manuel at gmail.com Tue Jun 5 06:48:45 2007 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Tue, 05 Jun 2007 09:48:45 -0300 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> References: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Message-ID: <46655BAD.7010501@gmail.com> That's right, an easier solution is creating symlinks to acm. For example make ttyS70 to 79 point to ACM0 to 9 and that will help you a lot, and doesn't even require compile. > Hi, > > I'm using a similar modem. By default rxtx doesn't look for devices > that start with ACM, so you need to modify the > source code and recompile. > > Look in RXTXCommDriver and add values for ACM in the > registerScannedPorts method in the Linux specific parts. Look for > osName.equals("Linux")... > From juanemc2 at gmail.com Tue Jun 5 07:02:43 2007 From: juanemc2 at gmail.com (Juan) Date: Tue, 5 Jun 2007 10:02:43 -0300 Subject: [Rxtx] Problems with Epson TMU220B POSPrinter using XON/XOFF Flow Control and rxtx jar and dll's with the serial port. Message-ID: Hi!, I?m having trouble printing to the serial port using the latest version of rxtx jar and dll's with an Epson POSPrinter. I`ve switched the printer to work with XON/XOFF Flow Control and have watched the serial port to be sure the printer is sending the XON XOFF stop and go characters. I`ve setted the port like this: CommPortIdentifier commPortIdentifier = CommPortIdentifier.* getPortIdentifier*(_portName); SerialPort serialPort = (SerialPort)commPortIdentifier.open(*this*.getClass().getName(), 2000); serialPort.setSerialPortParams(_baudRate, _dataBits, _stopBits, _parity); serialPort.setFlowControlMode( SerialPort.*FLOWCONTROL_XONXOFF_IN* | SerialPort.*FLOWCONTROL_XONXOFF_OUT*); where the baudRate is 9600 the dataBits is 8 the stopBits is 1 and the parity is 0 It seems as the library isn`t taking into account the XON XOFF setting. I would like to know if I`m setting correctly the Flow Control and if you had had any experiences using XON XOFF flow control and could give me some help to solve my problem. I`m very thankful in advance, Yours, Juan Polero -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/b080995a/attachment-0005.html From ehdez.correo at gmail.com Tue Jun 5 07:12:53 2007 From: ehdez.correo at gmail.com (=?ISO-8859-1?Q?Enrique_Hern=E1ndez?=) Date: Tue, 5 Jun 2007 09:12:53 -0400 Subject: [Rxtx] problem with rxtx Message-ID: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Hello: I doing a simple test to show the serial ports. This is the code: import java.util.Enumeration; import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; public class Show { private Enumeration portList; private CommPortIdentifier portId; private SerialPort port; /** Creates a new instance of Show */ public Show() { } public static void main(String args[]){ Show show = new Show(); show.portList = CommPortIdentifier.getPortIdentifiers(); String tPort = ""; System.out.println("========================================="); while(show.portList.hasMoreElements()){ show.portId = (CommPortIdentifier)show.portList.nextElement(); if(show.portId.getPortType() == CommPortIdentifier.PORT_SERIAL) tPort = "Serial"; else tPort = "Parallel"; System.out.println(show.portId.getName() + " " + tPort); } } } whit The problem is that this code not show the serial ports, this show the no use serial ports. I want to connect whit the modem but when windows open and connect the modem my application don't see the port(COMM3) when it is connect. what I can do? Is that the correct way to know the ports? thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/eedd744b/attachment-0005.html From ehdez.correo at gmail.com Tue Jun 5 07:42:13 2007 From: ehdez.correo at gmail.com (=?ISO-8859-1?Q?Enrique_Hern=E1ndez?=) Date: Tue, 5 Jun 2007 09:42:13 -0400 Subject: [Rxtx] serial port Message-ID: <4a814e1f0706050642p4ce9ac7bka80f9479c524c5ea@mail.gmail.com> Hello: How I can ask to the port what device is connect and information about this device. thanks. bye. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/4d10d26a/attachment-0005.html From supsoop at hotmail.com Tue Jun 5 09:29:00 2007 From: supsoop at hotmail.com (soop soop) Date: Tue, 05 Jun 2007 15:29:00 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Message-ID: Hi Guys, Thanks for all your help. I found the problem. I created a user, Tomcat55, for my tomcat but it did not belong to any group. I then added this user to dialout group to have access to the device ttyACM0. Works perfectly! Again permissions was the issue. This also seems to be persistent as a server reboot does not effect the access. Cheers! >From: "Alwyn Schoeman" >Reply-To: RXTX Developers and Users >To: "RXTX Developers and Users" >Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >Date: Tue, 5 Jun 2007 08:10:19 +0200 > >Hi, > >I'm using a similar modem. By default rxtx doesn't look for devices that >start with ACM, so you need to modify the >source code and recompile. > >Look in RXTXCommDriver and add values for ACM in the registerScannedPorts >method in the Linux specific parts. Look for osName.equals("Linux")... > >On 6/4/07, soop soop wrote: >> >>Hi Guys, >> >>Looked through the archives but still cannot figure this out. I have a >>Motorola G24 GPRS/GSM modem that I am connecting to my server running >>Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not >>detecting the port, CommPortIdentifier.getPortIdentifiers(). >> >>I have added the line to RXTXCommDriver: >> >>"ttyACM" // for USB Modems >> >>Rxtx still does not seem to find the port. Is there something I am missing >>to make this port visable? >> >>[ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver >>[ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device >>[ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control >>Model >>driver for USB modems and ISDN adapters >> >>I really need your help as I have moved my server from windows to Linux >>and >>have been down for a few days because of this .. Thanks so much! >> >>_________________________________________________________________ >>PC Magazine's 2007 editors' choice for best Web mail—award-winning Windows >>Live Hotmail. >> >>http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 >> >> >>_______________________________________________ >>Rxtx mailing list >>Rxtx at qbang.org >>http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > >-- >Alwyn Schoeman >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ Need a break? Find your escape route with Live Search Maps. http://maps.live.com/default.aspx?ss=Restaurants~Hotels~Amusement%20Park&cp=33.832922~-117.915659&style=r&lvl=13&tilt=-90&dir=0&alt=-1000&scene=1118863&encType=1&FORM=MGAC01 From netbeans at gatworks.com Tue Jun 5 09:42:31 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 11:42:31 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <46658467.20101@gatworks.com> soop soop wrote: > > Hi Guys, > > Thanks for all your help. I found the problem. I created a user, > Tomcat55, for my tomcat but it did not belong to any group. I then added Look at man pages for the program udev. From tjarvi at qbang.org Tue Jun 5 18:18:17 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Jun 2007 18:18:17 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Message-ID: On Tue, 5 Jun 2007, Enrique Hern?ndez wrote: > The problem is that this code not show the serial ports, this show the no > use serial ports. I want to connect whit the modem but when windows open and > connect the modem my application don't see the port(COMM3) when it is > connect. > what I can do? > Is that the correct way to know the ports? > Hello, We may have problems understanding each other. On windows, the port will not be an available serial port if another application has the port open. That is just how the library behaves. If you can not see the port in the enumerated list, you could not open it. Also note that enumeration only happens once. If you add a port such as a new USB dongle, the port will not be visible until the next time your application runs. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Tue Jun 5 18:45:01 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 20:45:01 -0400 Subject: [Rxtx] problem with rxtx In-Reply-To: References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Message-ID: <4666038D.8090700@gatworks.com> Trent Jarvi wrote: > > > Also note that enumeration only happens once. If you add a port such as > a new USB dongle, the port will not be visible until the next time your > application runs. Is this written in stone ? somewhere? From tjarvi at qbang.org Tue Jun 5 18:54:36 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Jun 2007 18:54:36 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <4666038D.8090700@gatworks.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> Message-ID: On Tue, 5 Jun 2007, Uncle George wrote: > Trent Jarvi wrote: >> >> >> Also note that enumeration only happens once. If you add a port such as >> a new USB dongle, the port will not be visible until the next time your >> application runs. > > Is this written in stone ? somewhere? It is just the current behavior. There is nothing preventing a fix that allows reenumeration. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Tue Jun 5 19:55:19 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 21:55:19 -0400 Subject: [Rxtx] problem with rxtx In-Reply-To: References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> Message-ID: <46661407.4020308@gatworks.com> >> Is this written in stone ? somewhere? > > It is just the current behavior. There is nothing preventing a fix that > allows reenumeration. With usb, ..... , things come and go. Seems a shame that you have to kill application to get at the device u just plugged in. From joachim at buechse.ch Wed Jun 6 01:50:06 2007 From: joachim at buechse.ch (Joachim Buechse) Date: Wed, 6 Jun 2007 09:50:06 +0200 Subject: [Rxtx] problem with rxtx In-Reply-To: <46661407.4020308@gatworks.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> <46661407.4020308@gatworks.com> Message-ID: <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> On MacOS RXTX's enumeration handling is more flexible. It will find new ports that are added during the lifetime of the application. But this is inherently incompatible with suns javax.comm implementation... Regards, Joachim On 06.06.2007, at 03:55, Uncle George wrote: > >>> Is this written in stone ? somewhere? >> >> It is just the current behavior. There is nothing preventing a >> fix that >> allows reenumeration. > > With usb, ..... , things come and go. Seems a shame that you have to > kill application to get at the device u just plugged in. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Jun 6 06:06:48 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Jun 2007 06:06:48 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> <46661407.4020308@gatworks.com> <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> Message-ID: Sun's javax.comm is not a major concern going forward. As long as we do not break old applications using rxtx, I see no reason to limit rxtx to that convention. We have already rejected version 3 from Sun as a dead end and limited our compatability to version 2. That does not mean we will not try to work with Sun and others but the current javax.comm convention (v3) is not a well conceived path. There has been discussion about doing a JSR which is one valid option. On Wed, 6 Jun 2007, Joachim Buechse wrote: > On MacOS RXTX's enumeration handling is more flexible. It will find > new ports that are added during the lifetime of the application. But > this is inherently incompatible with suns javax.comm implementation... > > Regards, > Joachim > > On 06.06.2007, at 03:55, Uncle George wrote: > >> >>>> Is this written in stone ? somewhere? >>> >>> It is just the current behavior. There is nothing preventing a >>> fix that >>> allows reenumeration. >> >> With usb, ..... , things come and go. Seems a shame that you have to >> kill application to get at the device u just plugged in. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From yvespielusenet at free.fr Wed Jun 6 08:46:35 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 16:46:35 +0200 Subject: [Rxtx] [PARALLEL] resource in use Message-ID: <1181141195.3407.20.camel@localhost.localdomain> Hello, I want to use rxtx in my application. I haveto send data to a very old printer (which have a drum and hammers http://perso.orange.fr/tiie/page00010017.html) This is printer is connecter with centronics. It works well but, while it's writting and I putthe printer off-line, after about 45 seconds, I have this error : ------------------------------------- java.io.IOException: La ressource demand?e est en cours d'utilisation. in writeArray at gnu.io.LPRPort.writeArray(Native Method) at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:292) at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:161) at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:156) at mce.buffer.bufferManager.BufferManager$PrintBuffer.run(BufferManager.java:141) The IOexception means "The wanted resource is in use" ------------------------------------- Here is the line 141 of BufferManager : ------------------------------------- while(send){ try{ fos.write(bb); <=== line 141 send = false; } catch(Exception e){ javax.swing.JOptionPane.showMessageDialog(null, "Erreur d'envoie. Veuillez cliquer sur OK pour relancer l'impression de la vignette.\nV?rifiez votre impression !", "Erreur d'envoie", javax.swing.JOptionPane.WARNING_MESSAGE); e.printStackTrace(System.err); System.err.flush(); System.out.println(e); send = true; } } -------------------------------- 'fos' is an outputstream which contains the rxtx stream (this.os is the rxtx outputstream) : -------------------------------- public void write(byte[] bb) throws IOException{ this.write(bb, 0, bb.length); } public void write(byte[] bb, int off, int len) throws IOException{ while(!imp1.isPrinterSelected() || !imp2.isPrinterSelected()){ } this.os.write(bb, off, len); } -------------------------------- Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( can you help me ? thank you :) -- yves piel From yvespielusenet at free.fr Wed Jun 6 09:11:15 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 17:11:15 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181141195.3407.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> Message-ID: <1181142675.3407.23.camel@localhost.localdomain> I forgot to tell that It's under windows XP and java 1.5. Le mercredi 06 juin 2007 ? 16:46 +0200, yves pielusenet a ?crit : > Hello, > I want to use rxtx in my application. I haveto send data to a very old > printer (which have a drum and hammers > http://perso.orange.fr/tiie/page00010017.html) > This is printer is connecter with centronics. It works well but, while > it's writting and I putthe printer off-line, after about 45 seconds, I > have this error : > ------------------------------------- > java.io.IOException: La ressource demand?e est en cours d'utilisation. > in writeArray > at gnu.io.LPRPort.writeArray(Native Method) > at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:292) > at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:161) > at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:156) > at mce.buffer.bufferManager.BufferManager$PrintBuffer.run(BufferManager.java:141) > > The IOexception means "The wanted resource is in use" > ------------------------------------- > > Here is the line 141 of BufferManager : > > ------------------------------------- > while(send){ > try{ > fos.write(bb); <=== line 141 > send = false; > } > catch(Exception e){ > javax.swing.JOptionPane.showMessageDialog(null, "Erreur d'envoie. Veuillez cliquer sur OK pour relancer l'impression de la vignette.\nV?rifiez votre impression !", "Erreur d'envoie", javax.swing.JOptionPane.WARNING_MESSAGE); > e.printStackTrace(System.err); > System.err.flush(); > System.out.println(e); > send = true; > } > } > -------------------------------- > 'fos' is an outputstream which contains the rxtx stream (this.os is the rxtx outputstream) : > > -------------------------------- > public void write(byte[] bb) throws IOException{ > this.write(bb, 0, bb.length); > } > public void write(byte[] bb, int off, int len) throws IOException{ > while(!imp1.isPrinterSelected() || !imp2.isPrinterSelected()){ > } > this.os.write(bb, off, len); > } > -------------------------------- > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > can you help me ? > > thank you :) > From netbeans at gatworks.com Wed Jun 6 09:21:46 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 11:21:46 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181141195.3407.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> Message-ID: <4666D10A.8000507@gatworks.com> } > -------------------------------- > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > can you help me ? > > thank you :) > windoz or linux? ( I guess windoz ) for windoz, there appears to be a timeout ( as Comments suggest ) of about 40seconds. > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } for linux, there is no implied timeout. > if( write( fd, bytes, count ) < 0 ) > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); From netbeans at gatworks.com Wed Jun 6 09:39:41 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 11:39:41 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666D10A.8000507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> Message-ID: <4666D53D.90000@gatworks.com> Uncle George wrote: > } >> -------------------------------- >> >> Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( >> >> can you help me ? From reading the code, I can see your concern. And it appears you are correct, because some of the data will be sent to the OS printer buffers, and then it will refuse to accept anymore. Unfortunately, writeArray does not return the num of characters written :{ So application has no idea to how many characters were accepted by the OS. I dont do windoz, so I cant say with absolute certainty what windoz will do with an off-line condition. If you have the source, and can compile, then maybe u can increase the loop count to hit 4hours? From yvespielusenet at free.fr Wed Jun 6 09:53:25 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 17:53:25 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666D10A.8000507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> Message-ID: <1181145205.3407.35.camel@localhost.localdomain> Thank you for your explanation :) This timeout comes when no data has been send to the printer after 40seconds if I well understand. But why there is such a timeout ? If I setthe printer offline while it's printing I mustn't have an exception. I don't understand why the "printer should solv all problems like buffer full" in 40 seconds. If I pause the printer the buffer will not be emptied, isn't it ? I not very familiar with C/C++, but it seem that the exception is thrown only when countWritten == 0, that means no data at all has been sent. So Is my code is good since when I intercept this exception I send all my buffer again. There is no way that the printer receive two times same bytes ? thanks ps: yes the application is running on windows XP since I developpe under Debian Le mercredi 06 juin 2007 ? 11:21 -0400, Uncle George a ?crit : > } > > -------------------------------- > > > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > > > can you help me ? > > > > thank you :) > > > > windoz or linux? ( I guess windoz ) > > for windoz, there appears to be a timeout ( as Comments suggest ) of > about 40seconds. > > while( count > 0 ){ > > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > > /* > > this are 20 * 2 seconds, in this time a printer (or other parallel device) > > should solv all problems like buffer full, etc > > */ > > if(errorCount++ < 20){ > > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > > continue; > > } > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > for linux, there is no implied timeout. > > if( write( fd, bytes, count ) < 0 ) > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Wed Jun 6 10:34:24 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 12:34:24 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181145205.3407.35.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> Message-ID: <4666E210.30507@gatworks.com> yves pielusenet wrote: > Thank you for your explanation :) > This timeout comes when no data has been send to the printer after > 40seconds if I well understand. But why there is such a timeout ? If I > setthe printer offline while it's printing I mustn't have an exception. > I don't understand why the "printer should solv all problems like buffer > full" in 40 seconds. If I pause the printer the buffer will not be > emptied, isn't it ? > > I not very familiar with C/C++, but it seem that the exception is thrown > only when countWritten == 0, that means no data at all has been sent. So > Is my code is good since when I intercept this exception I send all my > buffer again. There is no way that the printer receive two times same > bytes ? More technically, the function call returns and reports that 0 characters was written in this call. when 0 characters are written, it will check how many times 0 characters was written. If it has tried LESS than 20 times(errorCount), it will sleep() and try to write again. After 20 times, it wont sleep, but throw you the exception. Now suppose you are writing a 120 character line. you off-lined/paused your printer. The OS has room for 80 more characters in it's printer buffer. The WriteFile() will have a char count of 120, but on return the countWritten = 80. You still have 40 more characters to print. Since countWritten != 0, the counters: bytes += countWritten; count -= countWritten; get updated, and the Writefile now has a count of 40 characters. Since the printer is off-line, the countwritten is 0. And so the loop continues, till 40 seconds is up. As to why it is this way, i dont know ( not a windoz maven ); Also the sleep(20) in the loop is not so intuitive to suggest 2 seconds of sleep. I would have guessed 20seconds, or 20milliseconds. But go figure. BTW: Since your computer sends you error messages in French, does it curse in English? :)))) From yvespielusenet at free.fr Thu Jun 7 02:27:44 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Thu, 07 Jun 2007 10:27:44 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666E210.30507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> Message-ID: <1181204864.3501.10.camel@localhost.localdomain> Maybe in my case I should re-compile rxtx and change the code. Instead of send an exception I should display a dialog box to ask if it's printer problem or if it should trie to send bytes. Something like : while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } if(displayDialogBox("Try again to send datas ??")){ errorCount = 0; } else{ throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } } Le mercredi 06 juin 2007 ? 12:34 -0400, Uncle George a ?crit : > yves pielusenet wrote: > > Thank you for your explanation :) > > This timeout comes when no data has been send to the printer after > > 40seconds if I well understand. But why there is such a timeout ? If I > > setthe printer offline while it's printing I mustn't have an exception. > > I don't understand why the "printer should solv all problems like buffer > > full" in 40 seconds. If I pause the printer the buffer will not be > > emptied, isn't it ? > > > > I not very familiar with C/C++, but it seem that the exception is thrown > > only when countWritten == 0, that means no data at all has been sent. So > > Is my code is good since when I intercept this exception I send all my > > buffer again. There is no way that the printer receive two times same > > bytes ? > More technically, the function call returns and reports that 0 > characters was written in this call. > when 0 characters are written, it will check how many times 0 characters > was written. If it has tried LESS than 20 times(errorCount), it will > sleep() and try to write again. > After 20 times, it wont sleep, but throw you the exception. > > Now suppose you are writing a 120 character line. you off-lined/paused > your printer. The OS has room for 80 more characters in it's printer > buffer. The WriteFile() will have a char count of 120, but on return the > countWritten = 80. You still have 40 more characters to print. > Since countWritten != 0, the counters: > bytes += countWritten; > count -= countWritten; > get updated, and the Writefile now has a count of 40 characters. Since > the printer is off-line, the countwritten is 0. And so the loop > continues, till 40 seconds is up. > > As to why it is this way, i dont know ( not a windoz maven ); > Also the sleep(20) in the loop is not so intuitive to suggest 2 seconds > of sleep. I would have guessed 20seconds, or 20milliseconds. But go figure. > > BTW: Since your computer sends you error messages in French, does it > curse in English? :)))) > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 06:11:43 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 08:11:43 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181204864.3501.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> Message-ID: <4667F5FF.8070903@gatworks.com> your suggestion appears good. I dont know what displayDialogBox exactly will do, so all I can say it that it looks good. But I'd like to wait 10min before first dialog box And a 5 min wait for every dialog box there after. And since these are custom solution/choices, maybe a more exact explanation of what the issue is. if(errorCount++ < 300){ // wait 10min ( 10min * 60sec / 2 ) Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } if(displayDialogBox("Printer has Paused. Retry sending data?")){ errorCount = 150; // Wait for 5 min thereafter continue; } > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } yves pielusenet wrote: > Maybe in my case I should re-compile rxtx and change the code. Instead > of send an exception I should display a dialog box to ask if it's > printer problem or if it should trie to send bytes. Something like : > > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > > if(displayDialogBox("Try again to send datas ??")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > } > From yvespielusenet at free.fr Thu Jun 7 07:17:21 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Thu, 07 Jun 2007 15:17:21 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4667F5FF.8070903@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <4667F5FF.8070903@gatworks.com> Message-ID: <1181222241.3501.20.camel@localhost.localdomain> thank you :) 'displayDialogBox()' I think doesn't exist. It was just for the example :) But I think It should not be so complicated to display a dialog box under windows with YES/NO buttons. When yes is clicked it return 0 other it returns 1. Le jeudi 07 juin 2007 ? 08:11 -0400, Uncle George a ?crit : > your suggestion appears good. I dont know what displayDialogBox exactly > will do, so all I can say it that it looks good. > > But I'd like to wait 10min before first dialog box And a 5 min wait for > every dialog box there after. And since these are custom > solution/choices, maybe a more exact explanation of what the issue is. > > if(errorCount++ < 300){ // wait 10min ( 10min * 60sec / 2 ) > Sleep( 20 ); /* make a small pause to execute all other requests > in all other threads */ > continue; > } > > if(displayDialogBox("Printer has Paused. Retry sending data?")){ > errorCount = 150; // Wait for 5 min thereafter > continue; > } > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > > yves pielusenet wrote: > > Maybe in my case I should re-compile rxtx and change the code. Instead > > of send an exception I should display a dialog box to ask if it's > > printer problem or if it should trie to send bytes. Something like : > > > > while( count > 0 ){ > > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > > /* > > this are 20 * 2 seconds, in this time a printer (or other parallel device) > > should solv all problems like buffer full, etc > > */ > > if(errorCount++ < 20){ > > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > > continue; > > } > > > > if(displayDialogBox("Try again to send datas ??")){ > > errorCount = 0; > > } > > else{ > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > } > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 07:41:43 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 09:41:43 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181222241.3501.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <4667F5FF.8070903@gatworks.com> <1181222241.3501.20.camel@localhost.localdomain> Message-ID: <46680B17.8050109@gatworks.com> yves pielusenet wrote: > thank you :) > 'displayDialogBox()' I think doesn't exist. It was just for the > example :) too bad. Good luck. From rtrout at webbresearch.com Thu Jun 7 11:23:04 2007 From: rtrout at webbresearch.com (Robert Trout) Date: Thu, 07 Jun 2007 13:23:04 -0400 Subject: [Rxtx] Disconnected PortServer TS causes Java to hang Message-ID: <1181236984.14186.33.camel@sisyphus.DinkumSoftware.com> I'm running Linux with sun's Java 1.4.2, Java comm API 2.0, RXTX 2.0-7pre1, and the RealPort digi driver. "/dev/ttyrp00" is a RealPort device. My Java application never returns from a ComPortIdentifier.getPortIdentifier("/dev/ttyrp00") call while the Digi PortServer TS 4 is disconnected from the network. If I later re-connect the PortServer, the call returns about 30 seconds later (it's like a serial port read or write is blocking until the PortServer is re- connected). With the PortServer disconnected, minicom immediately responds with "cannot open /dev/ttyrp00: No such file or directory". I would like my Java application to behave similarly. That is, respond with an error condition instead of hanging when the PortServer is not connected. Since minicom and Java behave differently, I think this "hanging" behavior may be due to RXTX or Java? Has anyone had a similar issue? Solutions? Suggestions? Thanks, Robert From vicnevicne at gmail.com Thu Jun 7 12:16:02 2007 From: vicnevicne at gmail.com (Vicne) Date: Thu, 07 Jun 2007 20:16:02 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181204864.3501.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> Message-ID: <46684B62.7080802@gmail.com> yves pielusenet wrote: > Maybe in my case I should re-compile rxtx and change the code. Instead > of send an exception I should display a dialog box to ask if it's > printer problem or if it should trie to send bytes. Something like : > > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > > if(displayDialogBox("Try again to send datas ??")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > } > Sorry to step in without a specific solution to your problem, but I wanted to share my feeling regarding this proposal. AFAIK, it's generally considered bad practice to pop-up a prompt from a library. The main reason is that in general use, you can't guarantee that someone is actually present behind the console. Imagine a print server in a machine room, connected to a park of printers. In that case, when one printer fails, the logical behaviour would be to use an other one. If you change RxTx the way you propose, the printer queue will simply be stuck with a useless "Try again to send data ?" prompt until an administrator opens a remote connection to the print server's console and clicks "no". Second, it would create a dependency upon the existence of a graphical console (if you go the graphical "dialogBox" way). On many applications (typically server or embedded ones), the JVM is "headless" and if you try to pop-up a dialog, your app would throw an exception (at best) or just wouldn't display the prompt anywhere... Going the "text console" way is not more reliable, because on graphical environments, the text console is hidden unless explicitly requested. My advice would be to think again and find another solution. Ideas are : - make the number of retries a parameter so that you can tune it to what you think is reasonable - throw a more specific exception when the number of retries has been reached, so that a specific prompt can be shown at a higher level Anyway, if you feel that the prompt is the way to go in your case, I would at least make that prompt conditional. The least intrusive way would probably be using a system property, like if("true".equals(System.getProperty("org.rxtx.usePrompt")) && displayDialogBox("Retry sending data ?")){ errorCount = 0; } else{ throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } By default, the behaviour would remain as it is now, but you could force the prompts by defining the property at VM launch if desired. (for example : java.exe -Dorg.rxtx.usePrompt=true myApp) Also, you seemed to say you wanted the printer to start again exactly where is stopped. It would indeed be the best way when the printer is put offline for a few seconds. On the other hand, if the printer is turned off (or the printer runs out of paper, or someone steps on the mains cable), then the only way to go back to a "stable" situation would be by printing the item (page, label, etc.) again from scratch... Just my two cents. Vicne PS : By the way, the dialog box thing is very platform dependant on the C-side, and I think the simplest way would probably be to bridge it to a Java call where you can implement it like you proposed : public boolean displayDialogBox(prompt) { return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); } From netbeans at gatworks.com Thu Jun 7 14:08:24 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 16:08:24 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46684B62.7080802@gmail.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> Message-ID: <466865B8.4060004@gatworks.com> My feeling is that the code that was suggested was for his environs ( his shop ). The issue here is that after a 40+ second wait, an exception will be thrown. But you really dont have a way of 'cancelling' all the WriteFiles() that have already occured before the exception so that your writeArray and the Commapi can backtrack to a position in which they are in sync. The main ( really mine ) concern is not to lose data, or replicate data. After 40seconds, 300 seconds, 55min, no matter how long, data should not be lost or duplicated. But as soon as the exception is thrown, that possibility exists. Maybe an event should be thrown instead? Vicne wrote: > yves pielusenet wrote: >> Maybe in my case I should re-compile rxtx and change the code. Instead >> of send an exception I should display a dialog box to ask if it's >> printer problem or if it should trie to send bytes. Something like : >> >> while( count > 0 ){ >> if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ >> /* >> this are 20 * 2 seconds, in this time a printer (or other parallel device) >> should solv all problems like buffer full, etc >> */ >> if(errorCount++ < 20){ >> Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ >> continue; >> } >> >> if(displayDialogBox("Try again to send datas ??")){ >> errorCount = 0; >> } >> else{ >> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >> break; >> } >> } >> > > Sorry to step in without a specific solution to your problem, but I > wanted to share my feeling regarding this proposal. AFAIK, it's > generally considered bad practice to pop-up a prompt from a library. > The main reason is that in general use, you can't guarantee that > someone is actually present behind the console. Imagine a print server > in a machine room, connected to a park of printers. In that case, when > one printer fails, the logical behaviour would be to use an other one. > If you change RxTx the way you propose, the printer queue will simply be > stuck with a useless "Try again to send data ?" prompt until an > administrator opens a remote connection to the print server's console > and clicks "no". > Second, it would create a dependency upon the existence of a > graphical console (if you go the graphical "dialogBox" way). On many > applications (typically server or embedded ones), the JVM is "headless" > and if you try to pop-up a dialog, your app would throw an exception (at > best) or just wouldn't display the prompt anywhere... Going the "text > console" way is not more reliable, because on graphical environments, > the text console is hidden unless explicitly requested. > > My advice would be to think again and find another solution. Ideas are : > - make the number of retries a parameter so that you can tune it to what > you think is reasonable > - throw a more specific exception when the number of retries has been > reached, so that a specific prompt can be shown at a higher level > > Anyway, if you feel that the prompt is the way to go in your case, I > would at least make that prompt conditional. The least intrusive way > would probably be using a system property, like > > if("true".equals(System.getProperty("org.rxtx.usePrompt")) > && displayDialogBox("Retry sending data ?")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > > > By default, the behaviour would remain as it is now, but you could > force the prompts by defining the property at VM launch if desired. (for > example : java.exe -Dorg.rxtx.usePrompt=true myApp) > > > Also, you seemed to say you wanted the printer to start again > exactly where is stopped. It would indeed be the best way when the > printer is put offline for a few seconds. On the other hand, if the > printer is turned off (or the printer runs out of paper, or someone > steps on the mains cable), then the only way to go back to a "stable" > situation would be by printing the item (page, label, etc.) again from > scratch... > > > Just my two cents. > > > Vicne > > PS : By the way, the dialog box thing is very platform dependant on the > C-side, and I think the simplest way would probably be to bridge it to a > Java call where you can implement it like you proposed : > > public boolean displayDialogBox(prompt) { > return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", > JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); > } > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Thu Jun 7 17:48:11 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 Jun 2007 17:48:11 -0600 (MDT) Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <466865B8.4060004@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> Message-ID: An event is possible. I'm amazed this is the largest problem encountered while using the parallel code. How would the write ever exit if we throw events? Isn't this going to lead to hung applications? On Thu, 7 Jun 2007, Uncle George wrote: > My feeling is that the code that was suggested was for his environs ( > his shop ). > > The issue here is that after a 40+ second wait, an exception will be > thrown. But you really dont have a way of 'cancelling' all the > WriteFiles() that have already occured before the exception so that your > writeArray and the Commapi can backtrack to a position in which they are > in sync. > > The main ( really mine ) concern is not to lose data, or replicate data. > After 40seconds, 300 seconds, 55min, no matter how long, data should > not be lost or duplicated. But as soon as the exception is thrown, that > possibility exists. > > Maybe an event should be thrown instead? > > Vicne wrote: >> yves pielusenet wrote: >>> Maybe in my case I should re-compile rxtx and change the code. Instead >>> of send an exception I should display a dialog box to ask if it's >>> printer problem or if it should trie to send bytes. Something like : >>> >>> while( count > 0 ){ >>> if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ >>> /* >>> this are 20 * 2 seconds, in this time a printer (or other parallel device) >>> should solv all problems like buffer full, etc >>> */ >>> if(errorCount++ < 20){ >>> Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ >>> continue; >>> } >>> >>> if(displayDialogBox("Try again to send datas ??")){ >>> errorCount = 0; >>> } >>> else{ >>> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >>> break; >>> } >>> } >>> >> >> Sorry to step in without a specific solution to your problem, but I >> wanted to share my feeling regarding this proposal. AFAIK, it's >> generally considered bad practice to pop-up a prompt from a library. >> The main reason is that in general use, you can't guarantee that >> someone is actually present behind the console. Imagine a print server >> in a machine room, connected to a park of printers. In that case, when >> one printer fails, the logical behaviour would be to use an other one. >> If you change RxTx the way you propose, the printer queue will simply be >> stuck with a useless "Try again to send data ?" prompt until an >> administrator opens a remote connection to the print server's console >> and clicks "no". >> Second, it would create a dependency upon the existence of a >> graphical console (if you go the graphical "dialogBox" way). On many >> applications (typically server or embedded ones), the JVM is "headless" >> and if you try to pop-up a dialog, your app would throw an exception (at >> best) or just wouldn't display the prompt anywhere... Going the "text >> console" way is not more reliable, because on graphical environments, >> the text console is hidden unless explicitly requested. >> >> My advice would be to think again and find another solution. Ideas are : >> - make the number of retries a parameter so that you can tune it to what >> you think is reasonable >> - throw a more specific exception when the number of retries has been >> reached, so that a specific prompt can be shown at a higher level >> >> Anyway, if you feel that the prompt is the way to go in your case, I >> would at least make that prompt conditional. The least intrusive way >> would probably be using a system property, like >> >> if("true".equals(System.getProperty("org.rxtx.usePrompt")) >> && displayDialogBox("Retry sending data ?")){ >> errorCount = 0; >> } >> else{ >> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >> break; >> } >> >> >> By default, the behaviour would remain as it is now, but you could >> force the prompts by defining the property at VM launch if desired. (for >> example : java.exe -Dorg.rxtx.usePrompt=true myApp) >> >> >> Also, you seemed to say you wanted the printer to start again >> exactly where is stopped. It would indeed be the best way when the >> printer is put offline for a few seconds. On the other hand, if the >> printer is turned off (or the printer runs out of paper, or someone >> steps on the mains cable), then the only way to go back to a "stable" >> situation would be by printing the item (page, label, etc.) again from >> scratch... >> >> >> Just my two cents. >> >> >> Vicne >> >> PS : By the way, the dialog box thing is very platform dependant on the >> C-side, and I think the simplest way would probably be to bridge it to a >> Java call where you can implement it like you proposed : >> >> public boolean displayDialogBox(prompt) { >> return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", >> JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); >> } >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 19:18:51 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 21:18:51 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> Message-ID: <4668AE7B.3060409@gatworks.com> The UNIX version of writeArray is not too great either. It is possible that the write will only process some of the bytes. #else if( write( fd, bytes, count ) < 0 ) throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); #endif -------------------------------- Maybe it might be better to have the native function inform the caller of the # of characters written, then the commapi/output-buffer can be modified to reflect the #of chars written. If an exception is to be thrown, for too many loops of chars written == 0, then exception wont affect the state of the output buffer. Then a ParallelPort.restart() can be called to resume printing whats in the buffer. Trent Jarvi wrote: > An event is possible. I'm amazed this is the largest problem encountered > while using the parallel code. > > How would the write ever exit if we throw events? Isn't this going to > lead to hung applications? Sure. If you dont time out, then there is nothing that will force an EXIT from the write(). Issue is what has the OS done with the write. > > On Thu, 7 Jun 2007, Uncle George wrote: > >> My feeling is that the code that was suggested was for his environs ( >> his shop ). From yvespielusenet at free.fr Fri Jun 8 01:09:01 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Fri, 08 Jun 2007 09:09:01 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4668AE7B.3060409@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> Message-ID: <1181286541.3674.10.camel@localhost.localdomain> It is not possible that the rxtx java method write(byte[], int offset, int length) return anint which contains the number of byte really send to the printer instead of an exception ? So this is the programm which will see if all bytes have been sent. If not it can retry to send the unsended bytes. -------------------------------------------------------- int sended = 0; while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ sended += countWritten; /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } return sended; /*throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break;*/ } ... ... return countWritten; ------------------------------------------------ Le jeudi 07 juin 2007 ? 21:18 -0400, Uncle George a ?crit : > The UNIX version of writeArray is not too great either. It is possible > that the write will only process some of the bytes. > > #else > if( write( fd, bytes, count ) < 0 ) > throw_java_exception_system_msg( env, IO_EXCEPTION, > "writeArray" ); > #endif > -------------------------------- > > Maybe it might be better to have the native function inform the caller > of the # of characters written, then the commapi/output-buffer can be > modified to reflect the #of chars written. If an exception is to be > thrown, for too many loops of chars written == 0, then exception wont > affect the state of the output buffer. Then a ParallelPort.restart() can > be called to resume printing whats in the buffer. > > > Trent Jarvi wrote: > > An event is possible. I'm amazed this is the largest problem encountered > > while using the parallel code. > > > > How would the write ever exit if we throw events? Isn't this going to > > lead to hung applications? > Sure. If you dont time out, then there is nothing that will force an > EXIT from the write(). Issue is what has the OS done with the write. > > > > On Thu, 7 Jun 2007, Uncle George wrote: > > > >> My feeling is that the code that was suggested was for his environs ( > >> his shop ). > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Fri Jun 8 03:45:00 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 11:45:00 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181286541.3674.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> Message-ID: <20070608094500.GC21069@elberon.bln.de.ingenico.com> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > It is not possible that the rxtx java method write(byte[], int offset, > int length) return anint which contains the number of byte really send > to the printer instead of an exception ? > So this is the programm which will see if all bytes have been sent. If > not it can retry to send the unsended bytes. I think write() is void because in Java people love to do this since OutputStream :-) Of course on such interfaces you cannot implement something nice. If you would have a int write, you would not implement the interface and no applications expecting this interface would link/work/compile. oki, Steffen P.S.: (OT) If you propose not to implement the Java interfaces (especially not on JNI level), maybe optionally offering a wrapper that removes e.g. the write return value and so on to downgrade the powerful classic old POSIX read/write style to the modern limited Java style, then I agree :-) Same for read. Instead of things like "int avialable()" it is more powerful to have an approach as select(2) offers (to guarante the caller that read/write will not block [nothing else make sense anyway IMHO] but may read/write less bytes then requested). The caller gets full control and the higher level protocols can care about timeouts, invoking read in some loops and/or implement retransmission. On top of such an implementation, where everything is controlled, defined, guaranteed and reliable, someone could use an InputStream or OutputStream style interface. Or even better: don't use them at all :) just BTW :-) St. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From yvespielusenet at free.fr Fri Jun 8 05:52:45 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Fri, 08 Jun 2007 13:52:45 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <20070608094500.GC21069@elberon.bln.de.ingenico.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> Message-ID: <1181303565.11203.3.camel@localhost.localdomain> So maybe a better way should be to create a new Exception class which has a method "int getWrittenByte()". So the Exception should be use to send again bytes which are not printed yet. yves Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : > * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > > It is not possible that the rxtx java method write(byte[], int offset, > > int length) return anint which contains the number of byte really send > > to the printer instead of an exception ? > > So this is the programm which will see if all bytes have been sent. If > > not it can retry to send the unsended bytes. > > I think write() is void because in Java people love to do this > since OutputStream :-) Of course on such interfaces you cannot > implement something nice. If you would have a int write, you > would not implement the interface and no applications expecting > this interface would link/work/compile. > > oki, > > Steffen > > P.S.: (OT) > If you propose not to implement the Java interfaces (especially > not on JNI level), maybe optionally offering a wrapper that > removes e.g. the write return value and so on to downgrade the > powerful classic old POSIX read/write style to the modern limited > Java style, then I agree :-) Same for read. Instead of things > like "int avialable()" it is more powerful to have an approach as > select(2) offers (to guarante the caller that read/write will not > block [nothing else make sense anyway IMHO] but may read/write > less bytes then requested). The caller gets full control and the > higher level protocols can care about timeouts, invoking read in > some loops and/or implement retransmission. On top of such an > implementation, where everything is controlled, defined, > guaranteed and reliable, someone could use an InputStream or > OutputStream style interface. Or even better: don't use them at > all :) just BTW :-) > St. > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > 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. > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > 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. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Fri Jun 8 06:46:21 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 08:46:21 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181303565.11203.3.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> Message-ID: <46694F9D.5080501@gatworks.com> It seems that with outputstream.write(b[]), you become terribly uncoordinated as soon as an exception is thrown. Docs do not say what happens to the data. Yet from a practicable point of view, one would like to know if the write was accepted in-full, or rejected before any writes. There are no in betweens, as partial writes are not reportable. So for an outputstream.write(), in order for it to return, the full write request has to be taken, and stored in an internal output buffer. If there is no room, the write() is suspended, till there is room. Or throw's an IOException( "no room in buffer") ; As the select() loop for write reports buffer room avail, then more of the internal buffer is sent to the printer. yves pielusenet wrote: > So maybe a better way should be to create a new Exception class which > has a method "int getWrittenByte()". So the Exception should be use to > send again bytes which are not printed yet. > > yves > > Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : >> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: >>> It is not possible that the rxtx java method write(byte[], int offset, >>> int length) return anint which contains the number of byte really send >>> to the printer instead of an exception ? >>> So this is the programm which will see if all bytes have been sent. If >>> not it can retry to send the unsended bytes. >> I think write() is void because in Java people love to do this >> since OutputStream :-) Of course on such interfaces you cannot >> implement something nice. If you would have a int write, you >> would not implement the interface and no applications expecting >> this interface would link/work/compile. >> >> oki, >> >> Steffen >> >> P.S.: (OT) >> If you propose not to implement the Java interfaces (especially >> not on JNI level), maybe optionally offering a wrapper that >> removes e.g. the write return value and so on to downgrade the >> powerful classic old POSIX read/write style to the modern limited >> Java style, then I agree :-) Same for read. Instead of things >> like "int avialable()" it is more powerful to have an approach as >> select(2) offers (to guarante the caller that read/write will not >> block [nothing else make sense anyway IMHO] but may read/write >> less bytes then requested). The caller gets full control and the >> higher level protocols can care about timeouts, invoking read in >> some loops and/or implement retransmission. On top of such an >> implementation, where everything is controlled, defined, >> guaranteed and reliable, someone could use an InputStream or >> OutputStream style interface. Or even better: don't use them at >> all :) just BTW :-) >> St. >> >> About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. >> 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. >> >> About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. >> 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. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From Steffen.DETTMER at ingenico.com Fri Jun 8 08:12:18 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 16:12:18 +0200 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <46694F9D.5080501@gatworks.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: <20070608141218.GE21069@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 08:46 -0400: > It seems that with outputstream.write(b[]), you become terribly > uncoordinated as soon as an exception is thrown. Docs do not say what > happens to the data. (yes, so avoiding it seems to be good :)) > Yet from a practicable point of view, one would like to know if the > write was accepted in-full, or rejected before any writes. There are no > in betweens, as partial writes are not reportable. (which is an artificial API limitation. I never understood how this happend when they invented JDK because the well-known BSD socket API and thus [probably] WinSock does this correct, but anyway) > So for an outputstream.write(), in order for it to return, the full > write request has to be taken, and stored in an internal output buffer. > If there is no room, the write() is suspended, till there is room. Or > throw's an IOException( "no room in buffer") ; As the select() loop for > write reports buffer room avail, then more of the internal buffer is > sent to the printer. yes, might be good in case of a printer. May be horrible in case of PPP/TCP or some other transmission control protocol which may e.g. repeat data or even omit parts of it (e.g. internet realtime radio station broadcasting)... So I think the idea of "int write" (e.g. BSD sockets, linux files and so on) still is the best. A clean API / implementation should guarantee and allow implementations (users) to rely on that; assumptions and automatic background-sending and so on may look pragmatic and may even work on the first look, but may fail in other situations. BTW, if e.g. BSD socket API is known, why not simply copy it (until something better is invented :)) instead of fiddling around with JDK APIs? anyway, have a nice weekend everyone :-) oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Fri Jun 8 08:55:56 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 10:55:56 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070608141218.GE21069@elberon.bln.de.ingenico.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> Message-ID: <46696DFC.7000801@gatworks.com> >> write reports buffer room avail, then more of the internal buffer is >> sent to the printer. > > yes, might be good in case of a printer. May be horrible in case > of PPP/TCP or some other transmission control protocol which > may e.g. repeat data or even omit parts of it (e.g. internet > realtime radio station broadcasting)... So I think the idea of > "int write" (e.g. BSD sockets, linux files and so on) still is > the best. A clean API / implementation should guarantee and allow > implementations (users) to rely on that; assumptions and > automatic background-sending and so on may look pragmatic and may > even work on the first look, but may fail in other situations. > BTW, if e.g. BSD socket API is known, why not simply copy it > (until something better is invented :)) instead of fiddling > around with JDK APIs? But we were talking about the Parallel Port, and the transmission of data over the commapi/parallel-port schema. There isn't much in bi-directional software communication. Its a simple write one byte at a time interface. I'm not looking to change the comm-api. I'm just looking to alter the interaction between the Native ParallelPort functions, and the java ParallelPort functions that call them. This might be more readily doable than to get a committee to re-specify java-API specs. BTW: Whats is off-topic? ( help: not looking for def of off-topic ) From j.kenneth.gentle at acm.org Fri Jun 8 08:58:59 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Fri, 08 Jun 2007 10:58:59 -0400 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <20070608141218.GE21069@elberon.bln.de.ingenico.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> Message-ID: <200706081459.l58Ex5rA019991@qbang.org> Perhaps it is a bit late to jump in on this one, but here goes anyway. If the solutions all seem to "break" the contract with "java.io.outputstream", then, as noted, that may not be the appropriate contract. At the risk of being heretical, JDK1.4 introduced the "nio" package to address some of the compatibility issues with C apis mentioned in previous posts. The interface "java.nio.channels.WriteableByteChannel" defines the following single method: int write(ByteBuffer source); int, strangely enough, is the actual number of bytes written. So, if RXTX as written, against the JavaCOMM api and OutputStream, doesn't do what we want, how about writing a different set of bindings using the java.nio classes and as much of the underlying native code as possible. Note that just because the java.nio.channels.WriteableByteChannel sends back a result, OutputStream.write doesn't have to - and they could both call the same underlying native code. My 2 cents - maybe not worth even that... Ken From netbeans at gatworks.com Fri Jun 8 10:37:28 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 12:37:28 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <200706081459.l58Ex5rA019991@qbang.org> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> Message-ID: <466985C8.8000505@gatworks.com> Ken Gentle wrote: > Perhaps it is a bit late to jump in on this one, but here goes anyway. Common in, the waters fine. > > If the solutions all seem to "break" the contract with > "java.io.outputstream", then, as noted, that may not be the > appropriate contract. > How would the contract be broken? The machinery underneath is handling the contract. From j.kenneth.gentle at acm.org Fri Jun 8 10:48:01 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Fri, 08 Jun 2007 12:48:01 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466985C8.8000505@gatworks.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> Message-ID: <200706081648.l58Gm7YA022904@qbang.org> At 12:37 2007-06-08, you wrote: >Ken Gentle wrote: > > > > If the solutions all seem to "break" the contract with > > "java.io.outputstream", then, as noted, that may not be the > > appropriate contract. > > >How would the contract be broken? The machinery underneath is handling >the contract. It seems that a lot of the discussion has been about not only the timeout and being able to adjust it in the "machinery layer", but also about knowing in the Java layer, in the event of a timeout or exception, how many characters have been written to the device. An OutputStream won't ever do this with out an extension and including a return value "breaks" the contract, right? So, go with a Java IO api that *does* return the number of bytes written, out of the NIO package. I know it doesn't allow for a strict implementation of the JavaCOMM API - however, using NIO classes in place of the IO classes isn't that big a break and would allow those applications that need such information a way to get it. Maybe I'm misunderstanding the problem... Ken From netbeans at gatworks.com Fri Jun 8 11:24:14 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 13:24:14 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <200706081648.l58Gm7YA022904@qbang.org> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> Message-ID: <466990BE.7040100@gatworks.com> Ken Gentle wrote: An > OutputStream won't ever do this with out an extension and including a > return value "breaks" the contract, right? > i was not thinking of change the API to OutputSream. Are there specs for how output stream should work internally? for instance: String data = "Hello this is a line of data"; Outputstream.write( data.getbytes() ); ParallelPort.suspend(); int free = ParallelPort.getoutputbufferfree(); There is a symbiotic relationship between outputstream and the functionality of ParallelPort. From Steffen.DETTMER at ingenico.com Fri Jun 8 11:15:39 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 19:15:39 +0200 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <200706081459.l58Ex5rA019991@qbang.org> References: <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> Message-ID: <20070608171539.GK21069@elberon.bln.de.ingenico.com> * Ken Gentle wrote on Fri, Jun 08, 2007 at 10:58 -0400: > If the solutions all seem to "break" the contract with > "java.io.outputstream", then, as noted, that may not be the > appropriate contract. > > At the risk of being heretical, JDK1.4 introduced the "nio" package > to address some of the compatibility issues with C apis mentioned in > previous posts. The interface > "java.nio.channels.WriteableByteChannel" defines the following single method: > > int write(ByteBuffer source); > > int, strangely enough, is the actual number of bytes written. Yes, AFAIK one of the motivations for the NIO interface was, that the JDK-1.3 APIs (InputStream, e.g.) were not powerfull enough, especially for multi-connection-TCP servers or so. I don't know much about it but I've heard of a project where NIO usage was removed because of stability issues in multi-threaded environments and performance limitations under some circumstances. IIRC the "nio.ByteBuffer" is something very special (namely something you cannot implement in Java, it is "magic" or part of the language itself). Not sure if this is such a great idea (but for performance in the end sometimes heavy prices must be paid) :) > So, if RXTX as written, against the JavaCOMM api and OutputStream, > doesn't do what we want, how about writing a different set of > bindings using the java.nio classes and as much of the underlying > native code as possible. Yes, this would be an idea: use a full-featured interface on JNI, and, if wanted, deliver some wrappers converting this to a less-featured Java-compliant interface. However, powerful things as e.g. "select" are difficult to "emulate" if you are e.g. on some (older?) windows. But if you expose the full-featured APIs, you need to emulate them full-featured, theoretically. In the end it depends what you do on the serial line. If you just want to talk to a modem, then you may not need precise timeouts. But if you need to implement complexer protocols which define response times and timeouts, you may quickly get into difficulties. For instance, AFAIK, rxtx 1.7.2 (?) for windows is very messy with timeouts (there is a maximum, higher values are truncated; resolution is 100ms only; the function may take up to twice the timeout because internally it may be called twice). Probably for most people this is OK, but probably not for all. But having precise timeouts should be OK for all :-) Well, in the end it is nice to wish but somewhat hard to implement (many platforms, connections, USB, BlueTooth, whatever). oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Steffen.DETTMER at ingenico.com Fri Jun 8 11:04:22 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 19:04:22 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <46696DFC.7000801@gatworks.com> References: <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <46696DFC.7000801@gatworks.com> Message-ID: <20070608170422.GJ21069@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 10:55 -0400: > > BTW, if e.g. BSD socket API is known, why not simply copy it > > (until something better is invented :)) instead of fiddling > > around with JDK APIs? > > But we were talking about the Parallel Port, and the > transmission of data over the commapi/parallel-port schema. > There isn't much in bi-directional software communication. Its > a simple write one byte at a time interface. First, there are things like PLIP (http://en.wikipedia.org/wiki/Plip) - well, probably not widely used, sure ;) Second, I think if there is a good simple API known to support all that (with known "best practices") or so and there is no forcing need to invent a new one, why not simply using it? > I'm not looking to change the comm-api. I'm just looking to > alter the interaction between the Native ParallelPort > functions, and the java ParallelPort functions that call them. Ahh, yes. I think this is what I tried to ask. Having an usable JNI interface and on top (in pure java) some wrapper to InputStream or whatever could be done (e.g. by ignoring the return value of write or throwing if != length). Developers could then use the full-featured (non-JAVA-standard) API or select among various wrappers (as InputStream). > This might be more readily doable than to get a committee to > re-specify java-API specs. Yes, of course. I'm afraid that the Java APIs change regularily, but still yet with limited success it seems, so maybe they get it in one of the next iterations; who knows, maybe Java-9 has a BSD-like socket API :) SCNR. > BTW: Whats is off-topic? ( help: not looking for def of > off-topic ) I think I started some "re-specify java-API specs" which was OT probably. oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From lists at iDIAcomputing.com Fri Jun 8 18:48:54 2007 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Fri, 08 Jun 2007 20:48:54 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46684B62.7080802@gmail.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> Message-ID: <4669F8F6.3040101@iDIAcomputing.com> Vicne wrote: > Sorry to step in without a specific solution to your problem, but I > wanted to share my feeling regarding this proposal. AFAIK, it's > generally considered bad practice to pop-up a prompt from a library. ... > > My advice would be to think again and find another solution. Ideas are : > - make the number of retries a parameter so that you can tune it to what > you think is reasonable > - throw a more specific exception when the number of retries has been > reached, so that a specific prompt can be shown at a higher level You could also allow the client code to register a callback class which returns a boolean indicating whether to retry or cancel. This callback class could pop up a dialog, if appropriate, or follow some preset policy, or.... - George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From joachim at buechse.ch Sat Jun 9 09:43:16 2007 From: joachim at buechse.ch (Joachim Buechse) Date: Sat, 9 Jun 2007 17:43:16 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46694F9D.5080501@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: You should not forget, that in the case of an exception it may not even be known what happened to the data. You have a kernel buffer, outgoing chip buffer, incoming chip buffer, etc. So of course, it would be nice to know up to which point data was correctly processed, but this feedback does not exist on the hardware or protocol level and hence can in general not be magicly created on the software level... Regards, Joachim On 08.06.2007, at 14:46, Uncle George wrote: > It seems that with outputstream.write(b[]), you become terribly > uncoordinated as soon as an exception is thrown. Docs do not say what > happens to the data. > > Yet from a practicable point of view, one would like to know if the > write was accepted in-full, or rejected before any writes. There > are no > in betweens, as partial writes are not reportable. > > So for an outputstream.write(), in order for it to return, the full > write request has to be taken, and stored in an internal output > buffer. > If there is no room, the write() is suspended, till there is room. Or > throw's an IOException( "no room in buffer") ; As the select() loop > for > write reports buffer room avail, then more of the internal buffer is > sent to the printer. > > > > yves pielusenet wrote: >> So maybe a better way should be to create a new Exception class which >> has a method "int getWrittenByte()". So the Exception should be >> use to >> send again bytes which are not printed yet. >> >> yves >> >> Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : >>> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: >>>> It is not possible that the rxtx java method write(byte[], int >>>> offset, >>>> int length) return anint which contains the number of byte >>>> really send >>>> to the printer instead of an exception ? >>>> So this is the programm which will see if all bytes have been >>>> sent. If >>>> not it can retry to send the unsended bytes. >>> I think write() is void because in Java people love to do this >>> since OutputStream :-) Of course on such interfaces you cannot >>> implement something nice. If you would have a int write, you >>> would not implement the interface and no applications expecting >>> this interface would link/work/compile. >>> >>> oki, >>> >>> Steffen >>> >>> P.S.: (OT) >>> If you propose not to implement the Java interfaces (especially >>> not on JNI level), maybe optionally offering a wrapper that >>> removes e.g. the write return value and so on to downgrade the >>> powerful classic old POSIX read/write style to the modern limited >>> Java style, then I agree :-) Same for read. Instead of things >>> like "int avialable()" it is more powerful to have an approach as >>> select(2) offers (to guarante the caller that read/write will not >>> block [nothing else make sense anyway IMHO] but may read/write >>> less bytes then requested). The caller gets full control and the >>> higher level protocols can care about timeouts, invoking read in >>> some loops and/or implement retransmission. On top of such an >>> implementation, where everything is controlled, defined, >>> guaranteed and reliable, someone could use an InputStream or >>> OutputStream style interface. Or even better: don't use them at >>> all :) just BTW :-) >>> St. >>> >>> About Ingenico Throughout the world businesses rely on Ingenico >>> for secure and expedient electronic transaction acceptance. >>> Ingenico products leverage proven technology, established >>> standards and unparalleled ergonomics to provide optimal >>> reliability, versatility and usability. This comprehensive range >>> of products is complemented by a global array of services and >>> partnerships, enabling businesses in a number of vertical sectors >>> to accept transactions anywhere their business takes them. >>> 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. >>> >>> About Ingenico Throughout the world businesses rely on Ingenico >>> for secure and expedient electronic transaction acceptance. >>> Ingenico products leverage proven technology, established >>> standards and unparalleled ergonomics to provide optimal >>> reliability, versatility and usability. This comprehensive range >>> of products is complemented by a global array of services and >>> partnerships, enabling businesses in a number of vertical sectors >>> to accept transactions anywhere their business takes them. >>> 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. >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx 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 yvespielusenet at free.fr Mon Jun 11 03:15:12 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Mon, 11 Jun 2007 11:15:12 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: <1181553312.8335.14.camel@localhost.localdomain> So can someone tell a solution for my problem :( Must I say to the user to not put the printer off-line ? I can't since he has to do some pauses, verify print, paper conditioning etc... How do other people ? Before I use the parport librarry to read port status : http://www.geocities.com/Juanga69/parport/ (which doesn't work on windows XP) And I send data into the file LPT1 I use to have no problem when printer was disabled. thanks -- yves piel Le samedi 09 juin 2007 ? 17:43 +0200, Joachim Buechse a ?crit : > You should not forget, that in the case of an exception it may not > even be known what happened to the data. > > You have a kernel buffer, outgoing chip buffer, incoming chip buffer, > etc. So of course, it would be nice to know up to which point data > was correctly processed, but this feedback does not exist on the > hardware or protocol level and hence can in general not be magicly > created on the software level... > > Regards, > Joachim > > On 08.06.2007, at 14:46, Uncle George wrote: > > > It seems that with outputstream.write(b[]), you become terribly > > uncoordinated as soon as an exception is thrown. Docs do not say what > > happens to the data. > > > > Yet from a practicable point of view, one would like to know if the > > write was accepted in-full, or rejected before any writes. There > > are no > > in betweens, as partial writes are not reportable. > > > > So for an outputstream.write(), in order for it to return, the full > > write request has to be taken, and stored in an internal output > > buffer. > > If there is no room, the write() is suspended, till there is room. Or > > throw's an IOException( "no room in buffer") ; As the select() loop > > for > > write reports buffer room avail, then more of the internal buffer is > > sent to the printer. > > > > > > > > yves pielusenet wrote: > >> So maybe a better way should be to create a new Exception class which > >> has a method "int getWrittenByte()". So the Exception should be > >> use to > >> send again bytes which are not printed yet. > >> > >> yves > >> > >> Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : > >>> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > >>>> It is not possible that the rxtx java method write(byte[], int > >>>> offset, > >>>> int length) return anint which contains the number of byte > >>>> really send > >>>> to the printer instead of an exception ? > >>>> So this is the programm which will see if all bytes have been > >>>> sent. If > >>>> not it can retry to send the unsended bytes. > >>> I think write() is void because in Java people love to do this > >>> since OutputStream :-) Of course on such interfaces you cannot > >>> implement something nice. If you would have a int write, you > >>> would not implement the interface and no applications expecting > >>> this interface would link/work/compile. > >>> > >>> oki, > >>> > >>> Steffen > >>> > >>> P.S.: (OT) > >>> If you propose not to implement the Java interfaces (especially > >>> not on JNI level), maybe optionally offering a wrapper that > >>> removes e.g. the write return value and so on to downgrade the > >>> powerful classic old POSIX read/write style to the modern limited > >>> Java style, then I agree :-) Same for read. Instead of things > >>> like "int avialable()" it is more powerful to have an approach as > >>> select(2) offers (to guarante the caller that read/write will not > >>> block [nothing else make sense anyway IMHO] but may read/write > >>> less bytes then requested). The caller gets full control and the > >>> higher level protocols can care about timeouts, invoking read in > >>> some loops and/or implement retransmission. On top of such an > >>> implementation, where everything is controlled, defined, > >>> guaranteed and reliable, someone could use an InputStream or > >>> OutputStream style interface. Or even better: don't use them at > >>> all :) just BTW :-) > >>> St. > >>> > >>> About Ingenico Throughout the world businesses rely on Ingenico > >>> for secure and expedient electronic transaction acceptance. > >>> Ingenico products leverage proven technology, established > >>> standards and unparalleled ergonomics to provide optimal > >>> reliability, versatility and usability. This comprehensive range > >>> of products is complemented by a global array of services and > >>> partnerships, enabling businesses in a number of vertical sectors > >>> to accept transactions anywhere their business takes them. > >>> 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. > >>> > >>> About Ingenico Throughout the world businesses rely on Ingenico > >>> for secure and expedient electronic transaction acceptance. > >>> Ingenico products leverage proven technology, established > >>> standards and unparalleled ergonomics to provide optimal > >>> reliability, versatility and usability. This comprehensive range > >>> of products is complemented by a global array of services and > >>> partnerships, enabling businesses in a number of vertical sectors > >>> to accept transactions anywhere their business takes them. > >>> 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. > >>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx 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 > From Steffen.DETTMER at ingenico.com Mon Jun 11 03:56:18 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 11:56:18 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466990BE.7040100@gatworks.com> References: <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> Message-ID: <20070611095618.GA10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 13:24 -0400: > i was not thinking of change the API to OutputSream. Then I think either someone uses OutputStream (and has no reliable information about incomplete writes) or someone uses somethink else. > Are there specs for how output stream should work internally? > > for instance: > String data = "Hello this is a line of data"; > Outputstream.write( data.getbytes() ); > ParallelPort.suspend(); > int free = ParallelPort.getoutputbufferfree(); > > There is a symbiotic relationship between outputstream and the > functionality of ParallelPort. If you need OutputStream "plus something else", in short you're needing "something else". Personally I dislike the code above a lot. The stream "looks" like if it would be an OutputStream, but in fact it isn't. You need to call getoutputbufferfree later to check if write succeeded (but OutputStream promises that write succeedes synchronous, blocking, or throws an exception). So it is not an OutputStream. No application written for OutputStreams would work without change (because it won't know getoutputbufferfree at all). It is not abstracted from ParallelPort. I think this would be wrong. Then I think an alternative interface instead is better. Let's assume we had some "connection" (to distinguish between OutputStreams and Channels). Then why not working as on a file handle in POSIX: do { // ... select maybe using timer ... readyForWrite = ... if (readyForWrite) { int writtenBytes = connection.write(toWrite); toWrite.remove(0, writtenBytes); } while(readyForWrite && toWrite.length > 0); I think, having such a write isn't the big problem. I think, the difficult thing is around "select" - however this would look like. It should be OO, typesafe, performant, supporting multiple connections/channels/streams in various modes and should be orthogonal to other functionalities. Of course, this heavily depends on what the application is doing; for a simple situation (like reading a small, mandatory file from a local disk) this would be to uncomfortable (and offering unneeded features only). just BTW :) oki, Steffen -- // Modeline for VIM. Please don't remove. // (Help: autoindent, expandtab, shiftwidth=4, tabstop=4, textwidth=75) // vi: set ai et sw=4 ts=4 tw=75 ft=java: About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Mon Jun 11 05:38:33 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 07:38:33 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611095618.GA10821@elberon.bln.de.ingenico.com> References: <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> Message-ID: <466D3439.4020805@gatworks.com> Steffen DETTMER wrote: > (but OutputStream promises that write > succeedes synchronous, blocking, or throws an exception). Where is it so written? From Steffen.DETTMER at ingenico.com Mon Jun 11 06:36:50 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 14:36:50 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466D3439.4020805@gatworks.com> References: <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> <466D3439.4020805@gatworks.com> Message-ID: <20070611123650.GI10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Mon, Jun 11, 2007 at 07:38 -0400: > Steffen DETTMER wrote: > > > (but OutputStream promises that write > > succeedes synchronous, blocking, or throws an exception). > > Where is it so written? Now, as you ask, I think it is not written that clearly but follows from specification. mmm... Am I wrong? I understand the API doc in this way: * http://java.sun.com/j2se/1.4.2/docs/api/java/io/OutputStream.html#write(byte[]) > public void write(byte[] b) > throws IOException > > Writes b.length bytes from the specified byte array to this > output stream. The general contract for write(b) is that > it should have exactly the same effect as the call write(b, > 0, b.length). > > Parameters: > b - the data. > Throws: > IOException - if an I/O error occurs. > See Also: > write(byte[], int, int) and there is: > public void write(byte[] b, > int off, > int len) > throws IOException > > Writes len bytes from the specified byte array starting at > offset off to this output stream. The general contract for > write(b, off, len) is that some of the bytes in the array b > are written to the output stream in order; element b[off] > is the first byte written and b[off+len-1] is the last byte > written by this operation. > > The write method of OutputStream calls the write method of > one argument on each of the bytes to be written out. > Subclasses are encouraged to override this method and > provide a more efficient implementation. > > If b is null, a NullPointerException is thrown. > > If off is negative, or len is negative, or off+len is > greater than the length of the array b, then an > IndexOutOfBoundsException is thrown. > > Parameters: > b - the data. > off - the start offset in the data. > len - the number of bytes to write. > Throws: > IOException - if an I/O error occurs. In particular, an > IOException is thrown if the output stream is closed. In general, any specialisation (derived child class) must comform to this. So write in the end is specified (!) as "The write method ... calls the write method ... on each of the bytes to be written out". This is what must be implemented by ANY OutputStream. Of course, there is: "Subclasses are encouraged to override this method and provide a more efficient implementation." which IMHO does not contradict - the more efficient must behave in exactly the same way of course (just wasting less resources than a simple byte-by-byte write). So it does not matter here I think. The write that finally defines the behavior tells basically: > "Writes the specified byte to this output stream. The general > contract for write is that one byte is written to the output > stream. " > > Throws: > IOException - if an I/O error occurs. which IMHO is another way of saying "write writes the byte immediately and returns on success (only), otherwise an exception is thrown". Especially it cannot happen that zero bytes are written (i.e. the specified byte is NOT written) without an exception. So by this write must be synchronous and blocking, because otherwise it could not reliably know if an asynchronous operation will succeede or not (some getAsyncResult or so would be needed). Since write(byte[]) does this for each byte (or with a behavior beeing exactly the same as if it would do), I think this means that the write(byte[]) succeedes synchronous/blocking or throws an exception. Did I an error in reasoning or confused something or so? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From j.kenneth.gentle at acm.org Mon Jun 11 06:51:25 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 11 Jun 2007 08:51:25 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611123650.GI10821@elberon.bln.de.ingenico.com> References: <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> <466D3439.4020805@gatworks.com> <20070611123650.GI10821@elberon.bln.de.ingenico.com> Message-ID: <200706111251.l5BCpS9T017831@qbang.org> It is as Steffen describes. "InputStream" and "OutputStream" are inherently synchronous (which is why so many java programs resort to threads to use them). Anything outside of this "contract" is *not* an InputStream or OutputStream. That is why there is a new package for things that don't behave like the old *Stream classes - the NIO package. If you look carefully at the IO package, you'll note that almost all the classes are _Decorator_ pattern implementations of the *Stream classes - and the interface presents the _same_ behavior to the calling code in all cases - a synchronous operation that completes successfully or throws an exception (with the one exception of "read" that returns a "-1" on end-of-stream. I know I've read this numerous times - I'd suggest checking the Language Spec or one of the books by Bloch or Gosling. Ken At 08:36 2007-06-11, you wrote: >* Uncle George wrote on Mon, Jun 11, 2007 at 07:38 -0400: > > Steffen DETTMER wrote: > > > > > (but OutputStream promises that write > > > succeedes synchronous, blocking, or throws an exception). > > > > Where is it so written? > >Now, as you ask, I think it is not written that clearly but >follows from specification. mmm... > >Am I wrong? > >I understand the API doc in this way: > >* >http://java.sun.com/j2se/1.4.2/docs/api/java/io/OutputStream.html#write(byte[]) > > public void write(byte[] b) > > throws IOException > > > > Writes b.length bytes from the specified byte array to this > > output stream. The general contract for write(b) is that > > it should have exactly the same effect as the call write(b, > > 0, b.length). > > > > Parameters: > > b - the data. > > Throws: > > IOException - if an I/O error occurs. > > See Also: > > write(byte[], int, int) > > >and there is: > > > > public void write(byte[] b, > > int off, > > int len) > > throws IOException > > > > Writes len bytes from the specified byte array starting at > > offset off to this output stream. The general contract for > > write(b, off, len) is that some of the bytes in the array b > > are written to the output stream in order; element b[off] > > is the first byte written and b[off+len-1] is the last byte > > written by this operation. > > > > The write method of OutputStream calls the write method of > > one argument on each of the bytes to be written out. > > Subclasses are encouraged to override this method and > > provide a more efficient implementation. > > > > If b is null, a NullPointerException is thrown. > > > > If off is negative, or len is negative, or off+len is > > greater than the length of the array b, then an > > IndexOutOfBoundsException is thrown. > > > > Parameters: > > b - the data. > > off - the start offset in the data. > > len - the number of bytes to write. > > Throws: > > IOException - if an I/O error occurs. In particular, an > > IOException is thrown if the output stream is closed. > > >In general, any specialisation (derived child class) must comform >to this. So write in the end is specified (!) as "The write >method ... calls the write method ... on each of the bytes to be >written out". This is what must be implemented by ANY >OutputStream. > >Of course, there is: "Subclasses are encouraged to override this >method and provide a more efficient implementation." which IMHO >does not contradict - the more efficient must behave in exactly >the same way of course (just wasting less resources than a simple >byte-by-byte write). So it does not matter here I think. > > > >The write that finally defines the behavior tells basically: > > > "Writes the specified byte to this output stream. The general > > contract for write is that one byte is written to the output > > stream. " > > > > Throws: > > IOException - if an I/O error occurs. > > >which IMHO is another way of saying "write writes the byte >immediately and returns on success (only), otherwise an exception >is thrown". Especially it cannot happen that zero bytes are >written (i.e. the specified byte is NOT written) without an >exception. So by this write must be synchronous and blocking, >because otherwise it could not reliably know if an asynchronous >operation will succeede or not (some getAsyncResult or so would >be needed). > >Since write(byte[]) does this for each byte (or with a behavior >beeing exactly the same as if it would do), I think this means >that the write(byte[]) succeedes synchronous/blocking or throws >an exception. > >Did I an error in reasoning or confused something or so? > >oki, > >Steffen > >About Ingenico Throughout the world businesses rely on Ingenico for >secure and expedient electronic transaction acceptance. Ingenico >products leverage proven technology, established standards and >unparalleled ergonomics to provide optimal reliability, versatility >and usability. This comprehensive range of products is complemented >by a global array of services and partnerships, enabling businesses >in a number of vertical sectors to accept transactions anywhere >their business takes them. >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. > >About Ingenico Throughout the world businesses rely on Ingenico for >secure and expedient electronic transaction acceptance. Ingenico >products leverage proven technology, established standards and >unparalleled ergonomics to provide optimal reliability, versatility >and usability. This comprehensive range of products is complemented >by a global array of services and partnerships, enabling businesses >in a number of vertical sectors to accept transactions anywhere >their business takes them. >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. > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From alesinskyy at googlemail.com Mon Jun 11 07:25:33 2007 From: alesinskyy at googlemail.com (Oleksandr Alesinskyy) Date: Mon, 11 Jun 2007 15:25:33 +0200 Subject: [Rxtx] [OT] select :-) Message-ID: Sorry, but I have to disagree with following statement: "So write in the end is specified (!) as "The write method ... calls the write method ... on each of the bytes to be written out". This is what must be implemented by ANY OutputStream.". This is not part of the specification or contract, it is just revealed implementation detail of the OutputStream. It is not stated anywhere that behavoiur of derived classes shall conform with this one. Statement concerning "synchronous" nature of the output stream is invalid as well. Really synchronous stream does not require flush() but OutputStream has it. From Steffen.DETTMER at ingenico.com Mon Jun 11 08:21:16 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 16:21:16 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: Message-ID: <20070611142116.GN10821@elberon.bln.de.ingenico.com> * Oleksandr Alesinskyy wrote on Mon, Jun 11, 2007 at 15:25 +0200: > Sorry, but I have to disagree with following statement: > "So write in the end is specified (!) as "The write > method ... calls the write method ... on each of the bytes to be > written out". This is what must be implemented by ANY > OutputStream.". > > This is not part of the specification or contract, it is just > revealed implementation detail of the OutputStream. It is not > stated anywhere that behavoiur of derived classes shall conform > with this one. (I didn't meant that the implementation must really write byte by byte, but that it must "look as if it would do" - because all implementations of OutputStream must "look" in the same way [which is another way of saying "do abstract" I think]) I think the API doc is not "revealing implementation details" but it is the *specification* of that interface and derivations must (should) conform to this specification. Isn't this the idea of interfaces? A function that expects an OutputStream should work on ANY OutputStream, shouldn't it? just kidding: I mean, what would be the point in implementing a checksum function as OutputStream.write which throws its result as IOException? Or which requires to call close() as very first operation to tell that the application is about to transmit confidential data? :-) > Statement concerning "synchronous" nature of the output stream > is invalid as well. Really synchronous stream does not require > flush() but OutputStream has it. ahh, interesting point! I think this is another bug in the API. flush() is wrong. Because write specifies "The general contract for write is that one byte is written to the output stream." but not "a byte may be written or buffered". Actually, an application would need to call flush() after each write (or bunch of write calls) to ensure that write really did something otherwise I think. I didn't found in the spec of OutputStream that it would be required to call flush(). This should mean that calling flush is not required which in turn leads to the conclusion that write must be synchrous (private threads are forbidden because not specified :)) which in turn leads to the conclusion that flush() is not needed at all... I mean, what if someone would only store in write and do the "real write" in flush() and never else? An application could write in one stream and read on another one (e.g. in bidirectional communication) and would never get anything back, because nothing was actually written because no flush was called? Then someone could even think that on error in some write the data could remain buffered AND throw an exception, retrying to send the data in the next write. Ohh, and if there would be some message number inside, and underlaying write (e.g. a protocol offering InputStream/OutputStream) would check this and throw "DuplicatedMessageNumber" the stream would only throw it again and again beeing unusable... In short: I have no clue how someone could be able to implement an asynchrounos write (which is realiable and correct) without beeing specific to anything which is not specified by OutputStream. Well, I think in the end OutputStream was not intended for such communication or protocol implementations - but to read a local disk file or so. In case of I/O errors usually you can abort your application and change the hard disk :-) oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Bob_Jacobsen at lbl.gov Mon Jun 11 09:32:23 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Mon, 11 Jun 2007 08:32:23 -0700 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611142116.GN10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> Message-ID: At 4:21 PM +0200 6/11/07, Steffen DETTMER wrote: > > Statement concerning "synchronous" nature of the output stream >> is invalid as well. Really synchronous stream does not require >> flush() but OutputStream has it. > >ahh, interesting point! > >I think this is another bug in the API. flush() is wrong. Because >write specifies "The general contract for write is that one byte >is written to the output stream." but not "a byte may be written >or buffered". > >Actually, an application would need to call flush() after each >write (or bunch of write calls) to ensure that write really did >something otherwise I think. OutputStreams don't _have_ to be synchronous or asynchronous, but the OutputStream API was be arranged so that subclasses _can_ be synchronous or asynchronous. Such generality is the hardest part of getting an API right. Hence, if at some point a program using an OutputStream wants to be sure that the data has been pushed all the way out, flush() is available. For some subclasses, e.g. the buffered ones, this has important behavior. Others write the data from each call, and flush() doesn't do anything. You _can_ omit it in programs that are known to use this second type, but there's no requirement that you do so; the interface is general in that way. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From Steffen.DETTMER at ingenico.com Mon Jun 11 12:32:39 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 20:32:39 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> Message-ID: <20070611183239.GT10821@elberon.bln.de.ingenico.com> * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: > >Actually, an application would need to call flush() after each > >write (or bunch of write calls) to ensure that write really did > >something otherwise I think. > OutputStreams don't _have_ to be synchronous or asynchronous, > but the OutputStream API was be arranged so that subclasses > _can_ be synchronous or asynchronous. Ahh, oki. Thanks for the clarificaion. So in short, flush() MUST be called on OutputStream, this is just not documented correctly or so clearly (right?). So the overall usage semantics would be: 1. call write (multiple times if desired) 2. call flush only if both succeeded, write was successful. If flush fails it remains unknown if a part of the data was written and/or will be repeated. So the spec (API doc) is wrong. Correct would be to tell that write behaves as told as long as it is followed by a call to flush, otherwise data may or may not get lost (depending wheter close() is called and calls flush(), which seems not to be guaranteed/required). BTW, I think it is a little bit... erm... interesting to find the specification (java API doc reference) wrong, having a need to conclude it from the presence of some methods with "it would make no sense if they behave exactly as specified, so specification must be wrong (incomplete)". > Such generality is the hardest part of getting an API right. Yes, seems to be proven ;) > Hence, if at some point a program using an OutputStream wants > to be sure that the data has been pushed all the way out, > flush() is available. For some subclasses, e.g. the buffered > ones, this has important behavior. Others write the data from > each call, and flush() doesn't do anything. > You _can_ omit it in programs that are known to use this second > type, but there's no requirement that you do so; the interface > is general in that way. I think, it still it must be called always, otherwise the application could break if passing a different runtime type as OutputStream. I think, if the application/method needs a special "type of OutputStream" then the parameter type must be a subclass but not OutputStream, maybe a PrintStream or so - otherwise the compiler could not detect this error (passing wrong type). Is this correct? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Bob_Jacobsen at lbl.gov Mon Jun 11 13:00:52 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Mon, 11 Jun 2007 12:00:52 -0700 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611183239.GT10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> Message-ID: At 8:32 PM +0200 6/11/07, Steffen DETTMER wrote: >So the spec (API doc) is wrong. Correct would be to tell that >write behaves as told as long as it is followed by a call to >flush, otherwise data may or may not get lost (depending wheter >close() is called and calls flush(), which seems not to be >guaranteed/required). I'm not entirely sure that the spec is wrong, but reasonable people can differ on this. In the 1.5 JavaDocs, all that the docs say for the write methods is that they write to the _output_ _stream_; there is no guarantee of anything beyond that. Only the flush method has any guarantee about the data, which is >Flushes this output stream and forces any buffered output bytes to >be written out. The general contract of flush is that calling it is >an indication that, if any bytes previously written have been >buffered by the implementation of the output stream, such bytes >should immediately be written to their intended destination. People commonly use various OutputStreams without using flush(), and it often works, but it's a bad practice and will eventually bite them. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From netbeans at gatworks.com Mon Jun 11 13:31:57 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 15:31:57 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611183239.GT10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> Message-ID: <466DA32D.1010602@gatworks.com> Steffen DETTMER wrote: > * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: >>> Actually, an application would need to call flush() after each >>> write (or bunch of write calls) to ensure that write really did >>> something otherwise I think. > >> OutputStreams don't _have_ to be synchronous or asynchronous, >> but the OutputStream API was be arranged so that subclasses >> _can_ be synchronous or asynchronous. > > Ahh, oki. Thanks for the clarificaion. > > So in short, flush() MUST be called on OutputStream, this is just > not documented correctly or so clearly (right?). No. Flush can be called to force all current data in java buffer's to be written to the kernel - NOW. A flush() can also *imply* that, besides writing out the buffer's that java employs, may also imply/ask the kernel to write all data thusfar written to the kernel, to be physically placed on the destination device - NOW. For some OS's there is no need to do a kernel flush(), as the I/O is synchronized already. Since this is java, you never know what OS your on. From tjarvi at qbang.org Mon Jun 11 19:28:27 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Jun 2007 19:28:27 -0600 (MDT) Subject: [Rxtx] [OT] select :-) In-Reply-To: <466DA32D.1010602@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: On Mon, 11 Jun 2007, Uncle George wrote: > Steffen DETTMER wrote: >> * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: >>>> Actually, an application would need to call flush() after each >>>> write (or bunch of write calls) to ensure that write really did >>>> something otherwise I think. >> >>> OutputStreams don't _have_ to be synchronous or asynchronous, >>> but the OutputStream API was be arranged so that subclasses >>> _can_ be synchronous or asynchronous. >> >> Ahh, oki. Thanks for the clarificaion. >> >> So in short, flush() MUST be called on OutputStream, this is just >> not documented correctly or so clearly (right?). > No. > Flush can be called to force all current data in java buffer's to be > written to the kernel - NOW. > > A flush() can also *imply* that, besides writing out the buffer's that > java employs, may also imply/ask the kernel to write all data thusfar > written to the kernel, to be physically placed on the destination device > - NOW. > For some OS's there is no need to do a kernel flush(), as the I/O is > synchronized already. Since this is java, you never know what OS your on. To add to the confusion, flush on the C side throws away data. drain makes sure it is written. Looking at the ParallelImp.c we can probably do better. /* we set a timeout because all calls are sequentiell (also with asynchron) this means that the default timeout of unlimited blocks all calls (also close and status request) if the device is down */ GetCommTimeouts( (HANDLE)fd, &timeouts ); timeouts.WriteTotalTimeoutMultiplier = 0; timeouts.WriteTotalTimeoutConstant = 2000; /* 2000 is the min value for the default Windows NT and Windows 2000 driver */ SetCommTimeouts( (HANDLE)fd, &timeouts ); while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } errorCount = 0; bytes += countWritten; count -= countWritten; } LPRPort has some timeout code that appears to be doing nothing but flipping bits back and forth right now. The commapi rxtx follows allows for timeout control from javax.comm.CommPort. The above is a solution that worked in one specific use case. With timeouts in place, the original 'old printer going offline' problem could be solved. That printer code isn't written in stone. In fact it was ajusted from being able to print 'asdf' to a daisy wheel printer to working for one person. BTW, I've finished teaching after hours tonight and will be moving forward with a new rxtx release in my free time. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Jun 11 21:28:04 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 23:28:04 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: <466E12C4.1010305@gatworks.com> > Looking at the ParallelImp.c we can probably do better. > The problem stemmed from the possibility that the writev routine could have written some of the buffer, in chunks, printer pauses, refuses any more chunks, and a timeout occurs. Do you or do you not cause an exception to be thrown? Is there a way to set timeout for a ParallelPort data output stream? I cant find it. From tjarvi at qbang.org Mon Jun 11 22:17:23 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Jun 2007 22:17:23 -0600 (MDT) Subject: [Rxtx] [OT] select :-) In-Reply-To: <466E12C4.1010305@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> <466E12C4.1010305@gatworks.com> Message-ID: On Mon, 11 Jun 2007, Uncle George wrote: >> Looking at the ParallelImp.c we can probably do better. >> > The problem stemmed from the possibility that the writev routine could > have written some of the buffer, in chunks, printer pauses, refuses any > more chunks, and a timeout occurs. Do you or do you not cause an > exception to be thrown? > > Is there a way to set timeout for a ParallelPort data output stream? I > cant find it. hmm I looked again after you asked. The timeouts are only controllable on the receive side. This comes from CommPort; the parent. So what we are talking about is some bytes in memory that rxtx has and is supposed to write. A buffer perhaps? The approach with rxtx in the past has been to ignore output buffer sizes. The assumption is that the library does not know how to best handle buffers. There are buffered output streams that can do buffering on top of rxtx for instance. There is also a question regarding what was actually ment when the API was put together. My suspicion is that it was put together while looking at one OS API and was never ment to be anything more than a hook into that API. The comments are fairly telling combined with reading the w32 API. So looking at the problem again.. The current timeout behavior appears fairly arbitrary. Presumably this is to prevent a program from hanging instead of using a helper thread to write - heavy handed for new programmers. Even so, I don't think the write should timeout at all if it is not configurable. >From the API perspective, "What Timeout?" -- Trent Jarvi tjarvi at qbang.org From Steffen.DETTMER at ingenico.com Tue Jun 12 02:14:48 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 12 Jun 2007 10:14:48 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466DA32D.1010602@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: <20070612081447.GU10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Mon, Jun 11, 2007 at 15:31 -0400: > Steffen DETTMER wrote: > > Ahh, oki. Thanks for the clarificaion. > > > > So in short, flush() MUST be called on OutputStream, this is just > > not documented correctly or so clearly (right?). > No. hum (though now I got it, but...). > Flush can be called to force all current data in java buffer's to be > written to the kernel - NOW. > > A flush() can also *imply* that, besides writing out the > buffer's that java employs, may also imply/ask the kernel to > write all data thusfar written to the kernel, to be physically > placed on the destination device - NOW. > > For some OS's there is no need to do a kernel flush(), as the I/O is > synchronized already. Since this is java, you never know what OS your on. (well, but if you're going to kernel level, even flush cannot guarantee that data will "be physically placed". Maybe you're flushing to a file via NFS (and the client "thinks" that it was written, but maybe it was just buffered by the NFS server) or so... but of course such exceptions of the rules are constructable always.) Well, you tell that depending on the OS it can be that flush is needed or it can be that flush is not needed (beacuse the I/O is synchronized already), right? Also, applications should work on any OS, which includes the OSes that do need flush. Since the application cannot know whether flush is needed or not because it doesn't know what the OS is doing, it has to call flush, hasn't it? I mean, if it would not call flush then it would not work on such OSes (except the written data would not be needed at all, but in this would be an artificial example :)). Since applications are supposed to work this would be wrong, wouldn't it? So would it be correct to say: "Applications, that should work under all OSes (including the OSes where the I/O is not synchronised already), have to call flush on OutputStream to ensure the data is transfered to the kernel." or is this wrong? If so, then I'm afraid I missed the point again :( oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Tue Jun 12 04:46:52 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 12 Jun 2007 06:46:52 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070612081447.GU10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> <20070612081447.GU10821@elberon.bln.de.ingenico.com> Message-ID: <466E799C.7060700@gatworks.com> S > (well, but if you're going to kernel level, even flush cannot > guarantee that data will "be physically placed". Thats true now-a-days because ( from "man 2 sync" ) : > According to the standard specification (e.g., SVID), sync() schedules > the writes, but may return before the actual writing is done. However, > since version 1.3.20 Linux does actually wait. (This still does not > guarantee data integrity: modern disks have large caches.) My disk drive has 8mb cache. Maybe you're > flushing to a file via NFS (and the client "thinks" that it was > written, but maybe it was just buffered by the NFS server) or > so... but of course such exceptions of the rules are > constructable always.) > > Well, you tell that depending on the OS it can be that flush is > needed or it can be that flush is not needed (beacuse the I/O is > synchronized already), right? Also, applications should work on > any OS, which includes the OSes that do need flush. Its not OS's that need flush, its applications that want to have some assurance that data is written to the device that really needs to use flush. If your program ( or thread ) dies then it is in your best interest to write out the critical data as soon as possible, as economical as possible. These are trade-off's that the application programmer makes. A big buffer may mean big loss of data, a small buffer may mean spending too much time writing out data. > > > So would it be correct to say: > > "Applications, that should work under all OSes (including the > OSes where the I/O is not synchronised already), have to call > flush on OutputStream to ensure the data is transfered to the > kernel." > > or is this wrong? If so, then I'm afraid I missed the point again > :( > No that is not wrong. Ensuring that data is transfered to the OS is just about what any application can do. From tjarvi at qbang.org Thu Jun 14 08:16:47 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 14 Jun 2007 08:16:47 -0600 (MDT) Subject: [Rxtx] rxtx and usb-serial solution In-Reply-To: References: Message-ID: On Thu, 14 Jun 2007, Vladimir Kirtchev wrote: > Hi Trent, > > I develop a Java application which communicates with devices which have > USB-to-Serial bridge in them. The target OS is Linux. So for this purpose I > use RXTX. > > But I encountered a strange problem - when reading from the InputStream, I > receive series of zeros. I have this problem under Linux only. Under Windows > it is fine. > Actually this problem is the same as the one described here: > http://marc.info/?l=rxtx&m=109703190731748&w=2. > > > So I searched for the problem in the native code. And found that the root of > the problem is in SerialImp.c, > int configure_port( int fd ) > { > ... > ttyset.c_iflag = INPCK; > ... > } > > This line enables input parity checking, and the data sent from the device > is processed by the OS driver before being read with read(). > In this case the driver detects some problem and sets the received bytes to > zero. > > On the other hand in the Java part a set the serial port parameters with > SerialPort.PARITY_NONE. According to me, except all other things, this > should also disable INPCK in c_iflag. > > So I refactored the method translate_parity(...) to the following: > > int translate_parity( JNIEnv *env, struct termios *ttyset, jint parity ) > { > ENTER( "translate_parity" ); > #ifdef CMSPAR > ttyset->c_cflag &= ~(PARENB | PARODD | CMSPAR ); > #endif /* CMSPAR */ > switch( parity ) { > case JPARITY_NONE: > ttyset->c_iflag &= ~INPCK; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_EVEN: > ttyset->c_cflag |= PARENB; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_ODD: > ttyset->c_cflag |= PARENB | PARODD; > LEAVE( "translate_parity" ); > return 0; > #ifdef CMSPAR > case JPARITY_MARK: > ttyset->c_cflag |= PARENB | PARODD | CMSPAR; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_SPACE: > ttyset->c_cflag |= PARENB | CMSPAR; > LEAVE( "translate_parity" ); > return 0; > #endif /* CMSPAR */ > default: > printf("Parity missed %i\n", (int) parity ); > } > > LEAVE( "translate_parity" ); > /* > For some reason the native exceptions are not being caught. Moving this > to the Java side fixed the issue. taj. > throw_java_exception( env, UNSUPPORTED_COMM_OPERATION, > "", "parity value not supported" ); > */ > return 1; > } > > This modification solved the problem and now it works correctly under Linux. > > I think I will be a nice if this is idea is included in a future release of > RXTX. > > Thanks Vadim, I'll try that out. Forwarding to the rxtx mail-list too. This is probably not going to help USB drivers on windows which I'm sure some are looking for. As far as I can tell, windows USB bluetooth and serial dongles are limited by driver functionality. Some are good and others lack key features. -- Trent Jarvi tjarvi at qbang.org From dan.sandberg.lists at gmail.com Mon Jun 18 14:43:39 2007 From: dan.sandberg.lists at gmail.com (Dan Sandberg) Date: Mon, 18 Jun 2007 13:43:39 -0700 Subject: [Rxtx] Fix for JNI Get/Set Field Errors Message-ID: <4676EE7B.7060800@gmail.com> Hi, I've fixed the problems that cause the following JNI error when extra JNI checking ( -Xjni:check ) is turned on. FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) The problem was basically that GetLong was being used to get ints, and SetInt was used for longs. The patch below fixes this. Please let me know if there are any questions / problems. Cheers, -Dan diff -aur old/SerialImp.c src/SerialImp.c --- old/SerialImp.c 2007-06-18 13:24:33.000000000 -0700 +++ src/SerialImp.c 2007-06-18 06:26:26.000000000 -0700 @@ -1337,7 +1337,7 @@ report("init_threads: get eis\n"); jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); report("init_threads: set eis\n"); - (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); + (*eis->env)->SetLongField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); report("init_threads: stop\n"); report_time_end( ); return( 1 ); @@ -1530,7 +1530,7 @@ jobject jobj, jboolean interrupted ) { int fd = get_java_var( env, jobj,"fd","I" ); - struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var( env, jobj, "eis", "J" ); + struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var_long( env, jobj, "eis", "J" ); int result, count=0; char message[80]; @@ -2939,7 +2939,7 @@ /* TRENT */ int flag, count = 0; struct event_info_struct *eis = ( struct event_info_struct * ) - get_java_var( env, *jobj,"eis","J" ); + get_java_var_long( env, *jobj,"eis","J" ); report_time_start(); flag = eis->eventflags[SPE_DATA_AVAILABLE]; @@ -4873,9 +4873,9 @@ exceptions: none comments: ----------------------------------------------------------*/ -size_t get_java_var( JNIEnv *env, jobject jobj, char *id, char *type ) +long get_java_var_long( JNIEnv *env, jobject jobj, char *id, char *type ) { - int result = 0; + long result = 0; jclass jclazz = (*env)->GetObjectClass( env, jobj ); jfieldID jfd = (*env)->GetFieldID( env, jclazz, id, type ); @@ -4889,7 +4889,11 @@ LEAVE( "get_java_var" ); return result; } - result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); + if ( !strcmp( type, "J" ) ) { + result = (long)( (*env)->GetLongField( env, jobj, jfd ) ); + } else { + result = (int) ( (*env)->GetIntField( env, jobj, jfd ) ); + } /* ct7 & gel * Added DeleteLocalRef */ (*env)->DeleteLocalRef( env, jclazz ); if(!strncmp( "fd",id,2) && result == 0) @@ -4900,6 +4904,10 @@ return result; } +int get_java_var( JNIEnv *env, jobject jobj, char *id, char *type ) { + return (int) get_java_var_long( env, jobj, id, type ); +} + /*---------------------------------------------------------- throw_java_exception diff -aur old/SerialImp.h src/SerialImp.h --- old/SerialImp.h 2007-06-18 13:24:39.000000000 -0700 +++ src/SerialImp.h 2007-06-18 06:23:43.000000000 -0700 @@ -413,7 +413,8 @@ void system_wait(); void finalize_event_info_struct( struct event_info_struct * ); int read_byte_array( JNIEnv *, jobject *, int, unsigned char *, int, int ); -size_t get_java_var( JNIEnv *, jobject, char *, char * ); +int get_java_var( JNIEnv *, jobject, char *, char * ); +long get_java_var_long( JNIEnv *, jobject, char *, char * ); jboolean is_interrupted( struct event_info_struct * ); int send_event(struct event_info_struct *, jint, int ); void dump_termios(char *,struct termios *); From yvespielusenet at free.fr Tue Jun 26 03:41:58 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 11:41:58 +0200 Subject: [Rxtx] [PARALLEL] resource in use Message-ID: <1182850918.3483.10.camel@localhost.localdomain> Hello, So now I want to modify the timeout of the library for parallel port. I have downloaded source code. There is a makefile for migw. SO I have installed mingw on ubuntu and modified the makefile.mingw32 to set it for my system. I have no error but some warnings. The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But When I want to use it the jvm crash :( How can I know what is wrong ? How rxtx windows release has been done ? thanks -- yves piel From yvespielusenet at free.fr Tue Jun 26 07:17:02 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 15:17:02 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182850918.3483.10.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> Message-ID: <1182863822.3483.17.camel@localhost.localdomain> Here is the Makefile I use, the output of the 'make' and the log of the jvm when it crashed : - The Makefile : http://yvespiel.free.fr/rxtx/Makefile - The make output : http://yvespiel.free.fr/rxtx/compile.txt - The crash log : http://yvespiel.free.fr/rxtx/hs_err_pid2100.log I have compiled rxtx under Debian testing with mingw : narma at linimi:/tmp/err$ dpkg -l | grep mingw ii mingw32 3.4.5.20060117.1.dfsg-3 ii mingw32-binutils 2.17.50-20070129.1-1 ii mingw32-runtime 3.12-1 thanks fort help :) Le mardi 26 juin 2007 ? 11:41 +0200, yves pielusenet a ?crit : > Hello, > So now I want to modify the timeout of the library for parallel port. I > have downloaded source code. There is a makefile for migw. SO I have > installed mingw on ubuntu and modified the makefile.mingw32 to set it > for my system. > I have no error but some warnings. > The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But > When I want to use it the jvm crash :( > > How can I know what is wrong ? > > How rxtx windows release has been done ? > > thanks > From yvespielusenet at free.fr Tue Jun 26 07:40:11 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 15:40:11 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182863822.3483.17.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> <1182863822.3483.17.camel@localhost.localdomain> Message-ID: <1182865211.3483.21.camel@localhost.localdomain> I have add the options '--enable-stdcall-fixup' to the 'i586-mingw32msvc-ld' commande. Now I have no warning. But the JVM always crashes :( The output seems more detailled, but I don't understand anything... Here is files : http://yvespiel.free.fr/rxtx/2/ -- yves piel Le mardi 26 juin 2007 ? 15:17 +0200, yves pielusenet a ?crit : > Here is the Makefile I use, the output of the 'make' and the log of the > jvm when it crashed : > > - The Makefile : http://yvespiel.free.fr/rxtx/Makefile > - The make output : http://yvespiel.free.fr/rxtx/compile.txt > - The crash log : http://yvespiel.free.fr/rxtx/hs_err_pid2100.log > > I have compiled rxtx under Debian testing with mingw : > narma at linimi:/tmp/err$ dpkg -l | grep mingw > ii mingw32 3.4.5.20060117.1.dfsg-3 > ii mingw32-binutils 2.17.50-20070129.1-1 > ii mingw32-runtime 3.12-1 > > thanks fort help :) > > > Le mardi 26 juin 2007 ? 11:41 +0200, yves pielusenet a ?crit : > > Hello, > > So now I want to modify the timeout of the library for parallel port. I > > have downloaded source code. There is a makefile for migw. SO I have > > installed mingw on ubuntu and modified the makefile.mingw32 to set it > > for my system. > > I have no error but some warnings. > > The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But > > When I want to use it the jvm crash :( > > > > How can I know what is wrong ? > > > > How rxtx windows release has been done ? > > > > thanks > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From yvespielusenet at free.fr Tue Jun 26 08:27:42 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 16:27:42 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182865211.3483.21.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> <1182863822.3483.17.camel@localhost.localdomain> <1182865211.3483.21.camel@localhost.localdomain> Message-ID: <1182868062.3483.24.camel@localhost.localdomain> I think thant the include files of jdk were not for windows but for linux. So I have copied include/ folder from windows to linux and I modified the Makefile to use those file. It compile fine but the JVM always crash :( http://yvespiel.free.fr/rxtx/3/ Le mardi 26 juin 2007 ? 15:40 +0200, yves pielusenet a ?crit : > I have add the options '--enable-stdcall-fixup' to the > 'i586-mingw32msvc-ld' commande. Now I have no warning. But the JVM > always crashes :( The output seems more detailled, but I don't > understand anything... > Here is files : > http://yvespiel.free.fr/rxtx/2/ > From netbeans at gatworks.com Fri Jun 1 05:38:50 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 07:38:50 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <465F7ADD.1010501@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> Message-ID: <4660054A.2040202@gatworks.com> Manuel Naranjo wrote: In the case of my module, you can > unplug the device but it will not delete the symlink until those apps > that had opened the port has closed it. This is done this way to avoid > kernel panics. What does this mean to user code ? I have tried the alternate route ( other than closing ) which is sleep inbetween the I/O errors ( an unplugged USB device). When the device is plugged back in, The writes to the device still get an I/O error. This would seem to be a lost cause for the application. From netbeans at gatworks.com Fri Jun 1 06:35:48 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 08:35:48 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <465F7ADD.1010501@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> Message-ID: <466012A4.90608@gatworks.com> Manuel Naranjo wrote: In the case of my module, you can > unplug the device but it will not delete the symlink until those apps > that had opened the port has closed it. T Did u also mean for this to happen? USB0 was not closed by application. Apparently USB1 got created when USB device was plugged back in. There is only one USB device on a 4 port USB hub. This also seems to suggest that application recovery to be impossible. > Jun 1 07:10:08 mylaptop kernel: garmin_gps 1-1.4:1.0: Garmin GPS usb/tty converter detected > Jun 1 07:10:08 mylaptop kernel: usb 1-1.4: Garmin GPS usb/tty converter now attached to ttyUSB0 > Jun 1 07:15:17 mylaptop kernel: usb 1-1: USB disconnect, address 4 > Jun 1 07:15:17 mylaptop kernel: usb 1-1.4: USB disconnect, address 5 > Jun 1 07:15:17 mylaptop kernel: garmin_gps 1-1.4:1.0: device disconnected > Jun 1 07:15:26 mylaptop kernel: usb 1-1: new full speed USB device using uhci_hcd and address 6 > Jun 1 07:15:26 mylaptop kernel: hub 1-1:1.0: USB hub found > Jun 1 07:15:26 mylaptop kernel: hub 1-1:1.0: 4 ports detected > Jun 1 07:15:27 mylaptop kernel: usb 1-1.4: new full speed USB device using uhci_hcd and address 7 > Jun 1 07:15:27 mylaptop kernel: garmin_gps 1-1.4:1.0: Garmin GPS usb/tty converter detected > Jun 1 07:15:27 mylaptop kernel: usb 1-1.4: Garmin GPS usb/tty converter now attached to ttyUSB1 From naranjo.manuel at gmail.com Fri Jun 1 09:17:22 2007 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Fri, 01 Jun 2007 12:17:22 -0300 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <466012A4.90608@gatworks.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> <466012A4.90608@gatworks.com> Message-ID: <46603882.5050701@gmail.com> Uncle George escribi?: > Manuel Naranjo wrote: > In the case of my module, you can > >> unplug the device but it will not delete the symlink until those apps >> that had opened the port has closed it. T >> > > Did u also mean for this to happen? USB0 was not closed by application. > > Apparently USB1 got created when USB device was plugged back in. There > is only one USB device on a 4 port USB hub. > > This also seems to suggest that application recovery to be impossible. > Exactly there's a dead symlink (you can read and write to it and nothing will happen) and a new port will be created when a new device is connencted. From netbeans at gatworks.com Fri Jun 1 10:20:46 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 12:20:46 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <46603882.5050701@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> <466012A4.90608@gatworks.com> <46603882.5050701@gmail.com> Message-ID: <4660475E.5090202@gatworks.com> Not sure what u mean by "symlink". U cant read/write to it anymore. U get I/O error. In this scenario the device effectively went dead, and only solution is to close the channel. reconnecting the USB device, although dead, but not closed, will create a second device. This does not seem to be a desirable side-effect. The user will now have ttyUSB1, wondering where did ttyUSB0 go to. The application will also be in a confused state, as well as RXTX, because RXTX wont know about ttyUSB1. Manuel Naranjo wrote: > Uncle George escribi?: >> Manuel Naranjo wrote: >> In the case of my module, you can >> >>> unplug the device but it will not delete the symlink until those apps >>> that had opened the port has closed it. T >>> >> Did u also mean for this to happen? USB0 was not closed by application. >> >> Apparently USB1 got created when USB device was plugged back in. There >> is only one USB device on a 4 port USB hub. >> >> This also seems to suggest that application recovery to be impossible. >> > Exactly there's a dead symlink (you can read and write to it and nothing > will happen) and a new port will be created when a new device is connencted. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From arnab.bhaumik at gmail.com Mon Jun 4 01:40:16 2007 From: arnab.bhaumik at gmail.com (arnab bhaumik) Date: Mon, 4 Jun 2007 13:10:16 +0530 Subject: [Rxtx] full duplex com port with rxtx Message-ID: hi , till now i did half duplex communication with rxtx package on com package. my question is : is it possible to use com port with full duplex mode with rxtx package . ther is example of SimpleRead class and SimpleWrite class. it is clear that if i can use both the class simultaneously then full duplex is possible......... arnab/vu2bpw -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070604/6edb0453/attachment-0006.html From lists at iDIAcomputing.com Mon Jun 4 07:53:17 2007 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Mon, 04 Jun 2007 09:53:17 -0400 Subject: [Rxtx] full duplex com port with rxtx In-Reply-To: References: Message-ID: <4664194D.90301@iDIAcomputing.com> arnab bhaumik wrote: > hi , > > till now i did half duplex communication with rxtx package on com > package. > > my question is : is it possible to use com port with full duplex mode > with rxtx package . > > > ther is example of SimpleRead class and SimpleWrite class. it is > clear that if i can use both the class simultaneously then full duplex > is possible......... I haven't looked at the SimpleRead and SimpleWrite classes (I originally wrote my code for the javax.comm api), but full duplex is certainly possible. My CommReader class requires an object analogous to a OutputStream or Writer. When started, it spawns a thread that reads the comm port and writes to that output device. In this way the input is asynchronous and dependent on the actual input data. For full duplex, I extend that class with CommReaderWriter, which adds synchronous output methods. Hope that helps, George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From supsoop at hotmail.com Mon Jun 4 15:21:06 2007 From: supsoop at hotmail.com (soop soop) Date: Mon, 04 Jun 2007 21:21:06 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- Message-ID: Hi Guys, Looked through the archives but still cannot figure this out. I have a Motorola G24 GPRS/GSM modem that I am connecting to my server running Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not detecting the port, CommPortIdentifier.getPortIdentifiers(). I have added the line to RXTXCommDriver: "ttyACM" // for USB Modems Rxtx still does not seem to find the port. Is there something I am missing to make this port visable? [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control Model driver for USB modems and ISDN adapters I really need your help as I have moved my server from windows to Linux and have been down for a few days because of this .. Thanks so much! _________________________________________________________________ PC Magazine’s 2007 editors’ choice for best Web mail—award-winning Windows Live Hotmail. http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 From tjarvi at qbang.org Mon Jun 4 16:17:35 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Jun 2007 16:17:35 -0600 (MDT) Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: On Mon, 4 Jun 2007, soop soop wrote: > Hi Guys, > > Looked through the archives but still cannot figure this out. I have a > Motorola G24 GPRS/GSM modem that I am connecting to my server running Ubuntu. > I can see my modem as is shows up as ttyACM0, but RXTX is not detecting the > port, CommPortIdentifier.getPortIdentifiers(). > > I have added the line to RXTXCommDriver: > > "ttyACM" // for USB Modems > > Rxtx still does not seem to find the port. Is there something I am missing to > make this port visable? > > [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver > [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device > [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control Model > driver for USB modems and ISDN adapters > > I really need your help as I have moved my server from windows to Linux and > have been down for a few days because of this .. Thanks so much! > You could try the INSTALL documentation that comes with the source for possible solutions. Those usually involve lockfile creation, permissions on the device file or the device is in use by another application (even another session of your application). The usual commands: ls -l /dev/ttyACM0 fuser /dev/ttyACM0 touch /var/lock/LCK.testfile && rm -f /var/lock/LCK.testfile whoami To disable lockfiles: ../configure --disable-lockfiles && make install -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Jun 4 16:22:52 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 04 Jun 2007 18:22:52 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <466490BC.3090801@gatworks.com> soop soop wrote: > I really need your help as I have moved my server from windows to Linux > and have been down for a few days because of this .. Thanks so much! can u open the device ? ie is the file protection/permissions keeping you out? From supsoop at hotmail.com Mon Jun 4 16:44:40 2007 From: supsoop at hotmail.com (soop soop) Date: Mon, 04 Jun 2007 22:44:40 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <466490BC.3090801@gatworks.com> Message-ID: Thanks for the reply, I see no exceptions being thrown, just no detection of the port whats so ever. I will run rxtx in debug mode and log. If this were a permissions issue would I not see some exceptions being thrown? >From: Uncle George >Reply-To: RXTX Developers and Users >To: RXTX Developers and Users >Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >Date: Mon, 04 Jun 2007 18:22:52 -0400 > >soop soop wrote: > > > I really need your help as I have moved my server from windows to Linux > > and have been down for a few days because of this .. Thanks so much! > >can u open the device ? ie is the file protection/permissions keeping >you out? >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ Get a preview of Live Earth, the hottest event this summer - only on MSN http://liveearth.msn.com?source=msntaglineliveearthhm From netbeans at gatworks.com Mon Jun 4 17:06:15 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 04 Jun 2007 19:06:15 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <46649AE7.10405@gatworks.com> Exceptions on what? On startup it wants to lookup all devices in /dev that it is capable of opening ( within the list of specific 'comm' devices ). If it cannot open, then does not get onto list. Part of this process, if configured, will also test if the "LOCK" schema can also be opened for the device. then it gets on the list of avail comm port. soop soop wrote: > Thanks for the reply, > > I see no exceptions being thrown, just no detection of the port whats so > ever. I will run rxtx in debug mode and log. If this were a permissions > issue would I not see some exceptions being thrown? > > >> From: Uncle George >> Reply-To: RXTX Developers and Users >> To: RXTX Developers and Users >> Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >> Date: Mon, 04 Jun 2007 18:22:52 -0400 >> >> soop soop wrote: >> >>> I really need your help as I have moved my server from windows to Linux >>> and have been down for a few days because of this .. Thanks so much! >> can u open the device ? ie is the file protection/permissions keeping >> you out? >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _________________________________________________________________ > Get a preview of Live Earth, the hottest event this summer - only on MSN > http://liveearth.msn.com?source=msntaglineliveearthhm > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From alex.flint at gmail.com Mon Jun 4 21:31:49 2007 From: alex.flint at gmail.com (Alex Flint) Date: Tue, 5 Jun 2007 13:01:49 +0930 Subject: [Rxtx] random EXCEPTION_ACCESS_VIOLATION errors Message-ID: Hi All, I'm running winXP and RXTX 2.1-7r2 (the latest from the webpage as of June 2007). I'm sending sequences of 64 lines (each line has about 15 chars) at various intervals. The strings are sent fine, until I get the following error (from hs_err_pid3316.log, at the end of this email). What can I do to avoid the error? Obviously this is a low-level memory exception, but is there any way I can keep the JVM running after such an error? I noticed the exact same problem here: http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20070129/1180520.html Cheers, Alex # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x100034fb, pid=3316, tid=2400 # # Java VM: Java HotSpot(TM) Client VM (1.6.0_01-b06 mixed mode, sharing) # Problematic frame: # C [rxtxSerial.dll+0x34fb] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # --------------- T H R E A D --------------- Current thread (0x00386400): JavaThread "main" [_thread_in_native, id=2400] siginfo: ExceptionCode=0xc0000005, reading address 0x20726f78 Registers: EAX=0x20726f20, EBX=0x6d8922c0, ECX=0x00000005, EDX=0x20726f20 ESP=0x003efa30, EBP=0x003efb68, ESI=0x269728a0, EDI=0x00386400 EIP=0x100034fb, EFLAGS=0x00010212 Top of Stack: (sp=0x003efa30) 0x003efa30: 003efa3c 003efa64 0000000f ffffffff 0x003efa40: 003efa40 2a97f808 003efa6c 2b190ca8 0x003efa50: 00000000 2b190ec0 003efa90 008e2dd7 0x003efa60: 003efa90 008e2dd7 26977f88 6d815e72 0x003efa70: 00000004 2696eae0 0000008a 003efb0c 0x003efa80: 6d852b4a 2696eae0 00000003 26970930 0x003efa90: 000000cb 2696eae0 6d86b264 00385d40 0x003efaa0: 0000003f 003efb0c 26977f90 2ace65d8 Instructions: (pc=0x100034fb) 0x100034eb: ff ff 8d 76 00 eb 02 89 f6 90 8b 45 f8 8b 55 f8 0x100034fb: 8b 4a 58 83 c9 04 89 48 58 83 c4 f8 8b 45 f8 8b Stack: [0x003a0000,0x003f0000), sp=0x003efa30, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x34fb] Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j gnu.io.RXTXPort.writeArray([BIIZ)V+0 j gnu.io.RXTXPort$SerialOutputStream.write([B)V+76 j com.bjt.media.server.CommLink.send(Ljava/lang/String;)V+48 j com.bjt.media.server.DigitoolConnection.select(I)V+73 j com.bjt.media.server.DigitoolConnection.main([Ljava/lang/String;)V+74 v ~StubRoutines::call_stub --------------- P R O C E S S --------------- Java Threads: ( => current thread ) 0x02a69400 JavaThread "Thread-0" [_thread_in_native, id=3052] 0x02a4d000 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=3920] 0x02a48400 JavaThread "CompilerThread0" daemon [_thread_blocked, id=1968] 0x02a47400 JavaThread "Attach Listener" daemon [_thread_blocked, id=2984] 0x02a46400 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=2660] 0x02a41c00 JavaThread "Finalizer" daemon [_thread_blocked, id=3924] 0x02a3d800 JavaThread "Reference Handler" daemon [_thread_blocked, id=4008] =>0x00386400 JavaThread "main" [_thread_in_native, id=2400] Other Threads: 0x02a34400 VMThread [id=3708] 0x02a4e800 WatcherThread [id=3964] VM state:not at safepoint (normal execution) VM Mutex/Monitor currently owned by a thread: None Heap def new generation total 960K, used 131K [0x22960000, 0x22a60000, 0x22e40000) eden space 896K, 7% used [0x22960000, 0x22970ea8, 0x22a40000) from space 64K, 99% used [0x22a50000, 0x22a5fff8, 0x22a60000) to space 64K, 0% used [0x22a40000, 0x22a40000, 0x22a50000) tenured generation total 4096K, used 76K [0x22e40000, 0x23240000, 0x26960000) the space 4096K, 1% used [0x22e40000, 0x22e53060, 0x22e53200, 0x23240000) compacting perm gen total 12288K, used 137K [0x26960000, 0x27560000, 0x2a960000) the space 12288K, 1% used [0x26960000, 0x26982518, 0x26982600, 0x27560000) ro space 8192K, 62% used [0x2a960000, 0x2ae5e4e8, 0x2ae5e600, 0x2b160000) rw space 12288K, 52% used [0x2b160000, 0x2b7a0e78, 0x2b7a1000, 0x2bd60000) Dynamic libraries: 0x00400000 - 0x00423000 C:\Program Files\Java\jre1.6.0_01\bin\javaw.exe 0x7c900000 - 0x7c9b0000 C:\WINDOWS\system32\ntdll.dll 0x7c800000 - 0x7c8f4000 C:\WINDOWS\system32\kernel32.dll 0x77dd0000 - 0x77e6b000 C:\WINDOWS\system32\ADVAPI32.dll 0x77e70000 - 0x77f01000 C:\WINDOWS\system32\RPCRT4.dll 0x7e410000 - 0x7e4a0000 C:\WINDOWS\system32\USER32.dll 0x77f10000 - 0x77f57000 C:\WINDOWS\system32\GDI32.dll 0x76390000 - 0x763ad000 C:\WINDOWS\system32\IMM32.DLL 0x7c340000 - 0x7c396000 C:\Program Files\Java\jre1.6.0_01\bin\msvcr71.dll 0x6d7c0000 - 0x6da07000 C:\Program Files\Java\jre1.6.0_01\bin\client\jvm.dll 0x76b40000 - 0x76b6d000 C:\WINDOWS\system32\WINMM.dll 0x5cd70000 - 0x5cd77000 C:\WINDOWS\system32\serwvdrv.dll 0x5b0a0000 - 0x5b0a7000 C:\WINDOWS\system32\umdmxfrm.dll 0x6d310000 - 0x6d318000 C:\Program Files\Java\jre1.6.0_01\bin\hpi.dll 0x76bf0000 - 0x76bfb000 C:\WINDOWS\system32\PSAPI.DLL 0x6d770000 - 0x6d77c000 C:\Program Files\Java\jre1.6.0_01\bin\verify.dll 0x6d3b0000 - 0x6d3cf000 C:\Program Files\Java\jre1.6.0_01\bin\java.dll 0x6d7b0000 - 0x6d7bf000 C:\Program Files\Java\jre1.6.0_01\bin\zip.dll 0x10000000 - 0x10012000 C:\Documents and Settings\Alex\workspace\MediaServer\rxtxSerial.dll 0x73d90000 - 0x73db7000 C:\WINDOWS\system32\crtdll.dll VM Arguments: jvm_args: -Djava.library.path=C:\Documents and Settings\Alex\workspace\MediaServer java_command: com.bjt.media.server.DigitoolConnection Launcher Type: SUN_STANDARD Environment Variables: CLASSPATH=.;C:\Program Files\Java\j2re1.4.2_07\lib\ext\QTJava.zip PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\wbem;c:\applications\php;C:\Program Files\MATLAB\R2006a\bin\win32;C:\Roger\Projects\UAV\Bin\Debug;C:\Program Files\Microsoft SQL Server\80\Tools\Binn\;c:\Program Files\Microsoft SQL Server\90\Tools\binn\;C:\Program Files\QuickTime\QTSystem\;C:\Pfps\system;C:\Program Files\Java\jdk1.6.0_01\bin;C:\Program Files\Java\jdk1.6.0_01\jre\bin USERNAME=Alex OS=Windows_NT PROCESSOR_IDENTIFIER=x86 Family 15 Model 4 Stepping 1, GenuineIntel --------------- S Y S T E M --------------- OS: Windows XP Build 2600 Service Pack 2 CPU:total 1 family 15, cmov, cx8, fxsr, mmx, sse, sse2 Memory: 4k page, physical 1046508k(275288k free), swap 2522816k(1909176k free) vm_info: Java HotSpot(TM) Client VM (1.6.0_01-b06) for windows-x86, built on Mar 14 2007 00:24:02 by "java_re" with unknown MS VC++:1310 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070604/c87ae1f0/attachment-0006.html From alwyn.schoeman at gmail.com Tue Jun 5 00:10:19 2007 From: alwyn.schoeman at gmail.com (Alwyn Schoeman) Date: Tue, 5 Jun 2007 08:10:19 +0200 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Hi, I'm using a similar modem. By default rxtx doesn't look for devices that start with ACM, so you need to modify the source code and recompile. Look in RXTXCommDriver and add values for ACM in the registerScannedPorts method in the Linux specific parts. Look for osName.equals("Linux")... On 6/4/07, soop soop wrote: > > Hi Guys, > > Looked through the archives but still cannot figure this out. I have a > Motorola G24 GPRS/GSM modem that I am connecting to my server running > Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not > detecting the port, CommPortIdentifier.getPortIdentifiers(). > > I have added the line to RXTXCommDriver: > > "ttyACM" // for USB Modems > > Rxtx still does not seem to find the port. Is there something I am missing > to make this port visable? > > [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver > [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device > [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control > Model > driver for USB modems and ISDN adapters > > I really need your help as I have moved my server from windows to Linux > and > have been down for a few days because of this .. Thanks so much! > > _________________________________________________________________ > PC Magazine's 2007 editors' choice for best Web mail?award-winning Windows > Live Hotmail. > > http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -- Alwyn Schoeman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/b6cb3053/attachment-0006.html From naranjo.manuel at gmail.com Tue Jun 5 06:48:45 2007 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Tue, 05 Jun 2007 09:48:45 -0300 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> References: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Message-ID: <46655BAD.7010501@gmail.com> That's right, an easier solution is creating symlinks to acm. For example make ttyS70 to 79 point to ACM0 to 9 and that will help you a lot, and doesn't even require compile. > Hi, > > I'm using a similar modem. By default rxtx doesn't look for devices > that start with ACM, so you need to modify the > source code and recompile. > > Look in RXTXCommDriver and add values for ACM in the > registerScannedPorts method in the Linux specific parts. Look for > osName.equals("Linux")... > From juanemc2 at gmail.com Tue Jun 5 07:02:43 2007 From: juanemc2 at gmail.com (Juan) Date: Tue, 5 Jun 2007 10:02:43 -0300 Subject: [Rxtx] Problems with Epson TMU220B POSPrinter using XON/XOFF Flow Control and rxtx jar and dll's with the serial port. Message-ID: Hi!, I?m having trouble printing to the serial port using the latest version of rxtx jar and dll's with an Epson POSPrinter. I`ve switched the printer to work with XON/XOFF Flow Control and have watched the serial port to be sure the printer is sending the XON XOFF stop and go characters. I`ve setted the port like this: CommPortIdentifier commPortIdentifier = CommPortIdentifier.* getPortIdentifier*(_portName); SerialPort serialPort = (SerialPort)commPortIdentifier.open(*this*.getClass().getName(), 2000); serialPort.setSerialPortParams(_baudRate, _dataBits, _stopBits, _parity); serialPort.setFlowControlMode( SerialPort.*FLOWCONTROL_XONXOFF_IN* | SerialPort.*FLOWCONTROL_XONXOFF_OUT*); where the baudRate is 9600 the dataBits is 8 the stopBits is 1 and the parity is 0 It seems as the library isn`t taking into account the XON XOFF setting. I would like to know if I`m setting correctly the Flow Control and if you had had any experiences using XON XOFF flow control and could give me some help to solve my problem. I`m very thankful in advance, Yours, Juan Polero -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/b080995a/attachment-0006.html From ehdez.correo at gmail.com Tue Jun 5 07:12:53 2007 From: ehdez.correo at gmail.com (=?ISO-8859-1?Q?Enrique_Hern=E1ndez?=) Date: Tue, 5 Jun 2007 09:12:53 -0400 Subject: [Rxtx] problem with rxtx Message-ID: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Hello: I doing a simple test to show the serial ports. This is the code: import java.util.Enumeration; import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; public class Show { private Enumeration portList; private CommPortIdentifier portId; private SerialPort port; /** Creates a new instance of Show */ public Show() { } public static void main(String args[]){ Show show = new Show(); show.portList = CommPortIdentifier.getPortIdentifiers(); String tPort = ""; System.out.println("========================================="); while(show.portList.hasMoreElements()){ show.portId = (CommPortIdentifier)show.portList.nextElement(); if(show.portId.getPortType() == CommPortIdentifier.PORT_SERIAL) tPort = "Serial"; else tPort = "Parallel"; System.out.println(show.portId.getName() + " " + tPort); } } } whit The problem is that this code not show the serial ports, this show the no use serial ports. I want to connect whit the modem but when windows open and connect the modem my application don't see the port(COMM3) when it is connect. what I can do? Is that the correct way to know the ports? thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/eedd744b/attachment-0006.html From ehdez.correo at gmail.com Tue Jun 5 07:42:13 2007 From: ehdez.correo at gmail.com (=?ISO-8859-1?Q?Enrique_Hern=E1ndez?=) Date: Tue, 5 Jun 2007 09:42:13 -0400 Subject: [Rxtx] serial port Message-ID: <4a814e1f0706050642p4ce9ac7bka80f9479c524c5ea@mail.gmail.com> Hello: How I can ask to the port what device is connect and information about this device. thanks. bye. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/4d10d26a/attachment-0006.html From supsoop at hotmail.com Tue Jun 5 09:29:00 2007 From: supsoop at hotmail.com (soop soop) Date: Tue, 05 Jun 2007 15:29:00 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Message-ID: Hi Guys, Thanks for all your help. I found the problem. I created a user, Tomcat55, for my tomcat but it did not belong to any group. I then added this user to dialout group to have access to the device ttyACM0. Works perfectly! Again permissions was the issue. This also seems to be persistent as a server reboot does not effect the access. Cheers! >From: "Alwyn Schoeman" >Reply-To: RXTX Developers and Users >To: "RXTX Developers and Users" >Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >Date: Tue, 5 Jun 2007 08:10:19 +0200 > >Hi, > >I'm using a similar modem. By default rxtx doesn't look for devices that >start with ACM, so you need to modify the >source code and recompile. > >Look in RXTXCommDriver and add values for ACM in the registerScannedPorts >method in the Linux specific parts. Look for osName.equals("Linux")... > >On 6/4/07, soop soop wrote: >> >>Hi Guys, >> >>Looked through the archives but still cannot figure this out. I have a >>Motorola G24 GPRS/GSM modem that I am connecting to my server running >>Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not >>detecting the port, CommPortIdentifier.getPortIdentifiers(). >> >>I have added the line to RXTXCommDriver: >> >>"ttyACM" // for USB Modems >> >>Rxtx still does not seem to find the port. Is there something I am missing >>to make this port visable? >> >>[ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver >>[ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device >>[ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control >>Model >>driver for USB modems and ISDN adapters >> >>I really need your help as I have moved my server from windows to Linux >>and >>have been down for a few days because of this .. Thanks so much! >> >>_________________________________________________________________ >>PC Magazine's 2007 editors' choice for best Web mail—award-winning Windows >>Live Hotmail. >> >>http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 >> >> >>_______________________________________________ >>Rxtx mailing list >>Rxtx at qbang.org >>http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > >-- >Alwyn Schoeman >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ Need a break? Find your escape route with Live Search Maps. http://maps.live.com/default.aspx?ss=Restaurants~Hotels~Amusement%20Park&cp=33.832922~-117.915659&style=r&lvl=13&tilt=-90&dir=0&alt=-1000&scene=1118863&encType=1&FORM=MGAC01 From netbeans at gatworks.com Tue Jun 5 09:42:31 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 11:42:31 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <46658467.20101@gatworks.com> soop soop wrote: > > Hi Guys, > > Thanks for all your help. I found the problem. I created a user, > Tomcat55, for my tomcat but it did not belong to any group. I then added Look at man pages for the program udev. From tjarvi at qbang.org Tue Jun 5 18:18:17 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Jun 2007 18:18:17 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Message-ID: On Tue, 5 Jun 2007, Enrique Hern?ndez wrote: > The problem is that this code not show the serial ports, this show the no > use serial ports. I want to connect whit the modem but when windows open and > connect the modem my application don't see the port(COMM3) when it is > connect. > what I can do? > Is that the correct way to know the ports? > Hello, We may have problems understanding each other. On windows, the port will not be an available serial port if another application has the port open. That is just how the library behaves. If you can not see the port in the enumerated list, you could not open it. Also note that enumeration only happens once. If you add a port such as a new USB dongle, the port will not be visible until the next time your application runs. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Tue Jun 5 18:45:01 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 20:45:01 -0400 Subject: [Rxtx] problem with rxtx In-Reply-To: References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Message-ID: <4666038D.8090700@gatworks.com> Trent Jarvi wrote: > > > Also note that enumeration only happens once. If you add a port such as > a new USB dongle, the port will not be visible until the next time your > application runs. Is this written in stone ? somewhere? From tjarvi at qbang.org Tue Jun 5 18:54:36 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Jun 2007 18:54:36 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <4666038D.8090700@gatworks.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> Message-ID: On Tue, 5 Jun 2007, Uncle George wrote: > Trent Jarvi wrote: >> >> >> Also note that enumeration only happens once. If you add a port such as >> a new USB dongle, the port will not be visible until the next time your >> application runs. > > Is this written in stone ? somewhere? It is just the current behavior. There is nothing preventing a fix that allows reenumeration. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Tue Jun 5 19:55:19 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 21:55:19 -0400 Subject: [Rxtx] problem with rxtx In-Reply-To: References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> Message-ID: <46661407.4020308@gatworks.com> >> Is this written in stone ? somewhere? > > It is just the current behavior. There is nothing preventing a fix that > allows reenumeration. With usb, ..... , things come and go. Seems a shame that you have to kill application to get at the device u just plugged in. From joachim at buechse.ch Wed Jun 6 01:50:06 2007 From: joachim at buechse.ch (Joachim Buechse) Date: Wed, 6 Jun 2007 09:50:06 +0200 Subject: [Rxtx] problem with rxtx In-Reply-To: <46661407.4020308@gatworks.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> <46661407.4020308@gatworks.com> Message-ID: <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> On MacOS RXTX's enumeration handling is more flexible. It will find new ports that are added during the lifetime of the application. But this is inherently incompatible with suns javax.comm implementation... Regards, Joachim On 06.06.2007, at 03:55, Uncle George wrote: > >>> Is this written in stone ? somewhere? >> >> It is just the current behavior. There is nothing preventing a >> fix that >> allows reenumeration. > > With usb, ..... , things come and go. Seems a shame that you have to > kill application to get at the device u just plugged in. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Jun 6 06:06:48 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Jun 2007 06:06:48 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> <46661407.4020308@gatworks.com> <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> Message-ID: Sun's javax.comm is not a major concern going forward. As long as we do not break old applications using rxtx, I see no reason to limit rxtx to that convention. We have already rejected version 3 from Sun as a dead end and limited our compatability to version 2. That does not mean we will not try to work with Sun and others but the current javax.comm convention (v3) is not a well conceived path. There has been discussion about doing a JSR which is one valid option. On Wed, 6 Jun 2007, Joachim Buechse wrote: > On MacOS RXTX's enumeration handling is more flexible. It will find > new ports that are added during the lifetime of the application. But > this is inherently incompatible with suns javax.comm implementation... > > Regards, > Joachim > > On 06.06.2007, at 03:55, Uncle George wrote: > >> >>>> Is this written in stone ? somewhere? >>> >>> It is just the current behavior. There is nothing preventing a >>> fix that >>> allows reenumeration. >> >> With usb, ..... , things come and go. Seems a shame that you have to >> kill application to get at the device u just plugged in. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From yvespielusenet at free.fr Wed Jun 6 08:46:35 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 16:46:35 +0200 Subject: [Rxtx] [PARALLEL] resource in use Message-ID: <1181141195.3407.20.camel@localhost.localdomain> Hello, I want to use rxtx in my application. I haveto send data to a very old printer (which have a drum and hammers http://perso.orange.fr/tiie/page00010017.html) This is printer is connecter with centronics. It works well but, while it's writting and I putthe printer off-line, after about 45 seconds, I have this error : ------------------------------------- java.io.IOException: La ressource demand?e est en cours d'utilisation. in writeArray at gnu.io.LPRPort.writeArray(Native Method) at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:292) at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:161) at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:156) at mce.buffer.bufferManager.BufferManager$PrintBuffer.run(BufferManager.java:141) The IOexception means "The wanted resource is in use" ------------------------------------- Here is the line 141 of BufferManager : ------------------------------------- while(send){ try{ fos.write(bb); <=== line 141 send = false; } catch(Exception e){ javax.swing.JOptionPane.showMessageDialog(null, "Erreur d'envoie. Veuillez cliquer sur OK pour relancer l'impression de la vignette.\nV?rifiez votre impression !", "Erreur d'envoie", javax.swing.JOptionPane.WARNING_MESSAGE); e.printStackTrace(System.err); System.err.flush(); System.out.println(e); send = true; } } -------------------------------- 'fos' is an outputstream which contains the rxtx stream (this.os is the rxtx outputstream) : -------------------------------- public void write(byte[] bb) throws IOException{ this.write(bb, 0, bb.length); } public void write(byte[] bb, int off, int len) throws IOException{ while(!imp1.isPrinterSelected() || !imp2.isPrinterSelected()){ } this.os.write(bb, off, len); } -------------------------------- Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( can you help me ? thank you :) -- yves piel From yvespielusenet at free.fr Wed Jun 6 09:11:15 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 17:11:15 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181141195.3407.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> Message-ID: <1181142675.3407.23.camel@localhost.localdomain> I forgot to tell that It's under windows XP and java 1.5. Le mercredi 06 juin 2007 ? 16:46 +0200, yves pielusenet a ?crit : > Hello, > I want to use rxtx in my application. I haveto send data to a very old > printer (which have a drum and hammers > http://perso.orange.fr/tiie/page00010017.html) > This is printer is connecter with centronics. It works well but, while > it's writting and I putthe printer off-line, after about 45 seconds, I > have this error : > ------------------------------------- > java.io.IOException: La ressource demand?e est en cours d'utilisation. > in writeArray > at gnu.io.LPRPort.writeArray(Native Method) > at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:292) > at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:161) > at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:156) > at mce.buffer.bufferManager.BufferManager$PrintBuffer.run(BufferManager.java:141) > > The IOexception means "The wanted resource is in use" > ------------------------------------- > > Here is the line 141 of BufferManager : > > ------------------------------------- > while(send){ > try{ > fos.write(bb); <=== line 141 > send = false; > } > catch(Exception e){ > javax.swing.JOptionPane.showMessageDialog(null, "Erreur d'envoie. Veuillez cliquer sur OK pour relancer l'impression de la vignette.\nV?rifiez votre impression !", "Erreur d'envoie", javax.swing.JOptionPane.WARNING_MESSAGE); > e.printStackTrace(System.err); > System.err.flush(); > System.out.println(e); > send = true; > } > } > -------------------------------- > 'fos' is an outputstream which contains the rxtx stream (this.os is the rxtx outputstream) : > > -------------------------------- > public void write(byte[] bb) throws IOException{ > this.write(bb, 0, bb.length); > } > public void write(byte[] bb, int off, int len) throws IOException{ > while(!imp1.isPrinterSelected() || !imp2.isPrinterSelected()){ > } > this.os.write(bb, off, len); > } > -------------------------------- > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > can you help me ? > > thank you :) > From netbeans at gatworks.com Wed Jun 6 09:21:46 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 11:21:46 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181141195.3407.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> Message-ID: <4666D10A.8000507@gatworks.com> } > -------------------------------- > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > can you help me ? > > thank you :) > windoz or linux? ( I guess windoz ) for windoz, there appears to be a timeout ( as Comments suggest ) of about 40seconds. > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } for linux, there is no implied timeout. > if( write( fd, bytes, count ) < 0 ) > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); From netbeans at gatworks.com Wed Jun 6 09:39:41 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 11:39:41 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666D10A.8000507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> Message-ID: <4666D53D.90000@gatworks.com> Uncle George wrote: > } >> -------------------------------- >> >> Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( >> >> can you help me ? From reading the code, I can see your concern. And it appears you are correct, because some of the data will be sent to the OS printer buffers, and then it will refuse to accept anymore. Unfortunately, writeArray does not return the num of characters written :{ So application has no idea to how many characters were accepted by the OS. I dont do windoz, so I cant say with absolute certainty what windoz will do with an off-line condition. If you have the source, and can compile, then maybe u can increase the loop count to hit 4hours? From yvespielusenet at free.fr Wed Jun 6 09:53:25 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 17:53:25 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666D10A.8000507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> Message-ID: <1181145205.3407.35.camel@localhost.localdomain> Thank you for your explanation :) This timeout comes when no data has been send to the printer after 40seconds if I well understand. But why there is such a timeout ? If I setthe printer offline while it's printing I mustn't have an exception. I don't understand why the "printer should solv all problems like buffer full" in 40 seconds. If I pause the printer the buffer will not be emptied, isn't it ? I not very familiar with C/C++, but it seem that the exception is thrown only when countWritten == 0, that means no data at all has been sent. So Is my code is good since when I intercept this exception I send all my buffer again. There is no way that the printer receive two times same bytes ? thanks ps: yes the application is running on windows XP since I developpe under Debian Le mercredi 06 juin 2007 ? 11:21 -0400, Uncle George a ?crit : > } > > -------------------------------- > > > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > > > can you help me ? > > > > thank you :) > > > > windoz or linux? ( I guess windoz ) > > for windoz, there appears to be a timeout ( as Comments suggest ) of > about 40seconds. > > while( count > 0 ){ > > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > > /* > > this are 20 * 2 seconds, in this time a printer (or other parallel device) > > should solv all problems like buffer full, etc > > */ > > if(errorCount++ < 20){ > > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > > continue; > > } > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > for linux, there is no implied timeout. > > if( write( fd, bytes, count ) < 0 ) > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Wed Jun 6 10:34:24 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 12:34:24 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181145205.3407.35.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> Message-ID: <4666E210.30507@gatworks.com> yves pielusenet wrote: > Thank you for your explanation :) > This timeout comes when no data has been send to the printer after > 40seconds if I well understand. But why there is such a timeout ? If I > setthe printer offline while it's printing I mustn't have an exception. > I don't understand why the "printer should solv all problems like buffer > full" in 40 seconds. If I pause the printer the buffer will not be > emptied, isn't it ? > > I not very familiar with C/C++, but it seem that the exception is thrown > only when countWritten == 0, that means no data at all has been sent. So > Is my code is good since when I intercept this exception I send all my > buffer again. There is no way that the printer receive two times same > bytes ? More technically, the function call returns and reports that 0 characters was written in this call. when 0 characters are written, it will check how many times 0 characters was written. If it has tried LESS than 20 times(errorCount), it will sleep() and try to write again. After 20 times, it wont sleep, but throw you the exception. Now suppose you are writing a 120 character line. you off-lined/paused your printer. The OS has room for 80 more characters in it's printer buffer. The WriteFile() will have a char count of 120, but on return the countWritten = 80. You still have 40 more characters to print. Since countWritten != 0, the counters: bytes += countWritten; count -= countWritten; get updated, and the Writefile now has a count of 40 characters. Since the printer is off-line, the countwritten is 0. And so the loop continues, till 40 seconds is up. As to why it is this way, i dont know ( not a windoz maven ); Also the sleep(20) in the loop is not so intuitive to suggest 2 seconds of sleep. I would have guessed 20seconds, or 20milliseconds. But go figure. BTW: Since your computer sends you error messages in French, does it curse in English? :)))) From yvespielusenet at free.fr Thu Jun 7 02:27:44 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Thu, 07 Jun 2007 10:27:44 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666E210.30507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> Message-ID: <1181204864.3501.10.camel@localhost.localdomain> Maybe in my case I should re-compile rxtx and change the code. Instead of send an exception I should display a dialog box to ask if it's printer problem or if it should trie to send bytes. Something like : while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } if(displayDialogBox("Try again to send datas ??")){ errorCount = 0; } else{ throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } } Le mercredi 06 juin 2007 ? 12:34 -0400, Uncle George a ?crit : > yves pielusenet wrote: > > Thank you for your explanation :) > > This timeout comes when no data has been send to the printer after > > 40seconds if I well understand. But why there is such a timeout ? If I > > setthe printer offline while it's printing I mustn't have an exception. > > I don't understand why the "printer should solv all problems like buffer > > full" in 40 seconds. If I pause the printer the buffer will not be > > emptied, isn't it ? > > > > I not very familiar with C/C++, but it seem that the exception is thrown > > only when countWritten == 0, that means no data at all has been sent. So > > Is my code is good since when I intercept this exception I send all my > > buffer again. There is no way that the printer receive two times same > > bytes ? > More technically, the function call returns and reports that 0 > characters was written in this call. > when 0 characters are written, it will check how many times 0 characters > was written. If it has tried LESS than 20 times(errorCount), it will > sleep() and try to write again. > After 20 times, it wont sleep, but throw you the exception. > > Now suppose you are writing a 120 character line. you off-lined/paused > your printer. The OS has room for 80 more characters in it's printer > buffer. The WriteFile() will have a char count of 120, but on return the > countWritten = 80. You still have 40 more characters to print. > Since countWritten != 0, the counters: > bytes += countWritten; > count -= countWritten; > get updated, and the Writefile now has a count of 40 characters. Since > the printer is off-line, the countwritten is 0. And so the loop > continues, till 40 seconds is up. > > As to why it is this way, i dont know ( not a windoz maven ); > Also the sleep(20) in the loop is not so intuitive to suggest 2 seconds > of sleep. I would have guessed 20seconds, or 20milliseconds. But go figure. > > BTW: Since your computer sends you error messages in French, does it > curse in English? :)))) > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 06:11:43 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 08:11:43 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181204864.3501.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> Message-ID: <4667F5FF.8070903@gatworks.com> your suggestion appears good. I dont know what displayDialogBox exactly will do, so all I can say it that it looks good. But I'd like to wait 10min before first dialog box And a 5 min wait for every dialog box there after. And since these are custom solution/choices, maybe a more exact explanation of what the issue is. if(errorCount++ < 300){ // wait 10min ( 10min * 60sec / 2 ) Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } if(displayDialogBox("Printer has Paused. Retry sending data?")){ errorCount = 150; // Wait for 5 min thereafter continue; } > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } yves pielusenet wrote: > Maybe in my case I should re-compile rxtx and change the code. Instead > of send an exception I should display a dialog box to ask if it's > printer problem or if it should trie to send bytes. Something like : > > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > > if(displayDialogBox("Try again to send datas ??")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > } > From yvespielusenet at free.fr Thu Jun 7 07:17:21 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Thu, 07 Jun 2007 15:17:21 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4667F5FF.8070903@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <4667F5FF.8070903@gatworks.com> Message-ID: <1181222241.3501.20.camel@localhost.localdomain> thank you :) 'displayDialogBox()' I think doesn't exist. It was just for the example :) But I think It should not be so complicated to display a dialog box under windows with YES/NO buttons. When yes is clicked it return 0 other it returns 1. Le jeudi 07 juin 2007 ? 08:11 -0400, Uncle George a ?crit : > your suggestion appears good. I dont know what displayDialogBox exactly > will do, so all I can say it that it looks good. > > But I'd like to wait 10min before first dialog box And a 5 min wait for > every dialog box there after. And since these are custom > solution/choices, maybe a more exact explanation of what the issue is. > > if(errorCount++ < 300){ // wait 10min ( 10min * 60sec / 2 ) > Sleep( 20 ); /* make a small pause to execute all other requests > in all other threads */ > continue; > } > > if(displayDialogBox("Printer has Paused. Retry sending data?")){ > errorCount = 150; // Wait for 5 min thereafter > continue; > } > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > > yves pielusenet wrote: > > Maybe in my case I should re-compile rxtx and change the code. Instead > > of send an exception I should display a dialog box to ask if it's > > printer problem or if it should trie to send bytes. Something like : > > > > while( count > 0 ){ > > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > > /* > > this are 20 * 2 seconds, in this time a printer (or other parallel device) > > should solv all problems like buffer full, etc > > */ > > if(errorCount++ < 20){ > > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > > continue; > > } > > > > if(displayDialogBox("Try again to send datas ??")){ > > errorCount = 0; > > } > > else{ > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > } > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 07:41:43 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 09:41:43 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181222241.3501.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <4667F5FF.8070903@gatworks.com> <1181222241.3501.20.camel@localhost.localdomain> Message-ID: <46680B17.8050109@gatworks.com> yves pielusenet wrote: > thank you :) > 'displayDialogBox()' I think doesn't exist. It was just for the > example :) too bad. Good luck. From rtrout at webbresearch.com Thu Jun 7 11:23:04 2007 From: rtrout at webbresearch.com (Robert Trout) Date: Thu, 07 Jun 2007 13:23:04 -0400 Subject: [Rxtx] Disconnected PortServer TS causes Java to hang Message-ID: <1181236984.14186.33.camel@sisyphus.DinkumSoftware.com> I'm running Linux with sun's Java 1.4.2, Java comm API 2.0, RXTX 2.0-7pre1, and the RealPort digi driver. "/dev/ttyrp00" is a RealPort device. My Java application never returns from a ComPortIdentifier.getPortIdentifier("/dev/ttyrp00") call while the Digi PortServer TS 4 is disconnected from the network. If I later re-connect the PortServer, the call returns about 30 seconds later (it's like a serial port read or write is blocking until the PortServer is re- connected). With the PortServer disconnected, minicom immediately responds with "cannot open /dev/ttyrp00: No such file or directory". I would like my Java application to behave similarly. That is, respond with an error condition instead of hanging when the PortServer is not connected. Since minicom and Java behave differently, I think this "hanging" behavior may be due to RXTX or Java? Has anyone had a similar issue? Solutions? Suggestions? Thanks, Robert From vicnevicne at gmail.com Thu Jun 7 12:16:02 2007 From: vicnevicne at gmail.com (Vicne) Date: Thu, 07 Jun 2007 20:16:02 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181204864.3501.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> Message-ID: <46684B62.7080802@gmail.com> yves pielusenet wrote: > Maybe in my case I should re-compile rxtx and change the code. Instead > of send an exception I should display a dialog box to ask if it's > printer problem or if it should trie to send bytes. Something like : > > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > > if(displayDialogBox("Try again to send datas ??")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > } > Sorry to step in without a specific solution to your problem, but I wanted to share my feeling regarding this proposal. AFAIK, it's generally considered bad practice to pop-up a prompt from a library. The main reason is that in general use, you can't guarantee that someone is actually present behind the console. Imagine a print server in a machine room, connected to a park of printers. In that case, when one printer fails, the logical behaviour would be to use an other one. If you change RxTx the way you propose, the printer queue will simply be stuck with a useless "Try again to send data ?" prompt until an administrator opens a remote connection to the print server's console and clicks "no". Second, it would create a dependency upon the existence of a graphical console (if you go the graphical "dialogBox" way). On many applications (typically server or embedded ones), the JVM is "headless" and if you try to pop-up a dialog, your app would throw an exception (at best) or just wouldn't display the prompt anywhere... Going the "text console" way is not more reliable, because on graphical environments, the text console is hidden unless explicitly requested. My advice would be to think again and find another solution. Ideas are : - make the number of retries a parameter so that you can tune it to what you think is reasonable - throw a more specific exception when the number of retries has been reached, so that a specific prompt can be shown at a higher level Anyway, if you feel that the prompt is the way to go in your case, I would at least make that prompt conditional. The least intrusive way would probably be using a system property, like if("true".equals(System.getProperty("org.rxtx.usePrompt")) && displayDialogBox("Retry sending data ?")){ errorCount = 0; } else{ throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } By default, the behaviour would remain as it is now, but you could force the prompts by defining the property at VM launch if desired. (for example : java.exe -Dorg.rxtx.usePrompt=true myApp) Also, you seemed to say you wanted the printer to start again exactly where is stopped. It would indeed be the best way when the printer is put offline for a few seconds. On the other hand, if the printer is turned off (or the printer runs out of paper, or someone steps on the mains cable), then the only way to go back to a "stable" situation would be by printing the item (page, label, etc.) again from scratch... Just my two cents. Vicne PS : By the way, the dialog box thing is very platform dependant on the C-side, and I think the simplest way would probably be to bridge it to a Java call where you can implement it like you proposed : public boolean displayDialogBox(prompt) { return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); } From netbeans at gatworks.com Thu Jun 7 14:08:24 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 16:08:24 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46684B62.7080802@gmail.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> Message-ID: <466865B8.4060004@gatworks.com> My feeling is that the code that was suggested was for his environs ( his shop ). The issue here is that after a 40+ second wait, an exception will be thrown. But you really dont have a way of 'cancelling' all the WriteFiles() that have already occured before the exception so that your writeArray and the Commapi can backtrack to a position in which they are in sync. The main ( really mine ) concern is not to lose data, or replicate data. After 40seconds, 300 seconds, 55min, no matter how long, data should not be lost or duplicated. But as soon as the exception is thrown, that possibility exists. Maybe an event should be thrown instead? Vicne wrote: > yves pielusenet wrote: >> Maybe in my case I should re-compile rxtx and change the code. Instead >> of send an exception I should display a dialog box to ask if it's >> printer problem or if it should trie to send bytes. Something like : >> >> while( count > 0 ){ >> if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ >> /* >> this are 20 * 2 seconds, in this time a printer (or other parallel device) >> should solv all problems like buffer full, etc >> */ >> if(errorCount++ < 20){ >> Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ >> continue; >> } >> >> if(displayDialogBox("Try again to send datas ??")){ >> errorCount = 0; >> } >> else{ >> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >> break; >> } >> } >> > > Sorry to step in without a specific solution to your problem, but I > wanted to share my feeling regarding this proposal. AFAIK, it's > generally considered bad practice to pop-up a prompt from a library. > The main reason is that in general use, you can't guarantee that > someone is actually present behind the console. Imagine a print server > in a machine room, connected to a park of printers. In that case, when > one printer fails, the logical behaviour would be to use an other one. > If you change RxTx the way you propose, the printer queue will simply be > stuck with a useless "Try again to send data ?" prompt until an > administrator opens a remote connection to the print server's console > and clicks "no". > Second, it would create a dependency upon the existence of a > graphical console (if you go the graphical "dialogBox" way). On many > applications (typically server or embedded ones), the JVM is "headless" > and if you try to pop-up a dialog, your app would throw an exception (at > best) or just wouldn't display the prompt anywhere... Going the "text > console" way is not more reliable, because on graphical environments, > the text console is hidden unless explicitly requested. > > My advice would be to think again and find another solution. Ideas are : > - make the number of retries a parameter so that you can tune it to what > you think is reasonable > - throw a more specific exception when the number of retries has been > reached, so that a specific prompt can be shown at a higher level > > Anyway, if you feel that the prompt is the way to go in your case, I > would at least make that prompt conditional. The least intrusive way > would probably be using a system property, like > > if("true".equals(System.getProperty("org.rxtx.usePrompt")) > && displayDialogBox("Retry sending data ?")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > > > By default, the behaviour would remain as it is now, but you could > force the prompts by defining the property at VM launch if desired. (for > example : java.exe -Dorg.rxtx.usePrompt=true myApp) > > > Also, you seemed to say you wanted the printer to start again > exactly where is stopped. It would indeed be the best way when the > printer is put offline for a few seconds. On the other hand, if the > printer is turned off (or the printer runs out of paper, or someone > steps on the mains cable), then the only way to go back to a "stable" > situation would be by printing the item (page, label, etc.) again from > scratch... > > > Just my two cents. > > > Vicne > > PS : By the way, the dialog box thing is very platform dependant on the > C-side, and I think the simplest way would probably be to bridge it to a > Java call where you can implement it like you proposed : > > public boolean displayDialogBox(prompt) { > return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", > JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); > } > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Thu Jun 7 17:48:11 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 Jun 2007 17:48:11 -0600 (MDT) Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <466865B8.4060004@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> Message-ID: An event is possible. I'm amazed this is the largest problem encountered while using the parallel code. How would the write ever exit if we throw events? Isn't this going to lead to hung applications? On Thu, 7 Jun 2007, Uncle George wrote: > My feeling is that the code that was suggested was for his environs ( > his shop ). > > The issue here is that after a 40+ second wait, an exception will be > thrown. But you really dont have a way of 'cancelling' all the > WriteFiles() that have already occured before the exception so that your > writeArray and the Commapi can backtrack to a position in which they are > in sync. > > The main ( really mine ) concern is not to lose data, or replicate data. > After 40seconds, 300 seconds, 55min, no matter how long, data should > not be lost or duplicated. But as soon as the exception is thrown, that > possibility exists. > > Maybe an event should be thrown instead? > > Vicne wrote: >> yves pielusenet wrote: >>> Maybe in my case I should re-compile rxtx and change the code. Instead >>> of send an exception I should display a dialog box to ask if it's >>> printer problem or if it should trie to send bytes. Something like : >>> >>> while( count > 0 ){ >>> if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ >>> /* >>> this are 20 * 2 seconds, in this time a printer (or other parallel device) >>> should solv all problems like buffer full, etc >>> */ >>> if(errorCount++ < 20){ >>> Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ >>> continue; >>> } >>> >>> if(displayDialogBox("Try again to send datas ??")){ >>> errorCount = 0; >>> } >>> else{ >>> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >>> break; >>> } >>> } >>> >> >> Sorry to step in without a specific solution to your problem, but I >> wanted to share my feeling regarding this proposal. AFAIK, it's >> generally considered bad practice to pop-up a prompt from a library. >> The main reason is that in general use, you can't guarantee that >> someone is actually present behind the console. Imagine a print server >> in a machine room, connected to a park of printers. In that case, when >> one printer fails, the logical behaviour would be to use an other one. >> If you change RxTx the way you propose, the printer queue will simply be >> stuck with a useless "Try again to send data ?" prompt until an >> administrator opens a remote connection to the print server's console >> and clicks "no". >> Second, it would create a dependency upon the existence of a >> graphical console (if you go the graphical "dialogBox" way). On many >> applications (typically server or embedded ones), the JVM is "headless" >> and if you try to pop-up a dialog, your app would throw an exception (at >> best) or just wouldn't display the prompt anywhere... Going the "text >> console" way is not more reliable, because on graphical environments, >> the text console is hidden unless explicitly requested. >> >> My advice would be to think again and find another solution. Ideas are : >> - make the number of retries a parameter so that you can tune it to what >> you think is reasonable >> - throw a more specific exception when the number of retries has been >> reached, so that a specific prompt can be shown at a higher level >> >> Anyway, if you feel that the prompt is the way to go in your case, I >> would at least make that prompt conditional. The least intrusive way >> would probably be using a system property, like >> >> if("true".equals(System.getProperty("org.rxtx.usePrompt")) >> && displayDialogBox("Retry sending data ?")){ >> errorCount = 0; >> } >> else{ >> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >> break; >> } >> >> >> By default, the behaviour would remain as it is now, but you could >> force the prompts by defining the property at VM launch if desired. (for >> example : java.exe -Dorg.rxtx.usePrompt=true myApp) >> >> >> Also, you seemed to say you wanted the printer to start again >> exactly where is stopped. It would indeed be the best way when the >> printer is put offline for a few seconds. On the other hand, if the >> printer is turned off (or the printer runs out of paper, or someone >> steps on the mains cable), then the only way to go back to a "stable" >> situation would be by printing the item (page, label, etc.) again from >> scratch... >> >> >> Just my two cents. >> >> >> Vicne >> >> PS : By the way, the dialog box thing is very platform dependant on the >> C-side, and I think the simplest way would probably be to bridge it to a >> Java call where you can implement it like you proposed : >> >> public boolean displayDialogBox(prompt) { >> return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", >> JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); >> } >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 19:18:51 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 21:18:51 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> Message-ID: <4668AE7B.3060409@gatworks.com> The UNIX version of writeArray is not too great either. It is possible that the write will only process some of the bytes. #else if( write( fd, bytes, count ) < 0 ) throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); #endif -------------------------------- Maybe it might be better to have the native function inform the caller of the # of characters written, then the commapi/output-buffer can be modified to reflect the #of chars written. If an exception is to be thrown, for too many loops of chars written == 0, then exception wont affect the state of the output buffer. Then a ParallelPort.restart() can be called to resume printing whats in the buffer. Trent Jarvi wrote: > An event is possible. I'm amazed this is the largest problem encountered > while using the parallel code. > > How would the write ever exit if we throw events? Isn't this going to > lead to hung applications? Sure. If you dont time out, then there is nothing that will force an EXIT from the write(). Issue is what has the OS done with the write. > > On Thu, 7 Jun 2007, Uncle George wrote: > >> My feeling is that the code that was suggested was for his environs ( >> his shop ). From yvespielusenet at free.fr Fri Jun 8 01:09:01 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Fri, 08 Jun 2007 09:09:01 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4668AE7B.3060409@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> Message-ID: <1181286541.3674.10.camel@localhost.localdomain> It is not possible that the rxtx java method write(byte[], int offset, int length) return anint which contains the number of byte really send to the printer instead of an exception ? So this is the programm which will see if all bytes have been sent. If not it can retry to send the unsended bytes. -------------------------------------------------------- int sended = 0; while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ sended += countWritten; /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } return sended; /*throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break;*/ } ... ... return countWritten; ------------------------------------------------ Le jeudi 07 juin 2007 ? 21:18 -0400, Uncle George a ?crit : > The UNIX version of writeArray is not too great either. It is possible > that the write will only process some of the bytes. > > #else > if( write( fd, bytes, count ) < 0 ) > throw_java_exception_system_msg( env, IO_EXCEPTION, > "writeArray" ); > #endif > -------------------------------- > > Maybe it might be better to have the native function inform the caller > of the # of characters written, then the commapi/output-buffer can be > modified to reflect the #of chars written. If an exception is to be > thrown, for too many loops of chars written == 0, then exception wont > affect the state of the output buffer. Then a ParallelPort.restart() can > be called to resume printing whats in the buffer. > > > Trent Jarvi wrote: > > An event is possible. I'm amazed this is the largest problem encountered > > while using the parallel code. > > > > How would the write ever exit if we throw events? Isn't this going to > > lead to hung applications? > Sure. If you dont time out, then there is nothing that will force an > EXIT from the write(). Issue is what has the OS done with the write. > > > > On Thu, 7 Jun 2007, Uncle George wrote: > > > >> My feeling is that the code that was suggested was for his environs ( > >> his shop ). > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Fri Jun 8 03:45:00 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 11:45:00 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181286541.3674.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> Message-ID: <20070608094500.GC21069@elberon.bln.de.ingenico.com> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > It is not possible that the rxtx java method write(byte[], int offset, > int length) return anint which contains the number of byte really send > to the printer instead of an exception ? > So this is the programm which will see if all bytes have been sent. If > not it can retry to send the unsended bytes. I think write() is void because in Java people love to do this since OutputStream :-) Of course on such interfaces you cannot implement something nice. If you would have a int write, you would not implement the interface and no applications expecting this interface would link/work/compile. oki, Steffen P.S.: (OT) If you propose not to implement the Java interfaces (especially not on JNI level), maybe optionally offering a wrapper that removes e.g. the write return value and so on to downgrade the powerful classic old POSIX read/write style to the modern limited Java style, then I agree :-) Same for read. Instead of things like "int avialable()" it is more powerful to have an approach as select(2) offers (to guarante the caller that read/write will not block [nothing else make sense anyway IMHO] but may read/write less bytes then requested). The caller gets full control and the higher level protocols can care about timeouts, invoking read in some loops and/or implement retransmission. On top of such an implementation, where everything is controlled, defined, guaranteed and reliable, someone could use an InputStream or OutputStream style interface. Or even better: don't use them at all :) just BTW :-) St. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From yvespielusenet at free.fr Fri Jun 8 05:52:45 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Fri, 08 Jun 2007 13:52:45 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <20070608094500.GC21069@elberon.bln.de.ingenico.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> Message-ID: <1181303565.11203.3.camel@localhost.localdomain> So maybe a better way should be to create a new Exception class which has a method "int getWrittenByte()". So the Exception should be use to send again bytes which are not printed yet. yves Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : > * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > > It is not possible that the rxtx java method write(byte[], int offset, > > int length) return anint which contains the number of byte really send > > to the printer instead of an exception ? > > So this is the programm which will see if all bytes have been sent. If > > not it can retry to send the unsended bytes. > > I think write() is void because in Java people love to do this > since OutputStream :-) Of course on such interfaces you cannot > implement something nice. If you would have a int write, you > would not implement the interface and no applications expecting > this interface would link/work/compile. > > oki, > > Steffen > > P.S.: (OT) > If you propose not to implement the Java interfaces (especially > not on JNI level), maybe optionally offering a wrapper that > removes e.g. the write return value and so on to downgrade the > powerful classic old POSIX read/write style to the modern limited > Java style, then I agree :-) Same for read. Instead of things > like "int avialable()" it is more powerful to have an approach as > select(2) offers (to guarante the caller that read/write will not > block [nothing else make sense anyway IMHO] but may read/write > less bytes then requested). The caller gets full control and the > higher level protocols can care about timeouts, invoking read in > some loops and/or implement retransmission. On top of such an > implementation, where everything is controlled, defined, > guaranteed and reliable, someone could use an InputStream or > OutputStream style interface. Or even better: don't use them at > all :) just BTW :-) > St. > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > 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. > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > 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. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Fri Jun 8 06:46:21 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 08:46:21 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181303565.11203.3.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> Message-ID: <46694F9D.5080501@gatworks.com> It seems that with outputstream.write(b[]), you become terribly uncoordinated as soon as an exception is thrown. Docs do not say what happens to the data. Yet from a practicable point of view, one would like to know if the write was accepted in-full, or rejected before any writes. There are no in betweens, as partial writes are not reportable. So for an outputstream.write(), in order for it to return, the full write request has to be taken, and stored in an internal output buffer. If there is no room, the write() is suspended, till there is room. Or throw's an IOException( "no room in buffer") ; As the select() loop for write reports buffer room avail, then more of the internal buffer is sent to the printer. yves pielusenet wrote: > So maybe a better way should be to create a new Exception class which > has a method "int getWrittenByte()". So the Exception should be use to > send again bytes which are not printed yet. > > yves > > Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : >> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: >>> It is not possible that the rxtx java method write(byte[], int offset, >>> int length) return anint which contains the number of byte really send >>> to the printer instead of an exception ? >>> So this is the programm which will see if all bytes have been sent. If >>> not it can retry to send the unsended bytes. >> I think write() is void because in Java people love to do this >> since OutputStream :-) Of course on such interfaces you cannot >> implement something nice. If you would have a int write, you >> would not implement the interface and no applications expecting >> this interface would link/work/compile. >> >> oki, >> >> Steffen >> >> P.S.: (OT) >> If you propose not to implement the Java interfaces (especially >> not on JNI level), maybe optionally offering a wrapper that >> removes e.g. the write return value and so on to downgrade the >> powerful classic old POSIX read/write style to the modern limited >> Java style, then I agree :-) Same for read. Instead of things >> like "int avialable()" it is more powerful to have an approach as >> select(2) offers (to guarante the caller that read/write will not >> block [nothing else make sense anyway IMHO] but may read/write >> less bytes then requested). The caller gets full control and the >> higher level protocols can care about timeouts, invoking read in >> some loops and/or implement retransmission. On top of such an >> implementation, where everything is controlled, defined, >> guaranteed and reliable, someone could use an InputStream or >> OutputStream style interface. Or even better: don't use them at >> all :) just BTW :-) >> St. >> >> About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. >> 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. >> >> About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. >> 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. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From Steffen.DETTMER at ingenico.com Fri Jun 8 08:12:18 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 16:12:18 +0200 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <46694F9D.5080501@gatworks.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: <20070608141218.GE21069@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 08:46 -0400: > It seems that with outputstream.write(b[]), you become terribly > uncoordinated as soon as an exception is thrown. Docs do not say what > happens to the data. (yes, so avoiding it seems to be good :)) > Yet from a practicable point of view, one would like to know if the > write was accepted in-full, or rejected before any writes. There are no > in betweens, as partial writes are not reportable. (which is an artificial API limitation. I never understood how this happend when they invented JDK because the well-known BSD socket API and thus [probably] WinSock does this correct, but anyway) > So for an outputstream.write(), in order for it to return, the full > write request has to be taken, and stored in an internal output buffer. > If there is no room, the write() is suspended, till there is room. Or > throw's an IOException( "no room in buffer") ; As the select() loop for > write reports buffer room avail, then more of the internal buffer is > sent to the printer. yes, might be good in case of a printer. May be horrible in case of PPP/TCP or some other transmission control protocol which may e.g. repeat data or even omit parts of it (e.g. internet realtime radio station broadcasting)... So I think the idea of "int write" (e.g. BSD sockets, linux files and so on) still is the best. A clean API / implementation should guarantee and allow implementations (users) to rely on that; assumptions and automatic background-sending and so on may look pragmatic and may even work on the first look, but may fail in other situations. BTW, if e.g. BSD socket API is known, why not simply copy it (until something better is invented :)) instead of fiddling around with JDK APIs? anyway, have a nice weekend everyone :-) oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Fri Jun 8 08:55:56 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 10:55:56 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070608141218.GE21069@elberon.bln.de.ingenico.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> Message-ID: <46696DFC.7000801@gatworks.com> >> write reports buffer room avail, then more of the internal buffer is >> sent to the printer. > > yes, might be good in case of a printer. May be horrible in case > of PPP/TCP or some other transmission control protocol which > may e.g. repeat data or even omit parts of it (e.g. internet > realtime radio station broadcasting)... So I think the idea of > "int write" (e.g. BSD sockets, linux files and so on) still is > the best. A clean API / implementation should guarantee and allow > implementations (users) to rely on that; assumptions and > automatic background-sending and so on may look pragmatic and may > even work on the first look, but may fail in other situations. > BTW, if e.g. BSD socket API is known, why not simply copy it > (until something better is invented :)) instead of fiddling > around with JDK APIs? But we were talking about the Parallel Port, and the transmission of data over the commapi/parallel-port schema. There isn't much in bi-directional software communication. Its a simple write one byte at a time interface. I'm not looking to change the comm-api. I'm just looking to alter the interaction between the Native ParallelPort functions, and the java ParallelPort functions that call them. This might be more readily doable than to get a committee to re-specify java-API specs. BTW: Whats is off-topic? ( help: not looking for def of off-topic ) From j.kenneth.gentle at acm.org Fri Jun 8 08:58:59 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Fri, 08 Jun 2007 10:58:59 -0400 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <20070608141218.GE21069@elberon.bln.de.ingenico.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> Message-ID: <200706081459.l58Ex5rA019991@qbang.org> Perhaps it is a bit late to jump in on this one, but here goes anyway. If the solutions all seem to "break" the contract with "java.io.outputstream", then, as noted, that may not be the appropriate contract. At the risk of being heretical, JDK1.4 introduced the "nio" package to address some of the compatibility issues with C apis mentioned in previous posts. The interface "java.nio.channels.WriteableByteChannel" defines the following single method: int write(ByteBuffer source); int, strangely enough, is the actual number of bytes written. So, if RXTX as written, against the JavaCOMM api and OutputStream, doesn't do what we want, how about writing a different set of bindings using the java.nio classes and as much of the underlying native code as possible. Note that just because the java.nio.channels.WriteableByteChannel sends back a result, OutputStream.write doesn't have to - and they could both call the same underlying native code. My 2 cents - maybe not worth even that... Ken From netbeans at gatworks.com Fri Jun 8 10:37:28 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 12:37:28 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <200706081459.l58Ex5rA019991@qbang.org> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> Message-ID: <466985C8.8000505@gatworks.com> Ken Gentle wrote: > Perhaps it is a bit late to jump in on this one, but here goes anyway. Common in, the waters fine. > > If the solutions all seem to "break" the contract with > "java.io.outputstream", then, as noted, that may not be the > appropriate contract. > How would the contract be broken? The machinery underneath is handling the contract. From j.kenneth.gentle at acm.org Fri Jun 8 10:48:01 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Fri, 08 Jun 2007 12:48:01 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466985C8.8000505@gatworks.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> Message-ID: <200706081648.l58Gm7YA022904@qbang.org> At 12:37 2007-06-08, you wrote: >Ken Gentle wrote: > > > > If the solutions all seem to "break" the contract with > > "java.io.outputstream", then, as noted, that may not be the > > appropriate contract. > > >How would the contract be broken? The machinery underneath is handling >the contract. It seems that a lot of the discussion has been about not only the timeout and being able to adjust it in the "machinery layer", but also about knowing in the Java layer, in the event of a timeout or exception, how many characters have been written to the device. An OutputStream won't ever do this with out an extension and including a return value "breaks" the contract, right? So, go with a Java IO api that *does* return the number of bytes written, out of the NIO package. I know it doesn't allow for a strict implementation of the JavaCOMM API - however, using NIO classes in place of the IO classes isn't that big a break and would allow those applications that need such information a way to get it. Maybe I'm misunderstanding the problem... Ken From netbeans at gatworks.com Fri Jun 8 11:24:14 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 13:24:14 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <200706081648.l58Gm7YA022904@qbang.org> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> Message-ID: <466990BE.7040100@gatworks.com> Ken Gentle wrote: An > OutputStream won't ever do this with out an extension and including a > return value "breaks" the contract, right? > i was not thinking of change the API to OutputSream. Are there specs for how output stream should work internally? for instance: String data = "Hello this is a line of data"; Outputstream.write( data.getbytes() ); ParallelPort.suspend(); int free = ParallelPort.getoutputbufferfree(); There is a symbiotic relationship between outputstream and the functionality of ParallelPort. From Steffen.DETTMER at ingenico.com Fri Jun 8 11:15:39 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 19:15:39 +0200 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <200706081459.l58Ex5rA019991@qbang.org> References: <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> Message-ID: <20070608171539.GK21069@elberon.bln.de.ingenico.com> * Ken Gentle wrote on Fri, Jun 08, 2007 at 10:58 -0400: > If the solutions all seem to "break" the contract with > "java.io.outputstream", then, as noted, that may not be the > appropriate contract. > > At the risk of being heretical, JDK1.4 introduced the "nio" package > to address some of the compatibility issues with C apis mentioned in > previous posts. The interface > "java.nio.channels.WriteableByteChannel" defines the following single method: > > int write(ByteBuffer source); > > int, strangely enough, is the actual number of bytes written. Yes, AFAIK one of the motivations for the NIO interface was, that the JDK-1.3 APIs (InputStream, e.g.) were not powerfull enough, especially for multi-connection-TCP servers or so. I don't know much about it but I've heard of a project where NIO usage was removed because of stability issues in multi-threaded environments and performance limitations under some circumstances. IIRC the "nio.ByteBuffer" is something very special (namely something you cannot implement in Java, it is "magic" or part of the language itself). Not sure if this is such a great idea (but for performance in the end sometimes heavy prices must be paid) :) > So, if RXTX as written, against the JavaCOMM api and OutputStream, > doesn't do what we want, how about writing a different set of > bindings using the java.nio classes and as much of the underlying > native code as possible. Yes, this would be an idea: use a full-featured interface on JNI, and, if wanted, deliver some wrappers converting this to a less-featured Java-compliant interface. However, powerful things as e.g. "select" are difficult to "emulate" if you are e.g. on some (older?) windows. But if you expose the full-featured APIs, you need to emulate them full-featured, theoretically. In the end it depends what you do on the serial line. If you just want to talk to a modem, then you may not need precise timeouts. But if you need to implement complexer protocols which define response times and timeouts, you may quickly get into difficulties. For instance, AFAIK, rxtx 1.7.2 (?) for windows is very messy with timeouts (there is a maximum, higher values are truncated; resolution is 100ms only; the function may take up to twice the timeout because internally it may be called twice). Probably for most people this is OK, but probably not for all. But having precise timeouts should be OK for all :-) Well, in the end it is nice to wish but somewhat hard to implement (many platforms, connections, USB, BlueTooth, whatever). oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Steffen.DETTMER at ingenico.com Fri Jun 8 11:04:22 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 19:04:22 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <46696DFC.7000801@gatworks.com> References: <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <46696DFC.7000801@gatworks.com> Message-ID: <20070608170422.GJ21069@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 10:55 -0400: > > BTW, if e.g. BSD socket API is known, why not simply copy it > > (until something better is invented :)) instead of fiddling > > around with JDK APIs? > > But we were talking about the Parallel Port, and the > transmission of data over the commapi/parallel-port schema. > There isn't much in bi-directional software communication. Its > a simple write one byte at a time interface. First, there are things like PLIP (http://en.wikipedia.org/wiki/Plip) - well, probably not widely used, sure ;) Second, I think if there is a good simple API known to support all that (with known "best practices") or so and there is no forcing need to invent a new one, why not simply using it? > I'm not looking to change the comm-api. I'm just looking to > alter the interaction between the Native ParallelPort > functions, and the java ParallelPort functions that call them. Ahh, yes. I think this is what I tried to ask. Having an usable JNI interface and on top (in pure java) some wrapper to InputStream or whatever could be done (e.g. by ignoring the return value of write or throwing if != length). Developers could then use the full-featured (non-JAVA-standard) API or select among various wrappers (as InputStream). > This might be more readily doable than to get a committee to > re-specify java-API specs. Yes, of course. I'm afraid that the Java APIs change regularily, but still yet with limited success it seems, so maybe they get it in one of the next iterations; who knows, maybe Java-9 has a BSD-like socket API :) SCNR. > BTW: Whats is off-topic? ( help: not looking for def of > off-topic ) I think I started some "re-specify java-API specs" which was OT probably. oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From lists at iDIAcomputing.com Fri Jun 8 18:48:54 2007 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Fri, 08 Jun 2007 20:48:54 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46684B62.7080802@gmail.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> Message-ID: <4669F8F6.3040101@iDIAcomputing.com> Vicne wrote: > Sorry to step in without a specific solution to your problem, but I > wanted to share my feeling regarding this proposal. AFAIK, it's > generally considered bad practice to pop-up a prompt from a library. ... > > My advice would be to think again and find another solution. Ideas are : > - make the number of retries a parameter so that you can tune it to what > you think is reasonable > - throw a more specific exception when the number of retries has been > reached, so that a specific prompt can be shown at a higher level You could also allow the client code to register a callback class which returns a boolean indicating whether to retry or cancel. This callback class could pop up a dialog, if appropriate, or follow some preset policy, or.... - George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From joachim at buechse.ch Sat Jun 9 09:43:16 2007 From: joachim at buechse.ch (Joachim Buechse) Date: Sat, 9 Jun 2007 17:43:16 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46694F9D.5080501@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: You should not forget, that in the case of an exception it may not even be known what happened to the data. You have a kernel buffer, outgoing chip buffer, incoming chip buffer, etc. So of course, it would be nice to know up to which point data was correctly processed, but this feedback does not exist on the hardware or protocol level and hence can in general not be magicly created on the software level... Regards, Joachim On 08.06.2007, at 14:46, Uncle George wrote: > It seems that with outputstream.write(b[]), you become terribly > uncoordinated as soon as an exception is thrown. Docs do not say what > happens to the data. > > Yet from a practicable point of view, one would like to know if the > write was accepted in-full, or rejected before any writes. There > are no > in betweens, as partial writes are not reportable. > > So for an outputstream.write(), in order for it to return, the full > write request has to be taken, and stored in an internal output > buffer. > If there is no room, the write() is suspended, till there is room. Or > throw's an IOException( "no room in buffer") ; As the select() loop > for > write reports buffer room avail, then more of the internal buffer is > sent to the printer. > > > > yves pielusenet wrote: >> So maybe a better way should be to create a new Exception class which >> has a method "int getWrittenByte()". So the Exception should be >> use to >> send again bytes which are not printed yet. >> >> yves >> >> Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : >>> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: >>>> It is not possible that the rxtx java method write(byte[], int >>>> offset, >>>> int length) return anint which contains the number of byte >>>> really send >>>> to the printer instead of an exception ? >>>> So this is the programm which will see if all bytes have been >>>> sent. If >>>> not it can retry to send the unsended bytes. >>> I think write() is void because in Java people love to do this >>> since OutputStream :-) Of course on such interfaces you cannot >>> implement something nice. If you would have a int write, you >>> would not implement the interface and no applications expecting >>> this interface would link/work/compile. >>> >>> oki, >>> >>> Steffen >>> >>> P.S.: (OT) >>> If you propose not to implement the Java interfaces (especially >>> not on JNI level), maybe optionally offering a wrapper that >>> removes e.g. the write return value and so on to downgrade the >>> powerful classic old POSIX read/write style to the modern limited >>> Java style, then I agree :-) Same for read. Instead of things >>> like "int avialable()" it is more powerful to have an approach as >>> select(2) offers (to guarante the caller that read/write will not >>> block [nothing else make sense anyway IMHO] but may read/write >>> less bytes then requested). The caller gets full control and the >>> higher level protocols can care about timeouts, invoking read in >>> some loops and/or implement retransmission. On top of such an >>> implementation, where everything is controlled, defined, >>> guaranteed and reliable, someone could use an InputStream or >>> OutputStream style interface. Or even better: don't use them at >>> all :) just BTW :-) >>> St. >>> >>> About Ingenico Throughout the world businesses rely on Ingenico >>> for secure and expedient electronic transaction acceptance. >>> Ingenico products leverage proven technology, established >>> standards and unparalleled ergonomics to provide optimal >>> reliability, versatility and usability. This comprehensive range >>> of products is complemented by a global array of services and >>> partnerships, enabling businesses in a number of vertical sectors >>> to accept transactions anywhere their business takes them. >>> 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. >>> >>> About Ingenico Throughout the world businesses rely on Ingenico >>> for secure and expedient electronic transaction acceptance. >>> Ingenico products leverage proven technology, established >>> standards and unparalleled ergonomics to provide optimal >>> reliability, versatility and usability. This comprehensive range >>> of products is complemented by a global array of services and >>> partnerships, enabling businesses in a number of vertical sectors >>> to accept transactions anywhere their business takes them. >>> 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. >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx 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 yvespielusenet at free.fr Mon Jun 11 03:15:12 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Mon, 11 Jun 2007 11:15:12 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: <1181553312.8335.14.camel@localhost.localdomain> So can someone tell a solution for my problem :( Must I say to the user to not put the printer off-line ? I can't since he has to do some pauses, verify print, paper conditioning etc... How do other people ? Before I use the parport librarry to read port status : http://www.geocities.com/Juanga69/parport/ (which doesn't work on windows XP) And I send data into the file LPT1 I use to have no problem when printer was disabled. thanks -- yves piel Le samedi 09 juin 2007 ? 17:43 +0200, Joachim Buechse a ?crit : > You should not forget, that in the case of an exception it may not > even be known what happened to the data. > > You have a kernel buffer, outgoing chip buffer, incoming chip buffer, > etc. So of course, it would be nice to know up to which point data > was correctly processed, but this feedback does not exist on the > hardware or protocol level and hence can in general not be magicly > created on the software level... > > Regards, > Joachim > > On 08.06.2007, at 14:46, Uncle George wrote: > > > It seems that with outputstream.write(b[]), you become terribly > > uncoordinated as soon as an exception is thrown. Docs do not say what > > happens to the data. > > > > Yet from a practicable point of view, one would like to know if the > > write was accepted in-full, or rejected before any writes. There > > are no > > in betweens, as partial writes are not reportable. > > > > So for an outputstream.write(), in order for it to return, the full > > write request has to be taken, and stored in an internal output > > buffer. > > If there is no room, the write() is suspended, till there is room. Or > > throw's an IOException( "no room in buffer") ; As the select() loop > > for > > write reports buffer room avail, then more of the internal buffer is > > sent to the printer. > > > > > > > > yves pielusenet wrote: > >> So maybe a better way should be to create a new Exception class which > >> has a method "int getWrittenByte()". So the Exception should be > >> use to > >> send again bytes which are not printed yet. > >> > >> yves > >> > >> Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : > >>> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > >>>> It is not possible that the rxtx java method write(byte[], int > >>>> offset, > >>>> int length) return anint which contains the number of byte > >>>> really send > >>>> to the printer instead of an exception ? > >>>> So this is the programm which will see if all bytes have been > >>>> sent. If > >>>> not it can retry to send the unsended bytes. > >>> I think write() is void because in Java people love to do this > >>> since OutputStream :-) Of course on such interfaces you cannot > >>> implement something nice. If you would have a int write, you > >>> would not implement the interface and no applications expecting > >>> this interface would link/work/compile. > >>> > >>> oki, > >>> > >>> Steffen > >>> > >>> P.S.: (OT) > >>> If you propose not to implement the Java interfaces (especially > >>> not on JNI level), maybe optionally offering a wrapper that > >>> removes e.g. the write return value and so on to downgrade the > >>> powerful classic old POSIX read/write style to the modern limited > >>> Java style, then I agree :-) Same for read. Instead of things > >>> like "int avialable()" it is more powerful to have an approach as > >>> select(2) offers (to guarante the caller that read/write will not > >>> block [nothing else make sense anyway IMHO] but may read/write > >>> less bytes then requested). The caller gets full control and the > >>> higher level protocols can care about timeouts, invoking read in > >>> some loops and/or implement retransmission. On top of such an > >>> implementation, where everything is controlled, defined, > >>> guaranteed and reliable, someone could use an InputStream or > >>> OutputStream style interface. Or even better: don't use them at > >>> all :) just BTW :-) > >>> St. > >>> > >>> About Ingenico Throughout the world businesses rely on Ingenico > >>> for secure and expedient electronic transaction acceptance. > >>> Ingenico products leverage proven technology, established > >>> standards and unparalleled ergonomics to provide optimal > >>> reliability, versatility and usability. This comprehensive range > >>> of products is complemented by a global array of services and > >>> partnerships, enabling businesses in a number of vertical sectors > >>> to accept transactions anywhere their business takes them. > >>> 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. > >>> > >>> About Ingenico Throughout the world businesses rely on Ingenico > >>> for secure and expedient electronic transaction acceptance. > >>> Ingenico products leverage proven technology, established > >>> standards and unparalleled ergonomics to provide optimal > >>> reliability, versatility and usability. This comprehensive range > >>> of products is complemented by a global array of services and > >>> partnerships, enabling businesses in a number of vertical sectors > >>> to accept transactions anywhere their business takes them. > >>> 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. > >>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx 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 > From Steffen.DETTMER at ingenico.com Mon Jun 11 03:56:18 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 11:56:18 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466990BE.7040100@gatworks.com> References: <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> Message-ID: <20070611095618.GA10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 13:24 -0400: > i was not thinking of change the API to OutputSream. Then I think either someone uses OutputStream (and has no reliable information about incomplete writes) or someone uses somethink else. > Are there specs for how output stream should work internally? > > for instance: > String data = "Hello this is a line of data"; > Outputstream.write( data.getbytes() ); > ParallelPort.suspend(); > int free = ParallelPort.getoutputbufferfree(); > > There is a symbiotic relationship between outputstream and the > functionality of ParallelPort. If you need OutputStream "plus something else", in short you're needing "something else". Personally I dislike the code above a lot. The stream "looks" like if it would be an OutputStream, but in fact it isn't. You need to call getoutputbufferfree later to check if write succeeded (but OutputStream promises that write succeedes synchronous, blocking, or throws an exception). So it is not an OutputStream. No application written for OutputStreams would work without change (because it won't know getoutputbufferfree at all). It is not abstracted from ParallelPort. I think this would be wrong. Then I think an alternative interface instead is better. Let's assume we had some "connection" (to distinguish between OutputStreams and Channels). Then why not working as on a file handle in POSIX: do { // ... select maybe using timer ... readyForWrite = ... if (readyForWrite) { int writtenBytes = connection.write(toWrite); toWrite.remove(0, writtenBytes); } while(readyForWrite && toWrite.length > 0); I think, having such a write isn't the big problem. I think, the difficult thing is around "select" - however this would look like. It should be OO, typesafe, performant, supporting multiple connections/channels/streams in various modes and should be orthogonal to other functionalities. Of course, this heavily depends on what the application is doing; for a simple situation (like reading a small, mandatory file from a local disk) this would be to uncomfortable (and offering unneeded features only). just BTW :) oki, Steffen -- // Modeline for VIM. Please don't remove. // (Help: autoindent, expandtab, shiftwidth=4, tabstop=4, textwidth=75) // vi: set ai et sw=4 ts=4 tw=75 ft=java: About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Mon Jun 11 05:38:33 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 07:38:33 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611095618.GA10821@elberon.bln.de.ingenico.com> References: <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> Message-ID: <466D3439.4020805@gatworks.com> Steffen DETTMER wrote: > (but OutputStream promises that write > succeedes synchronous, blocking, or throws an exception). Where is it so written? From Steffen.DETTMER at ingenico.com Mon Jun 11 06:36:50 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 14:36:50 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466D3439.4020805@gatworks.com> References: <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> <466D3439.4020805@gatworks.com> Message-ID: <20070611123650.GI10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Mon, Jun 11, 2007 at 07:38 -0400: > Steffen DETTMER wrote: > > > (but OutputStream promises that write > > succeedes synchronous, blocking, or throws an exception). > > Where is it so written? Now, as you ask, I think it is not written that clearly but follows from specification. mmm... Am I wrong? I understand the API doc in this way: * http://java.sun.com/j2se/1.4.2/docs/api/java/io/OutputStream.html#write(byte[]) > public void write(byte[] b) > throws IOException > > Writes b.length bytes from the specified byte array to this > output stream. The general contract for write(b) is that > it should have exactly the same effect as the call write(b, > 0, b.length). > > Parameters: > b - the data. > Throws: > IOException - if an I/O error occurs. > See Also: > write(byte[], int, int) and there is: > public void write(byte[] b, > int off, > int len) > throws IOException > > Writes len bytes from the specified byte array starting at > offset off to this output stream. The general contract for > write(b, off, len) is that some of the bytes in the array b > are written to the output stream in order; element b[off] > is the first byte written and b[off+len-1] is the last byte > written by this operation. > > The write method of OutputStream calls the write method of > one argument on each of the bytes to be written out. > Subclasses are encouraged to override this method and > provide a more efficient implementation. > > If b is null, a NullPointerException is thrown. > > If off is negative, or len is negative, or off+len is > greater than the length of the array b, then an > IndexOutOfBoundsException is thrown. > > Parameters: > b - the data. > off - the start offset in the data. > len - the number of bytes to write. > Throws: > IOException - if an I/O error occurs. In particular, an > IOException is thrown if the output stream is closed. In general, any specialisation (derived child class) must comform to this. So write in the end is specified (!) as "The write method ... calls the write method ... on each of the bytes to be written out". This is what must be implemented by ANY OutputStream. Of course, there is: "Subclasses are encouraged to override this method and provide a more efficient implementation." which IMHO does not contradict - the more efficient must behave in exactly the same way of course (just wasting less resources than a simple byte-by-byte write). So it does not matter here I think. The write that finally defines the behavior tells basically: > "Writes the specified byte to this output stream. The general > contract for write is that one byte is written to the output > stream. " > > Throws: > IOException - if an I/O error occurs. which IMHO is another way of saying "write writes the byte immediately and returns on success (only), otherwise an exception is thrown". Especially it cannot happen that zero bytes are written (i.e. the specified byte is NOT written) without an exception. So by this write must be synchronous and blocking, because otherwise it could not reliably know if an asynchronous operation will succeede or not (some getAsyncResult or so would be needed). Since write(byte[]) does this for each byte (or with a behavior beeing exactly the same as if it would do), I think this means that the write(byte[]) succeedes synchronous/blocking or throws an exception. Did I an error in reasoning or confused something or so? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From j.kenneth.gentle at acm.org Mon Jun 11 06:51:25 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 11 Jun 2007 08:51:25 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611123650.GI10821@elberon.bln.de.ingenico.com> References: <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> <466D3439.4020805@gatworks.com> <20070611123650.GI10821@elberon.bln.de.ingenico.com> Message-ID: <200706111251.l5BCpS9T017831@qbang.org> It is as Steffen describes. "InputStream" and "OutputStream" are inherently synchronous (which is why so many java programs resort to threads to use them). Anything outside of this "contract" is *not* an InputStream or OutputStream. That is why there is a new package for things that don't behave like the old *Stream classes - the NIO package. If you look carefully at the IO package, you'll note that almost all the classes are _Decorator_ pattern implementations of the *Stream classes - and the interface presents the _same_ behavior to the calling code in all cases - a synchronous operation that completes successfully or throws an exception (with the one exception of "read" that returns a "-1" on end-of-stream. I know I've read this numerous times - I'd suggest checking the Language Spec or one of the books by Bloch or Gosling. Ken At 08:36 2007-06-11, you wrote: >* Uncle George wrote on Mon, Jun 11, 2007 at 07:38 -0400: > > Steffen DETTMER wrote: > > > > > (but OutputStream promises that write > > > succeedes synchronous, blocking, or throws an exception). > > > > Where is it so written? > >Now, as you ask, I think it is not written that clearly but >follows from specification. mmm... > >Am I wrong? > >I understand the API doc in this way: > >* >http://java.sun.com/j2se/1.4.2/docs/api/java/io/OutputStream.html#write(byte[]) > > public void write(byte[] b) > > throws IOException > > > > Writes b.length bytes from the specified byte array to this > > output stream. The general contract for write(b) is that > > it should have exactly the same effect as the call write(b, > > 0, b.length). > > > > Parameters: > > b - the data. > > Throws: > > IOException - if an I/O error occurs. > > See Also: > > write(byte[], int, int) > > >and there is: > > > > public void write(byte[] b, > > int off, > > int len) > > throws IOException > > > > Writes len bytes from the specified byte array starting at > > offset off to this output stream. The general contract for > > write(b, off, len) is that some of the bytes in the array b > > are written to the output stream in order; element b[off] > > is the first byte written and b[off+len-1] is the last byte > > written by this operation. > > > > The write method of OutputStream calls the write method of > > one argument on each of the bytes to be written out. > > Subclasses are encouraged to override this method and > > provide a more efficient implementation. > > > > If b is null, a NullPointerException is thrown. > > > > If off is negative, or len is negative, or off+len is > > greater than the length of the array b, then an > > IndexOutOfBoundsException is thrown. > > > > Parameters: > > b - the data. > > off - the start offset in the data. > > len - the number of bytes to write. > > Throws: > > IOException - if an I/O error occurs. In particular, an > > IOException is thrown if the output stream is closed. > > >In general, any specialisation (derived child class) must comform >to this. So write in the end is specified (!) as "The write >method ... calls the write method ... on each of the bytes to be >written out". This is what must be implemented by ANY >OutputStream. > >Of course, there is: "Subclasses are encouraged to override this >method and provide a more efficient implementation." which IMHO >does not contradict - the more efficient must behave in exactly >the same way of course (just wasting less resources than a simple >byte-by-byte write). So it does not matter here I think. > > > >The write that finally defines the behavior tells basically: > > > "Writes the specified byte to this output stream. The general > > contract for write is that one byte is written to the output > > stream. " > > > > Throws: > > IOException - if an I/O error occurs. > > >which IMHO is another way of saying "write writes the byte >immediately and returns on success (only), otherwise an exception >is thrown". Especially it cannot happen that zero bytes are >written (i.e. the specified byte is NOT written) without an >exception. So by this write must be synchronous and blocking, >because otherwise it could not reliably know if an asynchronous >operation will succeede or not (some getAsyncResult or so would >be needed). > >Since write(byte[]) does this for each byte (or with a behavior >beeing exactly the same as if it would do), I think this means >that the write(byte[]) succeedes synchronous/blocking or throws >an exception. > >Did I an error in reasoning or confused something or so? > >oki, > >Steffen > >About Ingenico Throughout the world businesses rely on Ingenico for >secure and expedient electronic transaction acceptance. Ingenico >products leverage proven technology, established standards and >unparalleled ergonomics to provide optimal reliability, versatility >and usability. This comprehensive range of products is complemented >by a global array of services and partnerships, enabling businesses >in a number of vertical sectors to accept transactions anywhere >their business takes them. >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. > >About Ingenico Throughout the world businesses rely on Ingenico for >secure and expedient electronic transaction acceptance. Ingenico >products leverage proven technology, established standards and >unparalleled ergonomics to provide optimal reliability, versatility >and usability. This comprehensive range of products is complemented >by a global array of services and partnerships, enabling businesses >in a number of vertical sectors to accept transactions anywhere >their business takes them. >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. > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From alesinskyy at googlemail.com Mon Jun 11 07:25:33 2007 From: alesinskyy at googlemail.com (Oleksandr Alesinskyy) Date: Mon, 11 Jun 2007 15:25:33 +0200 Subject: [Rxtx] [OT] select :-) Message-ID: Sorry, but I have to disagree with following statement: "So write in the end is specified (!) as "The write method ... calls the write method ... on each of the bytes to be written out". This is what must be implemented by ANY OutputStream.". This is not part of the specification or contract, it is just revealed implementation detail of the OutputStream. It is not stated anywhere that behavoiur of derived classes shall conform with this one. Statement concerning "synchronous" nature of the output stream is invalid as well. Really synchronous stream does not require flush() but OutputStream has it. From Steffen.DETTMER at ingenico.com Mon Jun 11 08:21:16 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 16:21:16 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: Message-ID: <20070611142116.GN10821@elberon.bln.de.ingenico.com> * Oleksandr Alesinskyy wrote on Mon, Jun 11, 2007 at 15:25 +0200: > Sorry, but I have to disagree with following statement: > "So write in the end is specified (!) as "The write > method ... calls the write method ... on each of the bytes to be > written out". This is what must be implemented by ANY > OutputStream.". > > This is not part of the specification or contract, it is just > revealed implementation detail of the OutputStream. It is not > stated anywhere that behavoiur of derived classes shall conform > with this one. (I didn't meant that the implementation must really write byte by byte, but that it must "look as if it would do" - because all implementations of OutputStream must "look" in the same way [which is another way of saying "do abstract" I think]) I think the API doc is not "revealing implementation details" but it is the *specification* of that interface and derivations must (should) conform to this specification. Isn't this the idea of interfaces? A function that expects an OutputStream should work on ANY OutputStream, shouldn't it? just kidding: I mean, what would be the point in implementing a checksum function as OutputStream.write which throws its result as IOException? Or which requires to call close() as very first operation to tell that the application is about to transmit confidential data? :-) > Statement concerning "synchronous" nature of the output stream > is invalid as well. Really synchronous stream does not require > flush() but OutputStream has it. ahh, interesting point! I think this is another bug in the API. flush() is wrong. Because write specifies "The general contract for write is that one byte is written to the output stream." but not "a byte may be written or buffered". Actually, an application would need to call flush() after each write (or bunch of write calls) to ensure that write really did something otherwise I think. I didn't found in the spec of OutputStream that it would be required to call flush(). This should mean that calling flush is not required which in turn leads to the conclusion that write must be synchrous (private threads are forbidden because not specified :)) which in turn leads to the conclusion that flush() is not needed at all... I mean, what if someone would only store in write and do the "real write" in flush() and never else? An application could write in one stream and read on another one (e.g. in bidirectional communication) and would never get anything back, because nothing was actually written because no flush was called? Then someone could even think that on error in some write the data could remain buffered AND throw an exception, retrying to send the data in the next write. Ohh, and if there would be some message number inside, and underlaying write (e.g. a protocol offering InputStream/OutputStream) would check this and throw "DuplicatedMessageNumber" the stream would only throw it again and again beeing unusable... In short: I have no clue how someone could be able to implement an asynchrounos write (which is realiable and correct) without beeing specific to anything which is not specified by OutputStream. Well, I think in the end OutputStream was not intended for such communication or protocol implementations - but to read a local disk file or so. In case of I/O errors usually you can abort your application and change the hard disk :-) oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Bob_Jacobsen at lbl.gov Mon Jun 11 09:32:23 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Mon, 11 Jun 2007 08:32:23 -0700 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611142116.GN10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> Message-ID: At 4:21 PM +0200 6/11/07, Steffen DETTMER wrote: > > Statement concerning "synchronous" nature of the output stream >> is invalid as well. Really synchronous stream does not require >> flush() but OutputStream has it. > >ahh, interesting point! > >I think this is another bug in the API. flush() is wrong. Because >write specifies "The general contract for write is that one byte >is written to the output stream." but not "a byte may be written >or buffered". > >Actually, an application would need to call flush() after each >write (or bunch of write calls) to ensure that write really did >something otherwise I think. OutputStreams don't _have_ to be synchronous or asynchronous, but the OutputStream API was be arranged so that subclasses _can_ be synchronous or asynchronous. Such generality is the hardest part of getting an API right. Hence, if at some point a program using an OutputStream wants to be sure that the data has been pushed all the way out, flush() is available. For some subclasses, e.g. the buffered ones, this has important behavior. Others write the data from each call, and flush() doesn't do anything. You _can_ omit it in programs that are known to use this second type, but there's no requirement that you do so; the interface is general in that way. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From Steffen.DETTMER at ingenico.com Mon Jun 11 12:32:39 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 20:32:39 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> Message-ID: <20070611183239.GT10821@elberon.bln.de.ingenico.com> * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: > >Actually, an application would need to call flush() after each > >write (or bunch of write calls) to ensure that write really did > >something otherwise I think. > OutputStreams don't _have_ to be synchronous or asynchronous, > but the OutputStream API was be arranged so that subclasses > _can_ be synchronous or asynchronous. Ahh, oki. Thanks for the clarificaion. So in short, flush() MUST be called on OutputStream, this is just not documented correctly or so clearly (right?). So the overall usage semantics would be: 1. call write (multiple times if desired) 2. call flush only if both succeeded, write was successful. If flush fails it remains unknown if a part of the data was written and/or will be repeated. So the spec (API doc) is wrong. Correct would be to tell that write behaves as told as long as it is followed by a call to flush, otherwise data may or may not get lost (depending wheter close() is called and calls flush(), which seems not to be guaranteed/required). BTW, I think it is a little bit... erm... interesting to find the specification (java API doc reference) wrong, having a need to conclude it from the presence of some methods with "it would make no sense if they behave exactly as specified, so specification must be wrong (incomplete)". > Such generality is the hardest part of getting an API right. Yes, seems to be proven ;) > Hence, if at some point a program using an OutputStream wants > to be sure that the data has been pushed all the way out, > flush() is available. For some subclasses, e.g. the buffered > ones, this has important behavior. Others write the data from > each call, and flush() doesn't do anything. > You _can_ omit it in programs that are known to use this second > type, but there's no requirement that you do so; the interface > is general in that way. I think, it still it must be called always, otherwise the application could break if passing a different runtime type as OutputStream. I think, if the application/method needs a special "type of OutputStream" then the parameter type must be a subclass but not OutputStream, maybe a PrintStream or so - otherwise the compiler could not detect this error (passing wrong type). Is this correct? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Bob_Jacobsen at lbl.gov Mon Jun 11 13:00:52 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Mon, 11 Jun 2007 12:00:52 -0700 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611183239.GT10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> Message-ID: At 8:32 PM +0200 6/11/07, Steffen DETTMER wrote: >So the spec (API doc) is wrong. Correct would be to tell that >write behaves as told as long as it is followed by a call to >flush, otherwise data may or may not get lost (depending wheter >close() is called and calls flush(), which seems not to be >guaranteed/required). I'm not entirely sure that the spec is wrong, but reasonable people can differ on this. In the 1.5 JavaDocs, all that the docs say for the write methods is that they write to the _output_ _stream_; there is no guarantee of anything beyond that. Only the flush method has any guarantee about the data, which is >Flushes this output stream and forces any buffered output bytes to >be written out. The general contract of flush is that calling it is >an indication that, if any bytes previously written have been >buffered by the implementation of the output stream, such bytes >should immediately be written to their intended destination. People commonly use various OutputStreams without using flush(), and it often works, but it's a bad practice and will eventually bite them. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From netbeans at gatworks.com Mon Jun 11 13:31:57 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 15:31:57 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611183239.GT10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> Message-ID: <466DA32D.1010602@gatworks.com> Steffen DETTMER wrote: > * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: >>> Actually, an application would need to call flush() after each >>> write (or bunch of write calls) to ensure that write really did >>> something otherwise I think. > >> OutputStreams don't _have_ to be synchronous or asynchronous, >> but the OutputStream API was be arranged so that subclasses >> _can_ be synchronous or asynchronous. > > Ahh, oki. Thanks for the clarificaion. > > So in short, flush() MUST be called on OutputStream, this is just > not documented correctly or so clearly (right?). No. Flush can be called to force all current data in java buffer's to be written to the kernel - NOW. A flush() can also *imply* that, besides writing out the buffer's that java employs, may also imply/ask the kernel to write all data thusfar written to the kernel, to be physically placed on the destination device - NOW. For some OS's there is no need to do a kernel flush(), as the I/O is synchronized already. Since this is java, you never know what OS your on. From tjarvi at qbang.org Mon Jun 11 19:28:27 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Jun 2007 19:28:27 -0600 (MDT) Subject: [Rxtx] [OT] select :-) In-Reply-To: <466DA32D.1010602@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: On Mon, 11 Jun 2007, Uncle George wrote: > Steffen DETTMER wrote: >> * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: >>>> Actually, an application would need to call flush() after each >>>> write (or bunch of write calls) to ensure that write really did >>>> something otherwise I think. >> >>> OutputStreams don't _have_ to be synchronous or asynchronous, >>> but the OutputStream API was be arranged so that subclasses >>> _can_ be synchronous or asynchronous. >> >> Ahh, oki. Thanks for the clarificaion. >> >> So in short, flush() MUST be called on OutputStream, this is just >> not documented correctly or so clearly (right?). > No. > Flush can be called to force all current data in java buffer's to be > written to the kernel - NOW. > > A flush() can also *imply* that, besides writing out the buffer's that > java employs, may also imply/ask the kernel to write all data thusfar > written to the kernel, to be physically placed on the destination device > - NOW. > For some OS's there is no need to do a kernel flush(), as the I/O is > synchronized already. Since this is java, you never know what OS your on. To add to the confusion, flush on the C side throws away data. drain makes sure it is written. Looking at the ParallelImp.c we can probably do better. /* we set a timeout because all calls are sequentiell (also with asynchron) this means that the default timeout of unlimited blocks all calls (also close and status request) if the device is down */ GetCommTimeouts( (HANDLE)fd, &timeouts ); timeouts.WriteTotalTimeoutMultiplier = 0; timeouts.WriteTotalTimeoutConstant = 2000; /* 2000 is the min value for the default Windows NT and Windows 2000 driver */ SetCommTimeouts( (HANDLE)fd, &timeouts ); while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } errorCount = 0; bytes += countWritten; count -= countWritten; } LPRPort has some timeout code that appears to be doing nothing but flipping bits back and forth right now. The commapi rxtx follows allows for timeout control from javax.comm.CommPort. The above is a solution that worked in one specific use case. With timeouts in place, the original 'old printer going offline' problem could be solved. That printer code isn't written in stone. In fact it was ajusted from being able to print 'asdf' to a daisy wheel printer to working for one person. BTW, I've finished teaching after hours tonight and will be moving forward with a new rxtx release in my free time. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Jun 11 21:28:04 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 23:28:04 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: <466E12C4.1010305@gatworks.com> > Looking at the ParallelImp.c we can probably do better. > The problem stemmed from the possibility that the writev routine could have written some of the buffer, in chunks, printer pauses, refuses any more chunks, and a timeout occurs. Do you or do you not cause an exception to be thrown? Is there a way to set timeout for a ParallelPort data output stream? I cant find it. From tjarvi at qbang.org Mon Jun 11 22:17:23 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Jun 2007 22:17:23 -0600 (MDT) Subject: [Rxtx] [OT] select :-) In-Reply-To: <466E12C4.1010305@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> <466E12C4.1010305@gatworks.com> Message-ID: On Mon, 11 Jun 2007, Uncle George wrote: >> Looking at the ParallelImp.c we can probably do better. >> > The problem stemmed from the possibility that the writev routine could > have written some of the buffer, in chunks, printer pauses, refuses any > more chunks, and a timeout occurs. Do you or do you not cause an > exception to be thrown? > > Is there a way to set timeout for a ParallelPort data output stream? I > cant find it. hmm I looked again after you asked. The timeouts are only controllable on the receive side. This comes from CommPort; the parent. So what we are talking about is some bytes in memory that rxtx has and is supposed to write. A buffer perhaps? The approach with rxtx in the past has been to ignore output buffer sizes. The assumption is that the library does not know how to best handle buffers. There are buffered output streams that can do buffering on top of rxtx for instance. There is also a question regarding what was actually ment when the API was put together. My suspicion is that it was put together while looking at one OS API and was never ment to be anything more than a hook into that API. The comments are fairly telling combined with reading the w32 API. So looking at the problem again.. The current timeout behavior appears fairly arbitrary. Presumably this is to prevent a program from hanging instead of using a helper thread to write - heavy handed for new programmers. Even so, I don't think the write should timeout at all if it is not configurable. >From the API perspective, "What Timeout?" -- Trent Jarvi tjarvi at qbang.org From Steffen.DETTMER at ingenico.com Tue Jun 12 02:14:48 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 12 Jun 2007 10:14:48 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466DA32D.1010602@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: <20070612081447.GU10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Mon, Jun 11, 2007 at 15:31 -0400: > Steffen DETTMER wrote: > > Ahh, oki. Thanks for the clarificaion. > > > > So in short, flush() MUST be called on OutputStream, this is just > > not documented correctly or so clearly (right?). > No. hum (though now I got it, but...). > Flush can be called to force all current data in java buffer's to be > written to the kernel - NOW. > > A flush() can also *imply* that, besides writing out the > buffer's that java employs, may also imply/ask the kernel to > write all data thusfar written to the kernel, to be physically > placed on the destination device - NOW. > > For some OS's there is no need to do a kernel flush(), as the I/O is > synchronized already. Since this is java, you never know what OS your on. (well, but if you're going to kernel level, even flush cannot guarantee that data will "be physically placed". Maybe you're flushing to a file via NFS (and the client "thinks" that it was written, but maybe it was just buffered by the NFS server) or so... but of course such exceptions of the rules are constructable always.) Well, you tell that depending on the OS it can be that flush is needed or it can be that flush is not needed (beacuse the I/O is synchronized already), right? Also, applications should work on any OS, which includes the OSes that do need flush. Since the application cannot know whether flush is needed or not because it doesn't know what the OS is doing, it has to call flush, hasn't it? I mean, if it would not call flush then it would not work on such OSes (except the written data would not be needed at all, but in this would be an artificial example :)). Since applications are supposed to work this would be wrong, wouldn't it? So would it be correct to say: "Applications, that should work under all OSes (including the OSes where the I/O is not synchronised already), have to call flush on OutputStream to ensure the data is transfered to the kernel." or is this wrong? If so, then I'm afraid I missed the point again :( oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Tue Jun 12 04:46:52 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 12 Jun 2007 06:46:52 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070612081447.GU10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> <20070612081447.GU10821@elberon.bln.de.ingenico.com> Message-ID: <466E799C.7060700@gatworks.com> S > (well, but if you're going to kernel level, even flush cannot > guarantee that data will "be physically placed". Thats true now-a-days because ( from "man 2 sync" ) : > According to the standard specification (e.g., SVID), sync() schedules > the writes, but may return before the actual writing is done. However, > since version 1.3.20 Linux does actually wait. (This still does not > guarantee data integrity: modern disks have large caches.) My disk drive has 8mb cache. Maybe you're > flushing to a file via NFS (and the client "thinks" that it was > written, but maybe it was just buffered by the NFS server) or > so... but of course such exceptions of the rules are > constructable always.) > > Well, you tell that depending on the OS it can be that flush is > needed or it can be that flush is not needed (beacuse the I/O is > synchronized already), right? Also, applications should work on > any OS, which includes the OSes that do need flush. Its not OS's that need flush, its applications that want to have some assurance that data is written to the device that really needs to use flush. If your program ( or thread ) dies then it is in your best interest to write out the critical data as soon as possible, as economical as possible. These are trade-off's that the application programmer makes. A big buffer may mean big loss of data, a small buffer may mean spending too much time writing out data. > > > So would it be correct to say: > > "Applications, that should work under all OSes (including the > OSes where the I/O is not synchronised already), have to call > flush on OutputStream to ensure the data is transfered to the > kernel." > > or is this wrong? If so, then I'm afraid I missed the point again > :( > No that is not wrong. Ensuring that data is transfered to the OS is just about what any application can do. From tjarvi at qbang.org Thu Jun 14 08:16:47 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 14 Jun 2007 08:16:47 -0600 (MDT) Subject: [Rxtx] rxtx and usb-serial solution In-Reply-To: References: Message-ID: On Thu, 14 Jun 2007, Vladimir Kirtchev wrote: > Hi Trent, > > I develop a Java application which communicates with devices which have > USB-to-Serial bridge in them. The target OS is Linux. So for this purpose I > use RXTX. > > But I encountered a strange problem - when reading from the InputStream, I > receive series of zeros. I have this problem under Linux only. Under Windows > it is fine. > Actually this problem is the same as the one described here: > http://marc.info/?l=rxtx&m=109703190731748&w=2. > > > So I searched for the problem in the native code. And found that the root of > the problem is in SerialImp.c, > int configure_port( int fd ) > { > ... > ttyset.c_iflag = INPCK; > ... > } > > This line enables input parity checking, and the data sent from the device > is processed by the OS driver before being read with read(). > In this case the driver detects some problem and sets the received bytes to > zero. > > On the other hand in the Java part a set the serial port parameters with > SerialPort.PARITY_NONE. According to me, except all other things, this > should also disable INPCK in c_iflag. > > So I refactored the method translate_parity(...) to the following: > > int translate_parity( JNIEnv *env, struct termios *ttyset, jint parity ) > { > ENTER( "translate_parity" ); > #ifdef CMSPAR > ttyset->c_cflag &= ~(PARENB | PARODD | CMSPAR ); > #endif /* CMSPAR */ > switch( parity ) { > case JPARITY_NONE: > ttyset->c_iflag &= ~INPCK; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_EVEN: > ttyset->c_cflag |= PARENB; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_ODD: > ttyset->c_cflag |= PARENB | PARODD; > LEAVE( "translate_parity" ); > return 0; > #ifdef CMSPAR > case JPARITY_MARK: > ttyset->c_cflag |= PARENB | PARODD | CMSPAR; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_SPACE: > ttyset->c_cflag |= PARENB | CMSPAR; > LEAVE( "translate_parity" ); > return 0; > #endif /* CMSPAR */ > default: > printf("Parity missed %i\n", (int) parity ); > } > > LEAVE( "translate_parity" ); > /* > For some reason the native exceptions are not being caught. Moving this > to the Java side fixed the issue. taj. > throw_java_exception( env, UNSUPPORTED_COMM_OPERATION, > "", "parity value not supported" ); > */ > return 1; > } > > This modification solved the problem and now it works correctly under Linux. > > I think I will be a nice if this is idea is included in a future release of > RXTX. > > Thanks Vadim, I'll try that out. Forwarding to the rxtx mail-list too. This is probably not going to help USB drivers on windows which I'm sure some are looking for. As far as I can tell, windows USB bluetooth and serial dongles are limited by driver functionality. Some are good and others lack key features. -- Trent Jarvi tjarvi at qbang.org From dan.sandberg.lists at gmail.com Mon Jun 18 14:43:39 2007 From: dan.sandberg.lists at gmail.com (Dan Sandberg) Date: Mon, 18 Jun 2007 13:43:39 -0700 Subject: [Rxtx] Fix for JNI Get/Set Field Errors Message-ID: <4676EE7B.7060800@gmail.com> Hi, I've fixed the problems that cause the following JNI error when extra JNI checking ( -Xjni:check ) is turned on. FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) The problem was basically that GetLong was being used to get ints, and SetInt was used for longs. The patch below fixes this. Please let me know if there are any questions / problems. Cheers, -Dan diff -aur old/SerialImp.c src/SerialImp.c --- old/SerialImp.c 2007-06-18 13:24:33.000000000 -0700 +++ src/SerialImp.c 2007-06-18 06:26:26.000000000 -0700 @@ -1337,7 +1337,7 @@ report("init_threads: get eis\n"); jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); report("init_threads: set eis\n"); - (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); + (*eis->env)->SetLongField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); report("init_threads: stop\n"); report_time_end( ); return( 1 ); @@ -1530,7 +1530,7 @@ jobject jobj, jboolean interrupted ) { int fd = get_java_var( env, jobj,"fd","I" ); - struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var( env, jobj, "eis", "J" ); + struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var_long( env, jobj, "eis", "J" ); int result, count=0; char message[80]; @@ -2939,7 +2939,7 @@ /* TRENT */ int flag, count = 0; struct event_info_struct *eis = ( struct event_info_struct * ) - get_java_var( env, *jobj,"eis","J" ); + get_java_var_long( env, *jobj,"eis","J" ); report_time_start(); flag = eis->eventflags[SPE_DATA_AVAILABLE]; @@ -4873,9 +4873,9 @@ exceptions: none comments: ----------------------------------------------------------*/ -size_t get_java_var( JNIEnv *env, jobject jobj, char *id, char *type ) +long get_java_var_long( JNIEnv *env, jobject jobj, char *id, char *type ) { - int result = 0; + long result = 0; jclass jclazz = (*env)->GetObjectClass( env, jobj ); jfieldID jfd = (*env)->GetFieldID( env, jclazz, id, type ); @@ -4889,7 +4889,11 @@ LEAVE( "get_java_var" ); return result; } - result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); + if ( !strcmp( type, "J" ) ) { + result = (long)( (*env)->GetLongField( env, jobj, jfd ) ); + } else { + result = (int) ( (*env)->GetIntField( env, jobj, jfd ) ); + } /* ct7 & gel * Added DeleteLocalRef */ (*env)->DeleteLocalRef( env, jclazz ); if(!strncmp( "fd",id,2) && result == 0) @@ -4900,6 +4904,10 @@ return result; } +int get_java_var( JNIEnv *env, jobject jobj, char *id, char *type ) { + return (int) get_java_var_long( env, jobj, id, type ); +} + /*---------------------------------------------------------- throw_java_exception diff -aur old/SerialImp.h src/SerialImp.h --- old/SerialImp.h 2007-06-18 13:24:39.000000000 -0700 +++ src/SerialImp.h 2007-06-18 06:23:43.000000000 -0700 @@ -413,7 +413,8 @@ void system_wait(); void finalize_event_info_struct( struct event_info_struct * ); int read_byte_array( JNIEnv *, jobject *, int, unsigned char *, int, int ); -size_t get_java_var( JNIEnv *, jobject, char *, char * ); +int get_java_var( JNIEnv *, jobject, char *, char * ); +long get_java_var_long( JNIEnv *, jobject, char *, char * ); jboolean is_interrupted( struct event_info_struct * ); int send_event(struct event_info_struct *, jint, int ); void dump_termios(char *,struct termios *); From yvespielusenet at free.fr Tue Jun 26 03:41:58 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 11:41:58 +0200 Subject: [Rxtx] [PARALLEL] resource in use Message-ID: <1182850918.3483.10.camel@localhost.localdomain> Hello, So now I want to modify the timeout of the library for parallel port. I have downloaded source code. There is a makefile for migw. SO I have installed mingw on ubuntu and modified the makefile.mingw32 to set it for my system. I have no error but some warnings. The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But When I want to use it the jvm crash :( How can I know what is wrong ? How rxtx windows release has been done ? thanks -- yves piel From yvespielusenet at free.fr Tue Jun 26 07:17:02 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 15:17:02 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182850918.3483.10.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> Message-ID: <1182863822.3483.17.camel@localhost.localdomain> Here is the Makefile I use, the output of the 'make' and the log of the jvm when it crashed : - The Makefile : http://yvespiel.free.fr/rxtx/Makefile - The make output : http://yvespiel.free.fr/rxtx/compile.txt - The crash log : http://yvespiel.free.fr/rxtx/hs_err_pid2100.log I have compiled rxtx under Debian testing with mingw : narma at linimi:/tmp/err$ dpkg -l | grep mingw ii mingw32 3.4.5.20060117.1.dfsg-3 ii mingw32-binutils 2.17.50-20070129.1-1 ii mingw32-runtime 3.12-1 thanks fort help :) Le mardi 26 juin 2007 ? 11:41 +0200, yves pielusenet a ?crit : > Hello, > So now I want to modify the timeout of the library for parallel port. I > have downloaded source code. There is a makefile for migw. SO I have > installed mingw on ubuntu and modified the makefile.mingw32 to set it > for my system. > I have no error but some warnings. > The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But > When I want to use it the jvm crash :( > > How can I know what is wrong ? > > How rxtx windows release has been done ? > > thanks > From yvespielusenet at free.fr Tue Jun 26 07:40:11 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 15:40:11 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182863822.3483.17.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> <1182863822.3483.17.camel@localhost.localdomain> Message-ID: <1182865211.3483.21.camel@localhost.localdomain> I have add the options '--enable-stdcall-fixup' to the 'i586-mingw32msvc-ld' commande. Now I have no warning. But the JVM always crashes :( The output seems more detailled, but I don't understand anything... Here is files : http://yvespiel.free.fr/rxtx/2/ -- yves piel Le mardi 26 juin 2007 ? 15:17 +0200, yves pielusenet a ?crit : > Here is the Makefile I use, the output of the 'make' and the log of the > jvm when it crashed : > > - The Makefile : http://yvespiel.free.fr/rxtx/Makefile > - The make output : http://yvespiel.free.fr/rxtx/compile.txt > - The crash log : http://yvespiel.free.fr/rxtx/hs_err_pid2100.log > > I have compiled rxtx under Debian testing with mingw : > narma at linimi:/tmp/err$ dpkg -l | grep mingw > ii mingw32 3.4.5.20060117.1.dfsg-3 > ii mingw32-binutils 2.17.50-20070129.1-1 > ii mingw32-runtime 3.12-1 > > thanks fort help :) > > > Le mardi 26 juin 2007 ? 11:41 +0200, yves pielusenet a ?crit : > > Hello, > > So now I want to modify the timeout of the library for parallel port. I > > have downloaded source code. There is a makefile for migw. SO I have > > installed mingw on ubuntu and modified the makefile.mingw32 to set it > > for my system. > > I have no error but some warnings. > > The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But > > When I want to use it the jvm crash :( > > > > How can I know what is wrong ? > > > > How rxtx windows release has been done ? > > > > thanks > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From yvespielusenet at free.fr Tue Jun 26 08:27:42 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 16:27:42 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182865211.3483.21.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> <1182863822.3483.17.camel@localhost.localdomain> <1182865211.3483.21.camel@localhost.localdomain> Message-ID: <1182868062.3483.24.camel@localhost.localdomain> I think thant the include files of jdk were not for windows but for linux. So I have copied include/ folder from windows to linux and I modified the Makefile to use those file. It compile fine but the JVM always crash :( http://yvespiel.free.fr/rxtx/3/ Le mardi 26 juin 2007 ? 15:40 +0200, yves pielusenet a ?crit : > I have add the options '--enable-stdcall-fixup' to the > 'i586-mingw32msvc-ld' commande. Now I have no warning. But the JVM > always crashes :( The output seems more detailled, but I don't > understand anything... > Here is files : > http://yvespiel.free.fr/rxtx/2/ > From netbeans at gatworks.com Fri Jun 1 05:38:50 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 07:38:50 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <465F7ADD.1010501@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> Message-ID: <4660054A.2040202@gatworks.com> Manuel Naranjo wrote: In the case of my module, you can > unplug the device but it will not delete the symlink until those apps > that had opened the port has closed it. This is done this way to avoid > kernel panics. What does this mean to user code ? I have tried the alternate route ( other than closing ) which is sleep inbetween the I/O errors ( an unplugged USB device). When the device is plugged back in, The writes to the device still get an I/O error. This would seem to be a lost cause for the application. From netbeans at gatworks.com Fri Jun 1 06:35:48 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 08:35:48 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <465F7ADD.1010501@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> Message-ID: <466012A4.90608@gatworks.com> Manuel Naranjo wrote: In the case of my module, you can > unplug the device but it will not delete the symlink until those apps > that had opened the port has closed it. T Did u also mean for this to happen? USB0 was not closed by application. Apparently USB1 got created when USB device was plugged back in. There is only one USB device on a 4 port USB hub. This also seems to suggest that application recovery to be impossible. > Jun 1 07:10:08 mylaptop kernel: garmin_gps 1-1.4:1.0: Garmin GPS usb/tty converter detected > Jun 1 07:10:08 mylaptop kernel: usb 1-1.4: Garmin GPS usb/tty converter now attached to ttyUSB0 > Jun 1 07:15:17 mylaptop kernel: usb 1-1: USB disconnect, address 4 > Jun 1 07:15:17 mylaptop kernel: usb 1-1.4: USB disconnect, address 5 > Jun 1 07:15:17 mylaptop kernel: garmin_gps 1-1.4:1.0: device disconnected > Jun 1 07:15:26 mylaptop kernel: usb 1-1: new full speed USB device using uhci_hcd and address 6 > Jun 1 07:15:26 mylaptop kernel: hub 1-1:1.0: USB hub found > Jun 1 07:15:26 mylaptop kernel: hub 1-1:1.0: 4 ports detected > Jun 1 07:15:27 mylaptop kernel: usb 1-1.4: new full speed USB device using uhci_hcd and address 7 > Jun 1 07:15:27 mylaptop kernel: garmin_gps 1-1.4:1.0: Garmin GPS usb/tty converter detected > Jun 1 07:15:27 mylaptop kernel: usb 1-1.4: Garmin GPS usb/tty converter now attached to ttyUSB1 From naranjo.manuel at gmail.com Fri Jun 1 09:17:22 2007 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Fri, 01 Jun 2007 12:17:22 -0300 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <466012A4.90608@gatworks.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> <466012A4.90608@gatworks.com> Message-ID: <46603882.5050701@gmail.com> Uncle George escribi?: > Manuel Naranjo wrote: > In the case of my module, you can > >> unplug the device but it will not delete the symlink until those apps >> that had opened the port has closed it. T >> > > Did u also mean for this to happen? USB0 was not closed by application. > > Apparently USB1 got created when USB device was plugged back in. There > is only one USB device on a 4 port USB hub. > > This also seems to suggest that application recovery to be impossible. > Exactly there's a dead symlink (you can read and write to it and nothing will happen) and a new port will be created when a new device is connencted. From netbeans at gatworks.com Fri Jun 1 10:20:46 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 12:20:46 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <46603882.5050701@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> <466012A4.90608@gatworks.com> <46603882.5050701@gmail.com> Message-ID: <4660475E.5090202@gatworks.com> Not sure what u mean by "symlink". U cant read/write to it anymore. U get I/O error. In this scenario the device effectively went dead, and only solution is to close the channel. reconnecting the USB device, although dead, but not closed, will create a second device. This does not seem to be a desirable side-effect. The user will now have ttyUSB1, wondering where did ttyUSB0 go to. The application will also be in a confused state, as well as RXTX, because RXTX wont know about ttyUSB1. Manuel Naranjo wrote: > Uncle George escribi?: >> Manuel Naranjo wrote: >> In the case of my module, you can >> >>> unplug the device but it will not delete the symlink until those apps >>> that had opened the port has closed it. T >>> >> Did u also mean for this to happen? USB0 was not closed by application. >> >> Apparently USB1 got created when USB device was plugged back in. There >> is only one USB device on a 4 port USB hub. >> >> This also seems to suggest that application recovery to be impossible. >> > Exactly there's a dead symlink (you can read and write to it and nothing > will happen) and a new port will be created when a new device is connencted. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From arnab.bhaumik at gmail.com Mon Jun 4 01:40:16 2007 From: arnab.bhaumik at gmail.com (arnab bhaumik) Date: Mon, 4 Jun 2007 13:10:16 +0530 Subject: [Rxtx] full duplex com port with rxtx Message-ID: hi , till now i did half duplex communication with rxtx package on com package. my question is : is it possible to use com port with full duplex mode with rxtx package . ther is example of SimpleRead class and SimpleWrite class. it is clear that if i can use both the class simultaneously then full duplex is possible......... arnab/vu2bpw -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070604/6edb0453/attachment-0007.html From lists at iDIAcomputing.com Mon Jun 4 07:53:17 2007 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Mon, 04 Jun 2007 09:53:17 -0400 Subject: [Rxtx] full duplex com port with rxtx In-Reply-To: References: Message-ID: <4664194D.90301@iDIAcomputing.com> arnab bhaumik wrote: > hi , > > till now i did half duplex communication with rxtx package on com > package. > > my question is : is it possible to use com port with full duplex mode > with rxtx package . > > > ther is example of SimpleRead class and SimpleWrite class. it is > clear that if i can use both the class simultaneously then full duplex > is possible......... I haven't looked at the SimpleRead and SimpleWrite classes (I originally wrote my code for the javax.comm api), but full duplex is certainly possible. My CommReader class requires an object analogous to a OutputStream or Writer. When started, it spawns a thread that reads the comm port and writes to that output device. In this way the input is asynchronous and dependent on the actual input data. For full duplex, I extend that class with CommReaderWriter, which adds synchronous output methods. Hope that helps, George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From supsoop at hotmail.com Mon Jun 4 15:21:06 2007 From: supsoop at hotmail.com (soop soop) Date: Mon, 04 Jun 2007 21:21:06 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- Message-ID: Hi Guys, Looked through the archives but still cannot figure this out. I have a Motorola G24 GPRS/GSM modem that I am connecting to my server running Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not detecting the port, CommPortIdentifier.getPortIdentifiers(). I have added the line to RXTXCommDriver: "ttyACM" // for USB Modems Rxtx still does not seem to find the port. Is there something I am missing to make this port visable? [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control Model driver for USB modems and ISDN adapters I really need your help as I have moved my server from windows to Linux and have been down for a few days because of this .. Thanks so much! _________________________________________________________________ PC Magazine’s 2007 editors’ choice for best Web mail—award-winning Windows Live Hotmail. http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 From tjarvi at qbang.org Mon Jun 4 16:17:35 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Jun 2007 16:17:35 -0600 (MDT) Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: On Mon, 4 Jun 2007, soop soop wrote: > Hi Guys, > > Looked through the archives but still cannot figure this out. I have a > Motorola G24 GPRS/GSM modem that I am connecting to my server running Ubuntu. > I can see my modem as is shows up as ttyACM0, but RXTX is not detecting the > port, CommPortIdentifier.getPortIdentifiers(). > > I have added the line to RXTXCommDriver: > > "ttyACM" // for USB Modems > > Rxtx still does not seem to find the port. Is there something I am missing to > make this port visable? > > [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver > [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device > [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control Model > driver for USB modems and ISDN adapters > > I really need your help as I have moved my server from windows to Linux and > have been down for a few days because of this .. Thanks so much! > You could try the INSTALL documentation that comes with the source for possible solutions. Those usually involve lockfile creation, permissions on the device file or the device is in use by another application (even another session of your application). The usual commands: ls -l /dev/ttyACM0 fuser /dev/ttyACM0 touch /var/lock/LCK.testfile && rm -f /var/lock/LCK.testfile whoami To disable lockfiles: ../configure --disable-lockfiles && make install -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Jun 4 16:22:52 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 04 Jun 2007 18:22:52 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <466490BC.3090801@gatworks.com> soop soop wrote: > I really need your help as I have moved my server from windows to Linux > and have been down for a few days because of this .. Thanks so much! can u open the device ? ie is the file protection/permissions keeping you out? From supsoop at hotmail.com Mon Jun 4 16:44:40 2007 From: supsoop at hotmail.com (soop soop) Date: Mon, 04 Jun 2007 22:44:40 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <466490BC.3090801@gatworks.com> Message-ID: Thanks for the reply, I see no exceptions being thrown, just no detection of the port whats so ever. I will run rxtx in debug mode and log. If this were a permissions issue would I not see some exceptions being thrown? >From: Uncle George >Reply-To: RXTX Developers and Users >To: RXTX Developers and Users >Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >Date: Mon, 04 Jun 2007 18:22:52 -0400 > >soop soop wrote: > > > I really need your help as I have moved my server from windows to Linux > > and have been down for a few days because of this .. Thanks so much! > >can u open the device ? ie is the file protection/permissions keeping >you out? >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ Get a preview of Live Earth, the hottest event this summer - only on MSN http://liveearth.msn.com?source=msntaglineliveearthhm From netbeans at gatworks.com Mon Jun 4 17:06:15 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 04 Jun 2007 19:06:15 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <46649AE7.10405@gatworks.com> Exceptions on what? On startup it wants to lookup all devices in /dev that it is capable of opening ( within the list of specific 'comm' devices ). If it cannot open, then does not get onto list. Part of this process, if configured, will also test if the "LOCK" schema can also be opened for the device. then it gets on the list of avail comm port. soop soop wrote: > Thanks for the reply, > > I see no exceptions being thrown, just no detection of the port whats so > ever. I will run rxtx in debug mode and log. If this were a permissions > issue would I not see some exceptions being thrown? > > >> From: Uncle George >> Reply-To: RXTX Developers and Users >> To: RXTX Developers and Users >> Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >> Date: Mon, 04 Jun 2007 18:22:52 -0400 >> >> soop soop wrote: >> >>> I really need your help as I have moved my server from windows to Linux >>> and have been down for a few days because of this .. Thanks so much! >> can u open the device ? ie is the file protection/permissions keeping >> you out? >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _________________________________________________________________ > Get a preview of Live Earth, the hottest event this summer - only on MSN > http://liveearth.msn.com?source=msntaglineliveearthhm > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From alex.flint at gmail.com Mon Jun 4 21:31:49 2007 From: alex.flint at gmail.com (Alex Flint) Date: Tue, 5 Jun 2007 13:01:49 +0930 Subject: [Rxtx] random EXCEPTION_ACCESS_VIOLATION errors Message-ID: Hi All, I'm running winXP and RXTX 2.1-7r2 (the latest from the webpage as of June 2007). I'm sending sequences of 64 lines (each line has about 15 chars) at various intervals. The strings are sent fine, until I get the following error (from hs_err_pid3316.log, at the end of this email). What can I do to avoid the error? Obviously this is a low-level memory exception, but is there any way I can keep the JVM running after such an error? I noticed the exact same problem here: http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20070129/1180520.html Cheers, Alex # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x100034fb, pid=3316, tid=2400 # # Java VM: Java HotSpot(TM) Client VM (1.6.0_01-b06 mixed mode, sharing) # Problematic frame: # C [rxtxSerial.dll+0x34fb] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # --------------- T H R E A D --------------- Current thread (0x00386400): JavaThread "main" [_thread_in_native, id=2400] siginfo: ExceptionCode=0xc0000005, reading address 0x20726f78 Registers: EAX=0x20726f20, EBX=0x6d8922c0, ECX=0x00000005, EDX=0x20726f20 ESP=0x003efa30, EBP=0x003efb68, ESI=0x269728a0, EDI=0x00386400 EIP=0x100034fb, EFLAGS=0x00010212 Top of Stack: (sp=0x003efa30) 0x003efa30: 003efa3c 003efa64 0000000f ffffffff 0x003efa40: 003efa40 2a97f808 003efa6c 2b190ca8 0x003efa50: 00000000 2b190ec0 003efa90 008e2dd7 0x003efa60: 003efa90 008e2dd7 26977f88 6d815e72 0x003efa70: 00000004 2696eae0 0000008a 003efb0c 0x003efa80: 6d852b4a 2696eae0 00000003 26970930 0x003efa90: 000000cb 2696eae0 6d86b264 00385d40 0x003efaa0: 0000003f 003efb0c 26977f90 2ace65d8 Instructions: (pc=0x100034fb) 0x100034eb: ff ff 8d 76 00 eb 02 89 f6 90 8b 45 f8 8b 55 f8 0x100034fb: 8b 4a 58 83 c9 04 89 48 58 83 c4 f8 8b 45 f8 8b Stack: [0x003a0000,0x003f0000), sp=0x003efa30, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x34fb] Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j gnu.io.RXTXPort.writeArray([BIIZ)V+0 j gnu.io.RXTXPort$SerialOutputStream.write([B)V+76 j com.bjt.media.server.CommLink.send(Ljava/lang/String;)V+48 j com.bjt.media.server.DigitoolConnection.select(I)V+73 j com.bjt.media.server.DigitoolConnection.main([Ljava/lang/String;)V+74 v ~StubRoutines::call_stub --------------- P R O C E S S --------------- Java Threads: ( => current thread ) 0x02a69400 JavaThread "Thread-0" [_thread_in_native, id=3052] 0x02a4d000 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=3920] 0x02a48400 JavaThread "CompilerThread0" daemon [_thread_blocked, id=1968] 0x02a47400 JavaThread "Attach Listener" daemon [_thread_blocked, id=2984] 0x02a46400 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=2660] 0x02a41c00 JavaThread "Finalizer" daemon [_thread_blocked, id=3924] 0x02a3d800 JavaThread "Reference Handler" daemon [_thread_blocked, id=4008] =>0x00386400 JavaThread "main" [_thread_in_native, id=2400] Other Threads: 0x02a34400 VMThread [id=3708] 0x02a4e800 WatcherThread [id=3964] VM state:not at safepoint (normal execution) VM Mutex/Monitor currently owned by a thread: None Heap def new generation total 960K, used 131K [0x22960000, 0x22a60000, 0x22e40000) eden space 896K, 7% used [0x22960000, 0x22970ea8, 0x22a40000) from space 64K, 99% used [0x22a50000, 0x22a5fff8, 0x22a60000) to space 64K, 0% used [0x22a40000, 0x22a40000, 0x22a50000) tenured generation total 4096K, used 76K [0x22e40000, 0x23240000, 0x26960000) the space 4096K, 1% used [0x22e40000, 0x22e53060, 0x22e53200, 0x23240000) compacting perm gen total 12288K, used 137K [0x26960000, 0x27560000, 0x2a960000) the space 12288K, 1% used [0x26960000, 0x26982518, 0x26982600, 0x27560000) ro space 8192K, 62% used [0x2a960000, 0x2ae5e4e8, 0x2ae5e600, 0x2b160000) rw space 12288K, 52% used [0x2b160000, 0x2b7a0e78, 0x2b7a1000, 0x2bd60000) Dynamic libraries: 0x00400000 - 0x00423000 C:\Program Files\Java\jre1.6.0_01\bin\javaw.exe 0x7c900000 - 0x7c9b0000 C:\WINDOWS\system32\ntdll.dll 0x7c800000 - 0x7c8f4000 C:\WINDOWS\system32\kernel32.dll 0x77dd0000 - 0x77e6b000 C:\WINDOWS\system32\ADVAPI32.dll 0x77e70000 - 0x77f01000 C:\WINDOWS\system32\RPCRT4.dll 0x7e410000 - 0x7e4a0000 C:\WINDOWS\system32\USER32.dll 0x77f10000 - 0x77f57000 C:\WINDOWS\system32\GDI32.dll 0x76390000 - 0x763ad000 C:\WINDOWS\system32\IMM32.DLL 0x7c340000 - 0x7c396000 C:\Program Files\Java\jre1.6.0_01\bin\msvcr71.dll 0x6d7c0000 - 0x6da07000 C:\Program Files\Java\jre1.6.0_01\bin\client\jvm.dll 0x76b40000 - 0x76b6d000 C:\WINDOWS\system32\WINMM.dll 0x5cd70000 - 0x5cd77000 C:\WINDOWS\system32\serwvdrv.dll 0x5b0a0000 - 0x5b0a7000 C:\WINDOWS\system32\umdmxfrm.dll 0x6d310000 - 0x6d318000 C:\Program Files\Java\jre1.6.0_01\bin\hpi.dll 0x76bf0000 - 0x76bfb000 C:\WINDOWS\system32\PSAPI.DLL 0x6d770000 - 0x6d77c000 C:\Program Files\Java\jre1.6.0_01\bin\verify.dll 0x6d3b0000 - 0x6d3cf000 C:\Program Files\Java\jre1.6.0_01\bin\java.dll 0x6d7b0000 - 0x6d7bf000 C:\Program Files\Java\jre1.6.0_01\bin\zip.dll 0x10000000 - 0x10012000 C:\Documents and Settings\Alex\workspace\MediaServer\rxtxSerial.dll 0x73d90000 - 0x73db7000 C:\WINDOWS\system32\crtdll.dll VM Arguments: jvm_args: -Djava.library.path=C:\Documents and Settings\Alex\workspace\MediaServer java_command: com.bjt.media.server.DigitoolConnection Launcher Type: SUN_STANDARD Environment Variables: CLASSPATH=.;C:\Program Files\Java\j2re1.4.2_07\lib\ext\QTJava.zip PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\wbem;c:\applications\php;C:\Program Files\MATLAB\R2006a\bin\win32;C:\Roger\Projects\UAV\Bin\Debug;C:\Program Files\Microsoft SQL Server\80\Tools\Binn\;c:\Program Files\Microsoft SQL Server\90\Tools\binn\;C:\Program Files\QuickTime\QTSystem\;C:\Pfps\system;C:\Program Files\Java\jdk1.6.0_01\bin;C:\Program Files\Java\jdk1.6.0_01\jre\bin USERNAME=Alex OS=Windows_NT PROCESSOR_IDENTIFIER=x86 Family 15 Model 4 Stepping 1, GenuineIntel --------------- S Y S T E M --------------- OS: Windows XP Build 2600 Service Pack 2 CPU:total 1 family 15, cmov, cx8, fxsr, mmx, sse, sse2 Memory: 4k page, physical 1046508k(275288k free), swap 2522816k(1909176k free) vm_info: Java HotSpot(TM) Client VM (1.6.0_01-b06) for windows-x86, built on Mar 14 2007 00:24:02 by "java_re" with unknown MS VC++:1310 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070604/c87ae1f0/attachment-0007.html From alwyn.schoeman at gmail.com Tue Jun 5 00:10:19 2007 From: alwyn.schoeman at gmail.com (Alwyn Schoeman) Date: Tue, 5 Jun 2007 08:10:19 +0200 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Hi, I'm using a similar modem. By default rxtx doesn't look for devices that start with ACM, so you need to modify the source code and recompile. Look in RXTXCommDriver and add values for ACM in the registerScannedPorts method in the Linux specific parts. Look for osName.equals("Linux")... On 6/4/07, soop soop wrote: > > Hi Guys, > > Looked through the archives but still cannot figure this out. I have a > Motorola G24 GPRS/GSM modem that I am connecting to my server running > Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not > detecting the port, CommPortIdentifier.getPortIdentifiers(). > > I have added the line to RXTXCommDriver: > > "ttyACM" // for USB Modems > > Rxtx still does not seem to find the port. Is there something I am missing > to make this port visable? > > [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver > [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device > [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control > Model > driver for USB modems and ISDN adapters > > I really need your help as I have moved my server from windows to Linux > and > have been down for a few days because of this .. Thanks so much! > > _________________________________________________________________ > PC Magazine's 2007 editors' choice for best Web mail?award-winning Windows > Live Hotmail. > > http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -- Alwyn Schoeman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/b6cb3053/attachment-0007.html From naranjo.manuel at gmail.com Tue Jun 5 06:48:45 2007 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Tue, 05 Jun 2007 09:48:45 -0300 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> References: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Message-ID: <46655BAD.7010501@gmail.com> That's right, an easier solution is creating symlinks to acm. For example make ttyS70 to 79 point to ACM0 to 9 and that will help you a lot, and doesn't even require compile. > Hi, > > I'm using a similar modem. By default rxtx doesn't look for devices > that start with ACM, so you need to modify the > source code and recompile. > > Look in RXTXCommDriver and add values for ACM in the > registerScannedPorts method in the Linux specific parts. Look for > osName.equals("Linux")... > From juanemc2 at gmail.com Tue Jun 5 07:02:43 2007 From: juanemc2 at gmail.com (Juan) Date: Tue, 5 Jun 2007 10:02:43 -0300 Subject: [Rxtx] Problems with Epson TMU220B POSPrinter using XON/XOFF Flow Control and rxtx jar and dll's with the serial port. Message-ID: Hi!, I?m having trouble printing to the serial port using the latest version of rxtx jar and dll's with an Epson POSPrinter. I`ve switched the printer to work with XON/XOFF Flow Control and have watched the serial port to be sure the printer is sending the XON XOFF stop and go characters. I`ve setted the port like this: CommPortIdentifier commPortIdentifier = CommPortIdentifier.* getPortIdentifier*(_portName); SerialPort serialPort = (SerialPort)commPortIdentifier.open(*this*.getClass().getName(), 2000); serialPort.setSerialPortParams(_baudRate, _dataBits, _stopBits, _parity); serialPort.setFlowControlMode( SerialPort.*FLOWCONTROL_XONXOFF_IN* | SerialPort.*FLOWCONTROL_XONXOFF_OUT*); where the baudRate is 9600 the dataBits is 8 the stopBits is 1 and the parity is 0 It seems as the library isn`t taking into account the XON XOFF setting. I would like to know if I`m setting correctly the Flow Control and if you had had any experiences using XON XOFF flow control and could give me some help to solve my problem. I`m very thankful in advance, Yours, Juan Polero -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/b080995a/attachment-0007.html From ehdez.correo at gmail.com Tue Jun 5 07:12:53 2007 From: ehdez.correo at gmail.com (=?ISO-8859-1?Q?Enrique_Hern=E1ndez?=) Date: Tue, 5 Jun 2007 09:12:53 -0400 Subject: [Rxtx] problem with rxtx Message-ID: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Hello: I doing a simple test to show the serial ports. This is the code: import java.util.Enumeration; import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; public class Show { private Enumeration portList; private CommPortIdentifier portId; private SerialPort port; /** Creates a new instance of Show */ public Show() { } public static void main(String args[]){ Show show = new Show(); show.portList = CommPortIdentifier.getPortIdentifiers(); String tPort = ""; System.out.println("========================================="); while(show.portList.hasMoreElements()){ show.portId = (CommPortIdentifier)show.portList.nextElement(); if(show.portId.getPortType() == CommPortIdentifier.PORT_SERIAL) tPort = "Serial"; else tPort = "Parallel"; System.out.println(show.portId.getName() + " " + tPort); } } } whit The problem is that this code not show the serial ports, this show the no use serial ports. I want to connect whit the modem but when windows open and connect the modem my application don't see the port(COMM3) when it is connect. what I can do? Is that the correct way to know the ports? thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/eedd744b/attachment-0007.html From ehdez.correo at gmail.com Tue Jun 5 07:42:13 2007 From: ehdez.correo at gmail.com (=?ISO-8859-1?Q?Enrique_Hern=E1ndez?=) Date: Tue, 5 Jun 2007 09:42:13 -0400 Subject: [Rxtx] serial port Message-ID: <4a814e1f0706050642p4ce9ac7bka80f9479c524c5ea@mail.gmail.com> Hello: How I can ask to the port what device is connect and information about this device. thanks. bye. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/4d10d26a/attachment-0007.html From supsoop at hotmail.com Tue Jun 5 09:29:00 2007 From: supsoop at hotmail.com (soop soop) Date: Tue, 05 Jun 2007 15:29:00 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Message-ID: Hi Guys, Thanks for all your help. I found the problem. I created a user, Tomcat55, for my tomcat but it did not belong to any group. I then added this user to dialout group to have access to the device ttyACM0. Works perfectly! Again permissions was the issue. This also seems to be persistent as a server reboot does not effect the access. Cheers! >From: "Alwyn Schoeman" >Reply-To: RXTX Developers and Users >To: "RXTX Developers and Users" >Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >Date: Tue, 5 Jun 2007 08:10:19 +0200 > >Hi, > >I'm using a similar modem. By default rxtx doesn't look for devices that >start with ACM, so you need to modify the >source code and recompile. > >Look in RXTXCommDriver and add values for ACM in the registerScannedPorts >method in the Linux specific parts. Look for osName.equals("Linux")... > >On 6/4/07, soop soop wrote: >> >>Hi Guys, >> >>Looked through the archives but still cannot figure this out. I have a >>Motorola G24 GPRS/GSM modem that I am connecting to my server running >>Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not >>detecting the port, CommPortIdentifier.getPortIdentifiers(). >> >>I have added the line to RXTXCommDriver: >> >>"ttyACM" // for USB Modems >> >>Rxtx still does not seem to find the port. Is there something I am missing >>to make this port visable? >> >>[ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver >>[ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device >>[ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control >>Model >>driver for USB modems and ISDN adapters >> >>I really need your help as I have moved my server from windows to Linux >>and >>have been down for a few days because of this .. Thanks so much! >> >>_________________________________________________________________ >>PC Magazine's 2007 editors' choice for best Web mail—award-winning Windows >>Live Hotmail. >> >>http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 >> >> >>_______________________________________________ >>Rxtx mailing list >>Rxtx at qbang.org >>http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > >-- >Alwyn Schoeman >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ Need a break? Find your escape route with Live Search Maps. http://maps.live.com/default.aspx?ss=Restaurants~Hotels~Amusement%20Park&cp=33.832922~-117.915659&style=r&lvl=13&tilt=-90&dir=0&alt=-1000&scene=1118863&encType=1&FORM=MGAC01 From netbeans at gatworks.com Tue Jun 5 09:42:31 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 11:42:31 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <46658467.20101@gatworks.com> soop soop wrote: > > Hi Guys, > > Thanks for all your help. I found the problem. I created a user, > Tomcat55, for my tomcat but it did not belong to any group. I then added Look at man pages for the program udev. From tjarvi at qbang.org Tue Jun 5 18:18:17 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Jun 2007 18:18:17 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Message-ID: On Tue, 5 Jun 2007, Enrique Hern?ndez wrote: > The problem is that this code not show the serial ports, this show the no > use serial ports. I want to connect whit the modem but when windows open and > connect the modem my application don't see the port(COMM3) when it is > connect. > what I can do? > Is that the correct way to know the ports? > Hello, We may have problems understanding each other. On windows, the port will not be an available serial port if another application has the port open. That is just how the library behaves. If you can not see the port in the enumerated list, you could not open it. Also note that enumeration only happens once. If you add a port such as a new USB dongle, the port will not be visible until the next time your application runs. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Tue Jun 5 18:45:01 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 20:45:01 -0400 Subject: [Rxtx] problem with rxtx In-Reply-To: References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Message-ID: <4666038D.8090700@gatworks.com> Trent Jarvi wrote: > > > Also note that enumeration only happens once. If you add a port such as > a new USB dongle, the port will not be visible until the next time your > application runs. Is this written in stone ? somewhere? From tjarvi at qbang.org Tue Jun 5 18:54:36 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Jun 2007 18:54:36 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <4666038D.8090700@gatworks.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> Message-ID: On Tue, 5 Jun 2007, Uncle George wrote: > Trent Jarvi wrote: >> >> >> Also note that enumeration only happens once. If you add a port such as >> a new USB dongle, the port will not be visible until the next time your >> application runs. > > Is this written in stone ? somewhere? It is just the current behavior. There is nothing preventing a fix that allows reenumeration. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Tue Jun 5 19:55:19 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 21:55:19 -0400 Subject: [Rxtx] problem with rxtx In-Reply-To: References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> Message-ID: <46661407.4020308@gatworks.com> >> Is this written in stone ? somewhere? > > It is just the current behavior. There is nothing preventing a fix that > allows reenumeration. With usb, ..... , things come and go. Seems a shame that you have to kill application to get at the device u just plugged in. From joachim at buechse.ch Wed Jun 6 01:50:06 2007 From: joachim at buechse.ch (Joachim Buechse) Date: Wed, 6 Jun 2007 09:50:06 +0200 Subject: [Rxtx] problem with rxtx In-Reply-To: <46661407.4020308@gatworks.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> <46661407.4020308@gatworks.com> Message-ID: <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> On MacOS RXTX's enumeration handling is more flexible. It will find new ports that are added during the lifetime of the application. But this is inherently incompatible with suns javax.comm implementation... Regards, Joachim On 06.06.2007, at 03:55, Uncle George wrote: > >>> Is this written in stone ? somewhere? >> >> It is just the current behavior. There is nothing preventing a >> fix that >> allows reenumeration. > > With usb, ..... , things come and go. Seems a shame that you have to > kill application to get at the device u just plugged in. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Jun 6 06:06:48 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Jun 2007 06:06:48 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> <46661407.4020308@gatworks.com> <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> Message-ID: Sun's javax.comm is not a major concern going forward. As long as we do not break old applications using rxtx, I see no reason to limit rxtx to that convention. We have already rejected version 3 from Sun as a dead end and limited our compatability to version 2. That does not mean we will not try to work with Sun and others but the current javax.comm convention (v3) is not a well conceived path. There has been discussion about doing a JSR which is one valid option. On Wed, 6 Jun 2007, Joachim Buechse wrote: > On MacOS RXTX's enumeration handling is more flexible. It will find > new ports that are added during the lifetime of the application. But > this is inherently incompatible with suns javax.comm implementation... > > Regards, > Joachim > > On 06.06.2007, at 03:55, Uncle George wrote: > >> >>>> Is this written in stone ? somewhere? >>> >>> It is just the current behavior. There is nothing preventing a >>> fix that >>> allows reenumeration. >> >> With usb, ..... , things come and go. Seems a shame that you have to >> kill application to get at the device u just plugged in. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From yvespielusenet at free.fr Wed Jun 6 08:46:35 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 16:46:35 +0200 Subject: [Rxtx] [PARALLEL] resource in use Message-ID: <1181141195.3407.20.camel@localhost.localdomain> Hello, I want to use rxtx in my application. I haveto send data to a very old printer (which have a drum and hammers http://perso.orange.fr/tiie/page00010017.html) This is printer is connecter with centronics. It works well but, while it's writting and I putthe printer off-line, after about 45 seconds, I have this error : ------------------------------------- java.io.IOException: La ressource demand?e est en cours d'utilisation. in writeArray at gnu.io.LPRPort.writeArray(Native Method) at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:292) at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:161) at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:156) at mce.buffer.bufferManager.BufferManager$PrintBuffer.run(BufferManager.java:141) The IOexception means "The wanted resource is in use" ------------------------------------- Here is the line 141 of BufferManager : ------------------------------------- while(send){ try{ fos.write(bb); <=== line 141 send = false; } catch(Exception e){ javax.swing.JOptionPane.showMessageDialog(null, "Erreur d'envoie. Veuillez cliquer sur OK pour relancer l'impression de la vignette.\nV?rifiez votre impression !", "Erreur d'envoie", javax.swing.JOptionPane.WARNING_MESSAGE); e.printStackTrace(System.err); System.err.flush(); System.out.println(e); send = true; } } -------------------------------- 'fos' is an outputstream which contains the rxtx stream (this.os is the rxtx outputstream) : -------------------------------- public void write(byte[] bb) throws IOException{ this.write(bb, 0, bb.length); } public void write(byte[] bb, int off, int len) throws IOException{ while(!imp1.isPrinterSelected() || !imp2.isPrinterSelected()){ } this.os.write(bb, off, len); } -------------------------------- Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( can you help me ? thank you :) -- yves piel From yvespielusenet at free.fr Wed Jun 6 09:11:15 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 17:11:15 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181141195.3407.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> Message-ID: <1181142675.3407.23.camel@localhost.localdomain> I forgot to tell that It's under windows XP and java 1.5. Le mercredi 06 juin 2007 ? 16:46 +0200, yves pielusenet a ?crit : > Hello, > I want to use rxtx in my application. I haveto send data to a very old > printer (which have a drum and hammers > http://perso.orange.fr/tiie/page00010017.html) > This is printer is connecter with centronics. It works well but, while > it's writting and I putthe printer off-line, after about 45 seconds, I > have this error : > ------------------------------------- > java.io.IOException: La ressource demand?e est en cours d'utilisation. > in writeArray > at gnu.io.LPRPort.writeArray(Native Method) > at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:292) > at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:161) > at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:156) > at mce.buffer.bufferManager.BufferManager$PrintBuffer.run(BufferManager.java:141) > > The IOexception means "The wanted resource is in use" > ------------------------------------- > > Here is the line 141 of BufferManager : > > ------------------------------------- > while(send){ > try{ > fos.write(bb); <=== line 141 > send = false; > } > catch(Exception e){ > javax.swing.JOptionPane.showMessageDialog(null, "Erreur d'envoie. Veuillez cliquer sur OK pour relancer l'impression de la vignette.\nV?rifiez votre impression !", "Erreur d'envoie", javax.swing.JOptionPane.WARNING_MESSAGE); > e.printStackTrace(System.err); > System.err.flush(); > System.out.println(e); > send = true; > } > } > -------------------------------- > 'fos' is an outputstream which contains the rxtx stream (this.os is the rxtx outputstream) : > > -------------------------------- > public void write(byte[] bb) throws IOException{ > this.write(bb, 0, bb.length); > } > public void write(byte[] bb, int off, int len) throws IOException{ > while(!imp1.isPrinterSelected() || !imp2.isPrinterSelected()){ > } > this.os.write(bb, off, len); > } > -------------------------------- > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > can you help me ? > > thank you :) > From netbeans at gatworks.com Wed Jun 6 09:21:46 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 11:21:46 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181141195.3407.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> Message-ID: <4666D10A.8000507@gatworks.com> } > -------------------------------- > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > can you help me ? > > thank you :) > windoz or linux? ( I guess windoz ) for windoz, there appears to be a timeout ( as Comments suggest ) of about 40seconds. > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } for linux, there is no implied timeout. > if( write( fd, bytes, count ) < 0 ) > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); From netbeans at gatworks.com Wed Jun 6 09:39:41 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 11:39:41 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666D10A.8000507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> Message-ID: <4666D53D.90000@gatworks.com> Uncle George wrote: > } >> -------------------------------- >> >> Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( >> >> can you help me ? From reading the code, I can see your concern. And it appears you are correct, because some of the data will be sent to the OS printer buffers, and then it will refuse to accept anymore. Unfortunately, writeArray does not return the num of characters written :{ So application has no idea to how many characters were accepted by the OS. I dont do windoz, so I cant say with absolute certainty what windoz will do with an off-line condition. If you have the source, and can compile, then maybe u can increase the loop count to hit 4hours? From yvespielusenet at free.fr Wed Jun 6 09:53:25 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 17:53:25 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666D10A.8000507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> Message-ID: <1181145205.3407.35.camel@localhost.localdomain> Thank you for your explanation :) This timeout comes when no data has been send to the printer after 40seconds if I well understand. But why there is such a timeout ? If I setthe printer offline while it's printing I mustn't have an exception. I don't understand why the "printer should solv all problems like buffer full" in 40 seconds. If I pause the printer the buffer will not be emptied, isn't it ? I not very familiar with C/C++, but it seem that the exception is thrown only when countWritten == 0, that means no data at all has been sent. So Is my code is good since when I intercept this exception I send all my buffer again. There is no way that the printer receive two times same bytes ? thanks ps: yes the application is running on windows XP since I developpe under Debian Le mercredi 06 juin 2007 ? 11:21 -0400, Uncle George a ?crit : > } > > -------------------------------- > > > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > > > can you help me ? > > > > thank you :) > > > > windoz or linux? ( I guess windoz ) > > for windoz, there appears to be a timeout ( as Comments suggest ) of > about 40seconds. > > while( count > 0 ){ > > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > > /* > > this are 20 * 2 seconds, in this time a printer (or other parallel device) > > should solv all problems like buffer full, etc > > */ > > if(errorCount++ < 20){ > > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > > continue; > > } > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > for linux, there is no implied timeout. > > if( write( fd, bytes, count ) < 0 ) > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Wed Jun 6 10:34:24 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 12:34:24 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181145205.3407.35.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> Message-ID: <4666E210.30507@gatworks.com> yves pielusenet wrote: > Thank you for your explanation :) > This timeout comes when no data has been send to the printer after > 40seconds if I well understand. But why there is such a timeout ? If I > setthe printer offline while it's printing I mustn't have an exception. > I don't understand why the "printer should solv all problems like buffer > full" in 40 seconds. If I pause the printer the buffer will not be > emptied, isn't it ? > > I not very familiar with C/C++, but it seem that the exception is thrown > only when countWritten == 0, that means no data at all has been sent. So > Is my code is good since when I intercept this exception I send all my > buffer again. There is no way that the printer receive two times same > bytes ? More technically, the function call returns and reports that 0 characters was written in this call. when 0 characters are written, it will check how many times 0 characters was written. If it has tried LESS than 20 times(errorCount), it will sleep() and try to write again. After 20 times, it wont sleep, but throw you the exception. Now suppose you are writing a 120 character line. you off-lined/paused your printer. The OS has room for 80 more characters in it's printer buffer. The WriteFile() will have a char count of 120, but on return the countWritten = 80. You still have 40 more characters to print. Since countWritten != 0, the counters: bytes += countWritten; count -= countWritten; get updated, and the Writefile now has a count of 40 characters. Since the printer is off-line, the countwritten is 0. And so the loop continues, till 40 seconds is up. As to why it is this way, i dont know ( not a windoz maven ); Also the sleep(20) in the loop is not so intuitive to suggest 2 seconds of sleep. I would have guessed 20seconds, or 20milliseconds. But go figure. BTW: Since your computer sends you error messages in French, does it curse in English? :)))) From yvespielusenet at free.fr Thu Jun 7 02:27:44 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Thu, 07 Jun 2007 10:27:44 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666E210.30507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> Message-ID: <1181204864.3501.10.camel@localhost.localdomain> Maybe in my case I should re-compile rxtx and change the code. Instead of send an exception I should display a dialog box to ask if it's printer problem or if it should trie to send bytes. Something like : while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } if(displayDialogBox("Try again to send datas ??")){ errorCount = 0; } else{ throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } } Le mercredi 06 juin 2007 ? 12:34 -0400, Uncle George a ?crit : > yves pielusenet wrote: > > Thank you for your explanation :) > > This timeout comes when no data has been send to the printer after > > 40seconds if I well understand. But why there is such a timeout ? If I > > setthe printer offline while it's printing I mustn't have an exception. > > I don't understand why the "printer should solv all problems like buffer > > full" in 40 seconds. If I pause the printer the buffer will not be > > emptied, isn't it ? > > > > I not very familiar with C/C++, but it seem that the exception is thrown > > only when countWritten == 0, that means no data at all has been sent. So > > Is my code is good since when I intercept this exception I send all my > > buffer again. There is no way that the printer receive two times same > > bytes ? > More technically, the function call returns and reports that 0 > characters was written in this call. > when 0 characters are written, it will check how many times 0 characters > was written. If it has tried LESS than 20 times(errorCount), it will > sleep() and try to write again. > After 20 times, it wont sleep, but throw you the exception. > > Now suppose you are writing a 120 character line. you off-lined/paused > your printer. The OS has room for 80 more characters in it's printer > buffer. The WriteFile() will have a char count of 120, but on return the > countWritten = 80. You still have 40 more characters to print. > Since countWritten != 0, the counters: > bytes += countWritten; > count -= countWritten; > get updated, and the Writefile now has a count of 40 characters. Since > the printer is off-line, the countwritten is 0. And so the loop > continues, till 40 seconds is up. > > As to why it is this way, i dont know ( not a windoz maven ); > Also the sleep(20) in the loop is not so intuitive to suggest 2 seconds > of sleep. I would have guessed 20seconds, or 20milliseconds. But go figure. > > BTW: Since your computer sends you error messages in French, does it > curse in English? :)))) > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 06:11:43 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 08:11:43 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181204864.3501.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> Message-ID: <4667F5FF.8070903@gatworks.com> your suggestion appears good. I dont know what displayDialogBox exactly will do, so all I can say it that it looks good. But I'd like to wait 10min before first dialog box And a 5 min wait for every dialog box there after. And since these are custom solution/choices, maybe a more exact explanation of what the issue is. if(errorCount++ < 300){ // wait 10min ( 10min * 60sec / 2 ) Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } if(displayDialogBox("Printer has Paused. Retry sending data?")){ errorCount = 150; // Wait for 5 min thereafter continue; } > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } yves pielusenet wrote: > Maybe in my case I should re-compile rxtx and change the code. Instead > of send an exception I should display a dialog box to ask if it's > printer problem or if it should trie to send bytes. Something like : > > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > > if(displayDialogBox("Try again to send datas ??")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > } > From yvespielusenet at free.fr Thu Jun 7 07:17:21 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Thu, 07 Jun 2007 15:17:21 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4667F5FF.8070903@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <4667F5FF.8070903@gatworks.com> Message-ID: <1181222241.3501.20.camel@localhost.localdomain> thank you :) 'displayDialogBox()' I think doesn't exist. It was just for the example :) But I think It should not be so complicated to display a dialog box under windows with YES/NO buttons. When yes is clicked it return 0 other it returns 1. Le jeudi 07 juin 2007 ? 08:11 -0400, Uncle George a ?crit : > your suggestion appears good. I dont know what displayDialogBox exactly > will do, so all I can say it that it looks good. > > But I'd like to wait 10min before first dialog box And a 5 min wait for > every dialog box there after. And since these are custom > solution/choices, maybe a more exact explanation of what the issue is. > > if(errorCount++ < 300){ // wait 10min ( 10min * 60sec / 2 ) > Sleep( 20 ); /* make a small pause to execute all other requests > in all other threads */ > continue; > } > > if(displayDialogBox("Printer has Paused. Retry sending data?")){ > errorCount = 150; // Wait for 5 min thereafter > continue; > } > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > > yves pielusenet wrote: > > Maybe in my case I should re-compile rxtx and change the code. Instead > > of send an exception I should display a dialog box to ask if it's > > printer problem or if it should trie to send bytes. Something like : > > > > while( count > 0 ){ > > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > > /* > > this are 20 * 2 seconds, in this time a printer (or other parallel device) > > should solv all problems like buffer full, etc > > */ > > if(errorCount++ < 20){ > > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > > continue; > > } > > > > if(displayDialogBox("Try again to send datas ??")){ > > errorCount = 0; > > } > > else{ > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > } > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 07:41:43 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 09:41:43 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181222241.3501.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <4667F5FF.8070903@gatworks.com> <1181222241.3501.20.camel@localhost.localdomain> Message-ID: <46680B17.8050109@gatworks.com> yves pielusenet wrote: > thank you :) > 'displayDialogBox()' I think doesn't exist. It was just for the > example :) too bad. Good luck. From rtrout at webbresearch.com Thu Jun 7 11:23:04 2007 From: rtrout at webbresearch.com (Robert Trout) Date: Thu, 07 Jun 2007 13:23:04 -0400 Subject: [Rxtx] Disconnected PortServer TS causes Java to hang Message-ID: <1181236984.14186.33.camel@sisyphus.DinkumSoftware.com> I'm running Linux with sun's Java 1.4.2, Java comm API 2.0, RXTX 2.0-7pre1, and the RealPort digi driver. "/dev/ttyrp00" is a RealPort device. My Java application never returns from a ComPortIdentifier.getPortIdentifier("/dev/ttyrp00") call while the Digi PortServer TS 4 is disconnected from the network. If I later re-connect the PortServer, the call returns about 30 seconds later (it's like a serial port read or write is blocking until the PortServer is re- connected). With the PortServer disconnected, minicom immediately responds with "cannot open /dev/ttyrp00: No such file or directory". I would like my Java application to behave similarly. That is, respond with an error condition instead of hanging when the PortServer is not connected. Since minicom and Java behave differently, I think this "hanging" behavior may be due to RXTX or Java? Has anyone had a similar issue? Solutions? Suggestions? Thanks, Robert From vicnevicne at gmail.com Thu Jun 7 12:16:02 2007 From: vicnevicne at gmail.com (Vicne) Date: Thu, 07 Jun 2007 20:16:02 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181204864.3501.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> Message-ID: <46684B62.7080802@gmail.com> yves pielusenet wrote: > Maybe in my case I should re-compile rxtx and change the code. Instead > of send an exception I should display a dialog box to ask if it's > printer problem or if it should trie to send bytes. Something like : > > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > > if(displayDialogBox("Try again to send datas ??")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > } > Sorry to step in without a specific solution to your problem, but I wanted to share my feeling regarding this proposal. AFAIK, it's generally considered bad practice to pop-up a prompt from a library. The main reason is that in general use, you can't guarantee that someone is actually present behind the console. Imagine a print server in a machine room, connected to a park of printers. In that case, when one printer fails, the logical behaviour would be to use an other one. If you change RxTx the way you propose, the printer queue will simply be stuck with a useless "Try again to send data ?" prompt until an administrator opens a remote connection to the print server's console and clicks "no". Second, it would create a dependency upon the existence of a graphical console (if you go the graphical "dialogBox" way). On many applications (typically server or embedded ones), the JVM is "headless" and if you try to pop-up a dialog, your app would throw an exception (at best) or just wouldn't display the prompt anywhere... Going the "text console" way is not more reliable, because on graphical environments, the text console is hidden unless explicitly requested. My advice would be to think again and find another solution. Ideas are : - make the number of retries a parameter so that you can tune it to what you think is reasonable - throw a more specific exception when the number of retries has been reached, so that a specific prompt can be shown at a higher level Anyway, if you feel that the prompt is the way to go in your case, I would at least make that prompt conditional. The least intrusive way would probably be using a system property, like if("true".equals(System.getProperty("org.rxtx.usePrompt")) && displayDialogBox("Retry sending data ?")){ errorCount = 0; } else{ throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } By default, the behaviour would remain as it is now, but you could force the prompts by defining the property at VM launch if desired. (for example : java.exe -Dorg.rxtx.usePrompt=true myApp) Also, you seemed to say you wanted the printer to start again exactly where is stopped. It would indeed be the best way when the printer is put offline for a few seconds. On the other hand, if the printer is turned off (or the printer runs out of paper, or someone steps on the mains cable), then the only way to go back to a "stable" situation would be by printing the item (page, label, etc.) again from scratch... Just my two cents. Vicne PS : By the way, the dialog box thing is very platform dependant on the C-side, and I think the simplest way would probably be to bridge it to a Java call where you can implement it like you proposed : public boolean displayDialogBox(prompt) { return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); } From netbeans at gatworks.com Thu Jun 7 14:08:24 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 16:08:24 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46684B62.7080802@gmail.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> Message-ID: <466865B8.4060004@gatworks.com> My feeling is that the code that was suggested was for his environs ( his shop ). The issue here is that after a 40+ second wait, an exception will be thrown. But you really dont have a way of 'cancelling' all the WriteFiles() that have already occured before the exception so that your writeArray and the Commapi can backtrack to a position in which they are in sync. The main ( really mine ) concern is not to lose data, or replicate data. After 40seconds, 300 seconds, 55min, no matter how long, data should not be lost or duplicated. But as soon as the exception is thrown, that possibility exists. Maybe an event should be thrown instead? Vicne wrote: > yves pielusenet wrote: >> Maybe in my case I should re-compile rxtx and change the code. Instead >> of send an exception I should display a dialog box to ask if it's >> printer problem or if it should trie to send bytes. Something like : >> >> while( count > 0 ){ >> if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ >> /* >> this are 20 * 2 seconds, in this time a printer (or other parallel device) >> should solv all problems like buffer full, etc >> */ >> if(errorCount++ < 20){ >> Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ >> continue; >> } >> >> if(displayDialogBox("Try again to send datas ??")){ >> errorCount = 0; >> } >> else{ >> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >> break; >> } >> } >> > > Sorry to step in without a specific solution to your problem, but I > wanted to share my feeling regarding this proposal. AFAIK, it's > generally considered bad practice to pop-up a prompt from a library. > The main reason is that in general use, you can't guarantee that > someone is actually present behind the console. Imagine a print server > in a machine room, connected to a park of printers. In that case, when > one printer fails, the logical behaviour would be to use an other one. > If you change RxTx the way you propose, the printer queue will simply be > stuck with a useless "Try again to send data ?" prompt until an > administrator opens a remote connection to the print server's console > and clicks "no". > Second, it would create a dependency upon the existence of a > graphical console (if you go the graphical "dialogBox" way). On many > applications (typically server or embedded ones), the JVM is "headless" > and if you try to pop-up a dialog, your app would throw an exception (at > best) or just wouldn't display the prompt anywhere... Going the "text > console" way is not more reliable, because on graphical environments, > the text console is hidden unless explicitly requested. > > My advice would be to think again and find another solution. Ideas are : > - make the number of retries a parameter so that you can tune it to what > you think is reasonable > - throw a more specific exception when the number of retries has been > reached, so that a specific prompt can be shown at a higher level > > Anyway, if you feel that the prompt is the way to go in your case, I > would at least make that prompt conditional. The least intrusive way > would probably be using a system property, like > > if("true".equals(System.getProperty("org.rxtx.usePrompt")) > && displayDialogBox("Retry sending data ?")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > > > By default, the behaviour would remain as it is now, but you could > force the prompts by defining the property at VM launch if desired. (for > example : java.exe -Dorg.rxtx.usePrompt=true myApp) > > > Also, you seemed to say you wanted the printer to start again > exactly where is stopped. It would indeed be the best way when the > printer is put offline for a few seconds. On the other hand, if the > printer is turned off (or the printer runs out of paper, or someone > steps on the mains cable), then the only way to go back to a "stable" > situation would be by printing the item (page, label, etc.) again from > scratch... > > > Just my two cents. > > > Vicne > > PS : By the way, the dialog box thing is very platform dependant on the > C-side, and I think the simplest way would probably be to bridge it to a > Java call where you can implement it like you proposed : > > public boolean displayDialogBox(prompt) { > return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", > JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); > } > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Thu Jun 7 17:48:11 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 Jun 2007 17:48:11 -0600 (MDT) Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <466865B8.4060004@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> Message-ID: An event is possible. I'm amazed this is the largest problem encountered while using the parallel code. How would the write ever exit if we throw events? Isn't this going to lead to hung applications? On Thu, 7 Jun 2007, Uncle George wrote: > My feeling is that the code that was suggested was for his environs ( > his shop ). > > The issue here is that after a 40+ second wait, an exception will be > thrown. But you really dont have a way of 'cancelling' all the > WriteFiles() that have already occured before the exception so that your > writeArray and the Commapi can backtrack to a position in which they are > in sync. > > The main ( really mine ) concern is not to lose data, or replicate data. > After 40seconds, 300 seconds, 55min, no matter how long, data should > not be lost or duplicated. But as soon as the exception is thrown, that > possibility exists. > > Maybe an event should be thrown instead? > > Vicne wrote: >> yves pielusenet wrote: >>> Maybe in my case I should re-compile rxtx and change the code. Instead >>> of send an exception I should display a dialog box to ask if it's >>> printer problem or if it should trie to send bytes. Something like : >>> >>> while( count > 0 ){ >>> if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ >>> /* >>> this are 20 * 2 seconds, in this time a printer (or other parallel device) >>> should solv all problems like buffer full, etc >>> */ >>> if(errorCount++ < 20){ >>> Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ >>> continue; >>> } >>> >>> if(displayDialogBox("Try again to send datas ??")){ >>> errorCount = 0; >>> } >>> else{ >>> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >>> break; >>> } >>> } >>> >> >> Sorry to step in without a specific solution to your problem, but I >> wanted to share my feeling regarding this proposal. AFAIK, it's >> generally considered bad practice to pop-up a prompt from a library. >> The main reason is that in general use, you can't guarantee that >> someone is actually present behind the console. Imagine a print server >> in a machine room, connected to a park of printers. In that case, when >> one printer fails, the logical behaviour would be to use an other one. >> If you change RxTx the way you propose, the printer queue will simply be >> stuck with a useless "Try again to send data ?" prompt until an >> administrator opens a remote connection to the print server's console >> and clicks "no". >> Second, it would create a dependency upon the existence of a >> graphical console (if you go the graphical "dialogBox" way). On many >> applications (typically server or embedded ones), the JVM is "headless" >> and if you try to pop-up a dialog, your app would throw an exception (at >> best) or just wouldn't display the prompt anywhere... Going the "text >> console" way is not more reliable, because on graphical environments, >> the text console is hidden unless explicitly requested. >> >> My advice would be to think again and find another solution. Ideas are : >> - make the number of retries a parameter so that you can tune it to what >> you think is reasonable >> - throw a more specific exception when the number of retries has been >> reached, so that a specific prompt can be shown at a higher level >> >> Anyway, if you feel that the prompt is the way to go in your case, I >> would at least make that prompt conditional. The least intrusive way >> would probably be using a system property, like >> >> if("true".equals(System.getProperty("org.rxtx.usePrompt")) >> && displayDialogBox("Retry sending data ?")){ >> errorCount = 0; >> } >> else{ >> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >> break; >> } >> >> >> By default, the behaviour would remain as it is now, but you could >> force the prompts by defining the property at VM launch if desired. (for >> example : java.exe -Dorg.rxtx.usePrompt=true myApp) >> >> >> Also, you seemed to say you wanted the printer to start again >> exactly where is stopped. It would indeed be the best way when the >> printer is put offline for a few seconds. On the other hand, if the >> printer is turned off (or the printer runs out of paper, or someone >> steps on the mains cable), then the only way to go back to a "stable" >> situation would be by printing the item (page, label, etc.) again from >> scratch... >> >> >> Just my two cents. >> >> >> Vicne >> >> PS : By the way, the dialog box thing is very platform dependant on the >> C-side, and I think the simplest way would probably be to bridge it to a >> Java call where you can implement it like you proposed : >> >> public boolean displayDialogBox(prompt) { >> return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", >> JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); >> } >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 19:18:51 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 21:18:51 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> Message-ID: <4668AE7B.3060409@gatworks.com> The UNIX version of writeArray is not too great either. It is possible that the write will only process some of the bytes. #else if( write( fd, bytes, count ) < 0 ) throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); #endif -------------------------------- Maybe it might be better to have the native function inform the caller of the # of characters written, then the commapi/output-buffer can be modified to reflect the #of chars written. If an exception is to be thrown, for too many loops of chars written == 0, then exception wont affect the state of the output buffer. Then a ParallelPort.restart() can be called to resume printing whats in the buffer. Trent Jarvi wrote: > An event is possible. I'm amazed this is the largest problem encountered > while using the parallel code. > > How would the write ever exit if we throw events? Isn't this going to > lead to hung applications? Sure. If you dont time out, then there is nothing that will force an EXIT from the write(). Issue is what has the OS done with the write. > > On Thu, 7 Jun 2007, Uncle George wrote: > >> My feeling is that the code that was suggested was for his environs ( >> his shop ). From yvespielusenet at free.fr Fri Jun 8 01:09:01 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Fri, 08 Jun 2007 09:09:01 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4668AE7B.3060409@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> Message-ID: <1181286541.3674.10.camel@localhost.localdomain> It is not possible that the rxtx java method write(byte[], int offset, int length) return anint which contains the number of byte really send to the printer instead of an exception ? So this is the programm which will see if all bytes have been sent. If not it can retry to send the unsended bytes. -------------------------------------------------------- int sended = 0; while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ sended += countWritten; /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } return sended; /*throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break;*/ } ... ... return countWritten; ------------------------------------------------ Le jeudi 07 juin 2007 ? 21:18 -0400, Uncle George a ?crit : > The UNIX version of writeArray is not too great either. It is possible > that the write will only process some of the bytes. > > #else > if( write( fd, bytes, count ) < 0 ) > throw_java_exception_system_msg( env, IO_EXCEPTION, > "writeArray" ); > #endif > -------------------------------- > > Maybe it might be better to have the native function inform the caller > of the # of characters written, then the commapi/output-buffer can be > modified to reflect the #of chars written. If an exception is to be > thrown, for too many loops of chars written == 0, then exception wont > affect the state of the output buffer. Then a ParallelPort.restart() can > be called to resume printing whats in the buffer. > > > Trent Jarvi wrote: > > An event is possible. I'm amazed this is the largest problem encountered > > while using the parallel code. > > > > How would the write ever exit if we throw events? Isn't this going to > > lead to hung applications? > Sure. If you dont time out, then there is nothing that will force an > EXIT from the write(). Issue is what has the OS done with the write. > > > > On Thu, 7 Jun 2007, Uncle George wrote: > > > >> My feeling is that the code that was suggested was for his environs ( > >> his shop ). > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Fri Jun 8 03:45:00 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 11:45:00 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181286541.3674.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> Message-ID: <20070608094500.GC21069@elberon.bln.de.ingenico.com> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > It is not possible that the rxtx java method write(byte[], int offset, > int length) return anint which contains the number of byte really send > to the printer instead of an exception ? > So this is the programm which will see if all bytes have been sent. If > not it can retry to send the unsended bytes. I think write() is void because in Java people love to do this since OutputStream :-) Of course on such interfaces you cannot implement something nice. If you would have a int write, you would not implement the interface and no applications expecting this interface would link/work/compile. oki, Steffen P.S.: (OT) If you propose not to implement the Java interfaces (especially not on JNI level), maybe optionally offering a wrapper that removes e.g. the write return value and so on to downgrade the powerful classic old POSIX read/write style to the modern limited Java style, then I agree :-) Same for read. Instead of things like "int avialable()" it is more powerful to have an approach as select(2) offers (to guarante the caller that read/write will not block [nothing else make sense anyway IMHO] but may read/write less bytes then requested). The caller gets full control and the higher level protocols can care about timeouts, invoking read in some loops and/or implement retransmission. On top of such an implementation, where everything is controlled, defined, guaranteed and reliable, someone could use an InputStream or OutputStream style interface. Or even better: don't use them at all :) just BTW :-) St. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From yvespielusenet at free.fr Fri Jun 8 05:52:45 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Fri, 08 Jun 2007 13:52:45 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <20070608094500.GC21069@elberon.bln.de.ingenico.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> Message-ID: <1181303565.11203.3.camel@localhost.localdomain> So maybe a better way should be to create a new Exception class which has a method "int getWrittenByte()". So the Exception should be use to send again bytes which are not printed yet. yves Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : > * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > > It is not possible that the rxtx java method write(byte[], int offset, > > int length) return anint which contains the number of byte really send > > to the printer instead of an exception ? > > So this is the programm which will see if all bytes have been sent. If > > not it can retry to send the unsended bytes. > > I think write() is void because in Java people love to do this > since OutputStream :-) Of course on such interfaces you cannot > implement something nice. If you would have a int write, you > would not implement the interface and no applications expecting > this interface would link/work/compile. > > oki, > > Steffen > > P.S.: (OT) > If you propose not to implement the Java interfaces (especially > not on JNI level), maybe optionally offering a wrapper that > removes e.g. the write return value and so on to downgrade the > powerful classic old POSIX read/write style to the modern limited > Java style, then I agree :-) Same for read. Instead of things > like "int avialable()" it is more powerful to have an approach as > select(2) offers (to guarante the caller that read/write will not > block [nothing else make sense anyway IMHO] but may read/write > less bytes then requested). The caller gets full control and the > higher level protocols can care about timeouts, invoking read in > some loops and/or implement retransmission. On top of such an > implementation, where everything is controlled, defined, > guaranteed and reliable, someone could use an InputStream or > OutputStream style interface. Or even better: don't use them at > all :) just BTW :-) > St. > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > 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. > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > 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. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Fri Jun 8 06:46:21 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 08:46:21 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181303565.11203.3.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> Message-ID: <46694F9D.5080501@gatworks.com> It seems that with outputstream.write(b[]), you become terribly uncoordinated as soon as an exception is thrown. Docs do not say what happens to the data. Yet from a practicable point of view, one would like to know if the write was accepted in-full, or rejected before any writes. There are no in betweens, as partial writes are not reportable. So for an outputstream.write(), in order for it to return, the full write request has to be taken, and stored in an internal output buffer. If there is no room, the write() is suspended, till there is room. Or throw's an IOException( "no room in buffer") ; As the select() loop for write reports buffer room avail, then more of the internal buffer is sent to the printer. yves pielusenet wrote: > So maybe a better way should be to create a new Exception class which > has a method "int getWrittenByte()". So the Exception should be use to > send again bytes which are not printed yet. > > yves > > Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : >> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: >>> It is not possible that the rxtx java method write(byte[], int offset, >>> int length) return anint which contains the number of byte really send >>> to the printer instead of an exception ? >>> So this is the programm which will see if all bytes have been sent. If >>> not it can retry to send the unsended bytes. >> I think write() is void because in Java people love to do this >> since OutputStream :-) Of course on such interfaces you cannot >> implement something nice. If you would have a int write, you >> would not implement the interface and no applications expecting >> this interface would link/work/compile. >> >> oki, >> >> Steffen >> >> P.S.: (OT) >> If you propose not to implement the Java interfaces (especially >> not on JNI level), maybe optionally offering a wrapper that >> removes e.g. the write return value and so on to downgrade the >> powerful classic old POSIX read/write style to the modern limited >> Java style, then I agree :-) Same for read. Instead of things >> like "int avialable()" it is more powerful to have an approach as >> select(2) offers (to guarante the caller that read/write will not >> block [nothing else make sense anyway IMHO] but may read/write >> less bytes then requested). The caller gets full control and the >> higher level protocols can care about timeouts, invoking read in >> some loops and/or implement retransmission. On top of such an >> implementation, where everything is controlled, defined, >> guaranteed and reliable, someone could use an InputStream or >> OutputStream style interface. Or even better: don't use them at >> all :) just BTW :-) >> St. >> >> About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. >> 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. >> >> About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. >> 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. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From Steffen.DETTMER at ingenico.com Fri Jun 8 08:12:18 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 16:12:18 +0200 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <46694F9D.5080501@gatworks.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: <20070608141218.GE21069@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 08:46 -0400: > It seems that with outputstream.write(b[]), you become terribly > uncoordinated as soon as an exception is thrown. Docs do not say what > happens to the data. (yes, so avoiding it seems to be good :)) > Yet from a practicable point of view, one would like to know if the > write was accepted in-full, or rejected before any writes. There are no > in betweens, as partial writes are not reportable. (which is an artificial API limitation. I never understood how this happend when they invented JDK because the well-known BSD socket API and thus [probably] WinSock does this correct, but anyway) > So for an outputstream.write(), in order for it to return, the full > write request has to be taken, and stored in an internal output buffer. > If there is no room, the write() is suspended, till there is room. Or > throw's an IOException( "no room in buffer") ; As the select() loop for > write reports buffer room avail, then more of the internal buffer is > sent to the printer. yes, might be good in case of a printer. May be horrible in case of PPP/TCP or some other transmission control protocol which may e.g. repeat data or even omit parts of it (e.g. internet realtime radio station broadcasting)... So I think the idea of "int write" (e.g. BSD sockets, linux files and so on) still is the best. A clean API / implementation should guarantee and allow implementations (users) to rely on that; assumptions and automatic background-sending and so on may look pragmatic and may even work on the first look, but may fail in other situations. BTW, if e.g. BSD socket API is known, why not simply copy it (until something better is invented :)) instead of fiddling around with JDK APIs? anyway, have a nice weekend everyone :-) oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Fri Jun 8 08:55:56 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 10:55:56 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070608141218.GE21069@elberon.bln.de.ingenico.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> Message-ID: <46696DFC.7000801@gatworks.com> >> write reports buffer room avail, then more of the internal buffer is >> sent to the printer. > > yes, might be good in case of a printer. May be horrible in case > of PPP/TCP or some other transmission control protocol which > may e.g. repeat data or even omit parts of it (e.g. internet > realtime radio station broadcasting)... So I think the idea of > "int write" (e.g. BSD sockets, linux files and so on) still is > the best. A clean API / implementation should guarantee and allow > implementations (users) to rely on that; assumptions and > automatic background-sending and so on may look pragmatic and may > even work on the first look, but may fail in other situations. > BTW, if e.g. BSD socket API is known, why not simply copy it > (until something better is invented :)) instead of fiddling > around with JDK APIs? But we were talking about the Parallel Port, and the transmission of data over the commapi/parallel-port schema. There isn't much in bi-directional software communication. Its a simple write one byte at a time interface. I'm not looking to change the comm-api. I'm just looking to alter the interaction between the Native ParallelPort functions, and the java ParallelPort functions that call them. This might be more readily doable than to get a committee to re-specify java-API specs. BTW: Whats is off-topic? ( help: not looking for def of off-topic ) From j.kenneth.gentle at acm.org Fri Jun 8 08:58:59 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Fri, 08 Jun 2007 10:58:59 -0400 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <20070608141218.GE21069@elberon.bln.de.ingenico.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> Message-ID: <200706081459.l58Ex5rA019991@qbang.org> Perhaps it is a bit late to jump in on this one, but here goes anyway. If the solutions all seem to "break" the contract with "java.io.outputstream", then, as noted, that may not be the appropriate contract. At the risk of being heretical, JDK1.4 introduced the "nio" package to address some of the compatibility issues with C apis mentioned in previous posts. The interface "java.nio.channels.WriteableByteChannel" defines the following single method: int write(ByteBuffer source); int, strangely enough, is the actual number of bytes written. So, if RXTX as written, against the JavaCOMM api and OutputStream, doesn't do what we want, how about writing a different set of bindings using the java.nio classes and as much of the underlying native code as possible. Note that just because the java.nio.channels.WriteableByteChannel sends back a result, OutputStream.write doesn't have to - and they could both call the same underlying native code. My 2 cents - maybe not worth even that... Ken From netbeans at gatworks.com Fri Jun 8 10:37:28 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 12:37:28 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <200706081459.l58Ex5rA019991@qbang.org> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> Message-ID: <466985C8.8000505@gatworks.com> Ken Gentle wrote: > Perhaps it is a bit late to jump in on this one, but here goes anyway. Common in, the waters fine. > > If the solutions all seem to "break" the contract with > "java.io.outputstream", then, as noted, that may not be the > appropriate contract. > How would the contract be broken? The machinery underneath is handling the contract. From j.kenneth.gentle at acm.org Fri Jun 8 10:48:01 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Fri, 08 Jun 2007 12:48:01 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466985C8.8000505@gatworks.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> Message-ID: <200706081648.l58Gm7YA022904@qbang.org> At 12:37 2007-06-08, you wrote: >Ken Gentle wrote: > > > > If the solutions all seem to "break" the contract with > > "java.io.outputstream", then, as noted, that may not be the > > appropriate contract. > > >How would the contract be broken? The machinery underneath is handling >the contract. It seems that a lot of the discussion has been about not only the timeout and being able to adjust it in the "machinery layer", but also about knowing in the Java layer, in the event of a timeout or exception, how many characters have been written to the device. An OutputStream won't ever do this with out an extension and including a return value "breaks" the contract, right? So, go with a Java IO api that *does* return the number of bytes written, out of the NIO package. I know it doesn't allow for a strict implementation of the JavaCOMM API - however, using NIO classes in place of the IO classes isn't that big a break and would allow those applications that need such information a way to get it. Maybe I'm misunderstanding the problem... Ken From netbeans at gatworks.com Fri Jun 8 11:24:14 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 13:24:14 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <200706081648.l58Gm7YA022904@qbang.org> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> Message-ID: <466990BE.7040100@gatworks.com> Ken Gentle wrote: An > OutputStream won't ever do this with out an extension and including a > return value "breaks" the contract, right? > i was not thinking of change the API to OutputSream. Are there specs for how output stream should work internally? for instance: String data = "Hello this is a line of data"; Outputstream.write( data.getbytes() ); ParallelPort.suspend(); int free = ParallelPort.getoutputbufferfree(); There is a symbiotic relationship between outputstream and the functionality of ParallelPort. From Steffen.DETTMER at ingenico.com Fri Jun 8 11:15:39 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 19:15:39 +0200 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <200706081459.l58Ex5rA019991@qbang.org> References: <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> Message-ID: <20070608171539.GK21069@elberon.bln.de.ingenico.com> * Ken Gentle wrote on Fri, Jun 08, 2007 at 10:58 -0400: > If the solutions all seem to "break" the contract with > "java.io.outputstream", then, as noted, that may not be the > appropriate contract. > > At the risk of being heretical, JDK1.4 introduced the "nio" package > to address some of the compatibility issues with C apis mentioned in > previous posts. The interface > "java.nio.channels.WriteableByteChannel" defines the following single method: > > int write(ByteBuffer source); > > int, strangely enough, is the actual number of bytes written. Yes, AFAIK one of the motivations for the NIO interface was, that the JDK-1.3 APIs (InputStream, e.g.) were not powerfull enough, especially for multi-connection-TCP servers or so. I don't know much about it but I've heard of a project where NIO usage was removed because of stability issues in multi-threaded environments and performance limitations under some circumstances. IIRC the "nio.ByteBuffer" is something very special (namely something you cannot implement in Java, it is "magic" or part of the language itself). Not sure if this is such a great idea (but for performance in the end sometimes heavy prices must be paid) :) > So, if RXTX as written, against the JavaCOMM api and OutputStream, > doesn't do what we want, how about writing a different set of > bindings using the java.nio classes and as much of the underlying > native code as possible. Yes, this would be an idea: use a full-featured interface on JNI, and, if wanted, deliver some wrappers converting this to a less-featured Java-compliant interface. However, powerful things as e.g. "select" are difficult to "emulate" if you are e.g. on some (older?) windows. But if you expose the full-featured APIs, you need to emulate them full-featured, theoretically. In the end it depends what you do on the serial line. If you just want to talk to a modem, then you may not need precise timeouts. But if you need to implement complexer protocols which define response times and timeouts, you may quickly get into difficulties. For instance, AFAIK, rxtx 1.7.2 (?) for windows is very messy with timeouts (there is a maximum, higher values are truncated; resolution is 100ms only; the function may take up to twice the timeout because internally it may be called twice). Probably for most people this is OK, but probably not for all. But having precise timeouts should be OK for all :-) Well, in the end it is nice to wish but somewhat hard to implement (many platforms, connections, USB, BlueTooth, whatever). oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Steffen.DETTMER at ingenico.com Fri Jun 8 11:04:22 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 19:04:22 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <46696DFC.7000801@gatworks.com> References: <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <46696DFC.7000801@gatworks.com> Message-ID: <20070608170422.GJ21069@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 10:55 -0400: > > BTW, if e.g. BSD socket API is known, why not simply copy it > > (until something better is invented :)) instead of fiddling > > around with JDK APIs? > > But we were talking about the Parallel Port, and the > transmission of data over the commapi/parallel-port schema. > There isn't much in bi-directional software communication. Its > a simple write one byte at a time interface. First, there are things like PLIP (http://en.wikipedia.org/wiki/Plip) - well, probably not widely used, sure ;) Second, I think if there is a good simple API known to support all that (with known "best practices") or so and there is no forcing need to invent a new one, why not simply using it? > I'm not looking to change the comm-api. I'm just looking to > alter the interaction between the Native ParallelPort > functions, and the java ParallelPort functions that call them. Ahh, yes. I think this is what I tried to ask. Having an usable JNI interface and on top (in pure java) some wrapper to InputStream or whatever could be done (e.g. by ignoring the return value of write or throwing if != length). Developers could then use the full-featured (non-JAVA-standard) API or select among various wrappers (as InputStream). > This might be more readily doable than to get a committee to > re-specify java-API specs. Yes, of course. I'm afraid that the Java APIs change regularily, but still yet with limited success it seems, so maybe they get it in one of the next iterations; who knows, maybe Java-9 has a BSD-like socket API :) SCNR. > BTW: Whats is off-topic? ( help: not looking for def of > off-topic ) I think I started some "re-specify java-API specs" which was OT probably. oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From lists at iDIAcomputing.com Fri Jun 8 18:48:54 2007 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Fri, 08 Jun 2007 20:48:54 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46684B62.7080802@gmail.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> Message-ID: <4669F8F6.3040101@iDIAcomputing.com> Vicne wrote: > Sorry to step in without a specific solution to your problem, but I > wanted to share my feeling regarding this proposal. AFAIK, it's > generally considered bad practice to pop-up a prompt from a library. ... > > My advice would be to think again and find another solution. Ideas are : > - make the number of retries a parameter so that you can tune it to what > you think is reasonable > - throw a more specific exception when the number of retries has been > reached, so that a specific prompt can be shown at a higher level You could also allow the client code to register a callback class which returns a boolean indicating whether to retry or cancel. This callback class could pop up a dialog, if appropriate, or follow some preset policy, or.... - George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From joachim at buechse.ch Sat Jun 9 09:43:16 2007 From: joachim at buechse.ch (Joachim Buechse) Date: Sat, 9 Jun 2007 17:43:16 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46694F9D.5080501@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: You should not forget, that in the case of an exception it may not even be known what happened to the data. You have a kernel buffer, outgoing chip buffer, incoming chip buffer, etc. So of course, it would be nice to know up to which point data was correctly processed, but this feedback does not exist on the hardware or protocol level and hence can in general not be magicly created on the software level... Regards, Joachim On 08.06.2007, at 14:46, Uncle George wrote: > It seems that with outputstream.write(b[]), you become terribly > uncoordinated as soon as an exception is thrown. Docs do not say what > happens to the data. > > Yet from a practicable point of view, one would like to know if the > write was accepted in-full, or rejected before any writes. There > are no > in betweens, as partial writes are not reportable. > > So for an outputstream.write(), in order for it to return, the full > write request has to be taken, and stored in an internal output > buffer. > If there is no room, the write() is suspended, till there is room. Or > throw's an IOException( "no room in buffer") ; As the select() loop > for > write reports buffer room avail, then more of the internal buffer is > sent to the printer. > > > > yves pielusenet wrote: >> So maybe a better way should be to create a new Exception class which >> has a method "int getWrittenByte()". So the Exception should be >> use to >> send again bytes which are not printed yet. >> >> yves >> >> Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : >>> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: >>>> It is not possible that the rxtx java method write(byte[], int >>>> offset, >>>> int length) return anint which contains the number of byte >>>> really send >>>> to the printer instead of an exception ? >>>> So this is the programm which will see if all bytes have been >>>> sent. If >>>> not it can retry to send the unsended bytes. >>> I think write() is void because in Java people love to do this >>> since OutputStream :-) Of course on such interfaces you cannot >>> implement something nice. If you would have a int write, you >>> would not implement the interface and no applications expecting >>> this interface would link/work/compile. >>> >>> oki, >>> >>> Steffen >>> >>> P.S.: (OT) >>> If you propose not to implement the Java interfaces (especially >>> not on JNI level), maybe optionally offering a wrapper that >>> removes e.g. the write return value and so on to downgrade the >>> powerful classic old POSIX read/write style to the modern limited >>> Java style, then I agree :-) Same for read. Instead of things >>> like "int avialable()" it is more powerful to have an approach as >>> select(2) offers (to guarante the caller that read/write will not >>> block [nothing else make sense anyway IMHO] but may read/write >>> less bytes then requested). The caller gets full control and the >>> higher level protocols can care about timeouts, invoking read in >>> some loops and/or implement retransmission. On top of such an >>> implementation, where everything is controlled, defined, >>> guaranteed and reliable, someone could use an InputStream or >>> OutputStream style interface. Or even better: don't use them at >>> all :) just BTW :-) >>> St. >>> >>> About Ingenico Throughout the world businesses rely on Ingenico >>> for secure and expedient electronic transaction acceptance. >>> Ingenico products leverage proven technology, established >>> standards and unparalleled ergonomics to provide optimal >>> reliability, versatility and usability. This comprehensive range >>> of products is complemented by a global array of services and >>> partnerships, enabling businesses in a number of vertical sectors >>> to accept transactions anywhere their business takes them. >>> 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. >>> >>> About Ingenico Throughout the world businesses rely on Ingenico >>> for secure and expedient electronic transaction acceptance. >>> Ingenico products leverage proven technology, established >>> standards and unparalleled ergonomics to provide optimal >>> reliability, versatility and usability. This comprehensive range >>> of products is complemented by a global array of services and >>> partnerships, enabling businesses in a number of vertical sectors >>> to accept transactions anywhere their business takes them. >>> 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. >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx 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 yvespielusenet at free.fr Mon Jun 11 03:15:12 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Mon, 11 Jun 2007 11:15:12 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: <1181553312.8335.14.camel@localhost.localdomain> So can someone tell a solution for my problem :( Must I say to the user to not put the printer off-line ? I can't since he has to do some pauses, verify print, paper conditioning etc... How do other people ? Before I use the parport librarry to read port status : http://www.geocities.com/Juanga69/parport/ (which doesn't work on windows XP) And I send data into the file LPT1 I use to have no problem when printer was disabled. thanks -- yves piel Le samedi 09 juin 2007 ? 17:43 +0200, Joachim Buechse a ?crit : > You should not forget, that in the case of an exception it may not > even be known what happened to the data. > > You have a kernel buffer, outgoing chip buffer, incoming chip buffer, > etc. So of course, it would be nice to know up to which point data > was correctly processed, but this feedback does not exist on the > hardware or protocol level and hence can in general not be magicly > created on the software level... > > Regards, > Joachim > > On 08.06.2007, at 14:46, Uncle George wrote: > > > It seems that with outputstream.write(b[]), you become terribly > > uncoordinated as soon as an exception is thrown. Docs do not say what > > happens to the data. > > > > Yet from a practicable point of view, one would like to know if the > > write was accepted in-full, or rejected before any writes. There > > are no > > in betweens, as partial writes are not reportable. > > > > So for an outputstream.write(), in order for it to return, the full > > write request has to be taken, and stored in an internal output > > buffer. > > If there is no room, the write() is suspended, till there is room. Or > > throw's an IOException( "no room in buffer") ; As the select() loop > > for > > write reports buffer room avail, then more of the internal buffer is > > sent to the printer. > > > > > > > > yves pielusenet wrote: > >> So maybe a better way should be to create a new Exception class which > >> has a method "int getWrittenByte()". So the Exception should be > >> use to > >> send again bytes which are not printed yet. > >> > >> yves > >> > >> Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : > >>> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > >>>> It is not possible that the rxtx java method write(byte[], int > >>>> offset, > >>>> int length) return anint which contains the number of byte > >>>> really send > >>>> to the printer instead of an exception ? > >>>> So this is the programm which will see if all bytes have been > >>>> sent. If > >>>> not it can retry to send the unsended bytes. > >>> I think write() is void because in Java people love to do this > >>> since OutputStream :-) Of course on such interfaces you cannot > >>> implement something nice. If you would have a int write, you > >>> would not implement the interface and no applications expecting > >>> this interface would link/work/compile. > >>> > >>> oki, > >>> > >>> Steffen > >>> > >>> P.S.: (OT) > >>> If you propose not to implement the Java interfaces (especially > >>> not on JNI level), maybe optionally offering a wrapper that > >>> removes e.g. the write return value and so on to downgrade the > >>> powerful classic old POSIX read/write style to the modern limited > >>> Java style, then I agree :-) Same for read. Instead of things > >>> like "int avialable()" it is more powerful to have an approach as > >>> select(2) offers (to guarante the caller that read/write will not > >>> block [nothing else make sense anyway IMHO] but may read/write > >>> less bytes then requested). The caller gets full control and the > >>> higher level protocols can care about timeouts, invoking read in > >>> some loops and/or implement retransmission. On top of such an > >>> implementation, where everything is controlled, defined, > >>> guaranteed and reliable, someone could use an InputStream or > >>> OutputStream style interface. Or even better: don't use them at > >>> all :) just BTW :-) > >>> St. > >>> > >>> About Ingenico Throughout the world businesses rely on Ingenico > >>> for secure and expedient electronic transaction acceptance. > >>> Ingenico products leverage proven technology, established > >>> standards and unparalleled ergonomics to provide optimal > >>> reliability, versatility and usability. This comprehensive range > >>> of products is complemented by a global array of services and > >>> partnerships, enabling businesses in a number of vertical sectors > >>> to accept transactions anywhere their business takes them. > >>> 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. > >>> > >>> About Ingenico Throughout the world businesses rely on Ingenico > >>> for secure and expedient electronic transaction acceptance. > >>> Ingenico products leverage proven technology, established > >>> standards and unparalleled ergonomics to provide optimal > >>> reliability, versatility and usability. This comprehensive range > >>> of products is complemented by a global array of services and > >>> partnerships, enabling businesses in a number of vertical sectors > >>> to accept transactions anywhere their business takes them. > >>> 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. > >>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx 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 > From Steffen.DETTMER at ingenico.com Mon Jun 11 03:56:18 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 11:56:18 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466990BE.7040100@gatworks.com> References: <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> Message-ID: <20070611095618.GA10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 13:24 -0400: > i was not thinking of change the API to OutputSream. Then I think either someone uses OutputStream (and has no reliable information about incomplete writes) or someone uses somethink else. > Are there specs for how output stream should work internally? > > for instance: > String data = "Hello this is a line of data"; > Outputstream.write( data.getbytes() ); > ParallelPort.suspend(); > int free = ParallelPort.getoutputbufferfree(); > > There is a symbiotic relationship between outputstream and the > functionality of ParallelPort. If you need OutputStream "plus something else", in short you're needing "something else". Personally I dislike the code above a lot. The stream "looks" like if it would be an OutputStream, but in fact it isn't. You need to call getoutputbufferfree later to check if write succeeded (but OutputStream promises that write succeedes synchronous, blocking, or throws an exception). So it is not an OutputStream. No application written for OutputStreams would work without change (because it won't know getoutputbufferfree at all). It is not abstracted from ParallelPort. I think this would be wrong. Then I think an alternative interface instead is better. Let's assume we had some "connection" (to distinguish between OutputStreams and Channels). Then why not working as on a file handle in POSIX: do { // ... select maybe using timer ... readyForWrite = ... if (readyForWrite) { int writtenBytes = connection.write(toWrite); toWrite.remove(0, writtenBytes); } while(readyForWrite && toWrite.length > 0); I think, having such a write isn't the big problem. I think, the difficult thing is around "select" - however this would look like. It should be OO, typesafe, performant, supporting multiple connections/channels/streams in various modes and should be orthogonal to other functionalities. Of course, this heavily depends on what the application is doing; for a simple situation (like reading a small, mandatory file from a local disk) this would be to uncomfortable (and offering unneeded features only). just BTW :) oki, Steffen -- // Modeline for VIM. Please don't remove. // (Help: autoindent, expandtab, shiftwidth=4, tabstop=4, textwidth=75) // vi: set ai et sw=4 ts=4 tw=75 ft=java: About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Mon Jun 11 05:38:33 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 07:38:33 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611095618.GA10821@elberon.bln.de.ingenico.com> References: <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> Message-ID: <466D3439.4020805@gatworks.com> Steffen DETTMER wrote: > (but OutputStream promises that write > succeedes synchronous, blocking, or throws an exception). Where is it so written? From Steffen.DETTMER at ingenico.com Mon Jun 11 06:36:50 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 14:36:50 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466D3439.4020805@gatworks.com> References: <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> <466D3439.4020805@gatworks.com> Message-ID: <20070611123650.GI10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Mon, Jun 11, 2007 at 07:38 -0400: > Steffen DETTMER wrote: > > > (but OutputStream promises that write > > succeedes synchronous, blocking, or throws an exception). > > Where is it so written? Now, as you ask, I think it is not written that clearly but follows from specification. mmm... Am I wrong? I understand the API doc in this way: * http://java.sun.com/j2se/1.4.2/docs/api/java/io/OutputStream.html#write(byte[]) > public void write(byte[] b) > throws IOException > > Writes b.length bytes from the specified byte array to this > output stream. The general contract for write(b) is that > it should have exactly the same effect as the call write(b, > 0, b.length). > > Parameters: > b - the data. > Throws: > IOException - if an I/O error occurs. > See Also: > write(byte[], int, int) and there is: > public void write(byte[] b, > int off, > int len) > throws IOException > > Writes len bytes from the specified byte array starting at > offset off to this output stream. The general contract for > write(b, off, len) is that some of the bytes in the array b > are written to the output stream in order; element b[off] > is the first byte written and b[off+len-1] is the last byte > written by this operation. > > The write method of OutputStream calls the write method of > one argument on each of the bytes to be written out. > Subclasses are encouraged to override this method and > provide a more efficient implementation. > > If b is null, a NullPointerException is thrown. > > If off is negative, or len is negative, or off+len is > greater than the length of the array b, then an > IndexOutOfBoundsException is thrown. > > Parameters: > b - the data. > off - the start offset in the data. > len - the number of bytes to write. > Throws: > IOException - if an I/O error occurs. In particular, an > IOException is thrown if the output stream is closed. In general, any specialisation (derived child class) must comform to this. So write in the end is specified (!) as "The write method ... calls the write method ... on each of the bytes to be written out". This is what must be implemented by ANY OutputStream. Of course, there is: "Subclasses are encouraged to override this method and provide a more efficient implementation." which IMHO does not contradict - the more efficient must behave in exactly the same way of course (just wasting less resources than a simple byte-by-byte write). So it does not matter here I think. The write that finally defines the behavior tells basically: > "Writes the specified byte to this output stream. The general > contract for write is that one byte is written to the output > stream. " > > Throws: > IOException - if an I/O error occurs. which IMHO is another way of saying "write writes the byte immediately and returns on success (only), otherwise an exception is thrown". Especially it cannot happen that zero bytes are written (i.e. the specified byte is NOT written) without an exception. So by this write must be synchronous and blocking, because otherwise it could not reliably know if an asynchronous operation will succeede or not (some getAsyncResult or so would be needed). Since write(byte[]) does this for each byte (or with a behavior beeing exactly the same as if it would do), I think this means that the write(byte[]) succeedes synchronous/blocking or throws an exception. Did I an error in reasoning or confused something or so? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From j.kenneth.gentle at acm.org Mon Jun 11 06:51:25 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 11 Jun 2007 08:51:25 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611123650.GI10821@elberon.bln.de.ingenico.com> References: <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> <466D3439.4020805@gatworks.com> <20070611123650.GI10821@elberon.bln.de.ingenico.com> Message-ID: <200706111251.l5BCpS9T017831@qbang.org> It is as Steffen describes. "InputStream" and "OutputStream" are inherently synchronous (which is why so many java programs resort to threads to use them). Anything outside of this "contract" is *not* an InputStream or OutputStream. That is why there is a new package for things that don't behave like the old *Stream classes - the NIO package. If you look carefully at the IO package, you'll note that almost all the classes are _Decorator_ pattern implementations of the *Stream classes - and the interface presents the _same_ behavior to the calling code in all cases - a synchronous operation that completes successfully or throws an exception (with the one exception of "read" that returns a "-1" on end-of-stream. I know I've read this numerous times - I'd suggest checking the Language Spec or one of the books by Bloch or Gosling. Ken At 08:36 2007-06-11, you wrote: >* Uncle George wrote on Mon, Jun 11, 2007 at 07:38 -0400: > > Steffen DETTMER wrote: > > > > > (but OutputStream promises that write > > > succeedes synchronous, blocking, or throws an exception). > > > > Where is it so written? > >Now, as you ask, I think it is not written that clearly but >follows from specification. mmm... > >Am I wrong? > >I understand the API doc in this way: > >* >http://java.sun.com/j2se/1.4.2/docs/api/java/io/OutputStream.html#write(byte[]) > > public void write(byte[] b) > > throws IOException > > > > Writes b.length bytes from the specified byte array to this > > output stream. The general contract for write(b) is that > > it should have exactly the same effect as the call write(b, > > 0, b.length). > > > > Parameters: > > b - the data. > > Throws: > > IOException - if an I/O error occurs. > > See Also: > > write(byte[], int, int) > > >and there is: > > > > public void write(byte[] b, > > int off, > > int len) > > throws IOException > > > > Writes len bytes from the specified byte array starting at > > offset off to this output stream. The general contract for > > write(b, off, len) is that some of the bytes in the array b > > are written to the output stream in order; element b[off] > > is the first byte written and b[off+len-1] is the last byte > > written by this operation. > > > > The write method of OutputStream calls the write method of > > one argument on each of the bytes to be written out. > > Subclasses are encouraged to override this method and > > provide a more efficient implementation. > > > > If b is null, a NullPointerException is thrown. > > > > If off is negative, or len is negative, or off+len is > > greater than the length of the array b, then an > > IndexOutOfBoundsException is thrown. > > > > Parameters: > > b - the data. > > off - the start offset in the data. > > len - the number of bytes to write. > > Throws: > > IOException - if an I/O error occurs. In particular, an > > IOException is thrown if the output stream is closed. > > >In general, any specialisation (derived child class) must comform >to this. So write in the end is specified (!) as "The write >method ... calls the write method ... on each of the bytes to be >written out". This is what must be implemented by ANY >OutputStream. > >Of course, there is: "Subclasses are encouraged to override this >method and provide a more efficient implementation." which IMHO >does not contradict - the more efficient must behave in exactly >the same way of course (just wasting less resources than a simple >byte-by-byte write). So it does not matter here I think. > > > >The write that finally defines the behavior tells basically: > > > "Writes the specified byte to this output stream. The general > > contract for write is that one byte is written to the output > > stream. " > > > > Throws: > > IOException - if an I/O error occurs. > > >which IMHO is another way of saying "write writes the byte >immediately and returns on success (only), otherwise an exception >is thrown". Especially it cannot happen that zero bytes are >written (i.e. the specified byte is NOT written) without an >exception. So by this write must be synchronous and blocking, >because otherwise it could not reliably know if an asynchronous >operation will succeede or not (some getAsyncResult or so would >be needed). > >Since write(byte[]) does this for each byte (or with a behavior >beeing exactly the same as if it would do), I think this means >that the write(byte[]) succeedes synchronous/blocking or throws >an exception. > >Did I an error in reasoning or confused something or so? > >oki, > >Steffen > >About Ingenico Throughout the world businesses rely on Ingenico for >secure and expedient electronic transaction acceptance. Ingenico >products leverage proven technology, established standards and >unparalleled ergonomics to provide optimal reliability, versatility >and usability. This comprehensive range of products is complemented >by a global array of services and partnerships, enabling businesses >in a number of vertical sectors to accept transactions anywhere >their business takes them. >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. > >About Ingenico Throughout the world businesses rely on Ingenico for >secure and expedient electronic transaction acceptance. Ingenico >products leverage proven technology, established standards and >unparalleled ergonomics to provide optimal reliability, versatility >and usability. This comprehensive range of products is complemented >by a global array of services and partnerships, enabling businesses >in a number of vertical sectors to accept transactions anywhere >their business takes them. >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. > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From alesinskyy at googlemail.com Mon Jun 11 07:25:33 2007 From: alesinskyy at googlemail.com (Oleksandr Alesinskyy) Date: Mon, 11 Jun 2007 15:25:33 +0200 Subject: [Rxtx] [OT] select :-) Message-ID: Sorry, but I have to disagree with following statement: "So write in the end is specified (!) as "The write method ... calls the write method ... on each of the bytes to be written out". This is what must be implemented by ANY OutputStream.". This is not part of the specification or contract, it is just revealed implementation detail of the OutputStream. It is not stated anywhere that behavoiur of derived classes shall conform with this one. Statement concerning "synchronous" nature of the output stream is invalid as well. Really synchronous stream does not require flush() but OutputStream has it. From Steffen.DETTMER at ingenico.com Mon Jun 11 08:21:16 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 16:21:16 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: Message-ID: <20070611142116.GN10821@elberon.bln.de.ingenico.com> * Oleksandr Alesinskyy wrote on Mon, Jun 11, 2007 at 15:25 +0200: > Sorry, but I have to disagree with following statement: > "So write in the end is specified (!) as "The write > method ... calls the write method ... on each of the bytes to be > written out". This is what must be implemented by ANY > OutputStream.". > > This is not part of the specification or contract, it is just > revealed implementation detail of the OutputStream. It is not > stated anywhere that behavoiur of derived classes shall conform > with this one. (I didn't meant that the implementation must really write byte by byte, but that it must "look as if it would do" - because all implementations of OutputStream must "look" in the same way [which is another way of saying "do abstract" I think]) I think the API doc is not "revealing implementation details" but it is the *specification* of that interface and derivations must (should) conform to this specification. Isn't this the idea of interfaces? A function that expects an OutputStream should work on ANY OutputStream, shouldn't it? just kidding: I mean, what would be the point in implementing a checksum function as OutputStream.write which throws its result as IOException? Or which requires to call close() as very first operation to tell that the application is about to transmit confidential data? :-) > Statement concerning "synchronous" nature of the output stream > is invalid as well. Really synchronous stream does not require > flush() but OutputStream has it. ahh, interesting point! I think this is another bug in the API. flush() is wrong. Because write specifies "The general contract for write is that one byte is written to the output stream." but not "a byte may be written or buffered". Actually, an application would need to call flush() after each write (or bunch of write calls) to ensure that write really did something otherwise I think. I didn't found in the spec of OutputStream that it would be required to call flush(). This should mean that calling flush is not required which in turn leads to the conclusion that write must be synchrous (private threads are forbidden because not specified :)) which in turn leads to the conclusion that flush() is not needed at all... I mean, what if someone would only store in write and do the "real write" in flush() and never else? An application could write in one stream and read on another one (e.g. in bidirectional communication) and would never get anything back, because nothing was actually written because no flush was called? Then someone could even think that on error in some write the data could remain buffered AND throw an exception, retrying to send the data in the next write. Ohh, and if there would be some message number inside, and underlaying write (e.g. a protocol offering InputStream/OutputStream) would check this and throw "DuplicatedMessageNumber" the stream would only throw it again and again beeing unusable... In short: I have no clue how someone could be able to implement an asynchrounos write (which is realiable and correct) without beeing specific to anything which is not specified by OutputStream. Well, I think in the end OutputStream was not intended for such communication or protocol implementations - but to read a local disk file or so. In case of I/O errors usually you can abort your application and change the hard disk :-) oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Bob_Jacobsen at lbl.gov Mon Jun 11 09:32:23 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Mon, 11 Jun 2007 08:32:23 -0700 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611142116.GN10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> Message-ID: At 4:21 PM +0200 6/11/07, Steffen DETTMER wrote: > > Statement concerning "synchronous" nature of the output stream >> is invalid as well. Really synchronous stream does not require >> flush() but OutputStream has it. > >ahh, interesting point! > >I think this is another bug in the API. flush() is wrong. Because >write specifies "The general contract for write is that one byte >is written to the output stream." but not "a byte may be written >or buffered". > >Actually, an application would need to call flush() after each >write (or bunch of write calls) to ensure that write really did >something otherwise I think. OutputStreams don't _have_ to be synchronous or asynchronous, but the OutputStream API was be arranged so that subclasses _can_ be synchronous or asynchronous. Such generality is the hardest part of getting an API right. Hence, if at some point a program using an OutputStream wants to be sure that the data has been pushed all the way out, flush() is available. For some subclasses, e.g. the buffered ones, this has important behavior. Others write the data from each call, and flush() doesn't do anything. You _can_ omit it in programs that are known to use this second type, but there's no requirement that you do so; the interface is general in that way. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From Steffen.DETTMER at ingenico.com Mon Jun 11 12:32:39 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 20:32:39 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> Message-ID: <20070611183239.GT10821@elberon.bln.de.ingenico.com> * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: > >Actually, an application would need to call flush() after each > >write (or bunch of write calls) to ensure that write really did > >something otherwise I think. > OutputStreams don't _have_ to be synchronous or asynchronous, > but the OutputStream API was be arranged so that subclasses > _can_ be synchronous or asynchronous. Ahh, oki. Thanks for the clarificaion. So in short, flush() MUST be called on OutputStream, this is just not documented correctly or so clearly (right?). So the overall usage semantics would be: 1. call write (multiple times if desired) 2. call flush only if both succeeded, write was successful. If flush fails it remains unknown if a part of the data was written and/or will be repeated. So the spec (API doc) is wrong. Correct would be to tell that write behaves as told as long as it is followed by a call to flush, otherwise data may or may not get lost (depending wheter close() is called and calls flush(), which seems not to be guaranteed/required). BTW, I think it is a little bit... erm... interesting to find the specification (java API doc reference) wrong, having a need to conclude it from the presence of some methods with "it would make no sense if they behave exactly as specified, so specification must be wrong (incomplete)". > Such generality is the hardest part of getting an API right. Yes, seems to be proven ;) > Hence, if at some point a program using an OutputStream wants > to be sure that the data has been pushed all the way out, > flush() is available. For some subclasses, e.g. the buffered > ones, this has important behavior. Others write the data from > each call, and flush() doesn't do anything. > You _can_ omit it in programs that are known to use this second > type, but there's no requirement that you do so; the interface > is general in that way. I think, it still it must be called always, otherwise the application could break if passing a different runtime type as OutputStream. I think, if the application/method needs a special "type of OutputStream" then the parameter type must be a subclass but not OutputStream, maybe a PrintStream or so - otherwise the compiler could not detect this error (passing wrong type). Is this correct? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Bob_Jacobsen at lbl.gov Mon Jun 11 13:00:52 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Mon, 11 Jun 2007 12:00:52 -0700 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611183239.GT10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> Message-ID: At 8:32 PM +0200 6/11/07, Steffen DETTMER wrote: >So the spec (API doc) is wrong. Correct would be to tell that >write behaves as told as long as it is followed by a call to >flush, otherwise data may or may not get lost (depending wheter >close() is called and calls flush(), which seems not to be >guaranteed/required). I'm not entirely sure that the spec is wrong, but reasonable people can differ on this. In the 1.5 JavaDocs, all that the docs say for the write methods is that they write to the _output_ _stream_; there is no guarantee of anything beyond that. Only the flush method has any guarantee about the data, which is >Flushes this output stream and forces any buffered output bytes to >be written out. The general contract of flush is that calling it is >an indication that, if any bytes previously written have been >buffered by the implementation of the output stream, such bytes >should immediately be written to their intended destination. People commonly use various OutputStreams without using flush(), and it often works, but it's a bad practice and will eventually bite them. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From netbeans at gatworks.com Mon Jun 11 13:31:57 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 15:31:57 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611183239.GT10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> Message-ID: <466DA32D.1010602@gatworks.com> Steffen DETTMER wrote: > * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: >>> Actually, an application would need to call flush() after each >>> write (or bunch of write calls) to ensure that write really did >>> something otherwise I think. > >> OutputStreams don't _have_ to be synchronous or asynchronous, >> but the OutputStream API was be arranged so that subclasses >> _can_ be synchronous or asynchronous. > > Ahh, oki. Thanks for the clarificaion. > > So in short, flush() MUST be called on OutputStream, this is just > not documented correctly or so clearly (right?). No. Flush can be called to force all current data in java buffer's to be written to the kernel - NOW. A flush() can also *imply* that, besides writing out the buffer's that java employs, may also imply/ask the kernel to write all data thusfar written to the kernel, to be physically placed on the destination device - NOW. For some OS's there is no need to do a kernel flush(), as the I/O is synchronized already. Since this is java, you never know what OS your on. From tjarvi at qbang.org Mon Jun 11 19:28:27 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Jun 2007 19:28:27 -0600 (MDT) Subject: [Rxtx] [OT] select :-) In-Reply-To: <466DA32D.1010602@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: On Mon, 11 Jun 2007, Uncle George wrote: > Steffen DETTMER wrote: >> * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: >>>> Actually, an application would need to call flush() after each >>>> write (or bunch of write calls) to ensure that write really did >>>> something otherwise I think. >> >>> OutputStreams don't _have_ to be synchronous or asynchronous, >>> but the OutputStream API was be arranged so that subclasses >>> _can_ be synchronous or asynchronous. >> >> Ahh, oki. Thanks for the clarificaion. >> >> So in short, flush() MUST be called on OutputStream, this is just >> not documented correctly or so clearly (right?). > No. > Flush can be called to force all current data in java buffer's to be > written to the kernel - NOW. > > A flush() can also *imply* that, besides writing out the buffer's that > java employs, may also imply/ask the kernel to write all data thusfar > written to the kernel, to be physically placed on the destination device > - NOW. > For some OS's there is no need to do a kernel flush(), as the I/O is > synchronized already. Since this is java, you never know what OS your on. To add to the confusion, flush on the C side throws away data. drain makes sure it is written. Looking at the ParallelImp.c we can probably do better. /* we set a timeout because all calls are sequentiell (also with asynchron) this means that the default timeout of unlimited blocks all calls (also close and status request) if the device is down */ GetCommTimeouts( (HANDLE)fd, &timeouts ); timeouts.WriteTotalTimeoutMultiplier = 0; timeouts.WriteTotalTimeoutConstant = 2000; /* 2000 is the min value for the default Windows NT and Windows 2000 driver */ SetCommTimeouts( (HANDLE)fd, &timeouts ); while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } errorCount = 0; bytes += countWritten; count -= countWritten; } LPRPort has some timeout code that appears to be doing nothing but flipping bits back and forth right now. The commapi rxtx follows allows for timeout control from javax.comm.CommPort. The above is a solution that worked in one specific use case. With timeouts in place, the original 'old printer going offline' problem could be solved. That printer code isn't written in stone. In fact it was ajusted from being able to print 'asdf' to a daisy wheel printer to working for one person. BTW, I've finished teaching after hours tonight and will be moving forward with a new rxtx release in my free time. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Jun 11 21:28:04 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 23:28:04 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: <466E12C4.1010305@gatworks.com> > Looking at the ParallelImp.c we can probably do better. > The problem stemmed from the possibility that the writev routine could have written some of the buffer, in chunks, printer pauses, refuses any more chunks, and a timeout occurs. Do you or do you not cause an exception to be thrown? Is there a way to set timeout for a ParallelPort data output stream? I cant find it. From tjarvi at qbang.org Mon Jun 11 22:17:23 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Jun 2007 22:17:23 -0600 (MDT) Subject: [Rxtx] [OT] select :-) In-Reply-To: <466E12C4.1010305@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> <466E12C4.1010305@gatworks.com> Message-ID: On Mon, 11 Jun 2007, Uncle George wrote: >> Looking at the ParallelImp.c we can probably do better. >> > The problem stemmed from the possibility that the writev routine could > have written some of the buffer, in chunks, printer pauses, refuses any > more chunks, and a timeout occurs. Do you or do you not cause an > exception to be thrown? > > Is there a way to set timeout for a ParallelPort data output stream? I > cant find it. hmm I looked again after you asked. The timeouts are only controllable on the receive side. This comes from CommPort; the parent. So what we are talking about is some bytes in memory that rxtx has and is supposed to write. A buffer perhaps? The approach with rxtx in the past has been to ignore output buffer sizes. The assumption is that the library does not know how to best handle buffers. There are buffered output streams that can do buffering on top of rxtx for instance. There is also a question regarding what was actually ment when the API was put together. My suspicion is that it was put together while looking at one OS API and was never ment to be anything more than a hook into that API. The comments are fairly telling combined with reading the w32 API. So looking at the problem again.. The current timeout behavior appears fairly arbitrary. Presumably this is to prevent a program from hanging instead of using a helper thread to write - heavy handed for new programmers. Even so, I don't think the write should timeout at all if it is not configurable. >From the API perspective, "What Timeout?" -- Trent Jarvi tjarvi at qbang.org From Steffen.DETTMER at ingenico.com Tue Jun 12 02:14:48 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 12 Jun 2007 10:14:48 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466DA32D.1010602@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: <20070612081447.GU10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Mon, Jun 11, 2007 at 15:31 -0400: > Steffen DETTMER wrote: > > Ahh, oki. Thanks for the clarificaion. > > > > So in short, flush() MUST be called on OutputStream, this is just > > not documented correctly or so clearly (right?). > No. hum (though now I got it, but...). > Flush can be called to force all current data in java buffer's to be > written to the kernel - NOW. > > A flush() can also *imply* that, besides writing out the > buffer's that java employs, may also imply/ask the kernel to > write all data thusfar written to the kernel, to be physically > placed on the destination device - NOW. > > For some OS's there is no need to do a kernel flush(), as the I/O is > synchronized already. Since this is java, you never know what OS your on. (well, but if you're going to kernel level, even flush cannot guarantee that data will "be physically placed". Maybe you're flushing to a file via NFS (and the client "thinks" that it was written, but maybe it was just buffered by the NFS server) or so... but of course such exceptions of the rules are constructable always.) Well, you tell that depending on the OS it can be that flush is needed or it can be that flush is not needed (beacuse the I/O is synchronized already), right? Also, applications should work on any OS, which includes the OSes that do need flush. Since the application cannot know whether flush is needed or not because it doesn't know what the OS is doing, it has to call flush, hasn't it? I mean, if it would not call flush then it would not work on such OSes (except the written data would not be needed at all, but in this would be an artificial example :)). Since applications are supposed to work this would be wrong, wouldn't it? So would it be correct to say: "Applications, that should work under all OSes (including the OSes where the I/O is not synchronised already), have to call flush on OutputStream to ensure the data is transfered to the kernel." or is this wrong? If so, then I'm afraid I missed the point again :( oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Tue Jun 12 04:46:52 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 12 Jun 2007 06:46:52 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070612081447.GU10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> <20070612081447.GU10821@elberon.bln.de.ingenico.com> Message-ID: <466E799C.7060700@gatworks.com> S > (well, but if you're going to kernel level, even flush cannot > guarantee that data will "be physically placed". Thats true now-a-days because ( from "man 2 sync" ) : > According to the standard specification (e.g., SVID), sync() schedules > the writes, but may return before the actual writing is done. However, > since version 1.3.20 Linux does actually wait. (This still does not > guarantee data integrity: modern disks have large caches.) My disk drive has 8mb cache. Maybe you're > flushing to a file via NFS (and the client "thinks" that it was > written, but maybe it was just buffered by the NFS server) or > so... but of course such exceptions of the rules are > constructable always.) > > Well, you tell that depending on the OS it can be that flush is > needed or it can be that flush is not needed (beacuse the I/O is > synchronized already), right? Also, applications should work on > any OS, which includes the OSes that do need flush. Its not OS's that need flush, its applications that want to have some assurance that data is written to the device that really needs to use flush. If your program ( or thread ) dies then it is in your best interest to write out the critical data as soon as possible, as economical as possible. These are trade-off's that the application programmer makes. A big buffer may mean big loss of data, a small buffer may mean spending too much time writing out data. > > > So would it be correct to say: > > "Applications, that should work under all OSes (including the > OSes where the I/O is not synchronised already), have to call > flush on OutputStream to ensure the data is transfered to the > kernel." > > or is this wrong? If so, then I'm afraid I missed the point again > :( > No that is not wrong. Ensuring that data is transfered to the OS is just about what any application can do. From tjarvi at qbang.org Thu Jun 14 08:16:47 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 14 Jun 2007 08:16:47 -0600 (MDT) Subject: [Rxtx] rxtx and usb-serial solution In-Reply-To: References: Message-ID: On Thu, 14 Jun 2007, Vladimir Kirtchev wrote: > Hi Trent, > > I develop a Java application which communicates with devices which have > USB-to-Serial bridge in them. The target OS is Linux. So for this purpose I > use RXTX. > > But I encountered a strange problem - when reading from the InputStream, I > receive series of zeros. I have this problem under Linux only. Under Windows > it is fine. > Actually this problem is the same as the one described here: > http://marc.info/?l=rxtx&m=109703190731748&w=2. > > > So I searched for the problem in the native code. And found that the root of > the problem is in SerialImp.c, > int configure_port( int fd ) > { > ... > ttyset.c_iflag = INPCK; > ... > } > > This line enables input parity checking, and the data sent from the device > is processed by the OS driver before being read with read(). > In this case the driver detects some problem and sets the received bytes to > zero. > > On the other hand in the Java part a set the serial port parameters with > SerialPort.PARITY_NONE. According to me, except all other things, this > should also disable INPCK in c_iflag. > > So I refactored the method translate_parity(...) to the following: > > int translate_parity( JNIEnv *env, struct termios *ttyset, jint parity ) > { > ENTER( "translate_parity" ); > #ifdef CMSPAR > ttyset->c_cflag &= ~(PARENB | PARODD | CMSPAR ); > #endif /* CMSPAR */ > switch( parity ) { > case JPARITY_NONE: > ttyset->c_iflag &= ~INPCK; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_EVEN: > ttyset->c_cflag |= PARENB; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_ODD: > ttyset->c_cflag |= PARENB | PARODD; > LEAVE( "translate_parity" ); > return 0; > #ifdef CMSPAR > case JPARITY_MARK: > ttyset->c_cflag |= PARENB | PARODD | CMSPAR; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_SPACE: > ttyset->c_cflag |= PARENB | CMSPAR; > LEAVE( "translate_parity" ); > return 0; > #endif /* CMSPAR */ > default: > printf("Parity missed %i\n", (int) parity ); > } > > LEAVE( "translate_parity" ); > /* > For some reason the native exceptions are not being caught. Moving this > to the Java side fixed the issue. taj. > throw_java_exception( env, UNSUPPORTED_COMM_OPERATION, > "", "parity value not supported" ); > */ > return 1; > } > > This modification solved the problem and now it works correctly under Linux. > > I think I will be a nice if this is idea is included in a future release of > RXTX. > > Thanks Vadim, I'll try that out. Forwarding to the rxtx mail-list too. This is probably not going to help USB drivers on windows which I'm sure some are looking for. As far as I can tell, windows USB bluetooth and serial dongles are limited by driver functionality. Some are good and others lack key features. -- Trent Jarvi tjarvi at qbang.org From dan.sandberg.lists at gmail.com Mon Jun 18 14:43:39 2007 From: dan.sandberg.lists at gmail.com (Dan Sandberg) Date: Mon, 18 Jun 2007 13:43:39 -0700 Subject: [Rxtx] Fix for JNI Get/Set Field Errors Message-ID: <4676EE7B.7060800@gmail.com> Hi, I've fixed the problems that cause the following JNI error when extra JNI checking ( -Xjni:check ) is turned on. FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) The problem was basically that GetLong was being used to get ints, and SetInt was used for longs. The patch below fixes this. Please let me know if there are any questions / problems. Cheers, -Dan diff -aur old/SerialImp.c src/SerialImp.c --- old/SerialImp.c 2007-06-18 13:24:33.000000000 -0700 +++ src/SerialImp.c 2007-06-18 06:26:26.000000000 -0700 @@ -1337,7 +1337,7 @@ report("init_threads: get eis\n"); jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); report("init_threads: set eis\n"); - (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); + (*eis->env)->SetLongField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); report("init_threads: stop\n"); report_time_end( ); return( 1 ); @@ -1530,7 +1530,7 @@ jobject jobj, jboolean interrupted ) { int fd = get_java_var( env, jobj,"fd","I" ); - struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var( env, jobj, "eis", "J" ); + struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var_long( env, jobj, "eis", "J" ); int result, count=0; char message[80]; @@ -2939,7 +2939,7 @@ /* TRENT */ int flag, count = 0; struct event_info_struct *eis = ( struct event_info_struct * ) - get_java_var( env, *jobj,"eis","J" ); + get_java_var_long( env, *jobj,"eis","J" ); report_time_start(); flag = eis->eventflags[SPE_DATA_AVAILABLE]; @@ -4873,9 +4873,9 @@ exceptions: none comments: ----------------------------------------------------------*/ -size_t get_java_var( JNIEnv *env, jobject jobj, char *id, char *type ) +long get_java_var_long( JNIEnv *env, jobject jobj, char *id, char *type ) { - int result = 0; + long result = 0; jclass jclazz = (*env)->GetObjectClass( env, jobj ); jfieldID jfd = (*env)->GetFieldID( env, jclazz, id, type ); @@ -4889,7 +4889,11 @@ LEAVE( "get_java_var" ); return result; } - result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); + if ( !strcmp( type, "J" ) ) { + result = (long)( (*env)->GetLongField( env, jobj, jfd ) ); + } else { + result = (int) ( (*env)->GetIntField( env, jobj, jfd ) ); + } /* ct7 & gel * Added DeleteLocalRef */ (*env)->DeleteLocalRef( env, jclazz ); if(!strncmp( "fd",id,2) && result == 0) @@ -4900,6 +4904,10 @@ return result; } +int get_java_var( JNIEnv *env, jobject jobj, char *id, char *type ) { + return (int) get_java_var_long( env, jobj, id, type ); +} + /*---------------------------------------------------------- throw_java_exception diff -aur old/SerialImp.h src/SerialImp.h --- old/SerialImp.h 2007-06-18 13:24:39.000000000 -0700 +++ src/SerialImp.h 2007-06-18 06:23:43.000000000 -0700 @@ -413,7 +413,8 @@ void system_wait(); void finalize_event_info_struct( struct event_info_struct * ); int read_byte_array( JNIEnv *, jobject *, int, unsigned char *, int, int ); -size_t get_java_var( JNIEnv *, jobject, char *, char * ); +int get_java_var( JNIEnv *, jobject, char *, char * ); +long get_java_var_long( JNIEnv *, jobject, char *, char * ); jboolean is_interrupted( struct event_info_struct * ); int send_event(struct event_info_struct *, jint, int ); void dump_termios(char *,struct termios *); From yvespielusenet at free.fr Tue Jun 26 03:41:58 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 11:41:58 +0200 Subject: [Rxtx] [PARALLEL] resource in use Message-ID: <1182850918.3483.10.camel@localhost.localdomain> Hello, So now I want to modify the timeout of the library for parallel port. I have downloaded source code. There is a makefile for migw. SO I have installed mingw on ubuntu and modified the makefile.mingw32 to set it for my system. I have no error but some warnings. The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But When I want to use it the jvm crash :( How can I know what is wrong ? How rxtx windows release has been done ? thanks -- yves piel From yvespielusenet at free.fr Tue Jun 26 07:17:02 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 15:17:02 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182850918.3483.10.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> Message-ID: <1182863822.3483.17.camel@localhost.localdomain> Here is the Makefile I use, the output of the 'make' and the log of the jvm when it crashed : - The Makefile : http://yvespiel.free.fr/rxtx/Makefile - The make output : http://yvespiel.free.fr/rxtx/compile.txt - The crash log : http://yvespiel.free.fr/rxtx/hs_err_pid2100.log I have compiled rxtx under Debian testing with mingw : narma at linimi:/tmp/err$ dpkg -l | grep mingw ii mingw32 3.4.5.20060117.1.dfsg-3 ii mingw32-binutils 2.17.50-20070129.1-1 ii mingw32-runtime 3.12-1 thanks fort help :) Le mardi 26 juin 2007 ? 11:41 +0200, yves pielusenet a ?crit : > Hello, > So now I want to modify the timeout of the library for parallel port. I > have downloaded source code. There is a makefile for migw. SO I have > installed mingw on ubuntu and modified the makefile.mingw32 to set it > for my system. > I have no error but some warnings. > The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But > When I want to use it the jvm crash :( > > How can I know what is wrong ? > > How rxtx windows release has been done ? > > thanks > From yvespielusenet at free.fr Tue Jun 26 07:40:11 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 15:40:11 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182863822.3483.17.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> <1182863822.3483.17.camel@localhost.localdomain> Message-ID: <1182865211.3483.21.camel@localhost.localdomain> I have add the options '--enable-stdcall-fixup' to the 'i586-mingw32msvc-ld' commande. Now I have no warning. But the JVM always crashes :( The output seems more detailled, but I don't understand anything... Here is files : http://yvespiel.free.fr/rxtx/2/ -- yves piel Le mardi 26 juin 2007 ? 15:17 +0200, yves pielusenet a ?crit : > Here is the Makefile I use, the output of the 'make' and the log of the > jvm when it crashed : > > - The Makefile : http://yvespiel.free.fr/rxtx/Makefile > - The make output : http://yvespiel.free.fr/rxtx/compile.txt > - The crash log : http://yvespiel.free.fr/rxtx/hs_err_pid2100.log > > I have compiled rxtx under Debian testing with mingw : > narma at linimi:/tmp/err$ dpkg -l | grep mingw > ii mingw32 3.4.5.20060117.1.dfsg-3 > ii mingw32-binutils 2.17.50-20070129.1-1 > ii mingw32-runtime 3.12-1 > > thanks fort help :) > > > Le mardi 26 juin 2007 ? 11:41 +0200, yves pielusenet a ?crit : > > Hello, > > So now I want to modify the timeout of the library for parallel port. I > > have downloaded source code. There is a makefile for migw. SO I have > > installed mingw on ubuntu and modified the makefile.mingw32 to set it > > for my system. > > I have no error but some warnings. > > The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But > > When I want to use it the jvm crash :( > > > > How can I know what is wrong ? > > > > How rxtx windows release has been done ? > > > > thanks > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From yvespielusenet at free.fr Tue Jun 26 08:27:42 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 16:27:42 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182865211.3483.21.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> <1182863822.3483.17.camel@localhost.localdomain> <1182865211.3483.21.camel@localhost.localdomain> Message-ID: <1182868062.3483.24.camel@localhost.localdomain> I think thant the include files of jdk were not for windows but for linux. So I have copied include/ folder from windows to linux and I modified the Makefile to use those file. It compile fine but the JVM always crash :( http://yvespiel.free.fr/rxtx/3/ Le mardi 26 juin 2007 ? 15:40 +0200, yves pielusenet a ?crit : > I have add the options '--enable-stdcall-fixup' to the > 'i586-mingw32msvc-ld' commande. Now I have no warning. But the JVM > always crashes :( The output seems more detailled, but I don't > understand anything... > Here is files : > http://yvespiel.free.fr/rxtx/2/ > From netbeans at gatworks.com Fri Jun 1 05:38:50 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 07:38:50 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <465F7ADD.1010501@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> Message-ID: <4660054A.2040202@gatworks.com> Manuel Naranjo wrote: In the case of my module, you can > unplug the device but it will not delete the symlink until those apps > that had opened the port has closed it. This is done this way to avoid > kernel panics. What does this mean to user code ? I have tried the alternate route ( other than closing ) which is sleep inbetween the I/O errors ( an unplugged USB device). When the device is plugged back in, The writes to the device still get an I/O error. This would seem to be a lost cause for the application. From netbeans at gatworks.com Fri Jun 1 06:35:48 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 08:35:48 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <465F7ADD.1010501@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> Message-ID: <466012A4.90608@gatworks.com> Manuel Naranjo wrote: In the case of my module, you can > unplug the device but it will not delete the symlink until those apps > that had opened the port has closed it. T Did u also mean for this to happen? USB0 was not closed by application. Apparently USB1 got created when USB device was plugged back in. There is only one USB device on a 4 port USB hub. This also seems to suggest that application recovery to be impossible. > Jun 1 07:10:08 mylaptop kernel: garmin_gps 1-1.4:1.0: Garmin GPS usb/tty converter detected > Jun 1 07:10:08 mylaptop kernel: usb 1-1.4: Garmin GPS usb/tty converter now attached to ttyUSB0 > Jun 1 07:15:17 mylaptop kernel: usb 1-1: USB disconnect, address 4 > Jun 1 07:15:17 mylaptop kernel: usb 1-1.4: USB disconnect, address 5 > Jun 1 07:15:17 mylaptop kernel: garmin_gps 1-1.4:1.0: device disconnected > Jun 1 07:15:26 mylaptop kernel: usb 1-1: new full speed USB device using uhci_hcd and address 6 > Jun 1 07:15:26 mylaptop kernel: hub 1-1:1.0: USB hub found > Jun 1 07:15:26 mylaptop kernel: hub 1-1:1.0: 4 ports detected > Jun 1 07:15:27 mylaptop kernel: usb 1-1.4: new full speed USB device using uhci_hcd and address 7 > Jun 1 07:15:27 mylaptop kernel: garmin_gps 1-1.4:1.0: Garmin GPS usb/tty converter detected > Jun 1 07:15:27 mylaptop kernel: usb 1-1.4: Garmin GPS usb/tty converter now attached to ttyUSB1 From naranjo.manuel at gmail.com Fri Jun 1 09:17:22 2007 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Fri, 01 Jun 2007 12:17:22 -0300 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <466012A4.90608@gatworks.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> <466012A4.90608@gatworks.com> Message-ID: <46603882.5050701@gmail.com> Uncle George escribi?: > Manuel Naranjo wrote: > In the case of my module, you can > >> unplug the device but it will not delete the symlink until those apps >> that had opened the port has closed it. T >> > > Did u also mean for this to happen? USB0 was not closed by application. > > Apparently USB1 got created when USB device was plugged back in. There > is only one USB device on a 4 port USB hub. > > This also seems to suggest that application recovery to be impossible. > Exactly there's a dead symlink (you can read and write to it and nothing will happen) and a new port will be created when a new device is connencted. From netbeans at gatworks.com Fri Jun 1 10:20:46 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 12:20:46 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <46603882.5050701@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> <466012A4.90608@gatworks.com> <46603882.5050701@gmail.com> Message-ID: <4660475E.5090202@gatworks.com> Not sure what u mean by "symlink". U cant read/write to it anymore. U get I/O error. In this scenario the device effectively went dead, and only solution is to close the channel. reconnecting the USB device, although dead, but not closed, will create a second device. This does not seem to be a desirable side-effect. The user will now have ttyUSB1, wondering where did ttyUSB0 go to. The application will also be in a confused state, as well as RXTX, because RXTX wont know about ttyUSB1. Manuel Naranjo wrote: > Uncle George escribi?: >> Manuel Naranjo wrote: >> In the case of my module, you can >> >>> unplug the device but it will not delete the symlink until those apps >>> that had opened the port has closed it. T >>> >> Did u also mean for this to happen? USB0 was not closed by application. >> >> Apparently USB1 got created when USB device was plugged back in. There >> is only one USB device on a 4 port USB hub. >> >> This also seems to suggest that application recovery to be impossible. >> > Exactly there's a dead symlink (you can read and write to it and nothing > will happen) and a new port will be created when a new device is connencted. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From arnab.bhaumik at gmail.com Mon Jun 4 01:40:16 2007 From: arnab.bhaumik at gmail.com (arnab bhaumik) Date: Mon, 4 Jun 2007 13:10:16 +0530 Subject: [Rxtx] full duplex com port with rxtx Message-ID: hi , till now i did half duplex communication with rxtx package on com package. my question is : is it possible to use com port with full duplex mode with rxtx package . ther is example of SimpleRead class and SimpleWrite class. it is clear that if i can use both the class simultaneously then full duplex is possible......... arnab/vu2bpw -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070604/6edb0453/attachment-0008.html From lists at iDIAcomputing.com Mon Jun 4 07:53:17 2007 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Mon, 04 Jun 2007 09:53:17 -0400 Subject: [Rxtx] full duplex com port with rxtx In-Reply-To: References: Message-ID: <4664194D.90301@iDIAcomputing.com> arnab bhaumik wrote: > hi , > > till now i did half duplex communication with rxtx package on com > package. > > my question is : is it possible to use com port with full duplex mode > with rxtx package . > > > ther is example of SimpleRead class and SimpleWrite class. it is > clear that if i can use both the class simultaneously then full duplex > is possible......... I haven't looked at the SimpleRead and SimpleWrite classes (I originally wrote my code for the javax.comm api), but full duplex is certainly possible. My CommReader class requires an object analogous to a OutputStream or Writer. When started, it spawns a thread that reads the comm port and writes to that output device. In this way the input is asynchronous and dependent on the actual input data. For full duplex, I extend that class with CommReaderWriter, which adds synchronous output methods. Hope that helps, George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From supsoop at hotmail.com Mon Jun 4 15:21:06 2007 From: supsoop at hotmail.com (soop soop) Date: Mon, 04 Jun 2007 21:21:06 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- Message-ID: Hi Guys, Looked through the archives but still cannot figure this out. I have a Motorola G24 GPRS/GSM modem that I am connecting to my server running Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not detecting the port, CommPortIdentifier.getPortIdentifiers(). I have added the line to RXTXCommDriver: "ttyACM" // for USB Modems Rxtx still does not seem to find the port. Is there something I am missing to make this port visable? [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control Model driver for USB modems and ISDN adapters I really need your help as I have moved my server from windows to Linux and have been down for a few days because of this .. Thanks so much! _________________________________________________________________ PC Magazine’s 2007 editors’ choice for best Web mail—award-winning Windows Live Hotmail. http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 From tjarvi at qbang.org Mon Jun 4 16:17:35 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Jun 2007 16:17:35 -0600 (MDT) Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: On Mon, 4 Jun 2007, soop soop wrote: > Hi Guys, > > Looked through the archives but still cannot figure this out. I have a > Motorola G24 GPRS/GSM modem that I am connecting to my server running Ubuntu. > I can see my modem as is shows up as ttyACM0, but RXTX is not detecting the > port, CommPortIdentifier.getPortIdentifiers(). > > I have added the line to RXTXCommDriver: > > "ttyACM" // for USB Modems > > Rxtx still does not seem to find the port. Is there something I am missing to > make this port visable? > > [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver > [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device > [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control Model > driver for USB modems and ISDN adapters > > I really need your help as I have moved my server from windows to Linux and > have been down for a few days because of this .. Thanks so much! > You could try the INSTALL documentation that comes with the source for possible solutions. Those usually involve lockfile creation, permissions on the device file or the device is in use by another application (even another session of your application). The usual commands: ls -l /dev/ttyACM0 fuser /dev/ttyACM0 touch /var/lock/LCK.testfile && rm -f /var/lock/LCK.testfile whoami To disable lockfiles: ../configure --disable-lockfiles && make install -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Jun 4 16:22:52 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 04 Jun 2007 18:22:52 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <466490BC.3090801@gatworks.com> soop soop wrote: > I really need your help as I have moved my server from windows to Linux > and have been down for a few days because of this .. Thanks so much! can u open the device ? ie is the file protection/permissions keeping you out? From supsoop at hotmail.com Mon Jun 4 16:44:40 2007 From: supsoop at hotmail.com (soop soop) Date: Mon, 04 Jun 2007 22:44:40 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <466490BC.3090801@gatworks.com> Message-ID: Thanks for the reply, I see no exceptions being thrown, just no detection of the port whats so ever. I will run rxtx in debug mode and log. If this were a permissions issue would I not see some exceptions being thrown? >From: Uncle George >Reply-To: RXTX Developers and Users >To: RXTX Developers and Users >Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >Date: Mon, 04 Jun 2007 18:22:52 -0400 > >soop soop wrote: > > > I really need your help as I have moved my server from windows to Linux > > and have been down for a few days because of this .. Thanks so much! > >can u open the device ? ie is the file protection/permissions keeping >you out? >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ Get a preview of Live Earth, the hottest event this summer - only on MSN http://liveearth.msn.com?source=msntaglineliveearthhm From netbeans at gatworks.com Mon Jun 4 17:06:15 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 04 Jun 2007 19:06:15 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <46649AE7.10405@gatworks.com> Exceptions on what? On startup it wants to lookup all devices in /dev that it is capable of opening ( within the list of specific 'comm' devices ). If it cannot open, then does not get onto list. Part of this process, if configured, will also test if the "LOCK" schema can also be opened for the device. then it gets on the list of avail comm port. soop soop wrote: > Thanks for the reply, > > I see no exceptions being thrown, just no detection of the port whats so > ever. I will run rxtx in debug mode and log. If this were a permissions > issue would I not see some exceptions being thrown? > > >> From: Uncle George >> Reply-To: RXTX Developers and Users >> To: RXTX Developers and Users >> Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >> Date: Mon, 04 Jun 2007 18:22:52 -0400 >> >> soop soop wrote: >> >>> I really need your help as I have moved my server from windows to Linux >>> and have been down for a few days because of this .. Thanks so much! >> can u open the device ? ie is the file protection/permissions keeping >> you out? >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _________________________________________________________________ > Get a preview of Live Earth, the hottest event this summer - only on MSN > http://liveearth.msn.com?source=msntaglineliveearthhm > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From alex.flint at gmail.com Mon Jun 4 21:31:49 2007 From: alex.flint at gmail.com (Alex Flint) Date: Tue, 5 Jun 2007 13:01:49 +0930 Subject: [Rxtx] random EXCEPTION_ACCESS_VIOLATION errors Message-ID: Hi All, I'm running winXP and RXTX 2.1-7r2 (the latest from the webpage as of June 2007). I'm sending sequences of 64 lines (each line has about 15 chars) at various intervals. The strings are sent fine, until I get the following error (from hs_err_pid3316.log, at the end of this email). What can I do to avoid the error? Obviously this is a low-level memory exception, but is there any way I can keep the JVM running after such an error? I noticed the exact same problem here: http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20070129/1180520.html Cheers, Alex # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x100034fb, pid=3316, tid=2400 # # Java VM: Java HotSpot(TM) Client VM (1.6.0_01-b06 mixed mode, sharing) # Problematic frame: # C [rxtxSerial.dll+0x34fb] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # --------------- T H R E A D --------------- Current thread (0x00386400): JavaThread "main" [_thread_in_native, id=2400] siginfo: ExceptionCode=0xc0000005, reading address 0x20726f78 Registers: EAX=0x20726f20, EBX=0x6d8922c0, ECX=0x00000005, EDX=0x20726f20 ESP=0x003efa30, EBP=0x003efb68, ESI=0x269728a0, EDI=0x00386400 EIP=0x100034fb, EFLAGS=0x00010212 Top of Stack: (sp=0x003efa30) 0x003efa30: 003efa3c 003efa64 0000000f ffffffff 0x003efa40: 003efa40 2a97f808 003efa6c 2b190ca8 0x003efa50: 00000000 2b190ec0 003efa90 008e2dd7 0x003efa60: 003efa90 008e2dd7 26977f88 6d815e72 0x003efa70: 00000004 2696eae0 0000008a 003efb0c 0x003efa80: 6d852b4a 2696eae0 00000003 26970930 0x003efa90: 000000cb 2696eae0 6d86b264 00385d40 0x003efaa0: 0000003f 003efb0c 26977f90 2ace65d8 Instructions: (pc=0x100034fb) 0x100034eb: ff ff 8d 76 00 eb 02 89 f6 90 8b 45 f8 8b 55 f8 0x100034fb: 8b 4a 58 83 c9 04 89 48 58 83 c4 f8 8b 45 f8 8b Stack: [0x003a0000,0x003f0000), sp=0x003efa30, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x34fb] Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j gnu.io.RXTXPort.writeArray([BIIZ)V+0 j gnu.io.RXTXPort$SerialOutputStream.write([B)V+76 j com.bjt.media.server.CommLink.send(Ljava/lang/String;)V+48 j com.bjt.media.server.DigitoolConnection.select(I)V+73 j com.bjt.media.server.DigitoolConnection.main([Ljava/lang/String;)V+74 v ~StubRoutines::call_stub --------------- P R O C E S S --------------- Java Threads: ( => current thread ) 0x02a69400 JavaThread "Thread-0" [_thread_in_native, id=3052] 0x02a4d000 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=3920] 0x02a48400 JavaThread "CompilerThread0" daemon [_thread_blocked, id=1968] 0x02a47400 JavaThread "Attach Listener" daemon [_thread_blocked, id=2984] 0x02a46400 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=2660] 0x02a41c00 JavaThread "Finalizer" daemon [_thread_blocked, id=3924] 0x02a3d800 JavaThread "Reference Handler" daemon [_thread_blocked, id=4008] =>0x00386400 JavaThread "main" [_thread_in_native, id=2400] Other Threads: 0x02a34400 VMThread [id=3708] 0x02a4e800 WatcherThread [id=3964] VM state:not at safepoint (normal execution) VM Mutex/Monitor currently owned by a thread: None Heap def new generation total 960K, used 131K [0x22960000, 0x22a60000, 0x22e40000) eden space 896K, 7% used [0x22960000, 0x22970ea8, 0x22a40000) from space 64K, 99% used [0x22a50000, 0x22a5fff8, 0x22a60000) to space 64K, 0% used [0x22a40000, 0x22a40000, 0x22a50000) tenured generation total 4096K, used 76K [0x22e40000, 0x23240000, 0x26960000) the space 4096K, 1% used [0x22e40000, 0x22e53060, 0x22e53200, 0x23240000) compacting perm gen total 12288K, used 137K [0x26960000, 0x27560000, 0x2a960000) the space 12288K, 1% used [0x26960000, 0x26982518, 0x26982600, 0x27560000) ro space 8192K, 62% used [0x2a960000, 0x2ae5e4e8, 0x2ae5e600, 0x2b160000) rw space 12288K, 52% used [0x2b160000, 0x2b7a0e78, 0x2b7a1000, 0x2bd60000) Dynamic libraries: 0x00400000 - 0x00423000 C:\Program Files\Java\jre1.6.0_01\bin\javaw.exe 0x7c900000 - 0x7c9b0000 C:\WINDOWS\system32\ntdll.dll 0x7c800000 - 0x7c8f4000 C:\WINDOWS\system32\kernel32.dll 0x77dd0000 - 0x77e6b000 C:\WINDOWS\system32\ADVAPI32.dll 0x77e70000 - 0x77f01000 C:\WINDOWS\system32\RPCRT4.dll 0x7e410000 - 0x7e4a0000 C:\WINDOWS\system32\USER32.dll 0x77f10000 - 0x77f57000 C:\WINDOWS\system32\GDI32.dll 0x76390000 - 0x763ad000 C:\WINDOWS\system32\IMM32.DLL 0x7c340000 - 0x7c396000 C:\Program Files\Java\jre1.6.0_01\bin\msvcr71.dll 0x6d7c0000 - 0x6da07000 C:\Program Files\Java\jre1.6.0_01\bin\client\jvm.dll 0x76b40000 - 0x76b6d000 C:\WINDOWS\system32\WINMM.dll 0x5cd70000 - 0x5cd77000 C:\WINDOWS\system32\serwvdrv.dll 0x5b0a0000 - 0x5b0a7000 C:\WINDOWS\system32\umdmxfrm.dll 0x6d310000 - 0x6d318000 C:\Program Files\Java\jre1.6.0_01\bin\hpi.dll 0x76bf0000 - 0x76bfb000 C:\WINDOWS\system32\PSAPI.DLL 0x6d770000 - 0x6d77c000 C:\Program Files\Java\jre1.6.0_01\bin\verify.dll 0x6d3b0000 - 0x6d3cf000 C:\Program Files\Java\jre1.6.0_01\bin\java.dll 0x6d7b0000 - 0x6d7bf000 C:\Program Files\Java\jre1.6.0_01\bin\zip.dll 0x10000000 - 0x10012000 C:\Documents and Settings\Alex\workspace\MediaServer\rxtxSerial.dll 0x73d90000 - 0x73db7000 C:\WINDOWS\system32\crtdll.dll VM Arguments: jvm_args: -Djava.library.path=C:\Documents and Settings\Alex\workspace\MediaServer java_command: com.bjt.media.server.DigitoolConnection Launcher Type: SUN_STANDARD Environment Variables: CLASSPATH=.;C:\Program Files\Java\j2re1.4.2_07\lib\ext\QTJava.zip PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\wbem;c:\applications\php;C:\Program Files\MATLAB\R2006a\bin\win32;C:\Roger\Projects\UAV\Bin\Debug;C:\Program Files\Microsoft SQL Server\80\Tools\Binn\;c:\Program Files\Microsoft SQL Server\90\Tools\binn\;C:\Program Files\QuickTime\QTSystem\;C:\Pfps\system;C:\Program Files\Java\jdk1.6.0_01\bin;C:\Program Files\Java\jdk1.6.0_01\jre\bin USERNAME=Alex OS=Windows_NT PROCESSOR_IDENTIFIER=x86 Family 15 Model 4 Stepping 1, GenuineIntel --------------- S Y S T E M --------------- OS: Windows XP Build 2600 Service Pack 2 CPU:total 1 family 15, cmov, cx8, fxsr, mmx, sse, sse2 Memory: 4k page, physical 1046508k(275288k free), swap 2522816k(1909176k free) vm_info: Java HotSpot(TM) Client VM (1.6.0_01-b06) for windows-x86, built on Mar 14 2007 00:24:02 by "java_re" with unknown MS VC++:1310 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070604/c87ae1f0/attachment-0008.html From alwyn.schoeman at gmail.com Tue Jun 5 00:10:19 2007 From: alwyn.schoeman at gmail.com (Alwyn Schoeman) Date: Tue, 5 Jun 2007 08:10:19 +0200 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Hi, I'm using a similar modem. By default rxtx doesn't look for devices that start with ACM, so you need to modify the source code and recompile. Look in RXTXCommDriver and add values for ACM in the registerScannedPorts method in the Linux specific parts. Look for osName.equals("Linux")... On 6/4/07, soop soop wrote: > > Hi Guys, > > Looked through the archives but still cannot figure this out. I have a > Motorola G24 GPRS/GSM modem that I am connecting to my server running > Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not > detecting the port, CommPortIdentifier.getPortIdentifiers(). > > I have added the line to RXTXCommDriver: > > "ttyACM" // for USB Modems > > Rxtx still does not seem to find the port. Is there something I am missing > to make this port visable? > > [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver > [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device > [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control > Model > driver for USB modems and ISDN adapters > > I really need your help as I have moved my server from windows to Linux > and > have been down for a few days because of this .. Thanks so much! > > _________________________________________________________________ > PC Magazine's 2007 editors' choice for best Web mail?award-winning Windows > Live Hotmail. > > http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -- Alwyn Schoeman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/b6cb3053/attachment-0008.html From naranjo.manuel at gmail.com Tue Jun 5 06:48:45 2007 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Tue, 05 Jun 2007 09:48:45 -0300 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> References: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Message-ID: <46655BAD.7010501@gmail.com> That's right, an easier solution is creating symlinks to acm. For example make ttyS70 to 79 point to ACM0 to 9 and that will help you a lot, and doesn't even require compile. > Hi, > > I'm using a similar modem. By default rxtx doesn't look for devices > that start with ACM, so you need to modify the > source code and recompile. > > Look in RXTXCommDriver and add values for ACM in the > registerScannedPorts method in the Linux specific parts. Look for > osName.equals("Linux")... > From juanemc2 at gmail.com Tue Jun 5 07:02:43 2007 From: juanemc2 at gmail.com (Juan) Date: Tue, 5 Jun 2007 10:02:43 -0300 Subject: [Rxtx] Problems with Epson TMU220B POSPrinter using XON/XOFF Flow Control and rxtx jar and dll's with the serial port. Message-ID: Hi!, I?m having trouble printing to the serial port using the latest version of rxtx jar and dll's with an Epson POSPrinter. I`ve switched the printer to work with XON/XOFF Flow Control and have watched the serial port to be sure the printer is sending the XON XOFF stop and go characters. I`ve setted the port like this: CommPortIdentifier commPortIdentifier = CommPortIdentifier.* getPortIdentifier*(_portName); SerialPort serialPort = (SerialPort)commPortIdentifier.open(*this*.getClass().getName(), 2000); serialPort.setSerialPortParams(_baudRate, _dataBits, _stopBits, _parity); serialPort.setFlowControlMode( SerialPort.*FLOWCONTROL_XONXOFF_IN* | SerialPort.*FLOWCONTROL_XONXOFF_OUT*); where the baudRate is 9600 the dataBits is 8 the stopBits is 1 and the parity is 0 It seems as the library isn`t taking into account the XON XOFF setting. I would like to know if I`m setting correctly the Flow Control and if you had had any experiences using XON XOFF flow control and could give me some help to solve my problem. I`m very thankful in advance, Yours, Juan Polero -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/b080995a/attachment-0008.html From ehdez.correo at gmail.com Tue Jun 5 07:12:53 2007 From: ehdez.correo at gmail.com (=?ISO-8859-1?Q?Enrique_Hern=E1ndez?=) Date: Tue, 5 Jun 2007 09:12:53 -0400 Subject: [Rxtx] problem with rxtx Message-ID: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Hello: I doing a simple test to show the serial ports. This is the code: import java.util.Enumeration; import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; public class Show { private Enumeration portList; private CommPortIdentifier portId; private SerialPort port; /** Creates a new instance of Show */ public Show() { } public static void main(String args[]){ Show show = new Show(); show.portList = CommPortIdentifier.getPortIdentifiers(); String tPort = ""; System.out.println("========================================="); while(show.portList.hasMoreElements()){ show.portId = (CommPortIdentifier)show.portList.nextElement(); if(show.portId.getPortType() == CommPortIdentifier.PORT_SERIAL) tPort = "Serial"; else tPort = "Parallel"; System.out.println(show.portId.getName() + " " + tPort); } } } whit The problem is that this code not show the serial ports, this show the no use serial ports. I want to connect whit the modem but when windows open and connect the modem my application don't see the port(COMM3) when it is connect. what I can do? Is that the correct way to know the ports? thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/eedd744b/attachment-0008.html From ehdez.correo at gmail.com Tue Jun 5 07:42:13 2007 From: ehdez.correo at gmail.com (=?ISO-8859-1?Q?Enrique_Hern=E1ndez?=) Date: Tue, 5 Jun 2007 09:42:13 -0400 Subject: [Rxtx] serial port Message-ID: <4a814e1f0706050642p4ce9ac7bka80f9479c524c5ea@mail.gmail.com> Hello: How I can ask to the port what device is connect and information about this device. thanks. bye. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/4d10d26a/attachment-0008.html From supsoop at hotmail.com Tue Jun 5 09:29:00 2007 From: supsoop at hotmail.com (soop soop) Date: Tue, 05 Jun 2007 15:29:00 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Message-ID: Hi Guys, Thanks for all your help. I found the problem. I created a user, Tomcat55, for my tomcat but it did not belong to any group. I then added this user to dialout group to have access to the device ttyACM0. Works perfectly! Again permissions was the issue. This also seems to be persistent as a server reboot does not effect the access. Cheers! >From: "Alwyn Schoeman" >Reply-To: RXTX Developers and Users >To: "RXTX Developers and Users" >Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >Date: Tue, 5 Jun 2007 08:10:19 +0200 > >Hi, > >I'm using a similar modem. By default rxtx doesn't look for devices that >start with ACM, so you need to modify the >source code and recompile. > >Look in RXTXCommDriver and add values for ACM in the registerScannedPorts >method in the Linux specific parts. Look for osName.equals("Linux")... > >On 6/4/07, soop soop wrote: >> >>Hi Guys, >> >>Looked through the archives but still cannot figure this out. I have a >>Motorola G24 GPRS/GSM modem that I am connecting to my server running >>Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not >>detecting the port, CommPortIdentifier.getPortIdentifiers(). >> >>I have added the line to RXTXCommDriver: >> >>"ttyACM" // for USB Modems >> >>Rxtx still does not seem to find the port. Is there something I am missing >>to make this port visable? >> >>[ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver >>[ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device >>[ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control >>Model >>driver for USB modems and ISDN adapters >> >>I really need your help as I have moved my server from windows to Linux >>and >>have been down for a few days because of this .. Thanks so much! >> >>_________________________________________________________________ >>PC Magazine's 2007 editors' choice for best Web mail—award-winning Windows >>Live Hotmail. >> >>http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 >> >> >>_______________________________________________ >>Rxtx mailing list >>Rxtx at qbang.org >>http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > >-- >Alwyn Schoeman >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ Need a break? Find your escape route with Live Search Maps. http://maps.live.com/default.aspx?ss=Restaurants~Hotels~Amusement%20Park&cp=33.832922~-117.915659&style=r&lvl=13&tilt=-90&dir=0&alt=-1000&scene=1118863&encType=1&FORM=MGAC01 From netbeans at gatworks.com Tue Jun 5 09:42:31 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 11:42:31 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <46658467.20101@gatworks.com> soop soop wrote: > > Hi Guys, > > Thanks for all your help. I found the problem. I created a user, > Tomcat55, for my tomcat but it did not belong to any group. I then added Look at man pages for the program udev. From tjarvi at qbang.org Tue Jun 5 18:18:17 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Jun 2007 18:18:17 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Message-ID: On Tue, 5 Jun 2007, Enrique Hern?ndez wrote: > The problem is that this code not show the serial ports, this show the no > use serial ports. I want to connect whit the modem but when windows open and > connect the modem my application don't see the port(COMM3) when it is > connect. > what I can do? > Is that the correct way to know the ports? > Hello, We may have problems understanding each other. On windows, the port will not be an available serial port if another application has the port open. That is just how the library behaves. If you can not see the port in the enumerated list, you could not open it. Also note that enumeration only happens once. If you add a port such as a new USB dongle, the port will not be visible until the next time your application runs. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Tue Jun 5 18:45:01 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 20:45:01 -0400 Subject: [Rxtx] problem with rxtx In-Reply-To: References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Message-ID: <4666038D.8090700@gatworks.com> Trent Jarvi wrote: > > > Also note that enumeration only happens once. If you add a port such as > a new USB dongle, the port will not be visible until the next time your > application runs. Is this written in stone ? somewhere? From tjarvi at qbang.org Tue Jun 5 18:54:36 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Jun 2007 18:54:36 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <4666038D.8090700@gatworks.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> Message-ID: On Tue, 5 Jun 2007, Uncle George wrote: > Trent Jarvi wrote: >> >> >> Also note that enumeration only happens once. If you add a port such as >> a new USB dongle, the port will not be visible until the next time your >> application runs. > > Is this written in stone ? somewhere? It is just the current behavior. There is nothing preventing a fix that allows reenumeration. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Tue Jun 5 19:55:19 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 21:55:19 -0400 Subject: [Rxtx] problem with rxtx In-Reply-To: References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> Message-ID: <46661407.4020308@gatworks.com> >> Is this written in stone ? somewhere? > > It is just the current behavior. There is nothing preventing a fix that > allows reenumeration. With usb, ..... , things come and go. Seems a shame that you have to kill application to get at the device u just plugged in. From joachim at buechse.ch Wed Jun 6 01:50:06 2007 From: joachim at buechse.ch (Joachim Buechse) Date: Wed, 6 Jun 2007 09:50:06 +0200 Subject: [Rxtx] problem with rxtx In-Reply-To: <46661407.4020308@gatworks.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> <46661407.4020308@gatworks.com> Message-ID: <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> On MacOS RXTX's enumeration handling is more flexible. It will find new ports that are added during the lifetime of the application. But this is inherently incompatible with suns javax.comm implementation... Regards, Joachim On 06.06.2007, at 03:55, Uncle George wrote: > >>> Is this written in stone ? somewhere? >> >> It is just the current behavior. There is nothing preventing a >> fix that >> allows reenumeration. > > With usb, ..... , things come and go. Seems a shame that you have to > kill application to get at the device u just plugged in. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Jun 6 06:06:48 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Jun 2007 06:06:48 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> <46661407.4020308@gatworks.com> <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> Message-ID: Sun's javax.comm is not a major concern going forward. As long as we do not break old applications using rxtx, I see no reason to limit rxtx to that convention. We have already rejected version 3 from Sun as a dead end and limited our compatability to version 2. That does not mean we will not try to work with Sun and others but the current javax.comm convention (v3) is not a well conceived path. There has been discussion about doing a JSR which is one valid option. On Wed, 6 Jun 2007, Joachim Buechse wrote: > On MacOS RXTX's enumeration handling is more flexible. It will find > new ports that are added during the lifetime of the application. But > this is inherently incompatible with suns javax.comm implementation... > > Regards, > Joachim > > On 06.06.2007, at 03:55, Uncle George wrote: > >> >>>> Is this written in stone ? somewhere? >>> >>> It is just the current behavior. There is nothing preventing a >>> fix that >>> allows reenumeration. >> >> With usb, ..... , things come and go. Seems a shame that you have to >> kill application to get at the device u just plugged in. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From yvespielusenet at free.fr Wed Jun 6 08:46:35 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 16:46:35 +0200 Subject: [Rxtx] [PARALLEL] resource in use Message-ID: <1181141195.3407.20.camel@localhost.localdomain> Hello, I want to use rxtx in my application. I haveto send data to a very old printer (which have a drum and hammers http://perso.orange.fr/tiie/page00010017.html) This is printer is connecter with centronics. It works well but, while it's writting and I putthe printer off-line, after about 45 seconds, I have this error : ------------------------------------- java.io.IOException: La ressource demand?e est en cours d'utilisation. in writeArray at gnu.io.LPRPort.writeArray(Native Method) at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:292) at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:161) at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:156) at mce.buffer.bufferManager.BufferManager$PrintBuffer.run(BufferManager.java:141) The IOexception means "The wanted resource is in use" ------------------------------------- Here is the line 141 of BufferManager : ------------------------------------- while(send){ try{ fos.write(bb); <=== line 141 send = false; } catch(Exception e){ javax.swing.JOptionPane.showMessageDialog(null, "Erreur d'envoie. Veuillez cliquer sur OK pour relancer l'impression de la vignette.\nV?rifiez votre impression !", "Erreur d'envoie", javax.swing.JOptionPane.WARNING_MESSAGE); e.printStackTrace(System.err); System.err.flush(); System.out.println(e); send = true; } } -------------------------------- 'fos' is an outputstream which contains the rxtx stream (this.os is the rxtx outputstream) : -------------------------------- public void write(byte[] bb) throws IOException{ this.write(bb, 0, bb.length); } public void write(byte[] bb, int off, int len) throws IOException{ while(!imp1.isPrinterSelected() || !imp2.isPrinterSelected()){ } this.os.write(bb, off, len); } -------------------------------- Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( can you help me ? thank you :) -- yves piel From yvespielusenet at free.fr Wed Jun 6 09:11:15 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 17:11:15 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181141195.3407.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> Message-ID: <1181142675.3407.23.camel@localhost.localdomain> I forgot to tell that It's under windows XP and java 1.5. Le mercredi 06 juin 2007 ? 16:46 +0200, yves pielusenet a ?crit : > Hello, > I want to use rxtx in my application. I haveto send data to a very old > printer (which have a drum and hammers > http://perso.orange.fr/tiie/page00010017.html) > This is printer is connecter with centronics. It works well but, while > it's writting and I putthe printer off-line, after about 45 seconds, I > have this error : > ------------------------------------- > java.io.IOException: La ressource demand?e est en cours d'utilisation. > in writeArray > at gnu.io.LPRPort.writeArray(Native Method) > at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:292) > at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:161) > at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:156) > at mce.buffer.bufferManager.BufferManager$PrintBuffer.run(BufferManager.java:141) > > The IOexception means "The wanted resource is in use" > ------------------------------------- > > Here is the line 141 of BufferManager : > > ------------------------------------- > while(send){ > try{ > fos.write(bb); <=== line 141 > send = false; > } > catch(Exception e){ > javax.swing.JOptionPane.showMessageDialog(null, "Erreur d'envoie. Veuillez cliquer sur OK pour relancer l'impression de la vignette.\nV?rifiez votre impression !", "Erreur d'envoie", javax.swing.JOptionPane.WARNING_MESSAGE); > e.printStackTrace(System.err); > System.err.flush(); > System.out.println(e); > send = true; > } > } > -------------------------------- > 'fos' is an outputstream which contains the rxtx stream (this.os is the rxtx outputstream) : > > -------------------------------- > public void write(byte[] bb) throws IOException{ > this.write(bb, 0, bb.length); > } > public void write(byte[] bb, int off, int len) throws IOException{ > while(!imp1.isPrinterSelected() || !imp2.isPrinterSelected()){ > } > this.os.write(bb, off, len); > } > -------------------------------- > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > can you help me ? > > thank you :) > From netbeans at gatworks.com Wed Jun 6 09:21:46 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 11:21:46 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181141195.3407.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> Message-ID: <4666D10A.8000507@gatworks.com> } > -------------------------------- > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > can you help me ? > > thank you :) > windoz or linux? ( I guess windoz ) for windoz, there appears to be a timeout ( as Comments suggest ) of about 40seconds. > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } for linux, there is no implied timeout. > if( write( fd, bytes, count ) < 0 ) > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); From netbeans at gatworks.com Wed Jun 6 09:39:41 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 11:39:41 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666D10A.8000507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> Message-ID: <4666D53D.90000@gatworks.com> Uncle George wrote: > } >> -------------------------------- >> >> Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( >> >> can you help me ? From reading the code, I can see your concern. And it appears you are correct, because some of the data will be sent to the OS printer buffers, and then it will refuse to accept anymore. Unfortunately, writeArray does not return the num of characters written :{ So application has no idea to how many characters were accepted by the OS. I dont do windoz, so I cant say with absolute certainty what windoz will do with an off-line condition. If you have the source, and can compile, then maybe u can increase the loop count to hit 4hours? From yvespielusenet at free.fr Wed Jun 6 09:53:25 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 17:53:25 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666D10A.8000507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> Message-ID: <1181145205.3407.35.camel@localhost.localdomain> Thank you for your explanation :) This timeout comes when no data has been send to the printer after 40seconds if I well understand. But why there is such a timeout ? If I setthe printer offline while it's printing I mustn't have an exception. I don't understand why the "printer should solv all problems like buffer full" in 40 seconds. If I pause the printer the buffer will not be emptied, isn't it ? I not very familiar with C/C++, but it seem that the exception is thrown only when countWritten == 0, that means no data at all has been sent. So Is my code is good since when I intercept this exception I send all my buffer again. There is no way that the printer receive two times same bytes ? thanks ps: yes the application is running on windows XP since I developpe under Debian Le mercredi 06 juin 2007 ? 11:21 -0400, Uncle George a ?crit : > } > > -------------------------------- > > > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > > > can you help me ? > > > > thank you :) > > > > windoz or linux? ( I guess windoz ) > > for windoz, there appears to be a timeout ( as Comments suggest ) of > about 40seconds. > > while( count > 0 ){ > > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > > /* > > this are 20 * 2 seconds, in this time a printer (or other parallel device) > > should solv all problems like buffer full, etc > > */ > > if(errorCount++ < 20){ > > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > > continue; > > } > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > for linux, there is no implied timeout. > > if( write( fd, bytes, count ) < 0 ) > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Wed Jun 6 10:34:24 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 12:34:24 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181145205.3407.35.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> Message-ID: <4666E210.30507@gatworks.com> yves pielusenet wrote: > Thank you for your explanation :) > This timeout comes when no data has been send to the printer after > 40seconds if I well understand. But why there is such a timeout ? If I > setthe printer offline while it's printing I mustn't have an exception. > I don't understand why the "printer should solv all problems like buffer > full" in 40 seconds. If I pause the printer the buffer will not be > emptied, isn't it ? > > I not very familiar with C/C++, but it seem that the exception is thrown > only when countWritten == 0, that means no data at all has been sent. So > Is my code is good since when I intercept this exception I send all my > buffer again. There is no way that the printer receive two times same > bytes ? More technically, the function call returns and reports that 0 characters was written in this call. when 0 characters are written, it will check how many times 0 characters was written. If it has tried LESS than 20 times(errorCount), it will sleep() and try to write again. After 20 times, it wont sleep, but throw you the exception. Now suppose you are writing a 120 character line. you off-lined/paused your printer. The OS has room for 80 more characters in it's printer buffer. The WriteFile() will have a char count of 120, but on return the countWritten = 80. You still have 40 more characters to print. Since countWritten != 0, the counters: bytes += countWritten; count -= countWritten; get updated, and the Writefile now has a count of 40 characters. Since the printer is off-line, the countwritten is 0. And so the loop continues, till 40 seconds is up. As to why it is this way, i dont know ( not a windoz maven ); Also the sleep(20) in the loop is not so intuitive to suggest 2 seconds of sleep. I would have guessed 20seconds, or 20milliseconds. But go figure. BTW: Since your computer sends you error messages in French, does it curse in English? :)))) From yvespielusenet at free.fr Thu Jun 7 02:27:44 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Thu, 07 Jun 2007 10:27:44 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666E210.30507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> Message-ID: <1181204864.3501.10.camel@localhost.localdomain> Maybe in my case I should re-compile rxtx and change the code. Instead of send an exception I should display a dialog box to ask if it's printer problem or if it should trie to send bytes. Something like : while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } if(displayDialogBox("Try again to send datas ??")){ errorCount = 0; } else{ throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } } Le mercredi 06 juin 2007 ? 12:34 -0400, Uncle George a ?crit : > yves pielusenet wrote: > > Thank you for your explanation :) > > This timeout comes when no data has been send to the printer after > > 40seconds if I well understand. But why there is such a timeout ? If I > > setthe printer offline while it's printing I mustn't have an exception. > > I don't understand why the "printer should solv all problems like buffer > > full" in 40 seconds. If I pause the printer the buffer will not be > > emptied, isn't it ? > > > > I not very familiar with C/C++, but it seem that the exception is thrown > > only when countWritten == 0, that means no data at all has been sent. So > > Is my code is good since when I intercept this exception I send all my > > buffer again. There is no way that the printer receive two times same > > bytes ? > More technically, the function call returns and reports that 0 > characters was written in this call. > when 0 characters are written, it will check how many times 0 characters > was written. If it has tried LESS than 20 times(errorCount), it will > sleep() and try to write again. > After 20 times, it wont sleep, but throw you the exception. > > Now suppose you are writing a 120 character line. you off-lined/paused > your printer. The OS has room for 80 more characters in it's printer > buffer. The WriteFile() will have a char count of 120, but on return the > countWritten = 80. You still have 40 more characters to print. > Since countWritten != 0, the counters: > bytes += countWritten; > count -= countWritten; > get updated, and the Writefile now has a count of 40 characters. Since > the printer is off-line, the countwritten is 0. And so the loop > continues, till 40 seconds is up. > > As to why it is this way, i dont know ( not a windoz maven ); > Also the sleep(20) in the loop is not so intuitive to suggest 2 seconds > of sleep. I would have guessed 20seconds, or 20milliseconds. But go figure. > > BTW: Since your computer sends you error messages in French, does it > curse in English? :)))) > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 06:11:43 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 08:11:43 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181204864.3501.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> Message-ID: <4667F5FF.8070903@gatworks.com> your suggestion appears good. I dont know what displayDialogBox exactly will do, so all I can say it that it looks good. But I'd like to wait 10min before first dialog box And a 5 min wait for every dialog box there after. And since these are custom solution/choices, maybe a more exact explanation of what the issue is. if(errorCount++ < 300){ // wait 10min ( 10min * 60sec / 2 ) Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } if(displayDialogBox("Printer has Paused. Retry sending data?")){ errorCount = 150; // Wait for 5 min thereafter continue; } > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } yves pielusenet wrote: > Maybe in my case I should re-compile rxtx and change the code. Instead > of send an exception I should display a dialog box to ask if it's > printer problem or if it should trie to send bytes. Something like : > > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > > if(displayDialogBox("Try again to send datas ??")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > } > From yvespielusenet at free.fr Thu Jun 7 07:17:21 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Thu, 07 Jun 2007 15:17:21 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4667F5FF.8070903@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <4667F5FF.8070903@gatworks.com> Message-ID: <1181222241.3501.20.camel@localhost.localdomain> thank you :) 'displayDialogBox()' I think doesn't exist. It was just for the example :) But I think It should not be so complicated to display a dialog box under windows with YES/NO buttons. When yes is clicked it return 0 other it returns 1. Le jeudi 07 juin 2007 ? 08:11 -0400, Uncle George a ?crit : > your suggestion appears good. I dont know what displayDialogBox exactly > will do, so all I can say it that it looks good. > > But I'd like to wait 10min before first dialog box And a 5 min wait for > every dialog box there after. And since these are custom > solution/choices, maybe a more exact explanation of what the issue is. > > if(errorCount++ < 300){ // wait 10min ( 10min * 60sec / 2 ) > Sleep( 20 ); /* make a small pause to execute all other requests > in all other threads */ > continue; > } > > if(displayDialogBox("Printer has Paused. Retry sending data?")){ > errorCount = 150; // Wait for 5 min thereafter > continue; > } > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > > yves pielusenet wrote: > > Maybe in my case I should re-compile rxtx and change the code. Instead > > of send an exception I should display a dialog box to ask if it's > > printer problem or if it should trie to send bytes. Something like : > > > > while( count > 0 ){ > > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > > /* > > this are 20 * 2 seconds, in this time a printer (or other parallel device) > > should solv all problems like buffer full, etc > > */ > > if(errorCount++ < 20){ > > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > > continue; > > } > > > > if(displayDialogBox("Try again to send datas ??")){ > > errorCount = 0; > > } > > else{ > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > } > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 07:41:43 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 09:41:43 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181222241.3501.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <4667F5FF.8070903@gatworks.com> <1181222241.3501.20.camel@localhost.localdomain> Message-ID: <46680B17.8050109@gatworks.com> yves pielusenet wrote: > thank you :) > 'displayDialogBox()' I think doesn't exist. It was just for the > example :) too bad. Good luck. From rtrout at webbresearch.com Thu Jun 7 11:23:04 2007 From: rtrout at webbresearch.com (Robert Trout) Date: Thu, 07 Jun 2007 13:23:04 -0400 Subject: [Rxtx] Disconnected PortServer TS causes Java to hang Message-ID: <1181236984.14186.33.camel@sisyphus.DinkumSoftware.com> I'm running Linux with sun's Java 1.4.2, Java comm API 2.0, RXTX 2.0-7pre1, and the RealPort digi driver. "/dev/ttyrp00" is a RealPort device. My Java application never returns from a ComPortIdentifier.getPortIdentifier("/dev/ttyrp00") call while the Digi PortServer TS 4 is disconnected from the network. If I later re-connect the PortServer, the call returns about 30 seconds later (it's like a serial port read or write is blocking until the PortServer is re- connected). With the PortServer disconnected, minicom immediately responds with "cannot open /dev/ttyrp00: No such file or directory". I would like my Java application to behave similarly. That is, respond with an error condition instead of hanging when the PortServer is not connected. Since minicom and Java behave differently, I think this "hanging" behavior may be due to RXTX or Java? Has anyone had a similar issue? Solutions? Suggestions? Thanks, Robert From vicnevicne at gmail.com Thu Jun 7 12:16:02 2007 From: vicnevicne at gmail.com (Vicne) Date: Thu, 07 Jun 2007 20:16:02 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181204864.3501.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> Message-ID: <46684B62.7080802@gmail.com> yves pielusenet wrote: > Maybe in my case I should re-compile rxtx and change the code. Instead > of send an exception I should display a dialog box to ask if it's > printer problem or if it should trie to send bytes. Something like : > > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > > if(displayDialogBox("Try again to send datas ??")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > } > Sorry to step in without a specific solution to your problem, but I wanted to share my feeling regarding this proposal. AFAIK, it's generally considered bad practice to pop-up a prompt from a library. The main reason is that in general use, you can't guarantee that someone is actually present behind the console. Imagine a print server in a machine room, connected to a park of printers. In that case, when one printer fails, the logical behaviour would be to use an other one. If you change RxTx the way you propose, the printer queue will simply be stuck with a useless "Try again to send data ?" prompt until an administrator opens a remote connection to the print server's console and clicks "no". Second, it would create a dependency upon the existence of a graphical console (if you go the graphical "dialogBox" way). On many applications (typically server or embedded ones), the JVM is "headless" and if you try to pop-up a dialog, your app would throw an exception (at best) or just wouldn't display the prompt anywhere... Going the "text console" way is not more reliable, because on graphical environments, the text console is hidden unless explicitly requested. My advice would be to think again and find another solution. Ideas are : - make the number of retries a parameter so that you can tune it to what you think is reasonable - throw a more specific exception when the number of retries has been reached, so that a specific prompt can be shown at a higher level Anyway, if you feel that the prompt is the way to go in your case, I would at least make that prompt conditional. The least intrusive way would probably be using a system property, like if("true".equals(System.getProperty("org.rxtx.usePrompt")) && displayDialogBox("Retry sending data ?")){ errorCount = 0; } else{ throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } By default, the behaviour would remain as it is now, but you could force the prompts by defining the property at VM launch if desired. (for example : java.exe -Dorg.rxtx.usePrompt=true myApp) Also, you seemed to say you wanted the printer to start again exactly where is stopped. It would indeed be the best way when the printer is put offline for a few seconds. On the other hand, if the printer is turned off (or the printer runs out of paper, or someone steps on the mains cable), then the only way to go back to a "stable" situation would be by printing the item (page, label, etc.) again from scratch... Just my two cents. Vicne PS : By the way, the dialog box thing is very platform dependant on the C-side, and I think the simplest way would probably be to bridge it to a Java call where you can implement it like you proposed : public boolean displayDialogBox(prompt) { return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); } From netbeans at gatworks.com Thu Jun 7 14:08:24 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 16:08:24 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46684B62.7080802@gmail.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> Message-ID: <466865B8.4060004@gatworks.com> My feeling is that the code that was suggested was for his environs ( his shop ). The issue here is that after a 40+ second wait, an exception will be thrown. But you really dont have a way of 'cancelling' all the WriteFiles() that have already occured before the exception so that your writeArray and the Commapi can backtrack to a position in which they are in sync. The main ( really mine ) concern is not to lose data, or replicate data. After 40seconds, 300 seconds, 55min, no matter how long, data should not be lost or duplicated. But as soon as the exception is thrown, that possibility exists. Maybe an event should be thrown instead? Vicne wrote: > yves pielusenet wrote: >> Maybe in my case I should re-compile rxtx and change the code. Instead >> of send an exception I should display a dialog box to ask if it's >> printer problem or if it should trie to send bytes. Something like : >> >> while( count > 0 ){ >> if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ >> /* >> this are 20 * 2 seconds, in this time a printer (or other parallel device) >> should solv all problems like buffer full, etc >> */ >> if(errorCount++ < 20){ >> Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ >> continue; >> } >> >> if(displayDialogBox("Try again to send datas ??")){ >> errorCount = 0; >> } >> else{ >> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >> break; >> } >> } >> > > Sorry to step in without a specific solution to your problem, but I > wanted to share my feeling regarding this proposal. AFAIK, it's > generally considered bad practice to pop-up a prompt from a library. > The main reason is that in general use, you can't guarantee that > someone is actually present behind the console. Imagine a print server > in a machine room, connected to a park of printers. In that case, when > one printer fails, the logical behaviour would be to use an other one. > If you change RxTx the way you propose, the printer queue will simply be > stuck with a useless "Try again to send data ?" prompt until an > administrator opens a remote connection to the print server's console > and clicks "no". > Second, it would create a dependency upon the existence of a > graphical console (if you go the graphical "dialogBox" way). On many > applications (typically server or embedded ones), the JVM is "headless" > and if you try to pop-up a dialog, your app would throw an exception (at > best) or just wouldn't display the prompt anywhere... Going the "text > console" way is not more reliable, because on graphical environments, > the text console is hidden unless explicitly requested. > > My advice would be to think again and find another solution. Ideas are : > - make the number of retries a parameter so that you can tune it to what > you think is reasonable > - throw a more specific exception when the number of retries has been > reached, so that a specific prompt can be shown at a higher level > > Anyway, if you feel that the prompt is the way to go in your case, I > would at least make that prompt conditional. The least intrusive way > would probably be using a system property, like > > if("true".equals(System.getProperty("org.rxtx.usePrompt")) > && displayDialogBox("Retry sending data ?")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > > > By default, the behaviour would remain as it is now, but you could > force the prompts by defining the property at VM launch if desired. (for > example : java.exe -Dorg.rxtx.usePrompt=true myApp) > > > Also, you seemed to say you wanted the printer to start again > exactly where is stopped. It would indeed be the best way when the > printer is put offline for a few seconds. On the other hand, if the > printer is turned off (or the printer runs out of paper, or someone > steps on the mains cable), then the only way to go back to a "stable" > situation would be by printing the item (page, label, etc.) again from > scratch... > > > Just my two cents. > > > Vicne > > PS : By the way, the dialog box thing is very platform dependant on the > C-side, and I think the simplest way would probably be to bridge it to a > Java call where you can implement it like you proposed : > > public boolean displayDialogBox(prompt) { > return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", > JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); > } > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Thu Jun 7 17:48:11 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 Jun 2007 17:48:11 -0600 (MDT) Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <466865B8.4060004@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> Message-ID: An event is possible. I'm amazed this is the largest problem encountered while using the parallel code. How would the write ever exit if we throw events? Isn't this going to lead to hung applications? On Thu, 7 Jun 2007, Uncle George wrote: > My feeling is that the code that was suggested was for his environs ( > his shop ). > > The issue here is that after a 40+ second wait, an exception will be > thrown. But you really dont have a way of 'cancelling' all the > WriteFiles() that have already occured before the exception so that your > writeArray and the Commapi can backtrack to a position in which they are > in sync. > > The main ( really mine ) concern is not to lose data, or replicate data. > After 40seconds, 300 seconds, 55min, no matter how long, data should > not be lost or duplicated. But as soon as the exception is thrown, that > possibility exists. > > Maybe an event should be thrown instead? > > Vicne wrote: >> yves pielusenet wrote: >>> Maybe in my case I should re-compile rxtx and change the code. Instead >>> of send an exception I should display a dialog box to ask if it's >>> printer problem or if it should trie to send bytes. Something like : >>> >>> while( count > 0 ){ >>> if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ >>> /* >>> this are 20 * 2 seconds, in this time a printer (or other parallel device) >>> should solv all problems like buffer full, etc >>> */ >>> if(errorCount++ < 20){ >>> Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ >>> continue; >>> } >>> >>> if(displayDialogBox("Try again to send datas ??")){ >>> errorCount = 0; >>> } >>> else{ >>> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >>> break; >>> } >>> } >>> >> >> Sorry to step in without a specific solution to your problem, but I >> wanted to share my feeling regarding this proposal. AFAIK, it's >> generally considered bad practice to pop-up a prompt from a library. >> The main reason is that in general use, you can't guarantee that >> someone is actually present behind the console. Imagine a print server >> in a machine room, connected to a park of printers. In that case, when >> one printer fails, the logical behaviour would be to use an other one. >> If you change RxTx the way you propose, the printer queue will simply be >> stuck with a useless "Try again to send data ?" prompt until an >> administrator opens a remote connection to the print server's console >> and clicks "no". >> Second, it would create a dependency upon the existence of a >> graphical console (if you go the graphical "dialogBox" way). On many >> applications (typically server or embedded ones), the JVM is "headless" >> and if you try to pop-up a dialog, your app would throw an exception (at >> best) or just wouldn't display the prompt anywhere... Going the "text >> console" way is not more reliable, because on graphical environments, >> the text console is hidden unless explicitly requested. >> >> My advice would be to think again and find another solution. Ideas are : >> - make the number of retries a parameter so that you can tune it to what >> you think is reasonable >> - throw a more specific exception when the number of retries has been >> reached, so that a specific prompt can be shown at a higher level >> >> Anyway, if you feel that the prompt is the way to go in your case, I >> would at least make that prompt conditional. The least intrusive way >> would probably be using a system property, like >> >> if("true".equals(System.getProperty("org.rxtx.usePrompt")) >> && displayDialogBox("Retry sending data ?")){ >> errorCount = 0; >> } >> else{ >> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >> break; >> } >> >> >> By default, the behaviour would remain as it is now, but you could >> force the prompts by defining the property at VM launch if desired. (for >> example : java.exe -Dorg.rxtx.usePrompt=true myApp) >> >> >> Also, you seemed to say you wanted the printer to start again >> exactly where is stopped. It would indeed be the best way when the >> printer is put offline for a few seconds. On the other hand, if the >> printer is turned off (or the printer runs out of paper, or someone >> steps on the mains cable), then the only way to go back to a "stable" >> situation would be by printing the item (page, label, etc.) again from >> scratch... >> >> >> Just my two cents. >> >> >> Vicne >> >> PS : By the way, the dialog box thing is very platform dependant on the >> C-side, and I think the simplest way would probably be to bridge it to a >> Java call where you can implement it like you proposed : >> >> public boolean displayDialogBox(prompt) { >> return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", >> JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); >> } >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 19:18:51 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 21:18:51 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> Message-ID: <4668AE7B.3060409@gatworks.com> The UNIX version of writeArray is not too great either. It is possible that the write will only process some of the bytes. #else if( write( fd, bytes, count ) < 0 ) throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); #endif -------------------------------- Maybe it might be better to have the native function inform the caller of the # of characters written, then the commapi/output-buffer can be modified to reflect the #of chars written. If an exception is to be thrown, for too many loops of chars written == 0, then exception wont affect the state of the output buffer. Then a ParallelPort.restart() can be called to resume printing whats in the buffer. Trent Jarvi wrote: > An event is possible. I'm amazed this is the largest problem encountered > while using the parallel code. > > How would the write ever exit if we throw events? Isn't this going to > lead to hung applications? Sure. If you dont time out, then there is nothing that will force an EXIT from the write(). Issue is what has the OS done with the write. > > On Thu, 7 Jun 2007, Uncle George wrote: > >> My feeling is that the code that was suggested was for his environs ( >> his shop ). From yvespielusenet at free.fr Fri Jun 8 01:09:01 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Fri, 08 Jun 2007 09:09:01 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4668AE7B.3060409@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> Message-ID: <1181286541.3674.10.camel@localhost.localdomain> It is not possible that the rxtx java method write(byte[], int offset, int length) return anint which contains the number of byte really send to the printer instead of an exception ? So this is the programm which will see if all bytes have been sent. If not it can retry to send the unsended bytes. -------------------------------------------------------- int sended = 0; while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ sended += countWritten; /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } return sended; /*throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break;*/ } ... ... return countWritten; ------------------------------------------------ Le jeudi 07 juin 2007 ? 21:18 -0400, Uncle George a ?crit : > The UNIX version of writeArray is not too great either. It is possible > that the write will only process some of the bytes. > > #else > if( write( fd, bytes, count ) < 0 ) > throw_java_exception_system_msg( env, IO_EXCEPTION, > "writeArray" ); > #endif > -------------------------------- > > Maybe it might be better to have the native function inform the caller > of the # of characters written, then the commapi/output-buffer can be > modified to reflect the #of chars written. If an exception is to be > thrown, for too many loops of chars written == 0, then exception wont > affect the state of the output buffer. Then a ParallelPort.restart() can > be called to resume printing whats in the buffer. > > > Trent Jarvi wrote: > > An event is possible. I'm amazed this is the largest problem encountered > > while using the parallel code. > > > > How would the write ever exit if we throw events? Isn't this going to > > lead to hung applications? > Sure. If you dont time out, then there is nothing that will force an > EXIT from the write(). Issue is what has the OS done with the write. > > > > On Thu, 7 Jun 2007, Uncle George wrote: > > > >> My feeling is that the code that was suggested was for his environs ( > >> his shop ). > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Fri Jun 8 03:45:00 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 11:45:00 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181286541.3674.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> Message-ID: <20070608094500.GC21069@elberon.bln.de.ingenico.com> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > It is not possible that the rxtx java method write(byte[], int offset, > int length) return anint which contains the number of byte really send > to the printer instead of an exception ? > So this is the programm which will see if all bytes have been sent. If > not it can retry to send the unsended bytes. I think write() is void because in Java people love to do this since OutputStream :-) Of course on such interfaces you cannot implement something nice. If you would have a int write, you would not implement the interface and no applications expecting this interface would link/work/compile. oki, Steffen P.S.: (OT) If you propose not to implement the Java interfaces (especially not on JNI level), maybe optionally offering a wrapper that removes e.g. the write return value and so on to downgrade the powerful classic old POSIX read/write style to the modern limited Java style, then I agree :-) Same for read. Instead of things like "int avialable()" it is more powerful to have an approach as select(2) offers (to guarante the caller that read/write will not block [nothing else make sense anyway IMHO] but may read/write less bytes then requested). The caller gets full control and the higher level protocols can care about timeouts, invoking read in some loops and/or implement retransmission. On top of such an implementation, where everything is controlled, defined, guaranteed and reliable, someone could use an InputStream or OutputStream style interface. Or even better: don't use them at all :) just BTW :-) St. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From yvespielusenet at free.fr Fri Jun 8 05:52:45 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Fri, 08 Jun 2007 13:52:45 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <20070608094500.GC21069@elberon.bln.de.ingenico.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> Message-ID: <1181303565.11203.3.camel@localhost.localdomain> So maybe a better way should be to create a new Exception class which has a method "int getWrittenByte()". So the Exception should be use to send again bytes which are not printed yet. yves Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : > * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > > It is not possible that the rxtx java method write(byte[], int offset, > > int length) return anint which contains the number of byte really send > > to the printer instead of an exception ? > > So this is the programm which will see if all bytes have been sent. If > > not it can retry to send the unsended bytes. > > I think write() is void because in Java people love to do this > since OutputStream :-) Of course on such interfaces you cannot > implement something nice. If you would have a int write, you > would not implement the interface and no applications expecting > this interface would link/work/compile. > > oki, > > Steffen > > P.S.: (OT) > If you propose not to implement the Java interfaces (especially > not on JNI level), maybe optionally offering a wrapper that > removes e.g. the write return value and so on to downgrade the > powerful classic old POSIX read/write style to the modern limited > Java style, then I agree :-) Same for read. Instead of things > like "int avialable()" it is more powerful to have an approach as > select(2) offers (to guarante the caller that read/write will not > block [nothing else make sense anyway IMHO] but may read/write > less bytes then requested). The caller gets full control and the > higher level protocols can care about timeouts, invoking read in > some loops and/or implement retransmission. On top of such an > implementation, where everything is controlled, defined, > guaranteed and reliable, someone could use an InputStream or > OutputStream style interface. Or even better: don't use them at > all :) just BTW :-) > St. > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > 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. > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > 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. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Fri Jun 8 06:46:21 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 08:46:21 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181303565.11203.3.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> Message-ID: <46694F9D.5080501@gatworks.com> It seems that with outputstream.write(b[]), you become terribly uncoordinated as soon as an exception is thrown. Docs do not say what happens to the data. Yet from a practicable point of view, one would like to know if the write was accepted in-full, or rejected before any writes. There are no in betweens, as partial writes are not reportable. So for an outputstream.write(), in order for it to return, the full write request has to be taken, and stored in an internal output buffer. If there is no room, the write() is suspended, till there is room. Or throw's an IOException( "no room in buffer") ; As the select() loop for write reports buffer room avail, then more of the internal buffer is sent to the printer. yves pielusenet wrote: > So maybe a better way should be to create a new Exception class which > has a method "int getWrittenByte()". So the Exception should be use to > send again bytes which are not printed yet. > > yves > > Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : >> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: >>> It is not possible that the rxtx java method write(byte[], int offset, >>> int length) return anint which contains the number of byte really send >>> to the printer instead of an exception ? >>> So this is the programm which will see if all bytes have been sent. If >>> not it can retry to send the unsended bytes. >> I think write() is void because in Java people love to do this >> since OutputStream :-) Of course on such interfaces you cannot >> implement something nice. If you would have a int write, you >> would not implement the interface and no applications expecting >> this interface would link/work/compile. >> >> oki, >> >> Steffen >> >> P.S.: (OT) >> If you propose not to implement the Java interfaces (especially >> not on JNI level), maybe optionally offering a wrapper that >> removes e.g. the write return value and so on to downgrade the >> powerful classic old POSIX read/write style to the modern limited >> Java style, then I agree :-) Same for read. Instead of things >> like "int avialable()" it is more powerful to have an approach as >> select(2) offers (to guarante the caller that read/write will not >> block [nothing else make sense anyway IMHO] but may read/write >> less bytes then requested). The caller gets full control and the >> higher level protocols can care about timeouts, invoking read in >> some loops and/or implement retransmission. On top of such an >> implementation, where everything is controlled, defined, >> guaranteed and reliable, someone could use an InputStream or >> OutputStream style interface. Or even better: don't use them at >> all :) just BTW :-) >> St. >> >> About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. >> 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. >> >> About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. >> 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. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From Steffen.DETTMER at ingenico.com Fri Jun 8 08:12:18 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 16:12:18 +0200 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <46694F9D.5080501@gatworks.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: <20070608141218.GE21069@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 08:46 -0400: > It seems that with outputstream.write(b[]), you become terribly > uncoordinated as soon as an exception is thrown. Docs do not say what > happens to the data. (yes, so avoiding it seems to be good :)) > Yet from a practicable point of view, one would like to know if the > write was accepted in-full, or rejected before any writes. There are no > in betweens, as partial writes are not reportable. (which is an artificial API limitation. I never understood how this happend when they invented JDK because the well-known BSD socket API and thus [probably] WinSock does this correct, but anyway) > So for an outputstream.write(), in order for it to return, the full > write request has to be taken, and stored in an internal output buffer. > If there is no room, the write() is suspended, till there is room. Or > throw's an IOException( "no room in buffer") ; As the select() loop for > write reports buffer room avail, then more of the internal buffer is > sent to the printer. yes, might be good in case of a printer. May be horrible in case of PPP/TCP or some other transmission control protocol which may e.g. repeat data or even omit parts of it (e.g. internet realtime radio station broadcasting)... So I think the idea of "int write" (e.g. BSD sockets, linux files and so on) still is the best. A clean API / implementation should guarantee and allow implementations (users) to rely on that; assumptions and automatic background-sending and so on may look pragmatic and may even work on the first look, but may fail in other situations. BTW, if e.g. BSD socket API is known, why not simply copy it (until something better is invented :)) instead of fiddling around with JDK APIs? anyway, have a nice weekend everyone :-) oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Fri Jun 8 08:55:56 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 10:55:56 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070608141218.GE21069@elberon.bln.de.ingenico.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> Message-ID: <46696DFC.7000801@gatworks.com> >> write reports buffer room avail, then more of the internal buffer is >> sent to the printer. > > yes, might be good in case of a printer. May be horrible in case > of PPP/TCP or some other transmission control protocol which > may e.g. repeat data or even omit parts of it (e.g. internet > realtime radio station broadcasting)... So I think the idea of > "int write" (e.g. BSD sockets, linux files and so on) still is > the best. A clean API / implementation should guarantee and allow > implementations (users) to rely on that; assumptions and > automatic background-sending and so on may look pragmatic and may > even work on the first look, but may fail in other situations. > BTW, if e.g. BSD socket API is known, why not simply copy it > (until something better is invented :)) instead of fiddling > around with JDK APIs? But we were talking about the Parallel Port, and the transmission of data over the commapi/parallel-port schema. There isn't much in bi-directional software communication. Its a simple write one byte at a time interface. I'm not looking to change the comm-api. I'm just looking to alter the interaction between the Native ParallelPort functions, and the java ParallelPort functions that call them. This might be more readily doable than to get a committee to re-specify java-API specs. BTW: Whats is off-topic? ( help: not looking for def of off-topic ) From j.kenneth.gentle at acm.org Fri Jun 8 08:58:59 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Fri, 08 Jun 2007 10:58:59 -0400 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <20070608141218.GE21069@elberon.bln.de.ingenico.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> Message-ID: <200706081459.l58Ex5rA019991@qbang.org> Perhaps it is a bit late to jump in on this one, but here goes anyway. If the solutions all seem to "break" the contract with "java.io.outputstream", then, as noted, that may not be the appropriate contract. At the risk of being heretical, JDK1.4 introduced the "nio" package to address some of the compatibility issues with C apis mentioned in previous posts. The interface "java.nio.channels.WriteableByteChannel" defines the following single method: int write(ByteBuffer source); int, strangely enough, is the actual number of bytes written. So, if RXTX as written, against the JavaCOMM api and OutputStream, doesn't do what we want, how about writing a different set of bindings using the java.nio classes and as much of the underlying native code as possible. Note that just because the java.nio.channels.WriteableByteChannel sends back a result, OutputStream.write doesn't have to - and they could both call the same underlying native code. My 2 cents - maybe not worth even that... Ken From netbeans at gatworks.com Fri Jun 8 10:37:28 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 12:37:28 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <200706081459.l58Ex5rA019991@qbang.org> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> Message-ID: <466985C8.8000505@gatworks.com> Ken Gentle wrote: > Perhaps it is a bit late to jump in on this one, but here goes anyway. Common in, the waters fine. > > If the solutions all seem to "break" the contract with > "java.io.outputstream", then, as noted, that may not be the > appropriate contract. > How would the contract be broken? The machinery underneath is handling the contract. From j.kenneth.gentle at acm.org Fri Jun 8 10:48:01 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Fri, 08 Jun 2007 12:48:01 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466985C8.8000505@gatworks.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> Message-ID: <200706081648.l58Gm7YA022904@qbang.org> At 12:37 2007-06-08, you wrote: >Ken Gentle wrote: > > > > If the solutions all seem to "break" the contract with > > "java.io.outputstream", then, as noted, that may not be the > > appropriate contract. > > >How would the contract be broken? The machinery underneath is handling >the contract. It seems that a lot of the discussion has been about not only the timeout and being able to adjust it in the "machinery layer", but also about knowing in the Java layer, in the event of a timeout or exception, how many characters have been written to the device. An OutputStream won't ever do this with out an extension and including a return value "breaks" the contract, right? So, go with a Java IO api that *does* return the number of bytes written, out of the NIO package. I know it doesn't allow for a strict implementation of the JavaCOMM API - however, using NIO classes in place of the IO classes isn't that big a break and would allow those applications that need such information a way to get it. Maybe I'm misunderstanding the problem... Ken From netbeans at gatworks.com Fri Jun 8 11:24:14 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 13:24:14 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <200706081648.l58Gm7YA022904@qbang.org> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> Message-ID: <466990BE.7040100@gatworks.com> Ken Gentle wrote: An > OutputStream won't ever do this with out an extension and including a > return value "breaks" the contract, right? > i was not thinking of change the API to OutputSream. Are there specs for how output stream should work internally? for instance: String data = "Hello this is a line of data"; Outputstream.write( data.getbytes() ); ParallelPort.suspend(); int free = ParallelPort.getoutputbufferfree(); There is a symbiotic relationship between outputstream and the functionality of ParallelPort. From Steffen.DETTMER at ingenico.com Fri Jun 8 11:15:39 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 19:15:39 +0200 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <200706081459.l58Ex5rA019991@qbang.org> References: <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> Message-ID: <20070608171539.GK21069@elberon.bln.de.ingenico.com> * Ken Gentle wrote on Fri, Jun 08, 2007 at 10:58 -0400: > If the solutions all seem to "break" the contract with > "java.io.outputstream", then, as noted, that may not be the > appropriate contract. > > At the risk of being heretical, JDK1.4 introduced the "nio" package > to address some of the compatibility issues with C apis mentioned in > previous posts. The interface > "java.nio.channels.WriteableByteChannel" defines the following single method: > > int write(ByteBuffer source); > > int, strangely enough, is the actual number of bytes written. Yes, AFAIK one of the motivations for the NIO interface was, that the JDK-1.3 APIs (InputStream, e.g.) were not powerfull enough, especially for multi-connection-TCP servers or so. I don't know much about it but I've heard of a project where NIO usage was removed because of stability issues in multi-threaded environments and performance limitations under some circumstances. IIRC the "nio.ByteBuffer" is something very special (namely something you cannot implement in Java, it is "magic" or part of the language itself). Not sure if this is such a great idea (but for performance in the end sometimes heavy prices must be paid) :) > So, if RXTX as written, against the JavaCOMM api and OutputStream, > doesn't do what we want, how about writing a different set of > bindings using the java.nio classes and as much of the underlying > native code as possible. Yes, this would be an idea: use a full-featured interface on JNI, and, if wanted, deliver some wrappers converting this to a less-featured Java-compliant interface. However, powerful things as e.g. "select" are difficult to "emulate" if you are e.g. on some (older?) windows. But if you expose the full-featured APIs, you need to emulate them full-featured, theoretically. In the end it depends what you do on the serial line. If you just want to talk to a modem, then you may not need precise timeouts. But if you need to implement complexer protocols which define response times and timeouts, you may quickly get into difficulties. For instance, AFAIK, rxtx 1.7.2 (?) for windows is very messy with timeouts (there is a maximum, higher values are truncated; resolution is 100ms only; the function may take up to twice the timeout because internally it may be called twice). Probably for most people this is OK, but probably not for all. But having precise timeouts should be OK for all :-) Well, in the end it is nice to wish but somewhat hard to implement (many platforms, connections, USB, BlueTooth, whatever). oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Steffen.DETTMER at ingenico.com Fri Jun 8 11:04:22 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 19:04:22 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <46696DFC.7000801@gatworks.com> References: <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <46696DFC.7000801@gatworks.com> Message-ID: <20070608170422.GJ21069@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 10:55 -0400: > > BTW, if e.g. BSD socket API is known, why not simply copy it > > (until something better is invented :)) instead of fiddling > > around with JDK APIs? > > But we were talking about the Parallel Port, and the > transmission of data over the commapi/parallel-port schema. > There isn't much in bi-directional software communication. Its > a simple write one byte at a time interface. First, there are things like PLIP (http://en.wikipedia.org/wiki/Plip) - well, probably not widely used, sure ;) Second, I think if there is a good simple API known to support all that (with known "best practices") or so and there is no forcing need to invent a new one, why not simply using it? > I'm not looking to change the comm-api. I'm just looking to > alter the interaction between the Native ParallelPort > functions, and the java ParallelPort functions that call them. Ahh, yes. I think this is what I tried to ask. Having an usable JNI interface and on top (in pure java) some wrapper to InputStream or whatever could be done (e.g. by ignoring the return value of write or throwing if != length). Developers could then use the full-featured (non-JAVA-standard) API or select among various wrappers (as InputStream). > This might be more readily doable than to get a committee to > re-specify java-API specs. Yes, of course. I'm afraid that the Java APIs change regularily, but still yet with limited success it seems, so maybe they get it in one of the next iterations; who knows, maybe Java-9 has a BSD-like socket API :) SCNR. > BTW: Whats is off-topic? ( help: not looking for def of > off-topic ) I think I started some "re-specify java-API specs" which was OT probably. oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From lists at iDIAcomputing.com Fri Jun 8 18:48:54 2007 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Fri, 08 Jun 2007 20:48:54 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46684B62.7080802@gmail.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> Message-ID: <4669F8F6.3040101@iDIAcomputing.com> Vicne wrote: > Sorry to step in without a specific solution to your problem, but I > wanted to share my feeling regarding this proposal. AFAIK, it's > generally considered bad practice to pop-up a prompt from a library. ... > > My advice would be to think again and find another solution. Ideas are : > - make the number of retries a parameter so that you can tune it to what > you think is reasonable > - throw a more specific exception when the number of retries has been > reached, so that a specific prompt can be shown at a higher level You could also allow the client code to register a callback class which returns a boolean indicating whether to retry or cancel. This callback class could pop up a dialog, if appropriate, or follow some preset policy, or.... - George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From joachim at buechse.ch Sat Jun 9 09:43:16 2007 From: joachim at buechse.ch (Joachim Buechse) Date: Sat, 9 Jun 2007 17:43:16 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46694F9D.5080501@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: You should not forget, that in the case of an exception it may not even be known what happened to the data. You have a kernel buffer, outgoing chip buffer, incoming chip buffer, etc. So of course, it would be nice to know up to which point data was correctly processed, but this feedback does not exist on the hardware or protocol level and hence can in general not be magicly created on the software level... Regards, Joachim On 08.06.2007, at 14:46, Uncle George wrote: > It seems that with outputstream.write(b[]), you become terribly > uncoordinated as soon as an exception is thrown. Docs do not say what > happens to the data. > > Yet from a practicable point of view, one would like to know if the > write was accepted in-full, or rejected before any writes. There > are no > in betweens, as partial writes are not reportable. > > So for an outputstream.write(), in order for it to return, the full > write request has to be taken, and stored in an internal output > buffer. > If there is no room, the write() is suspended, till there is room. Or > throw's an IOException( "no room in buffer") ; As the select() loop > for > write reports buffer room avail, then more of the internal buffer is > sent to the printer. > > > > yves pielusenet wrote: >> So maybe a better way should be to create a new Exception class which >> has a method "int getWrittenByte()". So the Exception should be >> use to >> send again bytes which are not printed yet. >> >> yves >> >> Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : >>> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: >>>> It is not possible that the rxtx java method write(byte[], int >>>> offset, >>>> int length) return anint which contains the number of byte >>>> really send >>>> to the printer instead of an exception ? >>>> So this is the programm which will see if all bytes have been >>>> sent. If >>>> not it can retry to send the unsended bytes. >>> I think write() is void because in Java people love to do this >>> since OutputStream :-) Of course on such interfaces you cannot >>> implement something nice. If you would have a int write, you >>> would not implement the interface and no applications expecting >>> this interface would link/work/compile. >>> >>> oki, >>> >>> Steffen >>> >>> P.S.: (OT) >>> If you propose not to implement the Java interfaces (especially >>> not on JNI level), maybe optionally offering a wrapper that >>> removes e.g. the write return value and so on to downgrade the >>> powerful classic old POSIX read/write style to the modern limited >>> Java style, then I agree :-) Same for read. Instead of things >>> like "int avialable()" it is more powerful to have an approach as >>> select(2) offers (to guarante the caller that read/write will not >>> block [nothing else make sense anyway IMHO] but may read/write >>> less bytes then requested). The caller gets full control and the >>> higher level protocols can care about timeouts, invoking read in >>> some loops and/or implement retransmission. On top of such an >>> implementation, where everything is controlled, defined, >>> guaranteed and reliable, someone could use an InputStream or >>> OutputStream style interface. Or even better: don't use them at >>> all :) just BTW :-) >>> St. >>> >>> About Ingenico Throughout the world businesses rely on Ingenico >>> for secure and expedient electronic transaction acceptance. >>> Ingenico products leverage proven technology, established >>> standards and unparalleled ergonomics to provide optimal >>> reliability, versatility and usability. This comprehensive range >>> of products is complemented by a global array of services and >>> partnerships, enabling businesses in a number of vertical sectors >>> to accept transactions anywhere their business takes them. >>> 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. >>> >>> About Ingenico Throughout the world businesses rely on Ingenico >>> for secure and expedient electronic transaction acceptance. >>> Ingenico products leverage proven technology, established >>> standards and unparalleled ergonomics to provide optimal >>> reliability, versatility and usability. This comprehensive range >>> of products is complemented by a global array of services and >>> partnerships, enabling businesses in a number of vertical sectors >>> to accept transactions anywhere their business takes them. >>> 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. >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx 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 yvespielusenet at free.fr Mon Jun 11 03:15:12 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Mon, 11 Jun 2007 11:15:12 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: <1181553312.8335.14.camel@localhost.localdomain> So can someone tell a solution for my problem :( Must I say to the user to not put the printer off-line ? I can't since he has to do some pauses, verify print, paper conditioning etc... How do other people ? Before I use the parport librarry to read port status : http://www.geocities.com/Juanga69/parport/ (which doesn't work on windows XP) And I send data into the file LPT1 I use to have no problem when printer was disabled. thanks -- yves piel Le samedi 09 juin 2007 ? 17:43 +0200, Joachim Buechse a ?crit : > You should not forget, that in the case of an exception it may not > even be known what happened to the data. > > You have a kernel buffer, outgoing chip buffer, incoming chip buffer, > etc. So of course, it would be nice to know up to which point data > was correctly processed, but this feedback does not exist on the > hardware or protocol level and hence can in general not be magicly > created on the software level... > > Regards, > Joachim > > On 08.06.2007, at 14:46, Uncle George wrote: > > > It seems that with outputstream.write(b[]), you become terribly > > uncoordinated as soon as an exception is thrown. Docs do not say what > > happens to the data. > > > > Yet from a practicable point of view, one would like to know if the > > write was accepted in-full, or rejected before any writes. There > > are no > > in betweens, as partial writes are not reportable. > > > > So for an outputstream.write(), in order for it to return, the full > > write request has to be taken, and stored in an internal output > > buffer. > > If there is no room, the write() is suspended, till there is room. Or > > throw's an IOException( "no room in buffer") ; As the select() loop > > for > > write reports buffer room avail, then more of the internal buffer is > > sent to the printer. > > > > > > > > yves pielusenet wrote: > >> So maybe a better way should be to create a new Exception class which > >> has a method "int getWrittenByte()". So the Exception should be > >> use to > >> send again bytes which are not printed yet. > >> > >> yves > >> > >> Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : > >>> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > >>>> It is not possible that the rxtx java method write(byte[], int > >>>> offset, > >>>> int length) return anint which contains the number of byte > >>>> really send > >>>> to the printer instead of an exception ? > >>>> So this is the programm which will see if all bytes have been > >>>> sent. If > >>>> not it can retry to send the unsended bytes. > >>> I think write() is void because in Java people love to do this > >>> since OutputStream :-) Of course on such interfaces you cannot > >>> implement something nice. If you would have a int write, you > >>> would not implement the interface and no applications expecting > >>> this interface would link/work/compile. > >>> > >>> oki, > >>> > >>> Steffen > >>> > >>> P.S.: (OT) > >>> If you propose not to implement the Java interfaces (especially > >>> not on JNI level), maybe optionally offering a wrapper that > >>> removes e.g. the write return value and so on to downgrade the > >>> powerful classic old POSIX read/write style to the modern limited > >>> Java style, then I agree :-) Same for read. Instead of things > >>> like "int avialable()" it is more powerful to have an approach as > >>> select(2) offers (to guarante the caller that read/write will not > >>> block [nothing else make sense anyway IMHO] but may read/write > >>> less bytes then requested). The caller gets full control and the > >>> higher level protocols can care about timeouts, invoking read in > >>> some loops and/or implement retransmission. On top of such an > >>> implementation, where everything is controlled, defined, > >>> guaranteed and reliable, someone could use an InputStream or > >>> OutputStream style interface. Or even better: don't use them at > >>> all :) just BTW :-) > >>> St. > >>> > >>> About Ingenico Throughout the world businesses rely on Ingenico > >>> for secure and expedient electronic transaction acceptance. > >>> Ingenico products leverage proven technology, established > >>> standards and unparalleled ergonomics to provide optimal > >>> reliability, versatility and usability. This comprehensive range > >>> of products is complemented by a global array of services and > >>> partnerships, enabling businesses in a number of vertical sectors > >>> to accept transactions anywhere their business takes them. > >>> 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. > >>> > >>> About Ingenico Throughout the world businesses rely on Ingenico > >>> for secure and expedient electronic transaction acceptance. > >>> Ingenico products leverage proven technology, established > >>> standards and unparalleled ergonomics to provide optimal > >>> reliability, versatility and usability. This comprehensive range > >>> of products is complemented by a global array of services and > >>> partnerships, enabling businesses in a number of vertical sectors > >>> to accept transactions anywhere their business takes them. > >>> 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. > >>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx 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 > From Steffen.DETTMER at ingenico.com Mon Jun 11 03:56:18 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 11:56:18 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466990BE.7040100@gatworks.com> References: <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> Message-ID: <20070611095618.GA10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 13:24 -0400: > i was not thinking of change the API to OutputSream. Then I think either someone uses OutputStream (and has no reliable information about incomplete writes) or someone uses somethink else. > Are there specs for how output stream should work internally? > > for instance: > String data = "Hello this is a line of data"; > Outputstream.write( data.getbytes() ); > ParallelPort.suspend(); > int free = ParallelPort.getoutputbufferfree(); > > There is a symbiotic relationship between outputstream and the > functionality of ParallelPort. If you need OutputStream "plus something else", in short you're needing "something else". Personally I dislike the code above a lot. The stream "looks" like if it would be an OutputStream, but in fact it isn't. You need to call getoutputbufferfree later to check if write succeeded (but OutputStream promises that write succeedes synchronous, blocking, or throws an exception). So it is not an OutputStream. No application written for OutputStreams would work without change (because it won't know getoutputbufferfree at all). It is not abstracted from ParallelPort. I think this would be wrong. Then I think an alternative interface instead is better. Let's assume we had some "connection" (to distinguish between OutputStreams and Channels). Then why not working as on a file handle in POSIX: do { // ... select maybe using timer ... readyForWrite = ... if (readyForWrite) { int writtenBytes = connection.write(toWrite); toWrite.remove(0, writtenBytes); } while(readyForWrite && toWrite.length > 0); I think, having such a write isn't the big problem. I think, the difficult thing is around "select" - however this would look like. It should be OO, typesafe, performant, supporting multiple connections/channels/streams in various modes and should be orthogonal to other functionalities. Of course, this heavily depends on what the application is doing; for a simple situation (like reading a small, mandatory file from a local disk) this would be to uncomfortable (and offering unneeded features only). just BTW :) oki, Steffen -- // Modeline for VIM. Please don't remove. // (Help: autoindent, expandtab, shiftwidth=4, tabstop=4, textwidth=75) // vi: set ai et sw=4 ts=4 tw=75 ft=java: About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Mon Jun 11 05:38:33 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 07:38:33 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611095618.GA10821@elberon.bln.de.ingenico.com> References: <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> Message-ID: <466D3439.4020805@gatworks.com> Steffen DETTMER wrote: > (but OutputStream promises that write > succeedes synchronous, blocking, or throws an exception). Where is it so written? From Steffen.DETTMER at ingenico.com Mon Jun 11 06:36:50 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 14:36:50 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466D3439.4020805@gatworks.com> References: <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> <466D3439.4020805@gatworks.com> Message-ID: <20070611123650.GI10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Mon, Jun 11, 2007 at 07:38 -0400: > Steffen DETTMER wrote: > > > (but OutputStream promises that write > > succeedes synchronous, blocking, or throws an exception). > > Where is it so written? Now, as you ask, I think it is not written that clearly but follows from specification. mmm... Am I wrong? I understand the API doc in this way: * http://java.sun.com/j2se/1.4.2/docs/api/java/io/OutputStream.html#write(byte[]) > public void write(byte[] b) > throws IOException > > Writes b.length bytes from the specified byte array to this > output stream. The general contract for write(b) is that > it should have exactly the same effect as the call write(b, > 0, b.length). > > Parameters: > b - the data. > Throws: > IOException - if an I/O error occurs. > See Also: > write(byte[], int, int) and there is: > public void write(byte[] b, > int off, > int len) > throws IOException > > Writes len bytes from the specified byte array starting at > offset off to this output stream. The general contract for > write(b, off, len) is that some of the bytes in the array b > are written to the output stream in order; element b[off] > is the first byte written and b[off+len-1] is the last byte > written by this operation. > > The write method of OutputStream calls the write method of > one argument on each of the bytes to be written out. > Subclasses are encouraged to override this method and > provide a more efficient implementation. > > If b is null, a NullPointerException is thrown. > > If off is negative, or len is negative, or off+len is > greater than the length of the array b, then an > IndexOutOfBoundsException is thrown. > > Parameters: > b - the data. > off - the start offset in the data. > len - the number of bytes to write. > Throws: > IOException - if an I/O error occurs. In particular, an > IOException is thrown if the output stream is closed. In general, any specialisation (derived child class) must comform to this. So write in the end is specified (!) as "The write method ... calls the write method ... on each of the bytes to be written out". This is what must be implemented by ANY OutputStream. Of course, there is: "Subclasses are encouraged to override this method and provide a more efficient implementation." which IMHO does not contradict - the more efficient must behave in exactly the same way of course (just wasting less resources than a simple byte-by-byte write). So it does not matter here I think. The write that finally defines the behavior tells basically: > "Writes the specified byte to this output stream. The general > contract for write is that one byte is written to the output > stream. " > > Throws: > IOException - if an I/O error occurs. which IMHO is another way of saying "write writes the byte immediately and returns on success (only), otherwise an exception is thrown". Especially it cannot happen that zero bytes are written (i.e. the specified byte is NOT written) without an exception. So by this write must be synchronous and blocking, because otherwise it could not reliably know if an asynchronous operation will succeede or not (some getAsyncResult or so would be needed). Since write(byte[]) does this for each byte (or with a behavior beeing exactly the same as if it would do), I think this means that the write(byte[]) succeedes synchronous/blocking or throws an exception. Did I an error in reasoning or confused something or so? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From j.kenneth.gentle at acm.org Mon Jun 11 06:51:25 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 11 Jun 2007 08:51:25 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611123650.GI10821@elberon.bln.de.ingenico.com> References: <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> <466D3439.4020805@gatworks.com> <20070611123650.GI10821@elberon.bln.de.ingenico.com> Message-ID: <200706111251.l5BCpS9T017831@qbang.org> It is as Steffen describes. "InputStream" and "OutputStream" are inherently synchronous (which is why so many java programs resort to threads to use them). Anything outside of this "contract" is *not* an InputStream or OutputStream. That is why there is a new package for things that don't behave like the old *Stream classes - the NIO package. If you look carefully at the IO package, you'll note that almost all the classes are _Decorator_ pattern implementations of the *Stream classes - and the interface presents the _same_ behavior to the calling code in all cases - a synchronous operation that completes successfully or throws an exception (with the one exception of "read" that returns a "-1" on end-of-stream. I know I've read this numerous times - I'd suggest checking the Language Spec or one of the books by Bloch or Gosling. Ken At 08:36 2007-06-11, you wrote: >* Uncle George wrote on Mon, Jun 11, 2007 at 07:38 -0400: > > Steffen DETTMER wrote: > > > > > (but OutputStream promises that write > > > succeedes synchronous, blocking, or throws an exception). > > > > Where is it so written? > >Now, as you ask, I think it is not written that clearly but >follows from specification. mmm... > >Am I wrong? > >I understand the API doc in this way: > >* >http://java.sun.com/j2se/1.4.2/docs/api/java/io/OutputStream.html#write(byte[]) > > public void write(byte[] b) > > throws IOException > > > > Writes b.length bytes from the specified byte array to this > > output stream. The general contract for write(b) is that > > it should have exactly the same effect as the call write(b, > > 0, b.length). > > > > Parameters: > > b - the data. > > Throws: > > IOException - if an I/O error occurs. > > See Also: > > write(byte[], int, int) > > >and there is: > > > > public void write(byte[] b, > > int off, > > int len) > > throws IOException > > > > Writes len bytes from the specified byte array starting at > > offset off to this output stream. The general contract for > > write(b, off, len) is that some of the bytes in the array b > > are written to the output stream in order; element b[off] > > is the first byte written and b[off+len-1] is the last byte > > written by this operation. > > > > The write method of OutputStream calls the write method of > > one argument on each of the bytes to be written out. > > Subclasses are encouraged to override this method and > > provide a more efficient implementation. > > > > If b is null, a NullPointerException is thrown. > > > > If off is negative, or len is negative, or off+len is > > greater than the length of the array b, then an > > IndexOutOfBoundsException is thrown. > > > > Parameters: > > b - the data. > > off - the start offset in the data. > > len - the number of bytes to write. > > Throws: > > IOException - if an I/O error occurs. In particular, an > > IOException is thrown if the output stream is closed. > > >In general, any specialisation (derived child class) must comform >to this. So write in the end is specified (!) as "The write >method ... calls the write method ... on each of the bytes to be >written out". This is what must be implemented by ANY >OutputStream. > >Of course, there is: "Subclasses are encouraged to override this >method and provide a more efficient implementation." which IMHO >does not contradict - the more efficient must behave in exactly >the same way of course (just wasting less resources than a simple >byte-by-byte write). So it does not matter here I think. > > > >The write that finally defines the behavior tells basically: > > > "Writes the specified byte to this output stream. The general > > contract for write is that one byte is written to the output > > stream. " > > > > Throws: > > IOException - if an I/O error occurs. > > >which IMHO is another way of saying "write writes the byte >immediately and returns on success (only), otherwise an exception >is thrown". Especially it cannot happen that zero bytes are >written (i.e. the specified byte is NOT written) without an >exception. So by this write must be synchronous and blocking, >because otherwise it could not reliably know if an asynchronous >operation will succeede or not (some getAsyncResult or so would >be needed). > >Since write(byte[]) does this for each byte (or with a behavior >beeing exactly the same as if it would do), I think this means >that the write(byte[]) succeedes synchronous/blocking or throws >an exception. > >Did I an error in reasoning or confused something or so? > >oki, > >Steffen > >About Ingenico Throughout the world businesses rely on Ingenico for >secure and expedient electronic transaction acceptance. Ingenico >products leverage proven technology, established standards and >unparalleled ergonomics to provide optimal reliability, versatility >and usability. This comprehensive range of products is complemented >by a global array of services and partnerships, enabling businesses >in a number of vertical sectors to accept transactions anywhere >their business takes them. >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. > >About Ingenico Throughout the world businesses rely on Ingenico for >secure and expedient electronic transaction acceptance. Ingenico >products leverage proven technology, established standards and >unparalleled ergonomics to provide optimal reliability, versatility >and usability. This comprehensive range of products is complemented >by a global array of services and partnerships, enabling businesses >in a number of vertical sectors to accept transactions anywhere >their business takes them. >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. > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From alesinskyy at googlemail.com Mon Jun 11 07:25:33 2007 From: alesinskyy at googlemail.com (Oleksandr Alesinskyy) Date: Mon, 11 Jun 2007 15:25:33 +0200 Subject: [Rxtx] [OT] select :-) Message-ID: Sorry, but I have to disagree with following statement: "So write in the end is specified (!) as "The write method ... calls the write method ... on each of the bytes to be written out". This is what must be implemented by ANY OutputStream.". This is not part of the specification or contract, it is just revealed implementation detail of the OutputStream. It is not stated anywhere that behavoiur of derived classes shall conform with this one. Statement concerning "synchronous" nature of the output stream is invalid as well. Really synchronous stream does not require flush() but OutputStream has it. From Steffen.DETTMER at ingenico.com Mon Jun 11 08:21:16 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 16:21:16 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: Message-ID: <20070611142116.GN10821@elberon.bln.de.ingenico.com> * Oleksandr Alesinskyy wrote on Mon, Jun 11, 2007 at 15:25 +0200: > Sorry, but I have to disagree with following statement: > "So write in the end is specified (!) as "The write > method ... calls the write method ... on each of the bytes to be > written out". This is what must be implemented by ANY > OutputStream.". > > This is not part of the specification or contract, it is just > revealed implementation detail of the OutputStream. It is not > stated anywhere that behavoiur of derived classes shall conform > with this one. (I didn't meant that the implementation must really write byte by byte, but that it must "look as if it would do" - because all implementations of OutputStream must "look" in the same way [which is another way of saying "do abstract" I think]) I think the API doc is not "revealing implementation details" but it is the *specification* of that interface and derivations must (should) conform to this specification. Isn't this the idea of interfaces? A function that expects an OutputStream should work on ANY OutputStream, shouldn't it? just kidding: I mean, what would be the point in implementing a checksum function as OutputStream.write which throws its result as IOException? Or which requires to call close() as very first operation to tell that the application is about to transmit confidential data? :-) > Statement concerning "synchronous" nature of the output stream > is invalid as well. Really synchronous stream does not require > flush() but OutputStream has it. ahh, interesting point! I think this is another bug in the API. flush() is wrong. Because write specifies "The general contract for write is that one byte is written to the output stream." but not "a byte may be written or buffered". Actually, an application would need to call flush() after each write (or bunch of write calls) to ensure that write really did something otherwise I think. I didn't found in the spec of OutputStream that it would be required to call flush(). This should mean that calling flush is not required which in turn leads to the conclusion that write must be synchrous (private threads are forbidden because not specified :)) which in turn leads to the conclusion that flush() is not needed at all... I mean, what if someone would only store in write and do the "real write" in flush() and never else? An application could write in one stream and read on another one (e.g. in bidirectional communication) and would never get anything back, because nothing was actually written because no flush was called? Then someone could even think that on error in some write the data could remain buffered AND throw an exception, retrying to send the data in the next write. Ohh, and if there would be some message number inside, and underlaying write (e.g. a protocol offering InputStream/OutputStream) would check this and throw "DuplicatedMessageNumber" the stream would only throw it again and again beeing unusable... In short: I have no clue how someone could be able to implement an asynchrounos write (which is realiable and correct) without beeing specific to anything which is not specified by OutputStream. Well, I think in the end OutputStream was not intended for such communication or protocol implementations - but to read a local disk file or so. In case of I/O errors usually you can abort your application and change the hard disk :-) oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Bob_Jacobsen at lbl.gov Mon Jun 11 09:32:23 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Mon, 11 Jun 2007 08:32:23 -0700 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611142116.GN10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> Message-ID: At 4:21 PM +0200 6/11/07, Steffen DETTMER wrote: > > Statement concerning "synchronous" nature of the output stream >> is invalid as well. Really synchronous stream does not require >> flush() but OutputStream has it. > >ahh, interesting point! > >I think this is another bug in the API. flush() is wrong. Because >write specifies "The general contract for write is that one byte >is written to the output stream." but not "a byte may be written >or buffered". > >Actually, an application would need to call flush() after each >write (or bunch of write calls) to ensure that write really did >something otherwise I think. OutputStreams don't _have_ to be synchronous or asynchronous, but the OutputStream API was be arranged so that subclasses _can_ be synchronous or asynchronous. Such generality is the hardest part of getting an API right. Hence, if at some point a program using an OutputStream wants to be sure that the data has been pushed all the way out, flush() is available. For some subclasses, e.g. the buffered ones, this has important behavior. Others write the data from each call, and flush() doesn't do anything. You _can_ omit it in programs that are known to use this second type, but there's no requirement that you do so; the interface is general in that way. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From Steffen.DETTMER at ingenico.com Mon Jun 11 12:32:39 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 20:32:39 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> Message-ID: <20070611183239.GT10821@elberon.bln.de.ingenico.com> * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: > >Actually, an application would need to call flush() after each > >write (or bunch of write calls) to ensure that write really did > >something otherwise I think. > OutputStreams don't _have_ to be synchronous or asynchronous, > but the OutputStream API was be arranged so that subclasses > _can_ be synchronous or asynchronous. Ahh, oki. Thanks for the clarificaion. So in short, flush() MUST be called on OutputStream, this is just not documented correctly or so clearly (right?). So the overall usage semantics would be: 1. call write (multiple times if desired) 2. call flush only if both succeeded, write was successful. If flush fails it remains unknown if a part of the data was written and/or will be repeated. So the spec (API doc) is wrong. Correct would be to tell that write behaves as told as long as it is followed by a call to flush, otherwise data may or may not get lost (depending wheter close() is called and calls flush(), which seems not to be guaranteed/required). BTW, I think it is a little bit... erm... interesting to find the specification (java API doc reference) wrong, having a need to conclude it from the presence of some methods with "it would make no sense if they behave exactly as specified, so specification must be wrong (incomplete)". > Such generality is the hardest part of getting an API right. Yes, seems to be proven ;) > Hence, if at some point a program using an OutputStream wants > to be sure that the data has been pushed all the way out, > flush() is available. For some subclasses, e.g. the buffered > ones, this has important behavior. Others write the data from > each call, and flush() doesn't do anything. > You _can_ omit it in programs that are known to use this second > type, but there's no requirement that you do so; the interface > is general in that way. I think, it still it must be called always, otherwise the application could break if passing a different runtime type as OutputStream. I think, if the application/method needs a special "type of OutputStream" then the parameter type must be a subclass but not OutputStream, maybe a PrintStream or so - otherwise the compiler could not detect this error (passing wrong type). Is this correct? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Bob_Jacobsen at lbl.gov Mon Jun 11 13:00:52 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Mon, 11 Jun 2007 12:00:52 -0700 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611183239.GT10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> Message-ID: At 8:32 PM +0200 6/11/07, Steffen DETTMER wrote: >So the spec (API doc) is wrong. Correct would be to tell that >write behaves as told as long as it is followed by a call to >flush, otherwise data may or may not get lost (depending wheter >close() is called and calls flush(), which seems not to be >guaranteed/required). I'm not entirely sure that the spec is wrong, but reasonable people can differ on this. In the 1.5 JavaDocs, all that the docs say for the write methods is that they write to the _output_ _stream_; there is no guarantee of anything beyond that. Only the flush method has any guarantee about the data, which is >Flushes this output stream and forces any buffered output bytes to >be written out. The general contract of flush is that calling it is >an indication that, if any bytes previously written have been >buffered by the implementation of the output stream, such bytes >should immediately be written to their intended destination. People commonly use various OutputStreams without using flush(), and it often works, but it's a bad practice and will eventually bite them. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From netbeans at gatworks.com Mon Jun 11 13:31:57 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 15:31:57 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611183239.GT10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> Message-ID: <466DA32D.1010602@gatworks.com> Steffen DETTMER wrote: > * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: >>> Actually, an application would need to call flush() after each >>> write (or bunch of write calls) to ensure that write really did >>> something otherwise I think. > >> OutputStreams don't _have_ to be synchronous or asynchronous, >> but the OutputStream API was be arranged so that subclasses >> _can_ be synchronous or asynchronous. > > Ahh, oki. Thanks for the clarificaion. > > So in short, flush() MUST be called on OutputStream, this is just > not documented correctly or so clearly (right?). No. Flush can be called to force all current data in java buffer's to be written to the kernel - NOW. A flush() can also *imply* that, besides writing out the buffer's that java employs, may also imply/ask the kernel to write all data thusfar written to the kernel, to be physically placed on the destination device - NOW. For some OS's there is no need to do a kernel flush(), as the I/O is synchronized already. Since this is java, you never know what OS your on. From tjarvi at qbang.org Mon Jun 11 19:28:27 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Jun 2007 19:28:27 -0600 (MDT) Subject: [Rxtx] [OT] select :-) In-Reply-To: <466DA32D.1010602@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: On Mon, 11 Jun 2007, Uncle George wrote: > Steffen DETTMER wrote: >> * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: >>>> Actually, an application would need to call flush() after each >>>> write (or bunch of write calls) to ensure that write really did >>>> something otherwise I think. >> >>> OutputStreams don't _have_ to be synchronous or asynchronous, >>> but the OutputStream API was be arranged so that subclasses >>> _can_ be synchronous or asynchronous. >> >> Ahh, oki. Thanks for the clarificaion. >> >> So in short, flush() MUST be called on OutputStream, this is just >> not documented correctly or so clearly (right?). > No. > Flush can be called to force all current data in java buffer's to be > written to the kernel - NOW. > > A flush() can also *imply* that, besides writing out the buffer's that > java employs, may also imply/ask the kernel to write all data thusfar > written to the kernel, to be physically placed on the destination device > - NOW. > For some OS's there is no need to do a kernel flush(), as the I/O is > synchronized already. Since this is java, you never know what OS your on. To add to the confusion, flush on the C side throws away data. drain makes sure it is written. Looking at the ParallelImp.c we can probably do better. /* we set a timeout because all calls are sequentiell (also with asynchron) this means that the default timeout of unlimited blocks all calls (also close and status request) if the device is down */ GetCommTimeouts( (HANDLE)fd, &timeouts ); timeouts.WriteTotalTimeoutMultiplier = 0; timeouts.WriteTotalTimeoutConstant = 2000; /* 2000 is the min value for the default Windows NT and Windows 2000 driver */ SetCommTimeouts( (HANDLE)fd, &timeouts ); while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } errorCount = 0; bytes += countWritten; count -= countWritten; } LPRPort has some timeout code that appears to be doing nothing but flipping bits back and forth right now. The commapi rxtx follows allows for timeout control from javax.comm.CommPort. The above is a solution that worked in one specific use case. With timeouts in place, the original 'old printer going offline' problem could be solved. That printer code isn't written in stone. In fact it was ajusted from being able to print 'asdf' to a daisy wheel printer to working for one person. BTW, I've finished teaching after hours tonight and will be moving forward with a new rxtx release in my free time. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Jun 11 21:28:04 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 23:28:04 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: <466E12C4.1010305@gatworks.com> > Looking at the ParallelImp.c we can probably do better. > The problem stemmed from the possibility that the writev routine could have written some of the buffer, in chunks, printer pauses, refuses any more chunks, and a timeout occurs. Do you or do you not cause an exception to be thrown? Is there a way to set timeout for a ParallelPort data output stream? I cant find it. From tjarvi at qbang.org Mon Jun 11 22:17:23 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Jun 2007 22:17:23 -0600 (MDT) Subject: [Rxtx] [OT] select :-) In-Reply-To: <466E12C4.1010305@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> <466E12C4.1010305@gatworks.com> Message-ID: On Mon, 11 Jun 2007, Uncle George wrote: >> Looking at the ParallelImp.c we can probably do better. >> > The problem stemmed from the possibility that the writev routine could > have written some of the buffer, in chunks, printer pauses, refuses any > more chunks, and a timeout occurs. Do you or do you not cause an > exception to be thrown? > > Is there a way to set timeout for a ParallelPort data output stream? I > cant find it. hmm I looked again after you asked. The timeouts are only controllable on the receive side. This comes from CommPort; the parent. So what we are talking about is some bytes in memory that rxtx has and is supposed to write. A buffer perhaps? The approach with rxtx in the past has been to ignore output buffer sizes. The assumption is that the library does not know how to best handle buffers. There are buffered output streams that can do buffering on top of rxtx for instance. There is also a question regarding what was actually ment when the API was put together. My suspicion is that it was put together while looking at one OS API and was never ment to be anything more than a hook into that API. The comments are fairly telling combined with reading the w32 API. So looking at the problem again.. The current timeout behavior appears fairly arbitrary. Presumably this is to prevent a program from hanging instead of using a helper thread to write - heavy handed for new programmers. Even so, I don't think the write should timeout at all if it is not configurable. >From the API perspective, "What Timeout?" -- Trent Jarvi tjarvi at qbang.org From Steffen.DETTMER at ingenico.com Tue Jun 12 02:14:48 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 12 Jun 2007 10:14:48 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466DA32D.1010602@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: <20070612081447.GU10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Mon, Jun 11, 2007 at 15:31 -0400: > Steffen DETTMER wrote: > > Ahh, oki. Thanks for the clarificaion. > > > > So in short, flush() MUST be called on OutputStream, this is just > > not documented correctly or so clearly (right?). > No. hum (though now I got it, but...). > Flush can be called to force all current data in java buffer's to be > written to the kernel - NOW. > > A flush() can also *imply* that, besides writing out the > buffer's that java employs, may also imply/ask the kernel to > write all data thusfar written to the kernel, to be physically > placed on the destination device - NOW. > > For some OS's there is no need to do a kernel flush(), as the I/O is > synchronized already. Since this is java, you never know what OS your on. (well, but if you're going to kernel level, even flush cannot guarantee that data will "be physically placed". Maybe you're flushing to a file via NFS (and the client "thinks" that it was written, but maybe it was just buffered by the NFS server) or so... but of course such exceptions of the rules are constructable always.) Well, you tell that depending on the OS it can be that flush is needed or it can be that flush is not needed (beacuse the I/O is synchronized already), right? Also, applications should work on any OS, which includes the OSes that do need flush. Since the application cannot know whether flush is needed or not because it doesn't know what the OS is doing, it has to call flush, hasn't it? I mean, if it would not call flush then it would not work on such OSes (except the written data would not be needed at all, but in this would be an artificial example :)). Since applications are supposed to work this would be wrong, wouldn't it? So would it be correct to say: "Applications, that should work under all OSes (including the OSes where the I/O is not synchronised already), have to call flush on OutputStream to ensure the data is transfered to the kernel." or is this wrong? If so, then I'm afraid I missed the point again :( oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Tue Jun 12 04:46:52 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 12 Jun 2007 06:46:52 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070612081447.GU10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> <20070612081447.GU10821@elberon.bln.de.ingenico.com> Message-ID: <466E799C.7060700@gatworks.com> S > (well, but if you're going to kernel level, even flush cannot > guarantee that data will "be physically placed". Thats true now-a-days because ( from "man 2 sync" ) : > According to the standard specification (e.g., SVID), sync() schedules > the writes, but may return before the actual writing is done. However, > since version 1.3.20 Linux does actually wait. (This still does not > guarantee data integrity: modern disks have large caches.) My disk drive has 8mb cache. Maybe you're > flushing to a file via NFS (and the client "thinks" that it was > written, but maybe it was just buffered by the NFS server) or > so... but of course such exceptions of the rules are > constructable always.) > > Well, you tell that depending on the OS it can be that flush is > needed or it can be that flush is not needed (beacuse the I/O is > synchronized already), right? Also, applications should work on > any OS, which includes the OSes that do need flush. Its not OS's that need flush, its applications that want to have some assurance that data is written to the device that really needs to use flush. If your program ( or thread ) dies then it is in your best interest to write out the critical data as soon as possible, as economical as possible. These are trade-off's that the application programmer makes. A big buffer may mean big loss of data, a small buffer may mean spending too much time writing out data. > > > So would it be correct to say: > > "Applications, that should work under all OSes (including the > OSes where the I/O is not synchronised already), have to call > flush on OutputStream to ensure the data is transfered to the > kernel." > > or is this wrong? If so, then I'm afraid I missed the point again > :( > No that is not wrong. Ensuring that data is transfered to the OS is just about what any application can do. From tjarvi at qbang.org Thu Jun 14 08:16:47 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 14 Jun 2007 08:16:47 -0600 (MDT) Subject: [Rxtx] rxtx and usb-serial solution In-Reply-To: References: Message-ID: On Thu, 14 Jun 2007, Vladimir Kirtchev wrote: > Hi Trent, > > I develop a Java application which communicates with devices which have > USB-to-Serial bridge in them. The target OS is Linux. So for this purpose I > use RXTX. > > But I encountered a strange problem - when reading from the InputStream, I > receive series of zeros. I have this problem under Linux only. Under Windows > it is fine. > Actually this problem is the same as the one described here: > http://marc.info/?l=rxtx&m=109703190731748&w=2. > > > So I searched for the problem in the native code. And found that the root of > the problem is in SerialImp.c, > int configure_port( int fd ) > { > ... > ttyset.c_iflag = INPCK; > ... > } > > This line enables input parity checking, and the data sent from the device > is processed by the OS driver before being read with read(). > In this case the driver detects some problem and sets the received bytes to > zero. > > On the other hand in the Java part a set the serial port parameters with > SerialPort.PARITY_NONE. According to me, except all other things, this > should also disable INPCK in c_iflag. > > So I refactored the method translate_parity(...) to the following: > > int translate_parity( JNIEnv *env, struct termios *ttyset, jint parity ) > { > ENTER( "translate_parity" ); > #ifdef CMSPAR > ttyset->c_cflag &= ~(PARENB | PARODD | CMSPAR ); > #endif /* CMSPAR */ > switch( parity ) { > case JPARITY_NONE: > ttyset->c_iflag &= ~INPCK; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_EVEN: > ttyset->c_cflag |= PARENB; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_ODD: > ttyset->c_cflag |= PARENB | PARODD; > LEAVE( "translate_parity" ); > return 0; > #ifdef CMSPAR > case JPARITY_MARK: > ttyset->c_cflag |= PARENB | PARODD | CMSPAR; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_SPACE: > ttyset->c_cflag |= PARENB | CMSPAR; > LEAVE( "translate_parity" ); > return 0; > #endif /* CMSPAR */ > default: > printf("Parity missed %i\n", (int) parity ); > } > > LEAVE( "translate_parity" ); > /* > For some reason the native exceptions are not being caught. Moving this > to the Java side fixed the issue. taj. > throw_java_exception( env, UNSUPPORTED_COMM_OPERATION, > "", "parity value not supported" ); > */ > return 1; > } > > This modification solved the problem and now it works correctly under Linux. > > I think I will be a nice if this is idea is included in a future release of > RXTX. > > Thanks Vadim, I'll try that out. Forwarding to the rxtx mail-list too. This is probably not going to help USB drivers on windows which I'm sure some are looking for. As far as I can tell, windows USB bluetooth and serial dongles are limited by driver functionality. Some are good and others lack key features. -- Trent Jarvi tjarvi at qbang.org From dan.sandberg.lists at gmail.com Mon Jun 18 14:43:39 2007 From: dan.sandberg.lists at gmail.com (Dan Sandberg) Date: Mon, 18 Jun 2007 13:43:39 -0700 Subject: [Rxtx] Fix for JNI Get/Set Field Errors Message-ID: <4676EE7B.7060800@gmail.com> Hi, I've fixed the problems that cause the following JNI error when extra JNI checking ( -Xjni:check ) is turned on. FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) The problem was basically that GetLong was being used to get ints, and SetInt was used for longs. The patch below fixes this. Please let me know if there are any questions / problems. Cheers, -Dan diff -aur old/SerialImp.c src/SerialImp.c --- old/SerialImp.c 2007-06-18 13:24:33.000000000 -0700 +++ src/SerialImp.c 2007-06-18 06:26:26.000000000 -0700 @@ -1337,7 +1337,7 @@ report("init_threads: get eis\n"); jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); report("init_threads: set eis\n"); - (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); + (*eis->env)->SetLongField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); report("init_threads: stop\n"); report_time_end( ); return( 1 ); @@ -1530,7 +1530,7 @@ jobject jobj, jboolean interrupted ) { int fd = get_java_var( env, jobj,"fd","I" ); - struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var( env, jobj, "eis", "J" ); + struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var_long( env, jobj, "eis", "J" ); int result, count=0; char message[80]; @@ -2939,7 +2939,7 @@ /* TRENT */ int flag, count = 0; struct event_info_struct *eis = ( struct event_info_struct * ) - get_java_var( env, *jobj,"eis","J" ); + get_java_var_long( env, *jobj,"eis","J" ); report_time_start(); flag = eis->eventflags[SPE_DATA_AVAILABLE]; @@ -4873,9 +4873,9 @@ exceptions: none comments: ----------------------------------------------------------*/ -size_t get_java_var( JNIEnv *env, jobject jobj, char *id, char *type ) +long get_java_var_long( JNIEnv *env, jobject jobj, char *id, char *type ) { - int result = 0; + long result = 0; jclass jclazz = (*env)->GetObjectClass( env, jobj ); jfieldID jfd = (*env)->GetFieldID( env, jclazz, id, type ); @@ -4889,7 +4889,11 @@ LEAVE( "get_java_var" ); return result; } - result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); + if ( !strcmp( type, "J" ) ) { + result = (long)( (*env)->GetLongField( env, jobj, jfd ) ); + } else { + result = (int) ( (*env)->GetIntField( env, jobj, jfd ) ); + } /* ct7 & gel * Added DeleteLocalRef */ (*env)->DeleteLocalRef( env, jclazz ); if(!strncmp( "fd",id,2) && result == 0) @@ -4900,6 +4904,10 @@ return result; } +int get_java_var( JNIEnv *env, jobject jobj, char *id, char *type ) { + return (int) get_java_var_long( env, jobj, id, type ); +} + /*---------------------------------------------------------- throw_java_exception diff -aur old/SerialImp.h src/SerialImp.h --- old/SerialImp.h 2007-06-18 13:24:39.000000000 -0700 +++ src/SerialImp.h 2007-06-18 06:23:43.000000000 -0700 @@ -413,7 +413,8 @@ void system_wait(); void finalize_event_info_struct( struct event_info_struct * ); int read_byte_array( JNIEnv *, jobject *, int, unsigned char *, int, int ); -size_t get_java_var( JNIEnv *, jobject, char *, char * ); +int get_java_var( JNIEnv *, jobject, char *, char * ); +long get_java_var_long( JNIEnv *, jobject, char *, char * ); jboolean is_interrupted( struct event_info_struct * ); int send_event(struct event_info_struct *, jint, int ); void dump_termios(char *,struct termios *); From yvespielusenet at free.fr Tue Jun 26 03:41:58 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 11:41:58 +0200 Subject: [Rxtx] [PARALLEL] resource in use Message-ID: <1182850918.3483.10.camel@localhost.localdomain> Hello, So now I want to modify the timeout of the library for parallel port. I have downloaded source code. There is a makefile for migw. SO I have installed mingw on ubuntu and modified the makefile.mingw32 to set it for my system. I have no error but some warnings. The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But When I want to use it the jvm crash :( How can I know what is wrong ? How rxtx windows release has been done ? thanks -- yves piel From yvespielusenet at free.fr Tue Jun 26 07:17:02 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 15:17:02 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182850918.3483.10.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> Message-ID: <1182863822.3483.17.camel@localhost.localdomain> Here is the Makefile I use, the output of the 'make' and the log of the jvm when it crashed : - The Makefile : http://yvespiel.free.fr/rxtx/Makefile - The make output : http://yvespiel.free.fr/rxtx/compile.txt - The crash log : http://yvespiel.free.fr/rxtx/hs_err_pid2100.log I have compiled rxtx under Debian testing with mingw : narma at linimi:/tmp/err$ dpkg -l | grep mingw ii mingw32 3.4.5.20060117.1.dfsg-3 ii mingw32-binutils 2.17.50-20070129.1-1 ii mingw32-runtime 3.12-1 thanks fort help :) Le mardi 26 juin 2007 ? 11:41 +0200, yves pielusenet a ?crit : > Hello, > So now I want to modify the timeout of the library for parallel port. I > have downloaded source code. There is a makefile for migw. SO I have > installed mingw on ubuntu and modified the makefile.mingw32 to set it > for my system. > I have no error but some warnings. > The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But > When I want to use it the jvm crash :( > > How can I know what is wrong ? > > How rxtx windows release has been done ? > > thanks > From yvespielusenet at free.fr Tue Jun 26 07:40:11 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 15:40:11 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182863822.3483.17.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> <1182863822.3483.17.camel@localhost.localdomain> Message-ID: <1182865211.3483.21.camel@localhost.localdomain> I have add the options '--enable-stdcall-fixup' to the 'i586-mingw32msvc-ld' commande. Now I have no warning. But the JVM always crashes :( The output seems more detailled, but I don't understand anything... Here is files : http://yvespiel.free.fr/rxtx/2/ -- yves piel Le mardi 26 juin 2007 ? 15:17 +0200, yves pielusenet a ?crit : > Here is the Makefile I use, the output of the 'make' and the log of the > jvm when it crashed : > > - The Makefile : http://yvespiel.free.fr/rxtx/Makefile > - The make output : http://yvespiel.free.fr/rxtx/compile.txt > - The crash log : http://yvespiel.free.fr/rxtx/hs_err_pid2100.log > > I have compiled rxtx under Debian testing with mingw : > narma at linimi:/tmp/err$ dpkg -l | grep mingw > ii mingw32 3.4.5.20060117.1.dfsg-3 > ii mingw32-binutils 2.17.50-20070129.1-1 > ii mingw32-runtime 3.12-1 > > thanks fort help :) > > > Le mardi 26 juin 2007 ? 11:41 +0200, yves pielusenet a ?crit : > > Hello, > > So now I want to modify the timeout of the library for parallel port. I > > have downloaded source code. There is a makefile for migw. SO I have > > installed mingw on ubuntu and modified the makefile.mingw32 to set it > > for my system. > > I have no error but some warnings. > > The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But > > When I want to use it the jvm crash :( > > > > How can I know what is wrong ? > > > > How rxtx windows release has been done ? > > > > thanks > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From yvespielusenet at free.fr Tue Jun 26 08:27:42 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 16:27:42 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182865211.3483.21.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> <1182863822.3483.17.camel@localhost.localdomain> <1182865211.3483.21.camel@localhost.localdomain> Message-ID: <1182868062.3483.24.camel@localhost.localdomain> I think thant the include files of jdk were not for windows but for linux. So I have copied include/ folder from windows to linux and I modified the Makefile to use those file. It compile fine but the JVM always crash :( http://yvespiel.free.fr/rxtx/3/ Le mardi 26 juin 2007 ? 15:40 +0200, yves pielusenet a ?crit : > I have add the options '--enable-stdcall-fixup' to the > 'i586-mingw32msvc-ld' commande. Now I have no warning. But the JVM > always crashes :( The output seems more detailled, but I don't > understand anything... > Here is files : > http://yvespiel.free.fr/rxtx/2/ > From netbeans at gatworks.com Fri Jun 1 05:38:50 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 07:38:50 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <465F7ADD.1010501@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> Message-ID: <4660054A.2040202@gatworks.com> Manuel Naranjo wrote: In the case of my module, you can > unplug the device but it will not delete the symlink until those apps > that had opened the port has closed it. This is done this way to avoid > kernel panics. What does this mean to user code ? I have tried the alternate route ( other than closing ) which is sleep inbetween the I/O errors ( an unplugged USB device). When the device is plugged back in, The writes to the device still get an I/O error. This would seem to be a lost cause for the application. From netbeans at gatworks.com Fri Jun 1 06:35:48 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 08:35:48 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <465F7ADD.1010501@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> Message-ID: <466012A4.90608@gatworks.com> Manuel Naranjo wrote: In the case of my module, you can > unplug the device but it will not delete the symlink until those apps > that had opened the port has closed it. T Did u also mean for this to happen? USB0 was not closed by application. Apparently USB1 got created when USB device was plugged back in. There is only one USB device on a 4 port USB hub. This also seems to suggest that application recovery to be impossible. > Jun 1 07:10:08 mylaptop kernel: garmin_gps 1-1.4:1.0: Garmin GPS usb/tty converter detected > Jun 1 07:10:08 mylaptop kernel: usb 1-1.4: Garmin GPS usb/tty converter now attached to ttyUSB0 > Jun 1 07:15:17 mylaptop kernel: usb 1-1: USB disconnect, address 4 > Jun 1 07:15:17 mylaptop kernel: usb 1-1.4: USB disconnect, address 5 > Jun 1 07:15:17 mylaptop kernel: garmin_gps 1-1.4:1.0: device disconnected > Jun 1 07:15:26 mylaptop kernel: usb 1-1: new full speed USB device using uhci_hcd and address 6 > Jun 1 07:15:26 mylaptop kernel: hub 1-1:1.0: USB hub found > Jun 1 07:15:26 mylaptop kernel: hub 1-1:1.0: 4 ports detected > Jun 1 07:15:27 mylaptop kernel: usb 1-1.4: new full speed USB device using uhci_hcd and address 7 > Jun 1 07:15:27 mylaptop kernel: garmin_gps 1-1.4:1.0: Garmin GPS usb/tty converter detected > Jun 1 07:15:27 mylaptop kernel: usb 1-1.4: Garmin GPS usb/tty converter now attached to ttyUSB1 From naranjo.manuel at gmail.com Fri Jun 1 09:17:22 2007 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Fri, 01 Jun 2007 12:17:22 -0300 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <466012A4.90608@gatworks.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> <466012A4.90608@gatworks.com> Message-ID: <46603882.5050701@gmail.com> Uncle George escribi?: > Manuel Naranjo wrote: > In the case of my module, you can > >> unplug the device but it will not delete the symlink until those apps >> that had opened the port has closed it. T >> > > Did u also mean for this to happen? USB0 was not closed by application. > > Apparently USB1 got created when USB device was plugged back in. There > is only one USB device on a 4 port USB hub. > > This also seems to suggest that application recovery to be impossible. > Exactly there's a dead symlink (you can read and write to it and nothing will happen) and a new port will be created when a new device is connencted. From netbeans at gatworks.com Fri Jun 1 10:20:46 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 12:20:46 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <46603882.5050701@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> <466012A4.90608@gatworks.com> <46603882.5050701@gmail.com> Message-ID: <4660475E.5090202@gatworks.com> Not sure what u mean by "symlink". U cant read/write to it anymore. U get I/O error. In this scenario the device effectively went dead, and only solution is to close the channel. reconnecting the USB device, although dead, but not closed, will create a second device. This does not seem to be a desirable side-effect. The user will now have ttyUSB1, wondering where did ttyUSB0 go to. The application will also be in a confused state, as well as RXTX, because RXTX wont know about ttyUSB1. Manuel Naranjo wrote: > Uncle George escribi?: >> Manuel Naranjo wrote: >> In the case of my module, you can >> >>> unplug the device but it will not delete the symlink until those apps >>> that had opened the port has closed it. T >>> >> Did u also mean for this to happen? USB0 was not closed by application. >> >> Apparently USB1 got created when USB device was plugged back in. There >> is only one USB device on a 4 port USB hub. >> >> This also seems to suggest that application recovery to be impossible. >> > Exactly there's a dead symlink (you can read and write to it and nothing > will happen) and a new port will be created when a new device is connencted. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From arnab.bhaumik at gmail.com Mon Jun 4 01:40:16 2007 From: arnab.bhaumik at gmail.com (arnab bhaumik) Date: Mon, 4 Jun 2007 13:10:16 +0530 Subject: [Rxtx] full duplex com port with rxtx Message-ID: hi , till now i did half duplex communication with rxtx package on com package. my question is : is it possible to use com port with full duplex mode with rxtx package . ther is example of SimpleRead class and SimpleWrite class. it is clear that if i can use both the class simultaneously then full duplex is possible......... arnab/vu2bpw -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070604/6edb0453/attachment-0009.html From lists at iDIAcomputing.com Mon Jun 4 07:53:17 2007 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Mon, 04 Jun 2007 09:53:17 -0400 Subject: [Rxtx] full duplex com port with rxtx In-Reply-To: References: Message-ID: <4664194D.90301@iDIAcomputing.com> arnab bhaumik wrote: > hi , > > till now i did half duplex communication with rxtx package on com > package. > > my question is : is it possible to use com port with full duplex mode > with rxtx package . > > > ther is example of SimpleRead class and SimpleWrite class. it is > clear that if i can use both the class simultaneously then full duplex > is possible......... I haven't looked at the SimpleRead and SimpleWrite classes (I originally wrote my code for the javax.comm api), but full duplex is certainly possible. My CommReader class requires an object analogous to a OutputStream or Writer. When started, it spawns a thread that reads the comm port and writes to that output device. In this way the input is asynchronous and dependent on the actual input data. For full duplex, I extend that class with CommReaderWriter, which adds synchronous output methods. Hope that helps, George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From supsoop at hotmail.com Mon Jun 4 15:21:06 2007 From: supsoop at hotmail.com (soop soop) Date: Mon, 04 Jun 2007 21:21:06 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- Message-ID: Hi Guys, Looked through the archives but still cannot figure this out. I have a Motorola G24 GPRS/GSM modem that I am connecting to my server running Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not detecting the port, CommPortIdentifier.getPortIdentifiers(). I have added the line to RXTXCommDriver: "ttyACM" // for USB Modems Rxtx still does not seem to find the port. Is there something I am missing to make this port visable? [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control Model driver for USB modems and ISDN adapters I really need your help as I have moved my server from windows to Linux and have been down for a few days because of this .. Thanks so much! _________________________________________________________________ PC Magazine’s 2007 editors’ choice for best Web mail—award-winning Windows Live Hotmail. http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 From tjarvi at qbang.org Mon Jun 4 16:17:35 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Jun 2007 16:17:35 -0600 (MDT) Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: On Mon, 4 Jun 2007, soop soop wrote: > Hi Guys, > > Looked through the archives but still cannot figure this out. I have a > Motorola G24 GPRS/GSM modem that I am connecting to my server running Ubuntu. > I can see my modem as is shows up as ttyACM0, but RXTX is not detecting the > port, CommPortIdentifier.getPortIdentifiers(). > > I have added the line to RXTXCommDriver: > > "ttyACM" // for USB Modems > > Rxtx still does not seem to find the port. Is there something I am missing to > make this port visable? > > [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver > [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device > [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control Model > driver for USB modems and ISDN adapters > > I really need your help as I have moved my server from windows to Linux and > have been down for a few days because of this .. Thanks so much! > You could try the INSTALL documentation that comes with the source for possible solutions. Those usually involve lockfile creation, permissions on the device file or the device is in use by another application (even another session of your application). The usual commands: ls -l /dev/ttyACM0 fuser /dev/ttyACM0 touch /var/lock/LCK.testfile && rm -f /var/lock/LCK.testfile whoami To disable lockfiles: ../configure --disable-lockfiles && make install -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Jun 4 16:22:52 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 04 Jun 2007 18:22:52 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <466490BC.3090801@gatworks.com> soop soop wrote: > I really need your help as I have moved my server from windows to Linux > and have been down for a few days because of this .. Thanks so much! can u open the device ? ie is the file protection/permissions keeping you out? From supsoop at hotmail.com Mon Jun 4 16:44:40 2007 From: supsoop at hotmail.com (soop soop) Date: Mon, 04 Jun 2007 22:44:40 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <466490BC.3090801@gatworks.com> Message-ID: Thanks for the reply, I see no exceptions being thrown, just no detection of the port whats so ever. I will run rxtx in debug mode and log. If this were a permissions issue would I not see some exceptions being thrown? >From: Uncle George >Reply-To: RXTX Developers and Users >To: RXTX Developers and Users >Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >Date: Mon, 04 Jun 2007 18:22:52 -0400 > >soop soop wrote: > > > I really need your help as I have moved my server from windows to Linux > > and have been down for a few days because of this .. Thanks so much! > >can u open the device ? ie is the file protection/permissions keeping >you out? >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ Get a preview of Live Earth, the hottest event this summer - only on MSN http://liveearth.msn.com?source=msntaglineliveearthhm From netbeans at gatworks.com Mon Jun 4 17:06:15 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 04 Jun 2007 19:06:15 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <46649AE7.10405@gatworks.com> Exceptions on what? On startup it wants to lookup all devices in /dev that it is capable of opening ( within the list of specific 'comm' devices ). If it cannot open, then does not get onto list. Part of this process, if configured, will also test if the "LOCK" schema can also be opened for the device. then it gets on the list of avail comm port. soop soop wrote: > Thanks for the reply, > > I see no exceptions being thrown, just no detection of the port whats so > ever. I will run rxtx in debug mode and log. If this were a permissions > issue would I not see some exceptions being thrown? > > >> From: Uncle George >> Reply-To: RXTX Developers and Users >> To: RXTX Developers and Users >> Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >> Date: Mon, 04 Jun 2007 18:22:52 -0400 >> >> soop soop wrote: >> >>> I really need your help as I have moved my server from windows to Linux >>> and have been down for a few days because of this .. Thanks so much! >> can u open the device ? ie is the file protection/permissions keeping >> you out? >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _________________________________________________________________ > Get a preview of Live Earth, the hottest event this summer - only on MSN > http://liveearth.msn.com?source=msntaglineliveearthhm > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From alex.flint at gmail.com Mon Jun 4 21:31:49 2007 From: alex.flint at gmail.com (Alex Flint) Date: Tue, 5 Jun 2007 13:01:49 +0930 Subject: [Rxtx] random EXCEPTION_ACCESS_VIOLATION errors Message-ID: Hi All, I'm running winXP and RXTX 2.1-7r2 (the latest from the webpage as of June 2007). I'm sending sequences of 64 lines (each line has about 15 chars) at various intervals. The strings are sent fine, until I get the following error (from hs_err_pid3316.log, at the end of this email). What can I do to avoid the error? Obviously this is a low-level memory exception, but is there any way I can keep the JVM running after such an error? I noticed the exact same problem here: http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20070129/1180520.html Cheers, Alex # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x100034fb, pid=3316, tid=2400 # # Java VM: Java HotSpot(TM) Client VM (1.6.0_01-b06 mixed mode, sharing) # Problematic frame: # C [rxtxSerial.dll+0x34fb] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # --------------- T H R E A D --------------- Current thread (0x00386400): JavaThread "main" [_thread_in_native, id=2400] siginfo: ExceptionCode=0xc0000005, reading address 0x20726f78 Registers: EAX=0x20726f20, EBX=0x6d8922c0, ECX=0x00000005, EDX=0x20726f20 ESP=0x003efa30, EBP=0x003efb68, ESI=0x269728a0, EDI=0x00386400 EIP=0x100034fb, EFLAGS=0x00010212 Top of Stack: (sp=0x003efa30) 0x003efa30: 003efa3c 003efa64 0000000f ffffffff 0x003efa40: 003efa40 2a97f808 003efa6c 2b190ca8 0x003efa50: 00000000 2b190ec0 003efa90 008e2dd7 0x003efa60: 003efa90 008e2dd7 26977f88 6d815e72 0x003efa70: 00000004 2696eae0 0000008a 003efb0c 0x003efa80: 6d852b4a 2696eae0 00000003 26970930 0x003efa90: 000000cb 2696eae0 6d86b264 00385d40 0x003efaa0: 0000003f 003efb0c 26977f90 2ace65d8 Instructions: (pc=0x100034fb) 0x100034eb: ff ff 8d 76 00 eb 02 89 f6 90 8b 45 f8 8b 55 f8 0x100034fb: 8b 4a 58 83 c9 04 89 48 58 83 c4 f8 8b 45 f8 8b Stack: [0x003a0000,0x003f0000), sp=0x003efa30, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x34fb] Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j gnu.io.RXTXPort.writeArray([BIIZ)V+0 j gnu.io.RXTXPort$SerialOutputStream.write([B)V+76 j com.bjt.media.server.CommLink.send(Ljava/lang/String;)V+48 j com.bjt.media.server.DigitoolConnection.select(I)V+73 j com.bjt.media.server.DigitoolConnection.main([Ljava/lang/String;)V+74 v ~StubRoutines::call_stub --------------- P R O C E S S --------------- Java Threads: ( => current thread ) 0x02a69400 JavaThread "Thread-0" [_thread_in_native, id=3052] 0x02a4d000 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=3920] 0x02a48400 JavaThread "CompilerThread0" daemon [_thread_blocked, id=1968] 0x02a47400 JavaThread "Attach Listener" daemon [_thread_blocked, id=2984] 0x02a46400 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=2660] 0x02a41c00 JavaThread "Finalizer" daemon [_thread_blocked, id=3924] 0x02a3d800 JavaThread "Reference Handler" daemon [_thread_blocked, id=4008] =>0x00386400 JavaThread "main" [_thread_in_native, id=2400] Other Threads: 0x02a34400 VMThread [id=3708] 0x02a4e800 WatcherThread [id=3964] VM state:not at safepoint (normal execution) VM Mutex/Monitor currently owned by a thread: None Heap def new generation total 960K, used 131K [0x22960000, 0x22a60000, 0x22e40000) eden space 896K, 7% used [0x22960000, 0x22970ea8, 0x22a40000) from space 64K, 99% used [0x22a50000, 0x22a5fff8, 0x22a60000) to space 64K, 0% used [0x22a40000, 0x22a40000, 0x22a50000) tenured generation total 4096K, used 76K [0x22e40000, 0x23240000, 0x26960000) the space 4096K, 1% used [0x22e40000, 0x22e53060, 0x22e53200, 0x23240000) compacting perm gen total 12288K, used 137K [0x26960000, 0x27560000, 0x2a960000) the space 12288K, 1% used [0x26960000, 0x26982518, 0x26982600, 0x27560000) ro space 8192K, 62% used [0x2a960000, 0x2ae5e4e8, 0x2ae5e600, 0x2b160000) rw space 12288K, 52% used [0x2b160000, 0x2b7a0e78, 0x2b7a1000, 0x2bd60000) Dynamic libraries: 0x00400000 - 0x00423000 C:\Program Files\Java\jre1.6.0_01\bin\javaw.exe 0x7c900000 - 0x7c9b0000 C:\WINDOWS\system32\ntdll.dll 0x7c800000 - 0x7c8f4000 C:\WINDOWS\system32\kernel32.dll 0x77dd0000 - 0x77e6b000 C:\WINDOWS\system32\ADVAPI32.dll 0x77e70000 - 0x77f01000 C:\WINDOWS\system32\RPCRT4.dll 0x7e410000 - 0x7e4a0000 C:\WINDOWS\system32\USER32.dll 0x77f10000 - 0x77f57000 C:\WINDOWS\system32\GDI32.dll 0x76390000 - 0x763ad000 C:\WINDOWS\system32\IMM32.DLL 0x7c340000 - 0x7c396000 C:\Program Files\Java\jre1.6.0_01\bin\msvcr71.dll 0x6d7c0000 - 0x6da07000 C:\Program Files\Java\jre1.6.0_01\bin\client\jvm.dll 0x76b40000 - 0x76b6d000 C:\WINDOWS\system32\WINMM.dll 0x5cd70000 - 0x5cd77000 C:\WINDOWS\system32\serwvdrv.dll 0x5b0a0000 - 0x5b0a7000 C:\WINDOWS\system32\umdmxfrm.dll 0x6d310000 - 0x6d318000 C:\Program Files\Java\jre1.6.0_01\bin\hpi.dll 0x76bf0000 - 0x76bfb000 C:\WINDOWS\system32\PSAPI.DLL 0x6d770000 - 0x6d77c000 C:\Program Files\Java\jre1.6.0_01\bin\verify.dll 0x6d3b0000 - 0x6d3cf000 C:\Program Files\Java\jre1.6.0_01\bin\java.dll 0x6d7b0000 - 0x6d7bf000 C:\Program Files\Java\jre1.6.0_01\bin\zip.dll 0x10000000 - 0x10012000 C:\Documents and Settings\Alex\workspace\MediaServer\rxtxSerial.dll 0x73d90000 - 0x73db7000 C:\WINDOWS\system32\crtdll.dll VM Arguments: jvm_args: -Djava.library.path=C:\Documents and Settings\Alex\workspace\MediaServer java_command: com.bjt.media.server.DigitoolConnection Launcher Type: SUN_STANDARD Environment Variables: CLASSPATH=.;C:\Program Files\Java\j2re1.4.2_07\lib\ext\QTJava.zip PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\wbem;c:\applications\php;C:\Program Files\MATLAB\R2006a\bin\win32;C:\Roger\Projects\UAV\Bin\Debug;C:\Program Files\Microsoft SQL Server\80\Tools\Binn\;c:\Program Files\Microsoft SQL Server\90\Tools\binn\;C:\Program Files\QuickTime\QTSystem\;C:\Pfps\system;C:\Program Files\Java\jdk1.6.0_01\bin;C:\Program Files\Java\jdk1.6.0_01\jre\bin USERNAME=Alex OS=Windows_NT PROCESSOR_IDENTIFIER=x86 Family 15 Model 4 Stepping 1, GenuineIntel --------------- S Y S T E M --------------- OS: Windows XP Build 2600 Service Pack 2 CPU:total 1 family 15, cmov, cx8, fxsr, mmx, sse, sse2 Memory: 4k page, physical 1046508k(275288k free), swap 2522816k(1909176k free) vm_info: Java HotSpot(TM) Client VM (1.6.0_01-b06) for windows-x86, built on Mar 14 2007 00:24:02 by "java_re" with unknown MS VC++:1310 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070604/c87ae1f0/attachment-0009.html From alwyn.schoeman at gmail.com Tue Jun 5 00:10:19 2007 From: alwyn.schoeman at gmail.com (Alwyn Schoeman) Date: Tue, 5 Jun 2007 08:10:19 +0200 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Hi, I'm using a similar modem. By default rxtx doesn't look for devices that start with ACM, so you need to modify the source code and recompile. Look in RXTXCommDriver and add values for ACM in the registerScannedPorts method in the Linux specific parts. Look for osName.equals("Linux")... On 6/4/07, soop soop wrote: > > Hi Guys, > > Looked through the archives but still cannot figure this out. I have a > Motorola G24 GPRS/GSM modem that I am connecting to my server running > Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not > detecting the port, CommPortIdentifier.getPortIdentifiers(). > > I have added the line to RXTXCommDriver: > > "ttyACM" // for USB Modems > > Rxtx still does not seem to find the port. Is there something I am missing > to make this port visable? > > [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver > [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device > [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control > Model > driver for USB modems and ISDN adapters > > I really need your help as I have moved my server from windows to Linux > and > have been down for a few days because of this .. Thanks so much! > > _________________________________________________________________ > PC Magazine's 2007 editors' choice for best Web mail?award-winning Windows > Live Hotmail. > > http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -- Alwyn Schoeman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/b6cb3053/attachment-0009.html From naranjo.manuel at gmail.com Tue Jun 5 06:48:45 2007 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Tue, 05 Jun 2007 09:48:45 -0300 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> References: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Message-ID: <46655BAD.7010501@gmail.com> That's right, an easier solution is creating symlinks to acm. For example make ttyS70 to 79 point to ACM0 to 9 and that will help you a lot, and doesn't even require compile. > Hi, > > I'm using a similar modem. By default rxtx doesn't look for devices > that start with ACM, so you need to modify the > source code and recompile. > > Look in RXTXCommDriver and add values for ACM in the > registerScannedPorts method in the Linux specific parts. Look for > osName.equals("Linux")... > From juanemc2 at gmail.com Tue Jun 5 07:02:43 2007 From: juanemc2 at gmail.com (Juan) Date: Tue, 5 Jun 2007 10:02:43 -0300 Subject: [Rxtx] Problems with Epson TMU220B POSPrinter using XON/XOFF Flow Control and rxtx jar and dll's with the serial port. Message-ID: Hi!, I?m having trouble printing to the serial port using the latest version of rxtx jar and dll's with an Epson POSPrinter. I`ve switched the printer to work with XON/XOFF Flow Control and have watched the serial port to be sure the printer is sending the XON XOFF stop and go characters. I`ve setted the port like this: CommPortIdentifier commPortIdentifier = CommPortIdentifier.* getPortIdentifier*(_portName); SerialPort serialPort = (SerialPort)commPortIdentifier.open(*this*.getClass().getName(), 2000); serialPort.setSerialPortParams(_baudRate, _dataBits, _stopBits, _parity); serialPort.setFlowControlMode( SerialPort.*FLOWCONTROL_XONXOFF_IN* | SerialPort.*FLOWCONTROL_XONXOFF_OUT*); where the baudRate is 9600 the dataBits is 8 the stopBits is 1 and the parity is 0 It seems as the library isn`t taking into account the XON XOFF setting. I would like to know if I`m setting correctly the Flow Control and if you had had any experiences using XON XOFF flow control and could give me some help to solve my problem. I`m very thankful in advance, Yours, Juan Polero -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/b080995a/attachment-0009.html From ehdez.correo at gmail.com Tue Jun 5 07:12:53 2007 From: ehdez.correo at gmail.com (=?ISO-8859-1?Q?Enrique_Hern=E1ndez?=) Date: Tue, 5 Jun 2007 09:12:53 -0400 Subject: [Rxtx] problem with rxtx Message-ID: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Hello: I doing a simple test to show the serial ports. This is the code: import java.util.Enumeration; import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; public class Show { private Enumeration portList; private CommPortIdentifier portId; private SerialPort port; /** Creates a new instance of Show */ public Show() { } public static void main(String args[]){ Show show = new Show(); show.portList = CommPortIdentifier.getPortIdentifiers(); String tPort = ""; System.out.println("========================================="); while(show.portList.hasMoreElements()){ show.portId = (CommPortIdentifier)show.portList.nextElement(); if(show.portId.getPortType() == CommPortIdentifier.PORT_SERIAL) tPort = "Serial"; else tPort = "Parallel"; System.out.println(show.portId.getName() + " " + tPort); } } } whit The problem is that this code not show the serial ports, this show the no use serial ports. I want to connect whit the modem but when windows open and connect the modem my application don't see the port(COMM3) when it is connect. what I can do? Is that the correct way to know the ports? thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/eedd744b/attachment-0009.html From ehdez.correo at gmail.com Tue Jun 5 07:42:13 2007 From: ehdez.correo at gmail.com (=?ISO-8859-1?Q?Enrique_Hern=E1ndez?=) Date: Tue, 5 Jun 2007 09:42:13 -0400 Subject: [Rxtx] serial port Message-ID: <4a814e1f0706050642p4ce9ac7bka80f9479c524c5ea@mail.gmail.com> Hello: How I can ask to the port what device is connect and information about this device. thanks. bye. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/4d10d26a/attachment-0009.html From supsoop at hotmail.com Tue Jun 5 09:29:00 2007 From: supsoop at hotmail.com (soop soop) Date: Tue, 05 Jun 2007 15:29:00 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Message-ID: Hi Guys, Thanks for all your help. I found the problem. I created a user, Tomcat55, for my tomcat but it did not belong to any group. I then added this user to dialout group to have access to the device ttyACM0. Works perfectly! Again permissions was the issue. This also seems to be persistent as a server reboot does not effect the access. Cheers! >From: "Alwyn Schoeman" >Reply-To: RXTX Developers and Users >To: "RXTX Developers and Users" >Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >Date: Tue, 5 Jun 2007 08:10:19 +0200 > >Hi, > >I'm using a similar modem. By default rxtx doesn't look for devices that >start with ACM, so you need to modify the >source code and recompile. > >Look in RXTXCommDriver and add values for ACM in the registerScannedPorts >method in the Linux specific parts. Look for osName.equals("Linux")... > >On 6/4/07, soop soop wrote: >> >>Hi Guys, >> >>Looked through the archives but still cannot figure this out. I have a >>Motorola G24 GPRS/GSM modem that I am connecting to my server running >>Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not >>detecting the port, CommPortIdentifier.getPortIdentifiers(). >> >>I have added the line to RXTXCommDriver: >> >>"ttyACM" // for USB Modems >> >>Rxtx still does not seem to find the port. Is there something I am missing >>to make this port visable? >> >>[ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver >>[ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device >>[ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control >>Model >>driver for USB modems and ISDN adapters >> >>I really need your help as I have moved my server from windows to Linux >>and >>have been down for a few days because of this .. Thanks so much! >> >>_________________________________________________________________ >>PC Magazine's 2007 editors' choice for best Web mail—award-winning Windows >>Live Hotmail. >> >>http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 >> >> >>_______________________________________________ >>Rxtx mailing list >>Rxtx at qbang.org >>http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > >-- >Alwyn Schoeman >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ Need a break? Find your escape route with Live Search Maps. http://maps.live.com/default.aspx?ss=Restaurants~Hotels~Amusement%20Park&cp=33.832922~-117.915659&style=r&lvl=13&tilt=-90&dir=0&alt=-1000&scene=1118863&encType=1&FORM=MGAC01 From netbeans at gatworks.com Tue Jun 5 09:42:31 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 11:42:31 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <46658467.20101@gatworks.com> soop soop wrote: > > Hi Guys, > > Thanks for all your help. I found the problem. I created a user, > Tomcat55, for my tomcat but it did not belong to any group. I then added Look at man pages for the program udev. From tjarvi at qbang.org Tue Jun 5 18:18:17 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Jun 2007 18:18:17 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Message-ID: On Tue, 5 Jun 2007, Enrique Hern?ndez wrote: > The problem is that this code not show the serial ports, this show the no > use serial ports. I want to connect whit the modem but when windows open and > connect the modem my application don't see the port(COMM3) when it is > connect. > what I can do? > Is that the correct way to know the ports? > Hello, We may have problems understanding each other. On windows, the port will not be an available serial port if another application has the port open. That is just how the library behaves. If you can not see the port in the enumerated list, you could not open it. Also note that enumeration only happens once. If you add a port such as a new USB dongle, the port will not be visible until the next time your application runs. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Tue Jun 5 18:45:01 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 20:45:01 -0400 Subject: [Rxtx] problem with rxtx In-Reply-To: References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Message-ID: <4666038D.8090700@gatworks.com> Trent Jarvi wrote: > > > Also note that enumeration only happens once. If you add a port such as > a new USB dongle, the port will not be visible until the next time your > application runs. Is this written in stone ? somewhere? From tjarvi at qbang.org Tue Jun 5 18:54:36 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Jun 2007 18:54:36 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <4666038D.8090700@gatworks.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> Message-ID: On Tue, 5 Jun 2007, Uncle George wrote: > Trent Jarvi wrote: >> >> >> Also note that enumeration only happens once. If you add a port such as >> a new USB dongle, the port will not be visible until the next time your >> application runs. > > Is this written in stone ? somewhere? It is just the current behavior. There is nothing preventing a fix that allows reenumeration. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Tue Jun 5 19:55:19 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 21:55:19 -0400 Subject: [Rxtx] problem with rxtx In-Reply-To: References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> Message-ID: <46661407.4020308@gatworks.com> >> Is this written in stone ? somewhere? > > It is just the current behavior. There is nothing preventing a fix that > allows reenumeration. With usb, ..... , things come and go. Seems a shame that you have to kill application to get at the device u just plugged in. From joachim at buechse.ch Wed Jun 6 01:50:06 2007 From: joachim at buechse.ch (Joachim Buechse) Date: Wed, 6 Jun 2007 09:50:06 +0200 Subject: [Rxtx] problem with rxtx In-Reply-To: <46661407.4020308@gatworks.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> <46661407.4020308@gatworks.com> Message-ID: <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> On MacOS RXTX's enumeration handling is more flexible. It will find new ports that are added during the lifetime of the application. But this is inherently incompatible with suns javax.comm implementation... Regards, Joachim On 06.06.2007, at 03:55, Uncle George wrote: > >>> Is this written in stone ? somewhere? >> >> It is just the current behavior. There is nothing preventing a >> fix that >> allows reenumeration. > > With usb, ..... , things come and go. Seems a shame that you have to > kill application to get at the device u just plugged in. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Jun 6 06:06:48 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Jun 2007 06:06:48 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> <46661407.4020308@gatworks.com> <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> Message-ID: Sun's javax.comm is not a major concern going forward. As long as we do not break old applications using rxtx, I see no reason to limit rxtx to that convention. We have already rejected version 3 from Sun as a dead end and limited our compatability to version 2. That does not mean we will not try to work with Sun and others but the current javax.comm convention (v3) is not a well conceived path. There has been discussion about doing a JSR which is one valid option. On Wed, 6 Jun 2007, Joachim Buechse wrote: > On MacOS RXTX's enumeration handling is more flexible. It will find > new ports that are added during the lifetime of the application. But > this is inherently incompatible with suns javax.comm implementation... > > Regards, > Joachim > > On 06.06.2007, at 03:55, Uncle George wrote: > >> >>>> Is this written in stone ? somewhere? >>> >>> It is just the current behavior. There is nothing preventing a >>> fix that >>> allows reenumeration. >> >> With usb, ..... , things come and go. Seems a shame that you have to >> kill application to get at the device u just plugged in. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From yvespielusenet at free.fr Wed Jun 6 08:46:35 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 16:46:35 +0200 Subject: [Rxtx] [PARALLEL] resource in use Message-ID: <1181141195.3407.20.camel@localhost.localdomain> Hello, I want to use rxtx in my application. I haveto send data to a very old printer (which have a drum and hammers http://perso.orange.fr/tiie/page00010017.html) This is printer is connecter with centronics. It works well but, while it's writting and I putthe printer off-line, after about 45 seconds, I have this error : ------------------------------------- java.io.IOException: La ressource demand?e est en cours d'utilisation. in writeArray at gnu.io.LPRPort.writeArray(Native Method) at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:292) at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:161) at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:156) at mce.buffer.bufferManager.BufferManager$PrintBuffer.run(BufferManager.java:141) The IOexception means "The wanted resource is in use" ------------------------------------- Here is the line 141 of BufferManager : ------------------------------------- while(send){ try{ fos.write(bb); <=== line 141 send = false; } catch(Exception e){ javax.swing.JOptionPane.showMessageDialog(null, "Erreur d'envoie. Veuillez cliquer sur OK pour relancer l'impression de la vignette.\nV?rifiez votre impression !", "Erreur d'envoie", javax.swing.JOptionPane.WARNING_MESSAGE); e.printStackTrace(System.err); System.err.flush(); System.out.println(e); send = true; } } -------------------------------- 'fos' is an outputstream which contains the rxtx stream (this.os is the rxtx outputstream) : -------------------------------- public void write(byte[] bb) throws IOException{ this.write(bb, 0, bb.length); } public void write(byte[] bb, int off, int len) throws IOException{ while(!imp1.isPrinterSelected() || !imp2.isPrinterSelected()){ } this.os.write(bb, off, len); } -------------------------------- Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( can you help me ? thank you :) -- yves piel From yvespielusenet at free.fr Wed Jun 6 09:11:15 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 17:11:15 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181141195.3407.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> Message-ID: <1181142675.3407.23.camel@localhost.localdomain> I forgot to tell that It's under windows XP and java 1.5. Le mercredi 06 juin 2007 ? 16:46 +0200, yves pielusenet a ?crit : > Hello, > I want to use rxtx in my application. I haveto send data to a very old > printer (which have a drum and hammers > http://perso.orange.fr/tiie/page00010017.html) > This is printer is connecter with centronics. It works well but, while > it's writting and I putthe printer off-line, after about 45 seconds, I > have this error : > ------------------------------------- > java.io.IOException: La ressource demand?e est en cours d'utilisation. > in writeArray > at gnu.io.LPRPort.writeArray(Native Method) > at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:292) > at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:161) > at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:156) > at mce.buffer.bufferManager.BufferManager$PrintBuffer.run(BufferManager.java:141) > > The IOexception means "The wanted resource is in use" > ------------------------------------- > > Here is the line 141 of BufferManager : > > ------------------------------------- > while(send){ > try{ > fos.write(bb); <=== line 141 > send = false; > } > catch(Exception e){ > javax.swing.JOptionPane.showMessageDialog(null, "Erreur d'envoie. Veuillez cliquer sur OK pour relancer l'impression de la vignette.\nV?rifiez votre impression !", "Erreur d'envoie", javax.swing.JOptionPane.WARNING_MESSAGE); > e.printStackTrace(System.err); > System.err.flush(); > System.out.println(e); > send = true; > } > } > -------------------------------- > 'fos' is an outputstream which contains the rxtx stream (this.os is the rxtx outputstream) : > > -------------------------------- > public void write(byte[] bb) throws IOException{ > this.write(bb, 0, bb.length); > } > public void write(byte[] bb, int off, int len) throws IOException{ > while(!imp1.isPrinterSelected() || !imp2.isPrinterSelected()){ > } > this.os.write(bb, off, len); > } > -------------------------------- > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > can you help me ? > > thank you :) > From netbeans at gatworks.com Wed Jun 6 09:21:46 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 11:21:46 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181141195.3407.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> Message-ID: <4666D10A.8000507@gatworks.com> } > -------------------------------- > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > can you help me ? > > thank you :) > windoz or linux? ( I guess windoz ) for windoz, there appears to be a timeout ( as Comments suggest ) of about 40seconds. > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } for linux, there is no implied timeout. > if( write( fd, bytes, count ) < 0 ) > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); From netbeans at gatworks.com Wed Jun 6 09:39:41 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 11:39:41 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666D10A.8000507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> Message-ID: <4666D53D.90000@gatworks.com> Uncle George wrote: > } >> -------------------------------- >> >> Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( >> >> can you help me ? From reading the code, I can see your concern. And it appears you are correct, because some of the data will be sent to the OS printer buffers, and then it will refuse to accept anymore. Unfortunately, writeArray does not return the num of characters written :{ So application has no idea to how many characters were accepted by the OS. I dont do windoz, so I cant say with absolute certainty what windoz will do with an off-line condition. If you have the source, and can compile, then maybe u can increase the loop count to hit 4hours? From yvespielusenet at free.fr Wed Jun 6 09:53:25 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 17:53:25 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666D10A.8000507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> Message-ID: <1181145205.3407.35.camel@localhost.localdomain> Thank you for your explanation :) This timeout comes when no data has been send to the printer after 40seconds if I well understand. But why there is such a timeout ? If I setthe printer offline while it's printing I mustn't have an exception. I don't understand why the "printer should solv all problems like buffer full" in 40 seconds. If I pause the printer the buffer will not be emptied, isn't it ? I not very familiar with C/C++, but it seem that the exception is thrown only when countWritten == 0, that means no data at all has been sent. So Is my code is good since when I intercept this exception I send all my buffer again. There is no way that the printer receive two times same bytes ? thanks ps: yes the application is running on windows XP since I developpe under Debian Le mercredi 06 juin 2007 ? 11:21 -0400, Uncle George a ?crit : > } > > -------------------------------- > > > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > > > can you help me ? > > > > thank you :) > > > > windoz or linux? ( I guess windoz ) > > for windoz, there appears to be a timeout ( as Comments suggest ) of > about 40seconds. > > while( count > 0 ){ > > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > > /* > > this are 20 * 2 seconds, in this time a printer (or other parallel device) > > should solv all problems like buffer full, etc > > */ > > if(errorCount++ < 20){ > > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > > continue; > > } > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > for linux, there is no implied timeout. > > if( write( fd, bytes, count ) < 0 ) > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Wed Jun 6 10:34:24 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 12:34:24 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181145205.3407.35.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> Message-ID: <4666E210.30507@gatworks.com> yves pielusenet wrote: > Thank you for your explanation :) > This timeout comes when no data has been send to the printer after > 40seconds if I well understand. But why there is such a timeout ? If I > setthe printer offline while it's printing I mustn't have an exception. > I don't understand why the "printer should solv all problems like buffer > full" in 40 seconds. If I pause the printer the buffer will not be > emptied, isn't it ? > > I not very familiar with C/C++, but it seem that the exception is thrown > only when countWritten == 0, that means no data at all has been sent. So > Is my code is good since when I intercept this exception I send all my > buffer again. There is no way that the printer receive two times same > bytes ? More technically, the function call returns and reports that 0 characters was written in this call. when 0 characters are written, it will check how many times 0 characters was written. If it has tried LESS than 20 times(errorCount), it will sleep() and try to write again. After 20 times, it wont sleep, but throw you the exception. Now suppose you are writing a 120 character line. you off-lined/paused your printer. The OS has room for 80 more characters in it's printer buffer. The WriteFile() will have a char count of 120, but on return the countWritten = 80. You still have 40 more characters to print. Since countWritten != 0, the counters: bytes += countWritten; count -= countWritten; get updated, and the Writefile now has a count of 40 characters. Since the printer is off-line, the countwritten is 0. And so the loop continues, till 40 seconds is up. As to why it is this way, i dont know ( not a windoz maven ); Also the sleep(20) in the loop is not so intuitive to suggest 2 seconds of sleep. I would have guessed 20seconds, or 20milliseconds. But go figure. BTW: Since your computer sends you error messages in French, does it curse in English? :)))) From yvespielusenet at free.fr Thu Jun 7 02:27:44 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Thu, 07 Jun 2007 10:27:44 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666E210.30507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> Message-ID: <1181204864.3501.10.camel@localhost.localdomain> Maybe in my case I should re-compile rxtx and change the code. Instead of send an exception I should display a dialog box to ask if it's printer problem or if it should trie to send bytes. Something like : while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } if(displayDialogBox("Try again to send datas ??")){ errorCount = 0; } else{ throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } } Le mercredi 06 juin 2007 ? 12:34 -0400, Uncle George a ?crit : > yves pielusenet wrote: > > Thank you for your explanation :) > > This timeout comes when no data has been send to the printer after > > 40seconds if I well understand. But why there is such a timeout ? If I > > setthe printer offline while it's printing I mustn't have an exception. > > I don't understand why the "printer should solv all problems like buffer > > full" in 40 seconds. If I pause the printer the buffer will not be > > emptied, isn't it ? > > > > I not very familiar with C/C++, but it seem that the exception is thrown > > only when countWritten == 0, that means no data at all has been sent. So > > Is my code is good since when I intercept this exception I send all my > > buffer again. There is no way that the printer receive two times same > > bytes ? > More technically, the function call returns and reports that 0 > characters was written in this call. > when 0 characters are written, it will check how many times 0 characters > was written. If it has tried LESS than 20 times(errorCount), it will > sleep() and try to write again. > After 20 times, it wont sleep, but throw you the exception. > > Now suppose you are writing a 120 character line. you off-lined/paused > your printer. The OS has room for 80 more characters in it's printer > buffer. The WriteFile() will have a char count of 120, but on return the > countWritten = 80. You still have 40 more characters to print. > Since countWritten != 0, the counters: > bytes += countWritten; > count -= countWritten; > get updated, and the Writefile now has a count of 40 characters. Since > the printer is off-line, the countwritten is 0. And so the loop > continues, till 40 seconds is up. > > As to why it is this way, i dont know ( not a windoz maven ); > Also the sleep(20) in the loop is not so intuitive to suggest 2 seconds > of sleep. I would have guessed 20seconds, or 20milliseconds. But go figure. > > BTW: Since your computer sends you error messages in French, does it > curse in English? :)))) > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 06:11:43 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 08:11:43 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181204864.3501.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> Message-ID: <4667F5FF.8070903@gatworks.com> your suggestion appears good. I dont know what displayDialogBox exactly will do, so all I can say it that it looks good. But I'd like to wait 10min before first dialog box And a 5 min wait for every dialog box there after. And since these are custom solution/choices, maybe a more exact explanation of what the issue is. if(errorCount++ < 300){ // wait 10min ( 10min * 60sec / 2 ) Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } if(displayDialogBox("Printer has Paused. Retry sending data?")){ errorCount = 150; // Wait for 5 min thereafter continue; } > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } yves pielusenet wrote: > Maybe in my case I should re-compile rxtx and change the code. Instead > of send an exception I should display a dialog box to ask if it's > printer problem or if it should trie to send bytes. Something like : > > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > > if(displayDialogBox("Try again to send datas ??")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > } > From yvespielusenet at free.fr Thu Jun 7 07:17:21 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Thu, 07 Jun 2007 15:17:21 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4667F5FF.8070903@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <4667F5FF.8070903@gatworks.com> Message-ID: <1181222241.3501.20.camel@localhost.localdomain> thank you :) 'displayDialogBox()' I think doesn't exist. It was just for the example :) But I think It should not be so complicated to display a dialog box under windows with YES/NO buttons. When yes is clicked it return 0 other it returns 1. Le jeudi 07 juin 2007 ? 08:11 -0400, Uncle George a ?crit : > your suggestion appears good. I dont know what displayDialogBox exactly > will do, so all I can say it that it looks good. > > But I'd like to wait 10min before first dialog box And a 5 min wait for > every dialog box there after. And since these are custom > solution/choices, maybe a more exact explanation of what the issue is. > > if(errorCount++ < 300){ // wait 10min ( 10min * 60sec / 2 ) > Sleep( 20 ); /* make a small pause to execute all other requests > in all other threads */ > continue; > } > > if(displayDialogBox("Printer has Paused. Retry sending data?")){ > errorCount = 150; // Wait for 5 min thereafter > continue; > } > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > > yves pielusenet wrote: > > Maybe in my case I should re-compile rxtx and change the code. Instead > > of send an exception I should display a dialog box to ask if it's > > printer problem or if it should trie to send bytes. Something like : > > > > while( count > 0 ){ > > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > > /* > > this are 20 * 2 seconds, in this time a printer (or other parallel device) > > should solv all problems like buffer full, etc > > */ > > if(errorCount++ < 20){ > > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > > continue; > > } > > > > if(displayDialogBox("Try again to send datas ??")){ > > errorCount = 0; > > } > > else{ > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > } > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 07:41:43 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 09:41:43 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181222241.3501.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <4667F5FF.8070903@gatworks.com> <1181222241.3501.20.camel@localhost.localdomain> Message-ID: <46680B17.8050109@gatworks.com> yves pielusenet wrote: > thank you :) > 'displayDialogBox()' I think doesn't exist. It was just for the > example :) too bad. Good luck. From rtrout at webbresearch.com Thu Jun 7 11:23:04 2007 From: rtrout at webbresearch.com (Robert Trout) Date: Thu, 07 Jun 2007 13:23:04 -0400 Subject: [Rxtx] Disconnected PortServer TS causes Java to hang Message-ID: <1181236984.14186.33.camel@sisyphus.DinkumSoftware.com> I'm running Linux with sun's Java 1.4.2, Java comm API 2.0, RXTX 2.0-7pre1, and the RealPort digi driver. "/dev/ttyrp00" is a RealPort device. My Java application never returns from a ComPortIdentifier.getPortIdentifier("/dev/ttyrp00") call while the Digi PortServer TS 4 is disconnected from the network. If I later re-connect the PortServer, the call returns about 30 seconds later (it's like a serial port read or write is blocking until the PortServer is re- connected). With the PortServer disconnected, minicom immediately responds with "cannot open /dev/ttyrp00: No such file or directory". I would like my Java application to behave similarly. That is, respond with an error condition instead of hanging when the PortServer is not connected. Since minicom and Java behave differently, I think this "hanging" behavior may be due to RXTX or Java? Has anyone had a similar issue? Solutions? Suggestions? Thanks, Robert From vicnevicne at gmail.com Thu Jun 7 12:16:02 2007 From: vicnevicne at gmail.com (Vicne) Date: Thu, 07 Jun 2007 20:16:02 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181204864.3501.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> Message-ID: <46684B62.7080802@gmail.com> yves pielusenet wrote: > Maybe in my case I should re-compile rxtx and change the code. Instead > of send an exception I should display a dialog box to ask if it's > printer problem or if it should trie to send bytes. Something like : > > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > > if(displayDialogBox("Try again to send datas ??")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > } > Sorry to step in without a specific solution to your problem, but I wanted to share my feeling regarding this proposal. AFAIK, it's generally considered bad practice to pop-up a prompt from a library. The main reason is that in general use, you can't guarantee that someone is actually present behind the console. Imagine a print server in a machine room, connected to a park of printers. In that case, when one printer fails, the logical behaviour would be to use an other one. If you change RxTx the way you propose, the printer queue will simply be stuck with a useless "Try again to send data ?" prompt until an administrator opens a remote connection to the print server's console and clicks "no". Second, it would create a dependency upon the existence of a graphical console (if you go the graphical "dialogBox" way). On many applications (typically server or embedded ones), the JVM is "headless" and if you try to pop-up a dialog, your app would throw an exception (at best) or just wouldn't display the prompt anywhere... Going the "text console" way is not more reliable, because on graphical environments, the text console is hidden unless explicitly requested. My advice would be to think again and find another solution. Ideas are : - make the number of retries a parameter so that you can tune it to what you think is reasonable - throw a more specific exception when the number of retries has been reached, so that a specific prompt can be shown at a higher level Anyway, if you feel that the prompt is the way to go in your case, I would at least make that prompt conditional. The least intrusive way would probably be using a system property, like if("true".equals(System.getProperty("org.rxtx.usePrompt")) && displayDialogBox("Retry sending data ?")){ errorCount = 0; } else{ throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } By default, the behaviour would remain as it is now, but you could force the prompts by defining the property at VM launch if desired. (for example : java.exe -Dorg.rxtx.usePrompt=true myApp) Also, you seemed to say you wanted the printer to start again exactly where is stopped. It would indeed be the best way when the printer is put offline for a few seconds. On the other hand, if the printer is turned off (or the printer runs out of paper, or someone steps on the mains cable), then the only way to go back to a "stable" situation would be by printing the item (page, label, etc.) again from scratch... Just my two cents. Vicne PS : By the way, the dialog box thing is very platform dependant on the C-side, and I think the simplest way would probably be to bridge it to a Java call where you can implement it like you proposed : public boolean displayDialogBox(prompt) { return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); } From netbeans at gatworks.com Thu Jun 7 14:08:24 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 16:08:24 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46684B62.7080802@gmail.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> Message-ID: <466865B8.4060004@gatworks.com> My feeling is that the code that was suggested was for his environs ( his shop ). The issue here is that after a 40+ second wait, an exception will be thrown. But you really dont have a way of 'cancelling' all the WriteFiles() that have already occured before the exception so that your writeArray and the Commapi can backtrack to a position in which they are in sync. The main ( really mine ) concern is not to lose data, or replicate data. After 40seconds, 300 seconds, 55min, no matter how long, data should not be lost or duplicated. But as soon as the exception is thrown, that possibility exists. Maybe an event should be thrown instead? Vicne wrote: > yves pielusenet wrote: >> Maybe in my case I should re-compile rxtx and change the code. Instead >> of send an exception I should display a dialog box to ask if it's >> printer problem or if it should trie to send bytes. Something like : >> >> while( count > 0 ){ >> if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ >> /* >> this are 20 * 2 seconds, in this time a printer (or other parallel device) >> should solv all problems like buffer full, etc >> */ >> if(errorCount++ < 20){ >> Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ >> continue; >> } >> >> if(displayDialogBox("Try again to send datas ??")){ >> errorCount = 0; >> } >> else{ >> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >> break; >> } >> } >> > > Sorry to step in without a specific solution to your problem, but I > wanted to share my feeling regarding this proposal. AFAIK, it's > generally considered bad practice to pop-up a prompt from a library. > The main reason is that in general use, you can't guarantee that > someone is actually present behind the console. Imagine a print server > in a machine room, connected to a park of printers. In that case, when > one printer fails, the logical behaviour would be to use an other one. > If you change RxTx the way you propose, the printer queue will simply be > stuck with a useless "Try again to send data ?" prompt until an > administrator opens a remote connection to the print server's console > and clicks "no". > Second, it would create a dependency upon the existence of a > graphical console (if you go the graphical "dialogBox" way). On many > applications (typically server or embedded ones), the JVM is "headless" > and if you try to pop-up a dialog, your app would throw an exception (at > best) or just wouldn't display the prompt anywhere... Going the "text > console" way is not more reliable, because on graphical environments, > the text console is hidden unless explicitly requested. > > My advice would be to think again and find another solution. Ideas are : > - make the number of retries a parameter so that you can tune it to what > you think is reasonable > - throw a more specific exception when the number of retries has been > reached, so that a specific prompt can be shown at a higher level > > Anyway, if you feel that the prompt is the way to go in your case, I > would at least make that prompt conditional. The least intrusive way > would probably be using a system property, like > > if("true".equals(System.getProperty("org.rxtx.usePrompt")) > && displayDialogBox("Retry sending data ?")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > > > By default, the behaviour would remain as it is now, but you could > force the prompts by defining the property at VM launch if desired. (for > example : java.exe -Dorg.rxtx.usePrompt=true myApp) > > > Also, you seemed to say you wanted the printer to start again > exactly where is stopped. It would indeed be the best way when the > printer is put offline for a few seconds. On the other hand, if the > printer is turned off (or the printer runs out of paper, or someone > steps on the mains cable), then the only way to go back to a "stable" > situation would be by printing the item (page, label, etc.) again from > scratch... > > > Just my two cents. > > > Vicne > > PS : By the way, the dialog box thing is very platform dependant on the > C-side, and I think the simplest way would probably be to bridge it to a > Java call where you can implement it like you proposed : > > public boolean displayDialogBox(prompt) { > return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", > JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); > } > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Thu Jun 7 17:48:11 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 Jun 2007 17:48:11 -0600 (MDT) Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <466865B8.4060004@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> Message-ID: An event is possible. I'm amazed this is the largest problem encountered while using the parallel code. How would the write ever exit if we throw events? Isn't this going to lead to hung applications? On Thu, 7 Jun 2007, Uncle George wrote: > My feeling is that the code that was suggested was for his environs ( > his shop ). > > The issue here is that after a 40+ second wait, an exception will be > thrown. But you really dont have a way of 'cancelling' all the > WriteFiles() that have already occured before the exception so that your > writeArray and the Commapi can backtrack to a position in which they are > in sync. > > The main ( really mine ) concern is not to lose data, or replicate data. > After 40seconds, 300 seconds, 55min, no matter how long, data should > not be lost or duplicated. But as soon as the exception is thrown, that > possibility exists. > > Maybe an event should be thrown instead? > > Vicne wrote: >> yves pielusenet wrote: >>> Maybe in my case I should re-compile rxtx and change the code. Instead >>> of send an exception I should display a dialog box to ask if it's >>> printer problem or if it should trie to send bytes. Something like : >>> >>> while( count > 0 ){ >>> if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ >>> /* >>> this are 20 * 2 seconds, in this time a printer (or other parallel device) >>> should solv all problems like buffer full, etc >>> */ >>> if(errorCount++ < 20){ >>> Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ >>> continue; >>> } >>> >>> if(displayDialogBox("Try again to send datas ??")){ >>> errorCount = 0; >>> } >>> else{ >>> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >>> break; >>> } >>> } >>> >> >> Sorry to step in without a specific solution to your problem, but I >> wanted to share my feeling regarding this proposal. AFAIK, it's >> generally considered bad practice to pop-up a prompt from a library. >> The main reason is that in general use, you can't guarantee that >> someone is actually present behind the console. Imagine a print server >> in a machine room, connected to a park of printers. In that case, when >> one printer fails, the logical behaviour would be to use an other one. >> If you change RxTx the way you propose, the printer queue will simply be >> stuck with a useless "Try again to send data ?" prompt until an >> administrator opens a remote connection to the print server's console >> and clicks "no". >> Second, it would create a dependency upon the existence of a >> graphical console (if you go the graphical "dialogBox" way). On many >> applications (typically server or embedded ones), the JVM is "headless" >> and if you try to pop-up a dialog, your app would throw an exception (at >> best) or just wouldn't display the prompt anywhere... Going the "text >> console" way is not more reliable, because on graphical environments, >> the text console is hidden unless explicitly requested. >> >> My advice would be to think again and find another solution. Ideas are : >> - make the number of retries a parameter so that you can tune it to what >> you think is reasonable >> - throw a more specific exception when the number of retries has been >> reached, so that a specific prompt can be shown at a higher level >> >> Anyway, if you feel that the prompt is the way to go in your case, I >> would at least make that prompt conditional. The least intrusive way >> would probably be using a system property, like >> >> if("true".equals(System.getProperty("org.rxtx.usePrompt")) >> && displayDialogBox("Retry sending data ?")){ >> errorCount = 0; >> } >> else{ >> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >> break; >> } >> >> >> By default, the behaviour would remain as it is now, but you could >> force the prompts by defining the property at VM launch if desired. (for >> example : java.exe -Dorg.rxtx.usePrompt=true myApp) >> >> >> Also, you seemed to say you wanted the printer to start again >> exactly where is stopped. It would indeed be the best way when the >> printer is put offline for a few seconds. On the other hand, if the >> printer is turned off (or the printer runs out of paper, or someone >> steps on the mains cable), then the only way to go back to a "stable" >> situation would be by printing the item (page, label, etc.) again from >> scratch... >> >> >> Just my two cents. >> >> >> Vicne >> >> PS : By the way, the dialog box thing is very platform dependant on the >> C-side, and I think the simplest way would probably be to bridge it to a >> Java call where you can implement it like you proposed : >> >> public boolean displayDialogBox(prompt) { >> return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", >> JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); >> } >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 19:18:51 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 21:18:51 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> Message-ID: <4668AE7B.3060409@gatworks.com> The UNIX version of writeArray is not too great either. It is possible that the write will only process some of the bytes. #else if( write( fd, bytes, count ) < 0 ) throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); #endif -------------------------------- Maybe it might be better to have the native function inform the caller of the # of characters written, then the commapi/output-buffer can be modified to reflect the #of chars written. If an exception is to be thrown, for too many loops of chars written == 0, then exception wont affect the state of the output buffer. Then a ParallelPort.restart() can be called to resume printing whats in the buffer. Trent Jarvi wrote: > An event is possible. I'm amazed this is the largest problem encountered > while using the parallel code. > > How would the write ever exit if we throw events? Isn't this going to > lead to hung applications? Sure. If you dont time out, then there is nothing that will force an EXIT from the write(). Issue is what has the OS done with the write. > > On Thu, 7 Jun 2007, Uncle George wrote: > >> My feeling is that the code that was suggested was for his environs ( >> his shop ). From yvespielusenet at free.fr Fri Jun 8 01:09:01 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Fri, 08 Jun 2007 09:09:01 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4668AE7B.3060409@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> Message-ID: <1181286541.3674.10.camel@localhost.localdomain> It is not possible that the rxtx java method write(byte[], int offset, int length) return anint which contains the number of byte really send to the printer instead of an exception ? So this is the programm which will see if all bytes have been sent. If not it can retry to send the unsended bytes. -------------------------------------------------------- int sended = 0; while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ sended += countWritten; /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } return sended; /*throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break;*/ } ... ... return countWritten; ------------------------------------------------ Le jeudi 07 juin 2007 ? 21:18 -0400, Uncle George a ?crit : > The UNIX version of writeArray is not too great either. It is possible > that the write will only process some of the bytes. > > #else > if( write( fd, bytes, count ) < 0 ) > throw_java_exception_system_msg( env, IO_EXCEPTION, > "writeArray" ); > #endif > -------------------------------- > > Maybe it might be better to have the native function inform the caller > of the # of characters written, then the commapi/output-buffer can be > modified to reflect the #of chars written. If an exception is to be > thrown, for too many loops of chars written == 0, then exception wont > affect the state of the output buffer. Then a ParallelPort.restart() can > be called to resume printing whats in the buffer. > > > Trent Jarvi wrote: > > An event is possible. I'm amazed this is the largest problem encountered > > while using the parallel code. > > > > How would the write ever exit if we throw events? Isn't this going to > > lead to hung applications? > Sure. If you dont time out, then there is nothing that will force an > EXIT from the write(). Issue is what has the OS done with the write. > > > > On Thu, 7 Jun 2007, Uncle George wrote: > > > >> My feeling is that the code that was suggested was for his environs ( > >> his shop ). > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Fri Jun 8 03:45:00 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 11:45:00 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181286541.3674.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> Message-ID: <20070608094500.GC21069@elberon.bln.de.ingenico.com> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > It is not possible that the rxtx java method write(byte[], int offset, > int length) return anint which contains the number of byte really send > to the printer instead of an exception ? > So this is the programm which will see if all bytes have been sent. If > not it can retry to send the unsended bytes. I think write() is void because in Java people love to do this since OutputStream :-) Of course on such interfaces you cannot implement something nice. If you would have a int write, you would not implement the interface and no applications expecting this interface would link/work/compile. oki, Steffen P.S.: (OT) If you propose not to implement the Java interfaces (especially not on JNI level), maybe optionally offering a wrapper that removes e.g. the write return value and so on to downgrade the powerful classic old POSIX read/write style to the modern limited Java style, then I agree :-) Same for read. Instead of things like "int avialable()" it is more powerful to have an approach as select(2) offers (to guarante the caller that read/write will not block [nothing else make sense anyway IMHO] but may read/write less bytes then requested). The caller gets full control and the higher level protocols can care about timeouts, invoking read in some loops and/or implement retransmission. On top of such an implementation, where everything is controlled, defined, guaranteed and reliable, someone could use an InputStream or OutputStream style interface. Or even better: don't use them at all :) just BTW :-) St. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From yvespielusenet at free.fr Fri Jun 8 05:52:45 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Fri, 08 Jun 2007 13:52:45 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <20070608094500.GC21069@elberon.bln.de.ingenico.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> Message-ID: <1181303565.11203.3.camel@localhost.localdomain> So maybe a better way should be to create a new Exception class which has a method "int getWrittenByte()". So the Exception should be use to send again bytes which are not printed yet. yves Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : > * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > > It is not possible that the rxtx java method write(byte[], int offset, > > int length) return anint which contains the number of byte really send > > to the printer instead of an exception ? > > So this is the programm which will see if all bytes have been sent. If > > not it can retry to send the unsended bytes. > > I think write() is void because in Java people love to do this > since OutputStream :-) Of course on such interfaces you cannot > implement something nice. If you would have a int write, you > would not implement the interface and no applications expecting > this interface would link/work/compile. > > oki, > > Steffen > > P.S.: (OT) > If you propose not to implement the Java interfaces (especially > not on JNI level), maybe optionally offering a wrapper that > removes e.g. the write return value and so on to downgrade the > powerful classic old POSIX read/write style to the modern limited > Java style, then I agree :-) Same for read. Instead of things > like "int avialable()" it is more powerful to have an approach as > select(2) offers (to guarante the caller that read/write will not > block [nothing else make sense anyway IMHO] but may read/write > less bytes then requested). The caller gets full control and the > higher level protocols can care about timeouts, invoking read in > some loops and/or implement retransmission. On top of such an > implementation, where everything is controlled, defined, > guaranteed and reliable, someone could use an InputStream or > OutputStream style interface. Or even better: don't use them at > all :) just BTW :-) > St. > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > 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. > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > 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. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Fri Jun 8 06:46:21 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 08:46:21 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181303565.11203.3.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> Message-ID: <46694F9D.5080501@gatworks.com> It seems that with outputstream.write(b[]), you become terribly uncoordinated as soon as an exception is thrown. Docs do not say what happens to the data. Yet from a practicable point of view, one would like to know if the write was accepted in-full, or rejected before any writes. There are no in betweens, as partial writes are not reportable. So for an outputstream.write(), in order for it to return, the full write request has to be taken, and stored in an internal output buffer. If there is no room, the write() is suspended, till there is room. Or throw's an IOException( "no room in buffer") ; As the select() loop for write reports buffer room avail, then more of the internal buffer is sent to the printer. yves pielusenet wrote: > So maybe a better way should be to create a new Exception class which > has a method "int getWrittenByte()". So the Exception should be use to > send again bytes which are not printed yet. > > yves > > Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : >> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: >>> It is not possible that the rxtx java method write(byte[], int offset, >>> int length) return anint which contains the number of byte really send >>> to the printer instead of an exception ? >>> So this is the programm which will see if all bytes have been sent. If >>> not it can retry to send the unsended bytes. >> I think write() is void because in Java people love to do this >> since OutputStream :-) Of course on such interfaces you cannot >> implement something nice. If you would have a int write, you >> would not implement the interface and no applications expecting >> this interface would link/work/compile. >> >> oki, >> >> Steffen >> >> P.S.: (OT) >> If you propose not to implement the Java interfaces (especially >> not on JNI level), maybe optionally offering a wrapper that >> removes e.g. the write return value and so on to downgrade the >> powerful classic old POSIX read/write style to the modern limited >> Java style, then I agree :-) Same for read. Instead of things >> like "int avialable()" it is more powerful to have an approach as >> select(2) offers (to guarante the caller that read/write will not >> block [nothing else make sense anyway IMHO] but may read/write >> less bytes then requested). The caller gets full control and the >> higher level protocols can care about timeouts, invoking read in >> some loops and/or implement retransmission. On top of such an >> implementation, where everything is controlled, defined, >> guaranteed and reliable, someone could use an InputStream or >> OutputStream style interface. Or even better: don't use them at >> all :) just BTW :-) >> St. >> >> About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. >> 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. >> >> About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. >> 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. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From Steffen.DETTMER at ingenico.com Fri Jun 8 08:12:18 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 16:12:18 +0200 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <46694F9D.5080501@gatworks.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: <20070608141218.GE21069@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 08:46 -0400: > It seems that with outputstream.write(b[]), you become terribly > uncoordinated as soon as an exception is thrown. Docs do not say what > happens to the data. (yes, so avoiding it seems to be good :)) > Yet from a practicable point of view, one would like to know if the > write was accepted in-full, or rejected before any writes. There are no > in betweens, as partial writes are not reportable. (which is an artificial API limitation. I never understood how this happend when they invented JDK because the well-known BSD socket API and thus [probably] WinSock does this correct, but anyway) > So for an outputstream.write(), in order for it to return, the full > write request has to be taken, and stored in an internal output buffer. > If there is no room, the write() is suspended, till there is room. Or > throw's an IOException( "no room in buffer") ; As the select() loop for > write reports buffer room avail, then more of the internal buffer is > sent to the printer. yes, might be good in case of a printer. May be horrible in case of PPP/TCP or some other transmission control protocol which may e.g. repeat data or even omit parts of it (e.g. internet realtime radio station broadcasting)... So I think the idea of "int write" (e.g. BSD sockets, linux files and so on) still is the best. A clean API / implementation should guarantee and allow implementations (users) to rely on that; assumptions and automatic background-sending and so on may look pragmatic and may even work on the first look, but may fail in other situations. BTW, if e.g. BSD socket API is known, why not simply copy it (until something better is invented :)) instead of fiddling around with JDK APIs? anyway, have a nice weekend everyone :-) oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Fri Jun 8 08:55:56 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 10:55:56 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070608141218.GE21069@elberon.bln.de.ingenico.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> Message-ID: <46696DFC.7000801@gatworks.com> >> write reports buffer room avail, then more of the internal buffer is >> sent to the printer. > > yes, might be good in case of a printer. May be horrible in case > of PPP/TCP or some other transmission control protocol which > may e.g. repeat data or even omit parts of it (e.g. internet > realtime radio station broadcasting)... So I think the idea of > "int write" (e.g. BSD sockets, linux files and so on) still is > the best. A clean API / implementation should guarantee and allow > implementations (users) to rely on that; assumptions and > automatic background-sending and so on may look pragmatic and may > even work on the first look, but may fail in other situations. > BTW, if e.g. BSD socket API is known, why not simply copy it > (until something better is invented :)) instead of fiddling > around with JDK APIs? But we were talking about the Parallel Port, and the transmission of data over the commapi/parallel-port schema. There isn't much in bi-directional software communication. Its a simple write one byte at a time interface. I'm not looking to change the comm-api. I'm just looking to alter the interaction between the Native ParallelPort functions, and the java ParallelPort functions that call them. This might be more readily doable than to get a committee to re-specify java-API specs. BTW: Whats is off-topic? ( help: not looking for def of off-topic ) From j.kenneth.gentle at acm.org Fri Jun 8 08:58:59 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Fri, 08 Jun 2007 10:58:59 -0400 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <20070608141218.GE21069@elberon.bln.de.ingenico.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> Message-ID: <200706081459.l58Ex5rA019991@qbang.org> Perhaps it is a bit late to jump in on this one, but here goes anyway. If the solutions all seem to "break" the contract with "java.io.outputstream", then, as noted, that may not be the appropriate contract. At the risk of being heretical, JDK1.4 introduced the "nio" package to address some of the compatibility issues with C apis mentioned in previous posts. The interface "java.nio.channels.WriteableByteChannel" defines the following single method: int write(ByteBuffer source); int, strangely enough, is the actual number of bytes written. So, if RXTX as written, against the JavaCOMM api and OutputStream, doesn't do what we want, how about writing a different set of bindings using the java.nio classes and as much of the underlying native code as possible. Note that just because the java.nio.channels.WriteableByteChannel sends back a result, OutputStream.write doesn't have to - and they could both call the same underlying native code. My 2 cents - maybe not worth even that... Ken From netbeans at gatworks.com Fri Jun 8 10:37:28 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 12:37:28 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <200706081459.l58Ex5rA019991@qbang.org> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> Message-ID: <466985C8.8000505@gatworks.com> Ken Gentle wrote: > Perhaps it is a bit late to jump in on this one, but here goes anyway. Common in, the waters fine. > > If the solutions all seem to "break" the contract with > "java.io.outputstream", then, as noted, that may not be the > appropriate contract. > How would the contract be broken? The machinery underneath is handling the contract. From j.kenneth.gentle at acm.org Fri Jun 8 10:48:01 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Fri, 08 Jun 2007 12:48:01 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466985C8.8000505@gatworks.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> Message-ID: <200706081648.l58Gm7YA022904@qbang.org> At 12:37 2007-06-08, you wrote: >Ken Gentle wrote: > > > > If the solutions all seem to "break" the contract with > > "java.io.outputstream", then, as noted, that may not be the > > appropriate contract. > > >How would the contract be broken? The machinery underneath is handling >the contract. It seems that a lot of the discussion has been about not only the timeout and being able to adjust it in the "machinery layer", but also about knowing in the Java layer, in the event of a timeout or exception, how many characters have been written to the device. An OutputStream won't ever do this with out an extension and including a return value "breaks" the contract, right? So, go with a Java IO api that *does* return the number of bytes written, out of the NIO package. I know it doesn't allow for a strict implementation of the JavaCOMM API - however, using NIO classes in place of the IO classes isn't that big a break and would allow those applications that need such information a way to get it. Maybe I'm misunderstanding the problem... Ken From netbeans at gatworks.com Fri Jun 8 11:24:14 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 13:24:14 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <200706081648.l58Gm7YA022904@qbang.org> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> Message-ID: <466990BE.7040100@gatworks.com> Ken Gentle wrote: An > OutputStream won't ever do this with out an extension and including a > return value "breaks" the contract, right? > i was not thinking of change the API to OutputSream. Are there specs for how output stream should work internally? for instance: String data = "Hello this is a line of data"; Outputstream.write( data.getbytes() ); ParallelPort.suspend(); int free = ParallelPort.getoutputbufferfree(); There is a symbiotic relationship between outputstream and the functionality of ParallelPort. From Steffen.DETTMER at ingenico.com Fri Jun 8 11:15:39 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 19:15:39 +0200 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <200706081459.l58Ex5rA019991@qbang.org> References: <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> Message-ID: <20070608171539.GK21069@elberon.bln.de.ingenico.com> * Ken Gentle wrote on Fri, Jun 08, 2007 at 10:58 -0400: > If the solutions all seem to "break" the contract with > "java.io.outputstream", then, as noted, that may not be the > appropriate contract. > > At the risk of being heretical, JDK1.4 introduced the "nio" package > to address some of the compatibility issues with C apis mentioned in > previous posts. The interface > "java.nio.channels.WriteableByteChannel" defines the following single method: > > int write(ByteBuffer source); > > int, strangely enough, is the actual number of bytes written. Yes, AFAIK one of the motivations for the NIO interface was, that the JDK-1.3 APIs (InputStream, e.g.) were not powerfull enough, especially for multi-connection-TCP servers or so. I don't know much about it but I've heard of a project where NIO usage was removed because of stability issues in multi-threaded environments and performance limitations under some circumstances. IIRC the "nio.ByteBuffer" is something very special (namely something you cannot implement in Java, it is "magic" or part of the language itself). Not sure if this is such a great idea (but for performance in the end sometimes heavy prices must be paid) :) > So, if RXTX as written, against the JavaCOMM api and OutputStream, > doesn't do what we want, how about writing a different set of > bindings using the java.nio classes and as much of the underlying > native code as possible. Yes, this would be an idea: use a full-featured interface on JNI, and, if wanted, deliver some wrappers converting this to a less-featured Java-compliant interface. However, powerful things as e.g. "select" are difficult to "emulate" if you are e.g. on some (older?) windows. But if you expose the full-featured APIs, you need to emulate them full-featured, theoretically. In the end it depends what you do on the serial line. If you just want to talk to a modem, then you may not need precise timeouts. But if you need to implement complexer protocols which define response times and timeouts, you may quickly get into difficulties. For instance, AFAIK, rxtx 1.7.2 (?) for windows is very messy with timeouts (there is a maximum, higher values are truncated; resolution is 100ms only; the function may take up to twice the timeout because internally it may be called twice). Probably for most people this is OK, but probably not for all. But having precise timeouts should be OK for all :-) Well, in the end it is nice to wish but somewhat hard to implement (many platforms, connections, USB, BlueTooth, whatever). oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Steffen.DETTMER at ingenico.com Fri Jun 8 11:04:22 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 19:04:22 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <46696DFC.7000801@gatworks.com> References: <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <46696DFC.7000801@gatworks.com> Message-ID: <20070608170422.GJ21069@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 10:55 -0400: > > BTW, if e.g. BSD socket API is known, why not simply copy it > > (until something better is invented :)) instead of fiddling > > around with JDK APIs? > > But we were talking about the Parallel Port, and the > transmission of data over the commapi/parallel-port schema. > There isn't much in bi-directional software communication. Its > a simple write one byte at a time interface. First, there are things like PLIP (http://en.wikipedia.org/wiki/Plip) - well, probably not widely used, sure ;) Second, I think if there is a good simple API known to support all that (with known "best practices") or so and there is no forcing need to invent a new one, why not simply using it? > I'm not looking to change the comm-api. I'm just looking to > alter the interaction between the Native ParallelPort > functions, and the java ParallelPort functions that call them. Ahh, yes. I think this is what I tried to ask. Having an usable JNI interface and on top (in pure java) some wrapper to InputStream or whatever could be done (e.g. by ignoring the return value of write or throwing if != length). Developers could then use the full-featured (non-JAVA-standard) API or select among various wrappers (as InputStream). > This might be more readily doable than to get a committee to > re-specify java-API specs. Yes, of course. I'm afraid that the Java APIs change regularily, but still yet with limited success it seems, so maybe they get it in one of the next iterations; who knows, maybe Java-9 has a BSD-like socket API :) SCNR. > BTW: Whats is off-topic? ( help: not looking for def of > off-topic ) I think I started some "re-specify java-API specs" which was OT probably. oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From lists at iDIAcomputing.com Fri Jun 8 18:48:54 2007 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Fri, 08 Jun 2007 20:48:54 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46684B62.7080802@gmail.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> Message-ID: <4669F8F6.3040101@iDIAcomputing.com> Vicne wrote: > Sorry to step in without a specific solution to your problem, but I > wanted to share my feeling regarding this proposal. AFAIK, it's > generally considered bad practice to pop-up a prompt from a library. ... > > My advice would be to think again and find another solution. Ideas are : > - make the number of retries a parameter so that you can tune it to what > you think is reasonable > - throw a more specific exception when the number of retries has been > reached, so that a specific prompt can be shown at a higher level You could also allow the client code to register a callback class which returns a boolean indicating whether to retry or cancel. This callback class could pop up a dialog, if appropriate, or follow some preset policy, or.... - George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From joachim at buechse.ch Sat Jun 9 09:43:16 2007 From: joachim at buechse.ch (Joachim Buechse) Date: Sat, 9 Jun 2007 17:43:16 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46694F9D.5080501@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: You should not forget, that in the case of an exception it may not even be known what happened to the data. You have a kernel buffer, outgoing chip buffer, incoming chip buffer, etc. So of course, it would be nice to know up to which point data was correctly processed, but this feedback does not exist on the hardware or protocol level and hence can in general not be magicly created on the software level... Regards, Joachim On 08.06.2007, at 14:46, Uncle George wrote: > It seems that with outputstream.write(b[]), you become terribly > uncoordinated as soon as an exception is thrown. Docs do not say what > happens to the data. > > Yet from a practicable point of view, one would like to know if the > write was accepted in-full, or rejected before any writes. There > are no > in betweens, as partial writes are not reportable. > > So for an outputstream.write(), in order for it to return, the full > write request has to be taken, and stored in an internal output > buffer. > If there is no room, the write() is suspended, till there is room. Or > throw's an IOException( "no room in buffer") ; As the select() loop > for > write reports buffer room avail, then more of the internal buffer is > sent to the printer. > > > > yves pielusenet wrote: >> So maybe a better way should be to create a new Exception class which >> has a method "int getWrittenByte()". So the Exception should be >> use to >> send again bytes which are not printed yet. >> >> yves >> >> Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : >>> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: >>>> It is not possible that the rxtx java method write(byte[], int >>>> offset, >>>> int length) return anint which contains the number of byte >>>> really send >>>> to the printer instead of an exception ? >>>> So this is the programm which will see if all bytes have been >>>> sent. If >>>> not it can retry to send the unsended bytes. >>> I think write() is void because in Java people love to do this >>> since OutputStream :-) Of course on such interfaces you cannot >>> implement something nice. If you would have a int write, you >>> would not implement the interface and no applications expecting >>> this interface would link/work/compile. >>> >>> oki, >>> >>> Steffen >>> >>> P.S.: (OT) >>> If you propose not to implement the Java interfaces (especially >>> not on JNI level), maybe optionally offering a wrapper that >>> removes e.g. the write return value and so on to downgrade the >>> powerful classic old POSIX read/write style to the modern limited >>> Java style, then I agree :-) Same for read. Instead of things >>> like "int avialable()" it is more powerful to have an approach as >>> select(2) offers (to guarante the caller that read/write will not >>> block [nothing else make sense anyway IMHO] but may read/write >>> less bytes then requested). The caller gets full control and the >>> higher level protocols can care about timeouts, invoking read in >>> some loops and/or implement retransmission. On top of such an >>> implementation, where everything is controlled, defined, >>> guaranteed and reliable, someone could use an InputStream or >>> OutputStream style interface. Or even better: don't use them at >>> all :) just BTW :-) >>> St. >>> >>> About Ingenico Throughout the world businesses rely on Ingenico >>> for secure and expedient electronic transaction acceptance. >>> Ingenico products leverage proven technology, established >>> standards and unparalleled ergonomics to provide optimal >>> reliability, versatility and usability. This comprehensive range >>> of products is complemented by a global array of services and >>> partnerships, enabling businesses in a number of vertical sectors >>> to accept transactions anywhere their business takes them. >>> 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. >>> >>> About Ingenico Throughout the world businesses rely on Ingenico >>> for secure and expedient electronic transaction acceptance. >>> Ingenico products leverage proven technology, established >>> standards and unparalleled ergonomics to provide optimal >>> reliability, versatility and usability. This comprehensive range >>> of products is complemented by a global array of services and >>> partnerships, enabling businesses in a number of vertical sectors >>> to accept transactions anywhere their business takes them. >>> 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. >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx 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 yvespielusenet at free.fr Mon Jun 11 03:15:12 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Mon, 11 Jun 2007 11:15:12 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: <1181553312.8335.14.camel@localhost.localdomain> So can someone tell a solution for my problem :( Must I say to the user to not put the printer off-line ? I can't since he has to do some pauses, verify print, paper conditioning etc... How do other people ? Before I use the parport librarry to read port status : http://www.geocities.com/Juanga69/parport/ (which doesn't work on windows XP) And I send data into the file LPT1 I use to have no problem when printer was disabled. thanks -- yves piel Le samedi 09 juin 2007 ? 17:43 +0200, Joachim Buechse a ?crit : > You should not forget, that in the case of an exception it may not > even be known what happened to the data. > > You have a kernel buffer, outgoing chip buffer, incoming chip buffer, > etc. So of course, it would be nice to know up to which point data > was correctly processed, but this feedback does not exist on the > hardware or protocol level and hence can in general not be magicly > created on the software level... > > Regards, > Joachim > > On 08.06.2007, at 14:46, Uncle George wrote: > > > It seems that with outputstream.write(b[]), you become terribly > > uncoordinated as soon as an exception is thrown. Docs do not say what > > happens to the data. > > > > Yet from a practicable point of view, one would like to know if the > > write was accepted in-full, or rejected before any writes. There > > are no > > in betweens, as partial writes are not reportable. > > > > So for an outputstream.write(), in order for it to return, the full > > write request has to be taken, and stored in an internal output > > buffer. > > If there is no room, the write() is suspended, till there is room. Or > > throw's an IOException( "no room in buffer") ; As the select() loop > > for > > write reports buffer room avail, then more of the internal buffer is > > sent to the printer. > > > > > > > > yves pielusenet wrote: > >> So maybe a better way should be to create a new Exception class which > >> has a method "int getWrittenByte()". So the Exception should be > >> use to > >> send again bytes which are not printed yet. > >> > >> yves > >> > >> Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : > >>> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > >>>> It is not possible that the rxtx java method write(byte[], int > >>>> offset, > >>>> int length) return anint which contains the number of byte > >>>> really send > >>>> to the printer instead of an exception ? > >>>> So this is the programm which will see if all bytes have been > >>>> sent. If > >>>> not it can retry to send the unsended bytes. > >>> I think write() is void because in Java people love to do this > >>> since OutputStream :-) Of course on such interfaces you cannot > >>> implement something nice. If you would have a int write, you > >>> would not implement the interface and no applications expecting > >>> this interface would link/work/compile. > >>> > >>> oki, > >>> > >>> Steffen > >>> > >>> P.S.: (OT) > >>> If you propose not to implement the Java interfaces (especially > >>> not on JNI level), maybe optionally offering a wrapper that > >>> removes e.g. the write return value and so on to downgrade the > >>> powerful classic old POSIX read/write style to the modern limited > >>> Java style, then I agree :-) Same for read. Instead of things > >>> like "int avialable()" it is more powerful to have an approach as > >>> select(2) offers (to guarante the caller that read/write will not > >>> block [nothing else make sense anyway IMHO] but may read/write > >>> less bytes then requested). The caller gets full control and the > >>> higher level protocols can care about timeouts, invoking read in > >>> some loops and/or implement retransmission. On top of such an > >>> implementation, where everything is controlled, defined, > >>> guaranteed and reliable, someone could use an InputStream or > >>> OutputStream style interface. Or even better: don't use them at > >>> all :) just BTW :-) > >>> St. > >>> > >>> About Ingenico Throughout the world businesses rely on Ingenico > >>> for secure and expedient electronic transaction acceptance. > >>> Ingenico products leverage proven technology, established > >>> standards and unparalleled ergonomics to provide optimal > >>> reliability, versatility and usability. This comprehensive range > >>> of products is complemented by a global array of services and > >>> partnerships, enabling businesses in a number of vertical sectors > >>> to accept transactions anywhere their business takes them. > >>> 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. > >>> > >>> About Ingenico Throughout the world businesses rely on Ingenico > >>> for secure and expedient electronic transaction acceptance. > >>> Ingenico products leverage proven technology, established > >>> standards and unparalleled ergonomics to provide optimal > >>> reliability, versatility and usability. This comprehensive range > >>> of products is complemented by a global array of services and > >>> partnerships, enabling businesses in a number of vertical sectors > >>> to accept transactions anywhere their business takes them. > >>> 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. > >>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx 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 > From Steffen.DETTMER at ingenico.com Mon Jun 11 03:56:18 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 11:56:18 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466990BE.7040100@gatworks.com> References: <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> Message-ID: <20070611095618.GA10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 13:24 -0400: > i was not thinking of change the API to OutputSream. Then I think either someone uses OutputStream (and has no reliable information about incomplete writes) or someone uses somethink else. > Are there specs for how output stream should work internally? > > for instance: > String data = "Hello this is a line of data"; > Outputstream.write( data.getbytes() ); > ParallelPort.suspend(); > int free = ParallelPort.getoutputbufferfree(); > > There is a symbiotic relationship between outputstream and the > functionality of ParallelPort. If you need OutputStream "plus something else", in short you're needing "something else". Personally I dislike the code above a lot. The stream "looks" like if it would be an OutputStream, but in fact it isn't. You need to call getoutputbufferfree later to check if write succeeded (but OutputStream promises that write succeedes synchronous, blocking, or throws an exception). So it is not an OutputStream. No application written for OutputStreams would work without change (because it won't know getoutputbufferfree at all). It is not abstracted from ParallelPort. I think this would be wrong. Then I think an alternative interface instead is better. Let's assume we had some "connection" (to distinguish between OutputStreams and Channels). Then why not working as on a file handle in POSIX: do { // ... select maybe using timer ... readyForWrite = ... if (readyForWrite) { int writtenBytes = connection.write(toWrite); toWrite.remove(0, writtenBytes); } while(readyForWrite && toWrite.length > 0); I think, having such a write isn't the big problem. I think, the difficult thing is around "select" - however this would look like. It should be OO, typesafe, performant, supporting multiple connections/channels/streams in various modes and should be orthogonal to other functionalities. Of course, this heavily depends on what the application is doing; for a simple situation (like reading a small, mandatory file from a local disk) this would be to uncomfortable (and offering unneeded features only). just BTW :) oki, Steffen -- // Modeline for VIM. Please don't remove. // (Help: autoindent, expandtab, shiftwidth=4, tabstop=4, textwidth=75) // vi: set ai et sw=4 ts=4 tw=75 ft=java: About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Mon Jun 11 05:38:33 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 07:38:33 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611095618.GA10821@elberon.bln.de.ingenico.com> References: <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> Message-ID: <466D3439.4020805@gatworks.com> Steffen DETTMER wrote: > (but OutputStream promises that write > succeedes synchronous, blocking, or throws an exception). Where is it so written? From Steffen.DETTMER at ingenico.com Mon Jun 11 06:36:50 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 14:36:50 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466D3439.4020805@gatworks.com> References: <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> <466D3439.4020805@gatworks.com> Message-ID: <20070611123650.GI10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Mon, Jun 11, 2007 at 07:38 -0400: > Steffen DETTMER wrote: > > > (but OutputStream promises that write > > succeedes synchronous, blocking, or throws an exception). > > Where is it so written? Now, as you ask, I think it is not written that clearly but follows from specification. mmm... Am I wrong? I understand the API doc in this way: * http://java.sun.com/j2se/1.4.2/docs/api/java/io/OutputStream.html#write(byte[]) > public void write(byte[] b) > throws IOException > > Writes b.length bytes from the specified byte array to this > output stream. The general contract for write(b) is that > it should have exactly the same effect as the call write(b, > 0, b.length). > > Parameters: > b - the data. > Throws: > IOException - if an I/O error occurs. > See Also: > write(byte[], int, int) and there is: > public void write(byte[] b, > int off, > int len) > throws IOException > > Writes len bytes from the specified byte array starting at > offset off to this output stream. The general contract for > write(b, off, len) is that some of the bytes in the array b > are written to the output stream in order; element b[off] > is the first byte written and b[off+len-1] is the last byte > written by this operation. > > The write method of OutputStream calls the write method of > one argument on each of the bytes to be written out. > Subclasses are encouraged to override this method and > provide a more efficient implementation. > > If b is null, a NullPointerException is thrown. > > If off is negative, or len is negative, or off+len is > greater than the length of the array b, then an > IndexOutOfBoundsException is thrown. > > Parameters: > b - the data. > off - the start offset in the data. > len - the number of bytes to write. > Throws: > IOException - if an I/O error occurs. In particular, an > IOException is thrown if the output stream is closed. In general, any specialisation (derived child class) must comform to this. So write in the end is specified (!) as "The write method ... calls the write method ... on each of the bytes to be written out". This is what must be implemented by ANY OutputStream. Of course, there is: "Subclasses are encouraged to override this method and provide a more efficient implementation." which IMHO does not contradict - the more efficient must behave in exactly the same way of course (just wasting less resources than a simple byte-by-byte write). So it does not matter here I think. The write that finally defines the behavior tells basically: > "Writes the specified byte to this output stream. The general > contract for write is that one byte is written to the output > stream. " > > Throws: > IOException - if an I/O error occurs. which IMHO is another way of saying "write writes the byte immediately and returns on success (only), otherwise an exception is thrown". Especially it cannot happen that zero bytes are written (i.e. the specified byte is NOT written) without an exception. So by this write must be synchronous and blocking, because otherwise it could not reliably know if an asynchronous operation will succeede or not (some getAsyncResult or so would be needed). Since write(byte[]) does this for each byte (or with a behavior beeing exactly the same as if it would do), I think this means that the write(byte[]) succeedes synchronous/blocking or throws an exception. Did I an error in reasoning or confused something or so? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From j.kenneth.gentle at acm.org Mon Jun 11 06:51:25 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 11 Jun 2007 08:51:25 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611123650.GI10821@elberon.bln.de.ingenico.com> References: <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> <466D3439.4020805@gatworks.com> <20070611123650.GI10821@elberon.bln.de.ingenico.com> Message-ID: <200706111251.l5BCpS9T017831@qbang.org> It is as Steffen describes. "InputStream" and "OutputStream" are inherently synchronous (which is why so many java programs resort to threads to use them). Anything outside of this "contract" is *not* an InputStream or OutputStream. That is why there is a new package for things that don't behave like the old *Stream classes - the NIO package. If you look carefully at the IO package, you'll note that almost all the classes are _Decorator_ pattern implementations of the *Stream classes - and the interface presents the _same_ behavior to the calling code in all cases - a synchronous operation that completes successfully or throws an exception (with the one exception of "read" that returns a "-1" on end-of-stream. I know I've read this numerous times - I'd suggest checking the Language Spec or one of the books by Bloch or Gosling. Ken At 08:36 2007-06-11, you wrote: >* Uncle George wrote on Mon, Jun 11, 2007 at 07:38 -0400: > > Steffen DETTMER wrote: > > > > > (but OutputStream promises that write > > > succeedes synchronous, blocking, or throws an exception). > > > > Where is it so written? > >Now, as you ask, I think it is not written that clearly but >follows from specification. mmm... > >Am I wrong? > >I understand the API doc in this way: > >* >http://java.sun.com/j2se/1.4.2/docs/api/java/io/OutputStream.html#write(byte[]) > > public void write(byte[] b) > > throws IOException > > > > Writes b.length bytes from the specified byte array to this > > output stream. The general contract for write(b) is that > > it should have exactly the same effect as the call write(b, > > 0, b.length). > > > > Parameters: > > b - the data. > > Throws: > > IOException - if an I/O error occurs. > > See Also: > > write(byte[], int, int) > > >and there is: > > > > public void write(byte[] b, > > int off, > > int len) > > throws IOException > > > > Writes len bytes from the specified byte array starting at > > offset off to this output stream. The general contract for > > write(b, off, len) is that some of the bytes in the array b > > are written to the output stream in order; element b[off] > > is the first byte written and b[off+len-1] is the last byte > > written by this operation. > > > > The write method of OutputStream calls the write method of > > one argument on each of the bytes to be written out. > > Subclasses are encouraged to override this method and > > provide a more efficient implementation. > > > > If b is null, a NullPointerException is thrown. > > > > If off is negative, or len is negative, or off+len is > > greater than the length of the array b, then an > > IndexOutOfBoundsException is thrown. > > > > Parameters: > > b - the data. > > off - the start offset in the data. > > len - the number of bytes to write. > > Throws: > > IOException - if an I/O error occurs. In particular, an > > IOException is thrown if the output stream is closed. > > >In general, any specialisation (derived child class) must comform >to this. So write in the end is specified (!) as "The write >method ... calls the write method ... on each of the bytes to be >written out". This is what must be implemented by ANY >OutputStream. > >Of course, there is: "Subclasses are encouraged to override this >method and provide a more efficient implementation." which IMHO >does not contradict - the more efficient must behave in exactly >the same way of course (just wasting less resources than a simple >byte-by-byte write). So it does not matter here I think. > > > >The write that finally defines the behavior tells basically: > > > "Writes the specified byte to this output stream. The general > > contract for write is that one byte is written to the output > > stream. " > > > > Throws: > > IOException - if an I/O error occurs. > > >which IMHO is another way of saying "write writes the byte >immediately and returns on success (only), otherwise an exception >is thrown". Especially it cannot happen that zero bytes are >written (i.e. the specified byte is NOT written) without an >exception. So by this write must be synchronous and blocking, >because otherwise it could not reliably know if an asynchronous >operation will succeede or not (some getAsyncResult or so would >be needed). > >Since write(byte[]) does this for each byte (or with a behavior >beeing exactly the same as if it would do), I think this means >that the write(byte[]) succeedes synchronous/blocking or throws >an exception. > >Did I an error in reasoning or confused something or so? > >oki, > >Steffen > >About Ingenico Throughout the world businesses rely on Ingenico for >secure and expedient electronic transaction acceptance. Ingenico >products leverage proven technology, established standards and >unparalleled ergonomics to provide optimal reliability, versatility >and usability. This comprehensive range of products is complemented >by a global array of services and partnerships, enabling businesses >in a number of vertical sectors to accept transactions anywhere >their business takes them. >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. > >About Ingenico Throughout the world businesses rely on Ingenico for >secure and expedient electronic transaction acceptance. Ingenico >products leverage proven technology, established standards and >unparalleled ergonomics to provide optimal reliability, versatility >and usability. This comprehensive range of products is complemented >by a global array of services and partnerships, enabling businesses >in a number of vertical sectors to accept transactions anywhere >their business takes them. >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. > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From alesinskyy at googlemail.com Mon Jun 11 07:25:33 2007 From: alesinskyy at googlemail.com (Oleksandr Alesinskyy) Date: Mon, 11 Jun 2007 15:25:33 +0200 Subject: [Rxtx] [OT] select :-) Message-ID: Sorry, but I have to disagree with following statement: "So write in the end is specified (!) as "The write method ... calls the write method ... on each of the bytes to be written out". This is what must be implemented by ANY OutputStream.". This is not part of the specification or contract, it is just revealed implementation detail of the OutputStream. It is not stated anywhere that behavoiur of derived classes shall conform with this one. Statement concerning "synchronous" nature of the output stream is invalid as well. Really synchronous stream does not require flush() but OutputStream has it. From Steffen.DETTMER at ingenico.com Mon Jun 11 08:21:16 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 16:21:16 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: Message-ID: <20070611142116.GN10821@elberon.bln.de.ingenico.com> * Oleksandr Alesinskyy wrote on Mon, Jun 11, 2007 at 15:25 +0200: > Sorry, but I have to disagree with following statement: > "So write in the end is specified (!) as "The write > method ... calls the write method ... on each of the bytes to be > written out". This is what must be implemented by ANY > OutputStream.". > > This is not part of the specification or contract, it is just > revealed implementation detail of the OutputStream. It is not > stated anywhere that behavoiur of derived classes shall conform > with this one. (I didn't meant that the implementation must really write byte by byte, but that it must "look as if it would do" - because all implementations of OutputStream must "look" in the same way [which is another way of saying "do abstract" I think]) I think the API doc is not "revealing implementation details" but it is the *specification* of that interface and derivations must (should) conform to this specification. Isn't this the idea of interfaces? A function that expects an OutputStream should work on ANY OutputStream, shouldn't it? just kidding: I mean, what would be the point in implementing a checksum function as OutputStream.write which throws its result as IOException? Or which requires to call close() as very first operation to tell that the application is about to transmit confidential data? :-) > Statement concerning "synchronous" nature of the output stream > is invalid as well. Really synchronous stream does not require > flush() but OutputStream has it. ahh, interesting point! I think this is another bug in the API. flush() is wrong. Because write specifies "The general contract for write is that one byte is written to the output stream." but not "a byte may be written or buffered". Actually, an application would need to call flush() after each write (or bunch of write calls) to ensure that write really did something otherwise I think. I didn't found in the spec of OutputStream that it would be required to call flush(). This should mean that calling flush is not required which in turn leads to the conclusion that write must be synchrous (private threads are forbidden because not specified :)) which in turn leads to the conclusion that flush() is not needed at all... I mean, what if someone would only store in write and do the "real write" in flush() and never else? An application could write in one stream and read on another one (e.g. in bidirectional communication) and would never get anything back, because nothing was actually written because no flush was called? Then someone could even think that on error in some write the data could remain buffered AND throw an exception, retrying to send the data in the next write. Ohh, and if there would be some message number inside, and underlaying write (e.g. a protocol offering InputStream/OutputStream) would check this and throw "DuplicatedMessageNumber" the stream would only throw it again and again beeing unusable... In short: I have no clue how someone could be able to implement an asynchrounos write (which is realiable and correct) without beeing specific to anything which is not specified by OutputStream. Well, I think in the end OutputStream was not intended for such communication or protocol implementations - but to read a local disk file or so. In case of I/O errors usually you can abort your application and change the hard disk :-) oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Bob_Jacobsen at lbl.gov Mon Jun 11 09:32:23 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Mon, 11 Jun 2007 08:32:23 -0700 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611142116.GN10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> Message-ID: At 4:21 PM +0200 6/11/07, Steffen DETTMER wrote: > > Statement concerning "synchronous" nature of the output stream >> is invalid as well. Really synchronous stream does not require >> flush() but OutputStream has it. > >ahh, interesting point! > >I think this is another bug in the API. flush() is wrong. Because >write specifies "The general contract for write is that one byte >is written to the output stream." but not "a byte may be written >or buffered". > >Actually, an application would need to call flush() after each >write (or bunch of write calls) to ensure that write really did >something otherwise I think. OutputStreams don't _have_ to be synchronous or asynchronous, but the OutputStream API was be arranged so that subclasses _can_ be synchronous or asynchronous. Such generality is the hardest part of getting an API right. Hence, if at some point a program using an OutputStream wants to be sure that the data has been pushed all the way out, flush() is available. For some subclasses, e.g. the buffered ones, this has important behavior. Others write the data from each call, and flush() doesn't do anything. You _can_ omit it in programs that are known to use this second type, but there's no requirement that you do so; the interface is general in that way. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From Steffen.DETTMER at ingenico.com Mon Jun 11 12:32:39 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 20:32:39 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> Message-ID: <20070611183239.GT10821@elberon.bln.de.ingenico.com> * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: > >Actually, an application would need to call flush() after each > >write (or bunch of write calls) to ensure that write really did > >something otherwise I think. > OutputStreams don't _have_ to be synchronous or asynchronous, > but the OutputStream API was be arranged so that subclasses > _can_ be synchronous or asynchronous. Ahh, oki. Thanks for the clarificaion. So in short, flush() MUST be called on OutputStream, this is just not documented correctly or so clearly (right?). So the overall usage semantics would be: 1. call write (multiple times if desired) 2. call flush only if both succeeded, write was successful. If flush fails it remains unknown if a part of the data was written and/or will be repeated. So the spec (API doc) is wrong. Correct would be to tell that write behaves as told as long as it is followed by a call to flush, otherwise data may or may not get lost (depending wheter close() is called and calls flush(), which seems not to be guaranteed/required). BTW, I think it is a little bit... erm... interesting to find the specification (java API doc reference) wrong, having a need to conclude it from the presence of some methods with "it would make no sense if they behave exactly as specified, so specification must be wrong (incomplete)". > Such generality is the hardest part of getting an API right. Yes, seems to be proven ;) > Hence, if at some point a program using an OutputStream wants > to be sure that the data has been pushed all the way out, > flush() is available. For some subclasses, e.g. the buffered > ones, this has important behavior. Others write the data from > each call, and flush() doesn't do anything. > You _can_ omit it in programs that are known to use this second > type, but there's no requirement that you do so; the interface > is general in that way. I think, it still it must be called always, otherwise the application could break if passing a different runtime type as OutputStream. I think, if the application/method needs a special "type of OutputStream" then the parameter type must be a subclass but not OutputStream, maybe a PrintStream or so - otherwise the compiler could not detect this error (passing wrong type). Is this correct? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Bob_Jacobsen at lbl.gov Mon Jun 11 13:00:52 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Mon, 11 Jun 2007 12:00:52 -0700 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611183239.GT10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> Message-ID: At 8:32 PM +0200 6/11/07, Steffen DETTMER wrote: >So the spec (API doc) is wrong. Correct would be to tell that >write behaves as told as long as it is followed by a call to >flush, otherwise data may or may not get lost (depending wheter >close() is called and calls flush(), which seems not to be >guaranteed/required). I'm not entirely sure that the spec is wrong, but reasonable people can differ on this. In the 1.5 JavaDocs, all that the docs say for the write methods is that they write to the _output_ _stream_; there is no guarantee of anything beyond that. Only the flush method has any guarantee about the data, which is >Flushes this output stream and forces any buffered output bytes to >be written out. The general contract of flush is that calling it is >an indication that, if any bytes previously written have been >buffered by the implementation of the output stream, such bytes >should immediately be written to their intended destination. People commonly use various OutputStreams without using flush(), and it often works, but it's a bad practice and will eventually bite them. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From netbeans at gatworks.com Mon Jun 11 13:31:57 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 15:31:57 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611183239.GT10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> Message-ID: <466DA32D.1010602@gatworks.com> Steffen DETTMER wrote: > * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: >>> Actually, an application would need to call flush() after each >>> write (or bunch of write calls) to ensure that write really did >>> something otherwise I think. > >> OutputStreams don't _have_ to be synchronous or asynchronous, >> but the OutputStream API was be arranged so that subclasses >> _can_ be synchronous or asynchronous. > > Ahh, oki. Thanks for the clarificaion. > > So in short, flush() MUST be called on OutputStream, this is just > not documented correctly or so clearly (right?). No. Flush can be called to force all current data in java buffer's to be written to the kernel - NOW. A flush() can also *imply* that, besides writing out the buffer's that java employs, may also imply/ask the kernel to write all data thusfar written to the kernel, to be physically placed on the destination device - NOW. For some OS's there is no need to do a kernel flush(), as the I/O is synchronized already. Since this is java, you never know what OS your on. From tjarvi at qbang.org Mon Jun 11 19:28:27 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Jun 2007 19:28:27 -0600 (MDT) Subject: [Rxtx] [OT] select :-) In-Reply-To: <466DA32D.1010602@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: On Mon, 11 Jun 2007, Uncle George wrote: > Steffen DETTMER wrote: >> * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: >>>> Actually, an application would need to call flush() after each >>>> write (or bunch of write calls) to ensure that write really did >>>> something otherwise I think. >> >>> OutputStreams don't _have_ to be synchronous or asynchronous, >>> but the OutputStream API was be arranged so that subclasses >>> _can_ be synchronous or asynchronous. >> >> Ahh, oki. Thanks for the clarificaion. >> >> So in short, flush() MUST be called on OutputStream, this is just >> not documented correctly or so clearly (right?). > No. > Flush can be called to force all current data in java buffer's to be > written to the kernel - NOW. > > A flush() can also *imply* that, besides writing out the buffer's that > java employs, may also imply/ask the kernel to write all data thusfar > written to the kernel, to be physically placed on the destination device > - NOW. > For some OS's there is no need to do a kernel flush(), as the I/O is > synchronized already. Since this is java, you never know what OS your on. To add to the confusion, flush on the C side throws away data. drain makes sure it is written. Looking at the ParallelImp.c we can probably do better. /* we set a timeout because all calls are sequentiell (also with asynchron) this means that the default timeout of unlimited blocks all calls (also close and status request) if the device is down */ GetCommTimeouts( (HANDLE)fd, &timeouts ); timeouts.WriteTotalTimeoutMultiplier = 0; timeouts.WriteTotalTimeoutConstant = 2000; /* 2000 is the min value for the default Windows NT and Windows 2000 driver */ SetCommTimeouts( (HANDLE)fd, &timeouts ); while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } errorCount = 0; bytes += countWritten; count -= countWritten; } LPRPort has some timeout code that appears to be doing nothing but flipping bits back and forth right now. The commapi rxtx follows allows for timeout control from javax.comm.CommPort. The above is a solution that worked in one specific use case. With timeouts in place, the original 'old printer going offline' problem could be solved. That printer code isn't written in stone. In fact it was ajusted from being able to print 'asdf' to a daisy wheel printer to working for one person. BTW, I've finished teaching after hours tonight and will be moving forward with a new rxtx release in my free time. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Jun 11 21:28:04 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 23:28:04 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: <466E12C4.1010305@gatworks.com> > Looking at the ParallelImp.c we can probably do better. > The problem stemmed from the possibility that the writev routine could have written some of the buffer, in chunks, printer pauses, refuses any more chunks, and a timeout occurs. Do you or do you not cause an exception to be thrown? Is there a way to set timeout for a ParallelPort data output stream? I cant find it. From tjarvi at qbang.org Mon Jun 11 22:17:23 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Jun 2007 22:17:23 -0600 (MDT) Subject: [Rxtx] [OT] select :-) In-Reply-To: <466E12C4.1010305@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> <466E12C4.1010305@gatworks.com> Message-ID: On Mon, 11 Jun 2007, Uncle George wrote: >> Looking at the ParallelImp.c we can probably do better. >> > The problem stemmed from the possibility that the writev routine could > have written some of the buffer, in chunks, printer pauses, refuses any > more chunks, and a timeout occurs. Do you or do you not cause an > exception to be thrown? > > Is there a way to set timeout for a ParallelPort data output stream? I > cant find it. hmm I looked again after you asked. The timeouts are only controllable on the receive side. This comes from CommPort; the parent. So what we are talking about is some bytes in memory that rxtx has and is supposed to write. A buffer perhaps? The approach with rxtx in the past has been to ignore output buffer sizes. The assumption is that the library does not know how to best handle buffers. There are buffered output streams that can do buffering on top of rxtx for instance. There is also a question regarding what was actually ment when the API was put together. My suspicion is that it was put together while looking at one OS API and was never ment to be anything more than a hook into that API. The comments are fairly telling combined with reading the w32 API. So looking at the problem again.. The current timeout behavior appears fairly arbitrary. Presumably this is to prevent a program from hanging instead of using a helper thread to write - heavy handed for new programmers. Even so, I don't think the write should timeout at all if it is not configurable. >From the API perspective, "What Timeout?" -- Trent Jarvi tjarvi at qbang.org From Steffen.DETTMER at ingenico.com Tue Jun 12 02:14:48 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 12 Jun 2007 10:14:48 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466DA32D.1010602@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: <20070612081447.GU10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Mon, Jun 11, 2007 at 15:31 -0400: > Steffen DETTMER wrote: > > Ahh, oki. Thanks for the clarificaion. > > > > So in short, flush() MUST be called on OutputStream, this is just > > not documented correctly or so clearly (right?). > No. hum (though now I got it, but...). > Flush can be called to force all current data in java buffer's to be > written to the kernel - NOW. > > A flush() can also *imply* that, besides writing out the > buffer's that java employs, may also imply/ask the kernel to > write all data thusfar written to the kernel, to be physically > placed on the destination device - NOW. > > For some OS's there is no need to do a kernel flush(), as the I/O is > synchronized already. Since this is java, you never know what OS your on. (well, but if you're going to kernel level, even flush cannot guarantee that data will "be physically placed". Maybe you're flushing to a file via NFS (and the client "thinks" that it was written, but maybe it was just buffered by the NFS server) or so... but of course such exceptions of the rules are constructable always.) Well, you tell that depending on the OS it can be that flush is needed or it can be that flush is not needed (beacuse the I/O is synchronized already), right? Also, applications should work on any OS, which includes the OSes that do need flush. Since the application cannot know whether flush is needed or not because it doesn't know what the OS is doing, it has to call flush, hasn't it? I mean, if it would not call flush then it would not work on such OSes (except the written data would not be needed at all, but in this would be an artificial example :)). Since applications are supposed to work this would be wrong, wouldn't it? So would it be correct to say: "Applications, that should work under all OSes (including the OSes where the I/O is not synchronised already), have to call flush on OutputStream to ensure the data is transfered to the kernel." or is this wrong? If so, then I'm afraid I missed the point again :( oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Tue Jun 12 04:46:52 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 12 Jun 2007 06:46:52 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070612081447.GU10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> <20070612081447.GU10821@elberon.bln.de.ingenico.com> Message-ID: <466E799C.7060700@gatworks.com> S > (well, but if you're going to kernel level, even flush cannot > guarantee that data will "be physically placed". Thats true now-a-days because ( from "man 2 sync" ) : > According to the standard specification (e.g., SVID), sync() schedules > the writes, but may return before the actual writing is done. However, > since version 1.3.20 Linux does actually wait. (This still does not > guarantee data integrity: modern disks have large caches.) My disk drive has 8mb cache. Maybe you're > flushing to a file via NFS (and the client "thinks" that it was > written, but maybe it was just buffered by the NFS server) or > so... but of course such exceptions of the rules are > constructable always.) > > Well, you tell that depending on the OS it can be that flush is > needed or it can be that flush is not needed (beacuse the I/O is > synchronized already), right? Also, applications should work on > any OS, which includes the OSes that do need flush. Its not OS's that need flush, its applications that want to have some assurance that data is written to the device that really needs to use flush. If your program ( or thread ) dies then it is in your best interest to write out the critical data as soon as possible, as economical as possible. These are trade-off's that the application programmer makes. A big buffer may mean big loss of data, a small buffer may mean spending too much time writing out data. > > > So would it be correct to say: > > "Applications, that should work under all OSes (including the > OSes where the I/O is not synchronised already), have to call > flush on OutputStream to ensure the data is transfered to the > kernel." > > or is this wrong? If so, then I'm afraid I missed the point again > :( > No that is not wrong. Ensuring that data is transfered to the OS is just about what any application can do. From tjarvi at qbang.org Thu Jun 14 08:16:47 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 14 Jun 2007 08:16:47 -0600 (MDT) Subject: [Rxtx] rxtx and usb-serial solution In-Reply-To: References: Message-ID: On Thu, 14 Jun 2007, Vladimir Kirtchev wrote: > Hi Trent, > > I develop a Java application which communicates with devices which have > USB-to-Serial bridge in them. The target OS is Linux. So for this purpose I > use RXTX. > > But I encountered a strange problem - when reading from the InputStream, I > receive series of zeros. I have this problem under Linux only. Under Windows > it is fine. > Actually this problem is the same as the one described here: > http://marc.info/?l=rxtx&m=109703190731748&w=2. > > > So I searched for the problem in the native code. And found that the root of > the problem is in SerialImp.c, > int configure_port( int fd ) > { > ... > ttyset.c_iflag = INPCK; > ... > } > > This line enables input parity checking, and the data sent from the device > is processed by the OS driver before being read with read(). > In this case the driver detects some problem and sets the received bytes to > zero. > > On the other hand in the Java part a set the serial port parameters with > SerialPort.PARITY_NONE. According to me, except all other things, this > should also disable INPCK in c_iflag. > > So I refactored the method translate_parity(...) to the following: > > int translate_parity( JNIEnv *env, struct termios *ttyset, jint parity ) > { > ENTER( "translate_parity" ); > #ifdef CMSPAR > ttyset->c_cflag &= ~(PARENB | PARODD | CMSPAR ); > #endif /* CMSPAR */ > switch( parity ) { > case JPARITY_NONE: > ttyset->c_iflag &= ~INPCK; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_EVEN: > ttyset->c_cflag |= PARENB; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_ODD: > ttyset->c_cflag |= PARENB | PARODD; > LEAVE( "translate_parity" ); > return 0; > #ifdef CMSPAR > case JPARITY_MARK: > ttyset->c_cflag |= PARENB | PARODD | CMSPAR; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_SPACE: > ttyset->c_cflag |= PARENB | CMSPAR; > LEAVE( "translate_parity" ); > return 0; > #endif /* CMSPAR */ > default: > printf("Parity missed %i\n", (int) parity ); > } > > LEAVE( "translate_parity" ); > /* > For some reason the native exceptions are not being caught. Moving this > to the Java side fixed the issue. taj. > throw_java_exception( env, UNSUPPORTED_COMM_OPERATION, > "", "parity value not supported" ); > */ > return 1; > } > > This modification solved the problem and now it works correctly under Linux. > > I think I will be a nice if this is idea is included in a future release of > RXTX. > > Thanks Vadim, I'll try that out. Forwarding to the rxtx mail-list too. This is probably not going to help USB drivers on windows which I'm sure some are looking for. As far as I can tell, windows USB bluetooth and serial dongles are limited by driver functionality. Some are good and others lack key features. -- Trent Jarvi tjarvi at qbang.org From dan.sandberg.lists at gmail.com Mon Jun 18 14:43:39 2007 From: dan.sandberg.lists at gmail.com (Dan Sandberg) Date: Mon, 18 Jun 2007 13:43:39 -0700 Subject: [Rxtx] Fix for JNI Get/Set Field Errors Message-ID: <4676EE7B.7060800@gmail.com> Hi, I've fixed the problems that cause the following JNI error when extra JNI checking ( -Xjni:check ) is turned on. FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) The problem was basically that GetLong was being used to get ints, and SetInt was used for longs. The patch below fixes this. Please let me know if there are any questions / problems. Cheers, -Dan diff -aur old/SerialImp.c src/SerialImp.c --- old/SerialImp.c 2007-06-18 13:24:33.000000000 -0700 +++ src/SerialImp.c 2007-06-18 06:26:26.000000000 -0700 @@ -1337,7 +1337,7 @@ report("init_threads: get eis\n"); jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); report("init_threads: set eis\n"); - (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); + (*eis->env)->SetLongField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); report("init_threads: stop\n"); report_time_end( ); return( 1 ); @@ -1530,7 +1530,7 @@ jobject jobj, jboolean interrupted ) { int fd = get_java_var( env, jobj,"fd","I" ); - struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var( env, jobj, "eis", "J" ); + struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var_long( env, jobj, "eis", "J" ); int result, count=0; char message[80]; @@ -2939,7 +2939,7 @@ /* TRENT */ int flag, count = 0; struct event_info_struct *eis = ( struct event_info_struct * ) - get_java_var( env, *jobj,"eis","J" ); + get_java_var_long( env, *jobj,"eis","J" ); report_time_start(); flag = eis->eventflags[SPE_DATA_AVAILABLE]; @@ -4873,9 +4873,9 @@ exceptions: none comments: ----------------------------------------------------------*/ -size_t get_java_var( JNIEnv *env, jobject jobj, char *id, char *type ) +long get_java_var_long( JNIEnv *env, jobject jobj, char *id, char *type ) { - int result = 0; + long result = 0; jclass jclazz = (*env)->GetObjectClass( env, jobj ); jfieldID jfd = (*env)->GetFieldID( env, jclazz, id, type ); @@ -4889,7 +4889,11 @@ LEAVE( "get_java_var" ); return result; } - result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); + if ( !strcmp( type, "J" ) ) { + result = (long)( (*env)->GetLongField( env, jobj, jfd ) ); + } else { + result = (int) ( (*env)->GetIntField( env, jobj, jfd ) ); + } /* ct7 & gel * Added DeleteLocalRef */ (*env)->DeleteLocalRef( env, jclazz ); if(!strncmp( "fd",id,2) && result == 0) @@ -4900,6 +4904,10 @@ return result; } +int get_java_var( JNIEnv *env, jobject jobj, char *id, char *type ) { + return (int) get_java_var_long( env, jobj, id, type ); +} + /*---------------------------------------------------------- throw_java_exception diff -aur old/SerialImp.h src/SerialImp.h --- old/SerialImp.h 2007-06-18 13:24:39.000000000 -0700 +++ src/SerialImp.h 2007-06-18 06:23:43.000000000 -0700 @@ -413,7 +413,8 @@ void system_wait(); void finalize_event_info_struct( struct event_info_struct * ); int read_byte_array( JNIEnv *, jobject *, int, unsigned char *, int, int ); -size_t get_java_var( JNIEnv *, jobject, char *, char * ); +int get_java_var( JNIEnv *, jobject, char *, char * ); +long get_java_var_long( JNIEnv *, jobject, char *, char * ); jboolean is_interrupted( struct event_info_struct * ); int send_event(struct event_info_struct *, jint, int ); void dump_termios(char *,struct termios *); From yvespielusenet at free.fr Tue Jun 26 03:41:58 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 11:41:58 +0200 Subject: [Rxtx] [PARALLEL] resource in use Message-ID: <1182850918.3483.10.camel@localhost.localdomain> Hello, So now I want to modify the timeout of the library for parallel port. I have downloaded source code. There is a makefile for migw. SO I have installed mingw on ubuntu and modified the makefile.mingw32 to set it for my system. I have no error but some warnings. The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But When I want to use it the jvm crash :( How can I know what is wrong ? How rxtx windows release has been done ? thanks -- yves piel From yvespielusenet at free.fr Tue Jun 26 07:17:02 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 15:17:02 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182850918.3483.10.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> Message-ID: <1182863822.3483.17.camel@localhost.localdomain> Here is the Makefile I use, the output of the 'make' and the log of the jvm when it crashed : - The Makefile : http://yvespiel.free.fr/rxtx/Makefile - The make output : http://yvespiel.free.fr/rxtx/compile.txt - The crash log : http://yvespiel.free.fr/rxtx/hs_err_pid2100.log I have compiled rxtx under Debian testing with mingw : narma at linimi:/tmp/err$ dpkg -l | grep mingw ii mingw32 3.4.5.20060117.1.dfsg-3 ii mingw32-binutils 2.17.50-20070129.1-1 ii mingw32-runtime 3.12-1 thanks fort help :) Le mardi 26 juin 2007 ? 11:41 +0200, yves pielusenet a ?crit : > Hello, > So now I want to modify the timeout of the library for parallel port. I > have downloaded source code. There is a makefile for migw. SO I have > installed mingw on ubuntu and modified the makefile.mingw32 to set it > for my system. > I have no error but some warnings. > The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But > When I want to use it the jvm crash :( > > How can I know what is wrong ? > > How rxtx windows release has been done ? > > thanks > From yvespielusenet at free.fr Tue Jun 26 07:40:11 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 15:40:11 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182863822.3483.17.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> <1182863822.3483.17.camel@localhost.localdomain> Message-ID: <1182865211.3483.21.camel@localhost.localdomain> I have add the options '--enable-stdcall-fixup' to the 'i586-mingw32msvc-ld' commande. Now I have no warning. But the JVM always crashes :( The output seems more detailled, but I don't understand anything... Here is files : http://yvespiel.free.fr/rxtx/2/ -- yves piel Le mardi 26 juin 2007 ? 15:17 +0200, yves pielusenet a ?crit : > Here is the Makefile I use, the output of the 'make' and the log of the > jvm when it crashed : > > - The Makefile : http://yvespiel.free.fr/rxtx/Makefile > - The make output : http://yvespiel.free.fr/rxtx/compile.txt > - The crash log : http://yvespiel.free.fr/rxtx/hs_err_pid2100.log > > I have compiled rxtx under Debian testing with mingw : > narma at linimi:/tmp/err$ dpkg -l | grep mingw > ii mingw32 3.4.5.20060117.1.dfsg-3 > ii mingw32-binutils 2.17.50-20070129.1-1 > ii mingw32-runtime 3.12-1 > > thanks fort help :) > > > Le mardi 26 juin 2007 ? 11:41 +0200, yves pielusenet a ?crit : > > Hello, > > So now I want to modify the timeout of the library for parallel port. I > > have downloaded source code. There is a makefile for migw. SO I have > > installed mingw on ubuntu and modified the makefile.mingw32 to set it > > for my system. > > I have no error but some warnings. > > The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But > > When I want to use it the jvm crash :( > > > > How can I know what is wrong ? > > > > How rxtx windows release has been done ? > > > > thanks > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From yvespielusenet at free.fr Tue Jun 26 08:27:42 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 16:27:42 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182865211.3483.21.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> <1182863822.3483.17.camel@localhost.localdomain> <1182865211.3483.21.camel@localhost.localdomain> Message-ID: <1182868062.3483.24.camel@localhost.localdomain> I think thant the include files of jdk were not for windows but for linux. So I have copied include/ folder from windows to linux and I modified the Makefile to use those file. It compile fine but the JVM always crash :( http://yvespiel.free.fr/rxtx/3/ Le mardi 26 juin 2007 ? 15:40 +0200, yves pielusenet a ?crit : > I have add the options '--enable-stdcall-fixup' to the > 'i586-mingw32msvc-ld' commande. Now I have no warning. But the JVM > always crashes :( The output seems more detailled, but I don't > understand anything... > Here is files : > http://yvespiel.free.fr/rxtx/2/ > From netbeans at gatworks.com Fri Jun 1 05:38:50 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 07:38:50 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <465F7ADD.1010501@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> Message-ID: <4660054A.2040202@gatworks.com> Manuel Naranjo wrote: In the case of my module, you can > unplug the device but it will not delete the symlink until those apps > that had opened the port has closed it. This is done this way to avoid > kernel panics. What does this mean to user code ? I have tried the alternate route ( other than closing ) which is sleep inbetween the I/O errors ( an unplugged USB device). When the device is plugged back in, The writes to the device still get an I/O error. This would seem to be a lost cause for the application. From netbeans at gatworks.com Fri Jun 1 06:35:48 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 08:35:48 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <465F7ADD.1010501@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> Message-ID: <466012A4.90608@gatworks.com> Manuel Naranjo wrote: In the case of my module, you can > unplug the device but it will not delete the symlink until those apps > that had opened the port has closed it. T Did u also mean for this to happen? USB0 was not closed by application. Apparently USB1 got created when USB device was plugged back in. There is only one USB device on a 4 port USB hub. This also seems to suggest that application recovery to be impossible. > Jun 1 07:10:08 mylaptop kernel: garmin_gps 1-1.4:1.0: Garmin GPS usb/tty converter detected > Jun 1 07:10:08 mylaptop kernel: usb 1-1.4: Garmin GPS usb/tty converter now attached to ttyUSB0 > Jun 1 07:15:17 mylaptop kernel: usb 1-1: USB disconnect, address 4 > Jun 1 07:15:17 mylaptop kernel: usb 1-1.4: USB disconnect, address 5 > Jun 1 07:15:17 mylaptop kernel: garmin_gps 1-1.4:1.0: device disconnected > Jun 1 07:15:26 mylaptop kernel: usb 1-1: new full speed USB device using uhci_hcd and address 6 > Jun 1 07:15:26 mylaptop kernel: hub 1-1:1.0: USB hub found > Jun 1 07:15:26 mylaptop kernel: hub 1-1:1.0: 4 ports detected > Jun 1 07:15:27 mylaptop kernel: usb 1-1.4: new full speed USB device using uhci_hcd and address 7 > Jun 1 07:15:27 mylaptop kernel: garmin_gps 1-1.4:1.0: Garmin GPS usb/tty converter detected > Jun 1 07:15:27 mylaptop kernel: usb 1-1.4: Garmin GPS usb/tty converter now attached to ttyUSB1 From naranjo.manuel at gmail.com Fri Jun 1 09:17:22 2007 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Fri, 01 Jun 2007 12:17:22 -0300 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <466012A4.90608@gatworks.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> <466012A4.90608@gatworks.com> Message-ID: <46603882.5050701@gmail.com> Uncle George escribi?: > Manuel Naranjo wrote: > In the case of my module, you can > >> unplug the device but it will not delete the symlink until those apps >> that had opened the port has closed it. T >> > > Did u also mean for this to happen? USB0 was not closed by application. > > Apparently USB1 got created when USB device was plugged back in. There > is only one USB device on a 4 port USB hub. > > This also seems to suggest that application recovery to be impossible. > Exactly there's a dead symlink (you can read and write to it and nothing will happen) and a new port will be created when a new device is connencted. From netbeans at gatworks.com Fri Jun 1 10:20:46 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 12:20:46 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <46603882.5050701@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> <466012A4.90608@gatworks.com> <46603882.5050701@gmail.com> Message-ID: <4660475E.5090202@gatworks.com> Not sure what u mean by "symlink". U cant read/write to it anymore. U get I/O error. In this scenario the device effectively went dead, and only solution is to close the channel. reconnecting the USB device, although dead, but not closed, will create a second device. This does not seem to be a desirable side-effect. The user will now have ttyUSB1, wondering where did ttyUSB0 go to. The application will also be in a confused state, as well as RXTX, because RXTX wont know about ttyUSB1. Manuel Naranjo wrote: > Uncle George escribi?: >> Manuel Naranjo wrote: >> In the case of my module, you can >> >>> unplug the device but it will not delete the symlink until those apps >>> that had opened the port has closed it. T >>> >> Did u also mean for this to happen? USB0 was not closed by application. >> >> Apparently USB1 got created when USB device was plugged back in. There >> is only one USB device on a 4 port USB hub. >> >> This also seems to suggest that application recovery to be impossible. >> > Exactly there's a dead symlink (you can read and write to it and nothing > will happen) and a new port will be created when a new device is connencted. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From arnab.bhaumik at gmail.com Mon Jun 4 01:40:16 2007 From: arnab.bhaumik at gmail.com (arnab bhaumik) Date: Mon, 4 Jun 2007 13:10:16 +0530 Subject: [Rxtx] full duplex com port with rxtx Message-ID: hi , till now i did half duplex communication with rxtx package on com package. my question is : is it possible to use com port with full duplex mode with rxtx package . ther is example of SimpleRead class and SimpleWrite class. it is clear that if i can use both the class simultaneously then full duplex is possible......... arnab/vu2bpw -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070604/6edb0453/attachment-0010.html From lists at iDIAcomputing.com Mon Jun 4 07:53:17 2007 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Mon, 04 Jun 2007 09:53:17 -0400 Subject: [Rxtx] full duplex com port with rxtx In-Reply-To: References: Message-ID: <4664194D.90301@iDIAcomputing.com> arnab bhaumik wrote: > hi , > > till now i did half duplex communication with rxtx package on com > package. > > my question is : is it possible to use com port with full duplex mode > with rxtx package . > > > ther is example of SimpleRead class and SimpleWrite class. it is > clear that if i can use both the class simultaneously then full duplex > is possible......... I haven't looked at the SimpleRead and SimpleWrite classes (I originally wrote my code for the javax.comm api), but full duplex is certainly possible. My CommReader class requires an object analogous to a OutputStream or Writer. When started, it spawns a thread that reads the comm port and writes to that output device. In this way the input is asynchronous and dependent on the actual input data. For full duplex, I extend that class with CommReaderWriter, which adds synchronous output methods. Hope that helps, George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From supsoop at hotmail.com Mon Jun 4 15:21:06 2007 From: supsoop at hotmail.com (soop soop) Date: Mon, 04 Jun 2007 21:21:06 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- Message-ID: Hi Guys, Looked through the archives but still cannot figure this out. I have a Motorola G24 GPRS/GSM modem that I am connecting to my server running Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not detecting the port, CommPortIdentifier.getPortIdentifiers(). I have added the line to RXTXCommDriver: "ttyACM" // for USB Modems Rxtx still does not seem to find the port. Is there something I am missing to make this port visable? [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control Model driver for USB modems and ISDN adapters I really need your help as I have moved my server from windows to Linux and have been down for a few days because of this .. Thanks so much! _________________________________________________________________ PC Magazine’s 2007 editors’ choice for best Web mail—award-winning Windows Live Hotmail. http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 From tjarvi at qbang.org Mon Jun 4 16:17:35 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Jun 2007 16:17:35 -0600 (MDT) Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: On Mon, 4 Jun 2007, soop soop wrote: > Hi Guys, > > Looked through the archives but still cannot figure this out. I have a > Motorola G24 GPRS/GSM modem that I am connecting to my server running Ubuntu. > I can see my modem as is shows up as ttyACM0, but RXTX is not detecting the > port, CommPortIdentifier.getPortIdentifiers(). > > I have added the line to RXTXCommDriver: > > "ttyACM" // for USB Modems > > Rxtx still does not seem to find the port. Is there something I am missing to > make this port visable? > > [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver > [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device > [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control Model > driver for USB modems and ISDN adapters > > I really need your help as I have moved my server from windows to Linux and > have been down for a few days because of this .. Thanks so much! > You could try the INSTALL documentation that comes with the source for possible solutions. Those usually involve lockfile creation, permissions on the device file or the device is in use by another application (even another session of your application). The usual commands: ls -l /dev/ttyACM0 fuser /dev/ttyACM0 touch /var/lock/LCK.testfile && rm -f /var/lock/LCK.testfile whoami To disable lockfiles: ../configure --disable-lockfiles && make install -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Jun 4 16:22:52 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 04 Jun 2007 18:22:52 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <466490BC.3090801@gatworks.com> soop soop wrote: > I really need your help as I have moved my server from windows to Linux > and have been down for a few days because of this .. Thanks so much! can u open the device ? ie is the file protection/permissions keeping you out? From supsoop at hotmail.com Mon Jun 4 16:44:40 2007 From: supsoop at hotmail.com (soop soop) Date: Mon, 04 Jun 2007 22:44:40 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <466490BC.3090801@gatworks.com> Message-ID: Thanks for the reply, I see no exceptions being thrown, just no detection of the port whats so ever. I will run rxtx in debug mode and log. If this were a permissions issue would I not see some exceptions being thrown? >From: Uncle George >Reply-To: RXTX Developers and Users >To: RXTX Developers and Users >Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >Date: Mon, 04 Jun 2007 18:22:52 -0400 > >soop soop wrote: > > > I really need your help as I have moved my server from windows to Linux > > and have been down for a few days because of this .. Thanks so much! > >can u open the device ? ie is the file protection/permissions keeping >you out? >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ Get a preview of Live Earth, the hottest event this summer - only on MSN http://liveearth.msn.com?source=msntaglineliveearthhm From netbeans at gatworks.com Mon Jun 4 17:06:15 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 04 Jun 2007 19:06:15 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <46649AE7.10405@gatworks.com> Exceptions on what? On startup it wants to lookup all devices in /dev that it is capable of opening ( within the list of specific 'comm' devices ). If it cannot open, then does not get onto list. Part of this process, if configured, will also test if the "LOCK" schema can also be opened for the device. then it gets on the list of avail comm port. soop soop wrote: > Thanks for the reply, > > I see no exceptions being thrown, just no detection of the port whats so > ever. I will run rxtx in debug mode and log. If this were a permissions > issue would I not see some exceptions being thrown? > > >> From: Uncle George >> Reply-To: RXTX Developers and Users >> To: RXTX Developers and Users >> Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >> Date: Mon, 04 Jun 2007 18:22:52 -0400 >> >> soop soop wrote: >> >>> I really need your help as I have moved my server from windows to Linux >>> and have been down for a few days because of this .. Thanks so much! >> can u open the device ? ie is the file protection/permissions keeping >> you out? >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _________________________________________________________________ > Get a preview of Live Earth, the hottest event this summer - only on MSN > http://liveearth.msn.com?source=msntaglineliveearthhm > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From alex.flint at gmail.com Mon Jun 4 21:31:49 2007 From: alex.flint at gmail.com (Alex Flint) Date: Tue, 5 Jun 2007 13:01:49 +0930 Subject: [Rxtx] random EXCEPTION_ACCESS_VIOLATION errors Message-ID: Hi All, I'm running winXP and RXTX 2.1-7r2 (the latest from the webpage as of June 2007). I'm sending sequences of 64 lines (each line has about 15 chars) at various intervals. The strings are sent fine, until I get the following error (from hs_err_pid3316.log, at the end of this email). What can I do to avoid the error? Obviously this is a low-level memory exception, but is there any way I can keep the JVM running after such an error? I noticed the exact same problem here: http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20070129/1180520.html Cheers, Alex # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x100034fb, pid=3316, tid=2400 # # Java VM: Java HotSpot(TM) Client VM (1.6.0_01-b06 mixed mode, sharing) # Problematic frame: # C [rxtxSerial.dll+0x34fb] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # --------------- T H R E A D --------------- Current thread (0x00386400): JavaThread "main" [_thread_in_native, id=2400] siginfo: ExceptionCode=0xc0000005, reading address 0x20726f78 Registers: EAX=0x20726f20, EBX=0x6d8922c0, ECX=0x00000005, EDX=0x20726f20 ESP=0x003efa30, EBP=0x003efb68, ESI=0x269728a0, EDI=0x00386400 EIP=0x100034fb, EFLAGS=0x00010212 Top of Stack: (sp=0x003efa30) 0x003efa30: 003efa3c 003efa64 0000000f ffffffff 0x003efa40: 003efa40 2a97f808 003efa6c 2b190ca8 0x003efa50: 00000000 2b190ec0 003efa90 008e2dd7 0x003efa60: 003efa90 008e2dd7 26977f88 6d815e72 0x003efa70: 00000004 2696eae0 0000008a 003efb0c 0x003efa80: 6d852b4a 2696eae0 00000003 26970930 0x003efa90: 000000cb 2696eae0 6d86b264 00385d40 0x003efaa0: 0000003f 003efb0c 26977f90 2ace65d8 Instructions: (pc=0x100034fb) 0x100034eb: ff ff 8d 76 00 eb 02 89 f6 90 8b 45 f8 8b 55 f8 0x100034fb: 8b 4a 58 83 c9 04 89 48 58 83 c4 f8 8b 45 f8 8b Stack: [0x003a0000,0x003f0000), sp=0x003efa30, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x34fb] Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j gnu.io.RXTXPort.writeArray([BIIZ)V+0 j gnu.io.RXTXPort$SerialOutputStream.write([B)V+76 j com.bjt.media.server.CommLink.send(Ljava/lang/String;)V+48 j com.bjt.media.server.DigitoolConnection.select(I)V+73 j com.bjt.media.server.DigitoolConnection.main([Ljava/lang/String;)V+74 v ~StubRoutines::call_stub --------------- P R O C E S S --------------- Java Threads: ( => current thread ) 0x02a69400 JavaThread "Thread-0" [_thread_in_native, id=3052] 0x02a4d000 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=3920] 0x02a48400 JavaThread "CompilerThread0" daemon [_thread_blocked, id=1968] 0x02a47400 JavaThread "Attach Listener" daemon [_thread_blocked, id=2984] 0x02a46400 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=2660] 0x02a41c00 JavaThread "Finalizer" daemon [_thread_blocked, id=3924] 0x02a3d800 JavaThread "Reference Handler" daemon [_thread_blocked, id=4008] =>0x00386400 JavaThread "main" [_thread_in_native, id=2400] Other Threads: 0x02a34400 VMThread [id=3708] 0x02a4e800 WatcherThread [id=3964] VM state:not at safepoint (normal execution) VM Mutex/Monitor currently owned by a thread: None Heap def new generation total 960K, used 131K [0x22960000, 0x22a60000, 0x22e40000) eden space 896K, 7% used [0x22960000, 0x22970ea8, 0x22a40000) from space 64K, 99% used [0x22a50000, 0x22a5fff8, 0x22a60000) to space 64K, 0% used [0x22a40000, 0x22a40000, 0x22a50000) tenured generation total 4096K, used 76K [0x22e40000, 0x23240000, 0x26960000) the space 4096K, 1% used [0x22e40000, 0x22e53060, 0x22e53200, 0x23240000) compacting perm gen total 12288K, used 137K [0x26960000, 0x27560000, 0x2a960000) the space 12288K, 1% used [0x26960000, 0x26982518, 0x26982600, 0x27560000) ro space 8192K, 62% used [0x2a960000, 0x2ae5e4e8, 0x2ae5e600, 0x2b160000) rw space 12288K, 52% used [0x2b160000, 0x2b7a0e78, 0x2b7a1000, 0x2bd60000) Dynamic libraries: 0x00400000 - 0x00423000 C:\Program Files\Java\jre1.6.0_01\bin\javaw.exe 0x7c900000 - 0x7c9b0000 C:\WINDOWS\system32\ntdll.dll 0x7c800000 - 0x7c8f4000 C:\WINDOWS\system32\kernel32.dll 0x77dd0000 - 0x77e6b000 C:\WINDOWS\system32\ADVAPI32.dll 0x77e70000 - 0x77f01000 C:\WINDOWS\system32\RPCRT4.dll 0x7e410000 - 0x7e4a0000 C:\WINDOWS\system32\USER32.dll 0x77f10000 - 0x77f57000 C:\WINDOWS\system32\GDI32.dll 0x76390000 - 0x763ad000 C:\WINDOWS\system32\IMM32.DLL 0x7c340000 - 0x7c396000 C:\Program Files\Java\jre1.6.0_01\bin\msvcr71.dll 0x6d7c0000 - 0x6da07000 C:\Program Files\Java\jre1.6.0_01\bin\client\jvm.dll 0x76b40000 - 0x76b6d000 C:\WINDOWS\system32\WINMM.dll 0x5cd70000 - 0x5cd77000 C:\WINDOWS\system32\serwvdrv.dll 0x5b0a0000 - 0x5b0a7000 C:\WINDOWS\system32\umdmxfrm.dll 0x6d310000 - 0x6d318000 C:\Program Files\Java\jre1.6.0_01\bin\hpi.dll 0x76bf0000 - 0x76bfb000 C:\WINDOWS\system32\PSAPI.DLL 0x6d770000 - 0x6d77c000 C:\Program Files\Java\jre1.6.0_01\bin\verify.dll 0x6d3b0000 - 0x6d3cf000 C:\Program Files\Java\jre1.6.0_01\bin\java.dll 0x6d7b0000 - 0x6d7bf000 C:\Program Files\Java\jre1.6.0_01\bin\zip.dll 0x10000000 - 0x10012000 C:\Documents and Settings\Alex\workspace\MediaServer\rxtxSerial.dll 0x73d90000 - 0x73db7000 C:\WINDOWS\system32\crtdll.dll VM Arguments: jvm_args: -Djava.library.path=C:\Documents and Settings\Alex\workspace\MediaServer java_command: com.bjt.media.server.DigitoolConnection Launcher Type: SUN_STANDARD Environment Variables: CLASSPATH=.;C:\Program Files\Java\j2re1.4.2_07\lib\ext\QTJava.zip PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\wbem;c:\applications\php;C:\Program Files\MATLAB\R2006a\bin\win32;C:\Roger\Projects\UAV\Bin\Debug;C:\Program Files\Microsoft SQL Server\80\Tools\Binn\;c:\Program Files\Microsoft SQL Server\90\Tools\binn\;C:\Program Files\QuickTime\QTSystem\;C:\Pfps\system;C:\Program Files\Java\jdk1.6.0_01\bin;C:\Program Files\Java\jdk1.6.0_01\jre\bin USERNAME=Alex OS=Windows_NT PROCESSOR_IDENTIFIER=x86 Family 15 Model 4 Stepping 1, GenuineIntel --------------- S Y S T E M --------------- OS: Windows XP Build 2600 Service Pack 2 CPU:total 1 family 15, cmov, cx8, fxsr, mmx, sse, sse2 Memory: 4k page, physical 1046508k(275288k free), swap 2522816k(1909176k free) vm_info: Java HotSpot(TM) Client VM (1.6.0_01-b06) for windows-x86, built on Mar 14 2007 00:24:02 by "java_re" with unknown MS VC++:1310 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070604/c87ae1f0/attachment-0010.html From alwyn.schoeman at gmail.com Tue Jun 5 00:10:19 2007 From: alwyn.schoeman at gmail.com (Alwyn Schoeman) Date: Tue, 5 Jun 2007 08:10:19 +0200 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Hi, I'm using a similar modem. By default rxtx doesn't look for devices that start with ACM, so you need to modify the source code and recompile. Look in RXTXCommDriver and add values for ACM in the registerScannedPorts method in the Linux specific parts. Look for osName.equals("Linux")... On 6/4/07, soop soop wrote: > > Hi Guys, > > Looked through the archives but still cannot figure this out. I have a > Motorola G24 GPRS/GSM modem that I am connecting to my server running > Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not > detecting the port, CommPortIdentifier.getPortIdentifiers(). > > I have added the line to RXTXCommDriver: > > "ttyACM" // for USB Modems > > Rxtx still does not seem to find the port. Is there something I am missing > to make this port visable? > > [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver > [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device > [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control > Model > driver for USB modems and ISDN adapters > > I really need your help as I have moved my server from windows to Linux > and > have been down for a few days because of this .. Thanks so much! > > _________________________________________________________________ > PC Magazine's 2007 editors' choice for best Web mail?award-winning Windows > Live Hotmail. > > http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -- Alwyn Schoeman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/b6cb3053/attachment-0010.html From naranjo.manuel at gmail.com Tue Jun 5 06:48:45 2007 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Tue, 05 Jun 2007 09:48:45 -0300 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> References: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Message-ID: <46655BAD.7010501@gmail.com> That's right, an easier solution is creating symlinks to acm. For example make ttyS70 to 79 point to ACM0 to 9 and that will help you a lot, and doesn't even require compile. > Hi, > > I'm using a similar modem. By default rxtx doesn't look for devices > that start with ACM, so you need to modify the > source code and recompile. > > Look in RXTXCommDriver and add values for ACM in the > registerScannedPorts method in the Linux specific parts. Look for > osName.equals("Linux")... > From juanemc2 at gmail.com Tue Jun 5 07:02:43 2007 From: juanemc2 at gmail.com (Juan) Date: Tue, 5 Jun 2007 10:02:43 -0300 Subject: [Rxtx] Problems with Epson TMU220B POSPrinter using XON/XOFF Flow Control and rxtx jar and dll's with the serial port. Message-ID: Hi!, I?m having trouble printing to the serial port using the latest version of rxtx jar and dll's with an Epson POSPrinter. I`ve switched the printer to work with XON/XOFF Flow Control and have watched the serial port to be sure the printer is sending the XON XOFF stop and go characters. I`ve setted the port like this: CommPortIdentifier commPortIdentifier = CommPortIdentifier.* getPortIdentifier*(_portName); SerialPort serialPort = (SerialPort)commPortIdentifier.open(*this*.getClass().getName(), 2000); serialPort.setSerialPortParams(_baudRate, _dataBits, _stopBits, _parity); serialPort.setFlowControlMode( SerialPort.*FLOWCONTROL_XONXOFF_IN* | SerialPort.*FLOWCONTROL_XONXOFF_OUT*); where the baudRate is 9600 the dataBits is 8 the stopBits is 1 and the parity is 0 It seems as the library isn`t taking into account the XON XOFF setting. I would like to know if I`m setting correctly the Flow Control and if you had had any experiences using XON XOFF flow control and could give me some help to solve my problem. I`m very thankful in advance, Yours, Juan Polero -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/b080995a/attachment-0010.html From ehdez.correo at gmail.com Tue Jun 5 07:12:53 2007 From: ehdez.correo at gmail.com (=?ISO-8859-1?Q?Enrique_Hern=E1ndez?=) Date: Tue, 5 Jun 2007 09:12:53 -0400 Subject: [Rxtx] problem with rxtx Message-ID: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Hello: I doing a simple test to show the serial ports. This is the code: import java.util.Enumeration; import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; public class Show { private Enumeration portList; private CommPortIdentifier portId; private SerialPort port; /** Creates a new instance of Show */ public Show() { } public static void main(String args[]){ Show show = new Show(); show.portList = CommPortIdentifier.getPortIdentifiers(); String tPort = ""; System.out.println("========================================="); while(show.portList.hasMoreElements()){ show.portId = (CommPortIdentifier)show.portList.nextElement(); if(show.portId.getPortType() == CommPortIdentifier.PORT_SERIAL) tPort = "Serial"; else tPort = "Parallel"; System.out.println(show.portId.getName() + " " + tPort); } } } whit The problem is that this code not show the serial ports, this show the no use serial ports. I want to connect whit the modem but when windows open and connect the modem my application don't see the port(COMM3) when it is connect. what I can do? Is that the correct way to know the ports? thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/eedd744b/attachment-0010.html From ehdez.correo at gmail.com Tue Jun 5 07:42:13 2007 From: ehdez.correo at gmail.com (=?ISO-8859-1?Q?Enrique_Hern=E1ndez?=) Date: Tue, 5 Jun 2007 09:42:13 -0400 Subject: [Rxtx] serial port Message-ID: <4a814e1f0706050642p4ce9ac7bka80f9479c524c5ea@mail.gmail.com> Hello: How I can ask to the port what device is connect and information about this device. thanks. bye. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/4d10d26a/attachment-0010.html From supsoop at hotmail.com Tue Jun 5 09:29:00 2007 From: supsoop at hotmail.com (soop soop) Date: Tue, 05 Jun 2007 15:29:00 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Message-ID: Hi Guys, Thanks for all your help. I found the problem. I created a user, Tomcat55, for my tomcat but it did not belong to any group. I then added this user to dialout group to have access to the device ttyACM0. Works perfectly! Again permissions was the issue. This also seems to be persistent as a server reboot does not effect the access. Cheers! >From: "Alwyn Schoeman" >Reply-To: RXTX Developers and Users >To: "RXTX Developers and Users" >Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >Date: Tue, 5 Jun 2007 08:10:19 +0200 > >Hi, > >I'm using a similar modem. By default rxtx doesn't look for devices that >start with ACM, so you need to modify the >source code and recompile. > >Look in RXTXCommDriver and add values for ACM in the registerScannedPorts >method in the Linux specific parts. Look for osName.equals("Linux")... > >On 6/4/07, soop soop wrote: >> >>Hi Guys, >> >>Looked through the archives but still cannot figure this out. I have a >>Motorola G24 GPRS/GSM modem that I am connecting to my server running >>Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not >>detecting the port, CommPortIdentifier.getPortIdentifiers(). >> >>I have added the line to RXTXCommDriver: >> >>"ttyACM" // for USB Modems >> >>Rxtx still does not seem to find the port. Is there something I am missing >>to make this port visable? >> >>[ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver >>[ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device >>[ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control >>Model >>driver for USB modems and ISDN adapters >> >>I really need your help as I have moved my server from windows to Linux >>and >>have been down for a few days because of this .. Thanks so much! >> >>_________________________________________________________________ >>PC Magazine's 2007 editors' choice for best Web mail—award-winning Windows >>Live Hotmail. >> >>http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 >> >> >>_______________________________________________ >>Rxtx mailing list >>Rxtx at qbang.org >>http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > >-- >Alwyn Schoeman >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ Need a break? Find your escape route with Live Search Maps. http://maps.live.com/default.aspx?ss=Restaurants~Hotels~Amusement%20Park&cp=33.832922~-117.915659&style=r&lvl=13&tilt=-90&dir=0&alt=-1000&scene=1118863&encType=1&FORM=MGAC01 From netbeans at gatworks.com Tue Jun 5 09:42:31 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 11:42:31 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <46658467.20101@gatworks.com> soop soop wrote: > > Hi Guys, > > Thanks for all your help. I found the problem. I created a user, > Tomcat55, for my tomcat but it did not belong to any group. I then added Look at man pages for the program udev. From tjarvi at qbang.org Tue Jun 5 18:18:17 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Jun 2007 18:18:17 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Message-ID: On Tue, 5 Jun 2007, Enrique Hern?ndez wrote: > The problem is that this code not show the serial ports, this show the no > use serial ports. I want to connect whit the modem but when windows open and > connect the modem my application don't see the port(COMM3) when it is > connect. > what I can do? > Is that the correct way to know the ports? > Hello, We may have problems understanding each other. On windows, the port will not be an available serial port if another application has the port open. That is just how the library behaves. If you can not see the port in the enumerated list, you could not open it. Also note that enumeration only happens once. If you add a port such as a new USB dongle, the port will not be visible until the next time your application runs. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Tue Jun 5 18:45:01 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 20:45:01 -0400 Subject: [Rxtx] problem with rxtx In-Reply-To: References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Message-ID: <4666038D.8090700@gatworks.com> Trent Jarvi wrote: > > > Also note that enumeration only happens once. If you add a port such as > a new USB dongle, the port will not be visible until the next time your > application runs. Is this written in stone ? somewhere? From tjarvi at qbang.org Tue Jun 5 18:54:36 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Jun 2007 18:54:36 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <4666038D.8090700@gatworks.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> Message-ID: On Tue, 5 Jun 2007, Uncle George wrote: > Trent Jarvi wrote: >> >> >> Also note that enumeration only happens once. If you add a port such as >> a new USB dongle, the port will not be visible until the next time your >> application runs. > > Is this written in stone ? somewhere? It is just the current behavior. There is nothing preventing a fix that allows reenumeration. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Tue Jun 5 19:55:19 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 21:55:19 -0400 Subject: [Rxtx] problem with rxtx In-Reply-To: References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> Message-ID: <46661407.4020308@gatworks.com> >> Is this written in stone ? somewhere? > > It is just the current behavior. There is nothing preventing a fix that > allows reenumeration. With usb, ..... , things come and go. Seems a shame that you have to kill application to get at the device u just plugged in. From joachim at buechse.ch Wed Jun 6 01:50:06 2007 From: joachim at buechse.ch (Joachim Buechse) Date: Wed, 6 Jun 2007 09:50:06 +0200 Subject: [Rxtx] problem with rxtx In-Reply-To: <46661407.4020308@gatworks.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> <46661407.4020308@gatworks.com> Message-ID: <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> On MacOS RXTX's enumeration handling is more flexible. It will find new ports that are added during the lifetime of the application. But this is inherently incompatible with suns javax.comm implementation... Regards, Joachim On 06.06.2007, at 03:55, Uncle George wrote: > >>> Is this written in stone ? somewhere? >> >> It is just the current behavior. There is nothing preventing a >> fix that >> allows reenumeration. > > With usb, ..... , things come and go. Seems a shame that you have to > kill application to get at the device u just plugged in. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Jun 6 06:06:48 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Jun 2007 06:06:48 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> <46661407.4020308@gatworks.com> <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> Message-ID: Sun's javax.comm is not a major concern going forward. As long as we do not break old applications using rxtx, I see no reason to limit rxtx to that convention. We have already rejected version 3 from Sun as a dead end and limited our compatability to version 2. That does not mean we will not try to work with Sun and others but the current javax.comm convention (v3) is not a well conceived path. There has been discussion about doing a JSR which is one valid option. On Wed, 6 Jun 2007, Joachim Buechse wrote: > On MacOS RXTX's enumeration handling is more flexible. It will find > new ports that are added during the lifetime of the application. But > this is inherently incompatible with suns javax.comm implementation... > > Regards, > Joachim > > On 06.06.2007, at 03:55, Uncle George wrote: > >> >>>> Is this written in stone ? somewhere? >>> >>> It is just the current behavior. There is nothing preventing a >>> fix that >>> allows reenumeration. >> >> With usb, ..... , things come and go. Seems a shame that you have to >> kill application to get at the device u just plugged in. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From yvespielusenet at free.fr Wed Jun 6 08:46:35 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 16:46:35 +0200 Subject: [Rxtx] [PARALLEL] resource in use Message-ID: <1181141195.3407.20.camel@localhost.localdomain> Hello, I want to use rxtx in my application. I haveto send data to a very old printer (which have a drum and hammers http://perso.orange.fr/tiie/page00010017.html) This is printer is connecter with centronics. It works well but, while it's writting and I putthe printer off-line, after about 45 seconds, I have this error : ------------------------------------- java.io.IOException: La ressource demand?e est en cours d'utilisation. in writeArray at gnu.io.LPRPort.writeArray(Native Method) at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:292) at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:161) at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:156) at mce.buffer.bufferManager.BufferManager$PrintBuffer.run(BufferManager.java:141) The IOexception means "The wanted resource is in use" ------------------------------------- Here is the line 141 of BufferManager : ------------------------------------- while(send){ try{ fos.write(bb); <=== line 141 send = false; } catch(Exception e){ javax.swing.JOptionPane.showMessageDialog(null, "Erreur d'envoie. Veuillez cliquer sur OK pour relancer l'impression de la vignette.\nV?rifiez votre impression !", "Erreur d'envoie", javax.swing.JOptionPane.WARNING_MESSAGE); e.printStackTrace(System.err); System.err.flush(); System.out.println(e); send = true; } } -------------------------------- 'fos' is an outputstream which contains the rxtx stream (this.os is the rxtx outputstream) : -------------------------------- public void write(byte[] bb) throws IOException{ this.write(bb, 0, bb.length); } public void write(byte[] bb, int off, int len) throws IOException{ while(!imp1.isPrinterSelected() || !imp2.isPrinterSelected()){ } this.os.write(bb, off, len); } -------------------------------- Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( can you help me ? thank you :) -- yves piel From yvespielusenet at free.fr Wed Jun 6 09:11:15 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 17:11:15 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181141195.3407.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> Message-ID: <1181142675.3407.23.camel@localhost.localdomain> I forgot to tell that It's under windows XP and java 1.5. Le mercredi 06 juin 2007 ? 16:46 +0200, yves pielusenet a ?crit : > Hello, > I want to use rxtx in my application. I haveto send data to a very old > printer (which have a drum and hammers > http://perso.orange.fr/tiie/page00010017.html) > This is printer is connecter with centronics. It works well but, while > it's writting and I putthe printer off-line, after about 45 seconds, I > have this error : > ------------------------------------- > java.io.IOException: La ressource demand?e est en cours d'utilisation. > in writeArray > at gnu.io.LPRPort.writeArray(Native Method) > at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:292) > at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:161) > at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:156) > at mce.buffer.bufferManager.BufferManager$PrintBuffer.run(BufferManager.java:141) > > The IOexception means "The wanted resource is in use" > ------------------------------------- > > Here is the line 141 of BufferManager : > > ------------------------------------- > while(send){ > try{ > fos.write(bb); <=== line 141 > send = false; > } > catch(Exception e){ > javax.swing.JOptionPane.showMessageDialog(null, "Erreur d'envoie. Veuillez cliquer sur OK pour relancer l'impression de la vignette.\nV?rifiez votre impression !", "Erreur d'envoie", javax.swing.JOptionPane.WARNING_MESSAGE); > e.printStackTrace(System.err); > System.err.flush(); > System.out.println(e); > send = true; > } > } > -------------------------------- > 'fos' is an outputstream which contains the rxtx stream (this.os is the rxtx outputstream) : > > -------------------------------- > public void write(byte[] bb) throws IOException{ > this.write(bb, 0, bb.length); > } > public void write(byte[] bb, int off, int len) throws IOException{ > while(!imp1.isPrinterSelected() || !imp2.isPrinterSelected()){ > } > this.os.write(bb, off, len); > } > -------------------------------- > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > can you help me ? > > thank you :) > From netbeans at gatworks.com Wed Jun 6 09:21:46 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 11:21:46 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181141195.3407.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> Message-ID: <4666D10A.8000507@gatworks.com> } > -------------------------------- > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > can you help me ? > > thank you :) > windoz or linux? ( I guess windoz ) for windoz, there appears to be a timeout ( as Comments suggest ) of about 40seconds. > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } for linux, there is no implied timeout. > if( write( fd, bytes, count ) < 0 ) > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); From netbeans at gatworks.com Wed Jun 6 09:39:41 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 11:39:41 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666D10A.8000507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> Message-ID: <4666D53D.90000@gatworks.com> Uncle George wrote: > } >> -------------------------------- >> >> Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( >> >> can you help me ? From reading the code, I can see your concern. And it appears you are correct, because some of the data will be sent to the OS printer buffers, and then it will refuse to accept anymore. Unfortunately, writeArray does not return the num of characters written :{ So application has no idea to how many characters were accepted by the OS. I dont do windoz, so I cant say with absolute certainty what windoz will do with an off-line condition. If you have the source, and can compile, then maybe u can increase the loop count to hit 4hours? From yvespielusenet at free.fr Wed Jun 6 09:53:25 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 17:53:25 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666D10A.8000507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> Message-ID: <1181145205.3407.35.camel@localhost.localdomain> Thank you for your explanation :) This timeout comes when no data has been send to the printer after 40seconds if I well understand. But why there is such a timeout ? If I setthe printer offline while it's printing I mustn't have an exception. I don't understand why the "printer should solv all problems like buffer full" in 40 seconds. If I pause the printer the buffer will not be emptied, isn't it ? I not very familiar with C/C++, but it seem that the exception is thrown only when countWritten == 0, that means no data at all has been sent. So Is my code is good since when I intercept this exception I send all my buffer again. There is no way that the printer receive two times same bytes ? thanks ps: yes the application is running on windows XP since I developpe under Debian Le mercredi 06 juin 2007 ? 11:21 -0400, Uncle George a ?crit : > } > > -------------------------------- > > > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > > > can you help me ? > > > > thank you :) > > > > windoz or linux? ( I guess windoz ) > > for windoz, there appears to be a timeout ( as Comments suggest ) of > about 40seconds. > > while( count > 0 ){ > > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > > /* > > this are 20 * 2 seconds, in this time a printer (or other parallel device) > > should solv all problems like buffer full, etc > > */ > > if(errorCount++ < 20){ > > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > > continue; > > } > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > for linux, there is no implied timeout. > > if( write( fd, bytes, count ) < 0 ) > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Wed Jun 6 10:34:24 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 12:34:24 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181145205.3407.35.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> Message-ID: <4666E210.30507@gatworks.com> yves pielusenet wrote: > Thank you for your explanation :) > This timeout comes when no data has been send to the printer after > 40seconds if I well understand. But why there is such a timeout ? If I > setthe printer offline while it's printing I mustn't have an exception. > I don't understand why the "printer should solv all problems like buffer > full" in 40 seconds. If I pause the printer the buffer will not be > emptied, isn't it ? > > I not very familiar with C/C++, but it seem that the exception is thrown > only when countWritten == 0, that means no data at all has been sent. So > Is my code is good since when I intercept this exception I send all my > buffer again. There is no way that the printer receive two times same > bytes ? More technically, the function call returns and reports that 0 characters was written in this call. when 0 characters are written, it will check how many times 0 characters was written. If it has tried LESS than 20 times(errorCount), it will sleep() and try to write again. After 20 times, it wont sleep, but throw you the exception. Now suppose you are writing a 120 character line. you off-lined/paused your printer. The OS has room for 80 more characters in it's printer buffer. The WriteFile() will have a char count of 120, but on return the countWritten = 80. You still have 40 more characters to print. Since countWritten != 0, the counters: bytes += countWritten; count -= countWritten; get updated, and the Writefile now has a count of 40 characters. Since the printer is off-line, the countwritten is 0. And so the loop continues, till 40 seconds is up. As to why it is this way, i dont know ( not a windoz maven ); Also the sleep(20) in the loop is not so intuitive to suggest 2 seconds of sleep. I would have guessed 20seconds, or 20milliseconds. But go figure. BTW: Since your computer sends you error messages in French, does it curse in English? :)))) From yvespielusenet at free.fr Thu Jun 7 02:27:44 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Thu, 07 Jun 2007 10:27:44 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666E210.30507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> Message-ID: <1181204864.3501.10.camel@localhost.localdomain> Maybe in my case I should re-compile rxtx and change the code. Instead of send an exception I should display a dialog box to ask if it's printer problem or if it should trie to send bytes. Something like : while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } if(displayDialogBox("Try again to send datas ??")){ errorCount = 0; } else{ throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } } Le mercredi 06 juin 2007 ? 12:34 -0400, Uncle George a ?crit : > yves pielusenet wrote: > > Thank you for your explanation :) > > This timeout comes when no data has been send to the printer after > > 40seconds if I well understand. But why there is such a timeout ? If I > > setthe printer offline while it's printing I mustn't have an exception. > > I don't understand why the "printer should solv all problems like buffer > > full" in 40 seconds. If I pause the printer the buffer will not be > > emptied, isn't it ? > > > > I not very familiar with C/C++, but it seem that the exception is thrown > > only when countWritten == 0, that means no data at all has been sent. So > > Is my code is good since when I intercept this exception I send all my > > buffer again. There is no way that the printer receive two times same > > bytes ? > More technically, the function call returns and reports that 0 > characters was written in this call. > when 0 characters are written, it will check how many times 0 characters > was written. If it has tried LESS than 20 times(errorCount), it will > sleep() and try to write again. > After 20 times, it wont sleep, but throw you the exception. > > Now suppose you are writing a 120 character line. you off-lined/paused > your printer. The OS has room for 80 more characters in it's printer > buffer. The WriteFile() will have a char count of 120, but on return the > countWritten = 80. You still have 40 more characters to print. > Since countWritten != 0, the counters: > bytes += countWritten; > count -= countWritten; > get updated, and the Writefile now has a count of 40 characters. Since > the printer is off-line, the countwritten is 0. And so the loop > continues, till 40 seconds is up. > > As to why it is this way, i dont know ( not a windoz maven ); > Also the sleep(20) in the loop is not so intuitive to suggest 2 seconds > of sleep. I would have guessed 20seconds, or 20milliseconds. But go figure. > > BTW: Since your computer sends you error messages in French, does it > curse in English? :)))) > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 06:11:43 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 08:11:43 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181204864.3501.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> Message-ID: <4667F5FF.8070903@gatworks.com> your suggestion appears good. I dont know what displayDialogBox exactly will do, so all I can say it that it looks good. But I'd like to wait 10min before first dialog box And a 5 min wait for every dialog box there after. And since these are custom solution/choices, maybe a more exact explanation of what the issue is. if(errorCount++ < 300){ // wait 10min ( 10min * 60sec / 2 ) Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } if(displayDialogBox("Printer has Paused. Retry sending data?")){ errorCount = 150; // Wait for 5 min thereafter continue; } > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } yves pielusenet wrote: > Maybe in my case I should re-compile rxtx and change the code. Instead > of send an exception I should display a dialog box to ask if it's > printer problem or if it should trie to send bytes. Something like : > > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > > if(displayDialogBox("Try again to send datas ??")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > } > From yvespielusenet at free.fr Thu Jun 7 07:17:21 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Thu, 07 Jun 2007 15:17:21 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4667F5FF.8070903@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <4667F5FF.8070903@gatworks.com> Message-ID: <1181222241.3501.20.camel@localhost.localdomain> thank you :) 'displayDialogBox()' I think doesn't exist. It was just for the example :) But I think It should not be so complicated to display a dialog box under windows with YES/NO buttons. When yes is clicked it return 0 other it returns 1. Le jeudi 07 juin 2007 ? 08:11 -0400, Uncle George a ?crit : > your suggestion appears good. I dont know what displayDialogBox exactly > will do, so all I can say it that it looks good. > > But I'd like to wait 10min before first dialog box And a 5 min wait for > every dialog box there after. And since these are custom > solution/choices, maybe a more exact explanation of what the issue is. > > if(errorCount++ < 300){ // wait 10min ( 10min * 60sec / 2 ) > Sleep( 20 ); /* make a small pause to execute all other requests > in all other threads */ > continue; > } > > if(displayDialogBox("Printer has Paused. Retry sending data?")){ > errorCount = 150; // Wait for 5 min thereafter > continue; > } > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > > yves pielusenet wrote: > > Maybe in my case I should re-compile rxtx and change the code. Instead > > of send an exception I should display a dialog box to ask if it's > > printer problem or if it should trie to send bytes. Something like : > > > > while( count > 0 ){ > > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > > /* > > this are 20 * 2 seconds, in this time a printer (or other parallel device) > > should solv all problems like buffer full, etc > > */ > > if(errorCount++ < 20){ > > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > > continue; > > } > > > > if(displayDialogBox("Try again to send datas ??")){ > > errorCount = 0; > > } > > else{ > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > } > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 07:41:43 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 09:41:43 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181222241.3501.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <4667F5FF.8070903@gatworks.com> <1181222241.3501.20.camel@localhost.localdomain> Message-ID: <46680B17.8050109@gatworks.com> yves pielusenet wrote: > thank you :) > 'displayDialogBox()' I think doesn't exist. It was just for the > example :) too bad. Good luck. From rtrout at webbresearch.com Thu Jun 7 11:23:04 2007 From: rtrout at webbresearch.com (Robert Trout) Date: Thu, 07 Jun 2007 13:23:04 -0400 Subject: [Rxtx] Disconnected PortServer TS causes Java to hang Message-ID: <1181236984.14186.33.camel@sisyphus.DinkumSoftware.com> I'm running Linux with sun's Java 1.4.2, Java comm API 2.0, RXTX 2.0-7pre1, and the RealPort digi driver. "/dev/ttyrp00" is a RealPort device. My Java application never returns from a ComPortIdentifier.getPortIdentifier("/dev/ttyrp00") call while the Digi PortServer TS 4 is disconnected from the network. If I later re-connect the PortServer, the call returns about 30 seconds later (it's like a serial port read or write is blocking until the PortServer is re- connected). With the PortServer disconnected, minicom immediately responds with "cannot open /dev/ttyrp00: No such file or directory". I would like my Java application to behave similarly. That is, respond with an error condition instead of hanging when the PortServer is not connected. Since minicom and Java behave differently, I think this "hanging" behavior may be due to RXTX or Java? Has anyone had a similar issue? Solutions? Suggestions? Thanks, Robert From vicnevicne at gmail.com Thu Jun 7 12:16:02 2007 From: vicnevicne at gmail.com (Vicne) Date: Thu, 07 Jun 2007 20:16:02 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181204864.3501.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> Message-ID: <46684B62.7080802@gmail.com> yves pielusenet wrote: > Maybe in my case I should re-compile rxtx and change the code. Instead > of send an exception I should display a dialog box to ask if it's > printer problem or if it should trie to send bytes. Something like : > > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > > if(displayDialogBox("Try again to send datas ??")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > } > Sorry to step in without a specific solution to your problem, but I wanted to share my feeling regarding this proposal. AFAIK, it's generally considered bad practice to pop-up a prompt from a library. The main reason is that in general use, you can't guarantee that someone is actually present behind the console. Imagine a print server in a machine room, connected to a park of printers. In that case, when one printer fails, the logical behaviour would be to use an other one. If you change RxTx the way you propose, the printer queue will simply be stuck with a useless "Try again to send data ?" prompt until an administrator opens a remote connection to the print server's console and clicks "no". Second, it would create a dependency upon the existence of a graphical console (if you go the graphical "dialogBox" way). On many applications (typically server or embedded ones), the JVM is "headless" and if you try to pop-up a dialog, your app would throw an exception (at best) or just wouldn't display the prompt anywhere... Going the "text console" way is not more reliable, because on graphical environments, the text console is hidden unless explicitly requested. My advice would be to think again and find another solution. Ideas are : - make the number of retries a parameter so that you can tune it to what you think is reasonable - throw a more specific exception when the number of retries has been reached, so that a specific prompt can be shown at a higher level Anyway, if you feel that the prompt is the way to go in your case, I would at least make that prompt conditional. The least intrusive way would probably be using a system property, like if("true".equals(System.getProperty("org.rxtx.usePrompt")) && displayDialogBox("Retry sending data ?")){ errorCount = 0; } else{ throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } By default, the behaviour would remain as it is now, but you could force the prompts by defining the property at VM launch if desired. (for example : java.exe -Dorg.rxtx.usePrompt=true myApp) Also, you seemed to say you wanted the printer to start again exactly where is stopped. It would indeed be the best way when the printer is put offline for a few seconds. On the other hand, if the printer is turned off (or the printer runs out of paper, or someone steps on the mains cable), then the only way to go back to a "stable" situation would be by printing the item (page, label, etc.) again from scratch... Just my two cents. Vicne PS : By the way, the dialog box thing is very platform dependant on the C-side, and I think the simplest way would probably be to bridge it to a Java call where you can implement it like you proposed : public boolean displayDialogBox(prompt) { return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); } From netbeans at gatworks.com Thu Jun 7 14:08:24 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 16:08:24 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46684B62.7080802@gmail.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> Message-ID: <466865B8.4060004@gatworks.com> My feeling is that the code that was suggested was for his environs ( his shop ). The issue here is that after a 40+ second wait, an exception will be thrown. But you really dont have a way of 'cancelling' all the WriteFiles() that have already occured before the exception so that your writeArray and the Commapi can backtrack to a position in which they are in sync. The main ( really mine ) concern is not to lose data, or replicate data. After 40seconds, 300 seconds, 55min, no matter how long, data should not be lost or duplicated. But as soon as the exception is thrown, that possibility exists. Maybe an event should be thrown instead? Vicne wrote: > yves pielusenet wrote: >> Maybe in my case I should re-compile rxtx and change the code. Instead >> of send an exception I should display a dialog box to ask if it's >> printer problem or if it should trie to send bytes. Something like : >> >> while( count > 0 ){ >> if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ >> /* >> this are 20 * 2 seconds, in this time a printer (or other parallel device) >> should solv all problems like buffer full, etc >> */ >> if(errorCount++ < 20){ >> Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ >> continue; >> } >> >> if(displayDialogBox("Try again to send datas ??")){ >> errorCount = 0; >> } >> else{ >> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >> break; >> } >> } >> > > Sorry to step in without a specific solution to your problem, but I > wanted to share my feeling regarding this proposal. AFAIK, it's > generally considered bad practice to pop-up a prompt from a library. > The main reason is that in general use, you can't guarantee that > someone is actually present behind the console. Imagine a print server > in a machine room, connected to a park of printers. In that case, when > one printer fails, the logical behaviour would be to use an other one. > If you change RxTx the way you propose, the printer queue will simply be > stuck with a useless "Try again to send data ?" prompt until an > administrator opens a remote connection to the print server's console > and clicks "no". > Second, it would create a dependency upon the existence of a > graphical console (if you go the graphical "dialogBox" way). On many > applications (typically server or embedded ones), the JVM is "headless" > and if you try to pop-up a dialog, your app would throw an exception (at > best) or just wouldn't display the prompt anywhere... Going the "text > console" way is not more reliable, because on graphical environments, > the text console is hidden unless explicitly requested. > > My advice would be to think again and find another solution. Ideas are : > - make the number of retries a parameter so that you can tune it to what > you think is reasonable > - throw a more specific exception when the number of retries has been > reached, so that a specific prompt can be shown at a higher level > > Anyway, if you feel that the prompt is the way to go in your case, I > would at least make that prompt conditional. The least intrusive way > would probably be using a system property, like > > if("true".equals(System.getProperty("org.rxtx.usePrompt")) > && displayDialogBox("Retry sending data ?")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > > > By default, the behaviour would remain as it is now, but you could > force the prompts by defining the property at VM launch if desired. (for > example : java.exe -Dorg.rxtx.usePrompt=true myApp) > > > Also, you seemed to say you wanted the printer to start again > exactly where is stopped. It would indeed be the best way when the > printer is put offline for a few seconds. On the other hand, if the > printer is turned off (or the printer runs out of paper, or someone > steps on the mains cable), then the only way to go back to a "stable" > situation would be by printing the item (page, label, etc.) again from > scratch... > > > Just my two cents. > > > Vicne > > PS : By the way, the dialog box thing is very platform dependant on the > C-side, and I think the simplest way would probably be to bridge it to a > Java call where you can implement it like you proposed : > > public boolean displayDialogBox(prompt) { > return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", > JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); > } > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Thu Jun 7 17:48:11 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 Jun 2007 17:48:11 -0600 (MDT) Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <466865B8.4060004@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> Message-ID: An event is possible. I'm amazed this is the largest problem encountered while using the parallel code. How would the write ever exit if we throw events? Isn't this going to lead to hung applications? On Thu, 7 Jun 2007, Uncle George wrote: > My feeling is that the code that was suggested was for his environs ( > his shop ). > > The issue here is that after a 40+ second wait, an exception will be > thrown. But you really dont have a way of 'cancelling' all the > WriteFiles() that have already occured before the exception so that your > writeArray and the Commapi can backtrack to a position in which they are > in sync. > > The main ( really mine ) concern is not to lose data, or replicate data. > After 40seconds, 300 seconds, 55min, no matter how long, data should > not be lost or duplicated. But as soon as the exception is thrown, that > possibility exists. > > Maybe an event should be thrown instead? > > Vicne wrote: >> yves pielusenet wrote: >>> Maybe in my case I should re-compile rxtx and change the code. Instead >>> of send an exception I should display a dialog box to ask if it's >>> printer problem or if it should trie to send bytes. Something like : >>> >>> while( count > 0 ){ >>> if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ >>> /* >>> this are 20 * 2 seconds, in this time a printer (or other parallel device) >>> should solv all problems like buffer full, etc >>> */ >>> if(errorCount++ < 20){ >>> Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ >>> continue; >>> } >>> >>> if(displayDialogBox("Try again to send datas ??")){ >>> errorCount = 0; >>> } >>> else{ >>> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >>> break; >>> } >>> } >>> >> >> Sorry to step in without a specific solution to your problem, but I >> wanted to share my feeling regarding this proposal. AFAIK, it's >> generally considered bad practice to pop-up a prompt from a library. >> The main reason is that in general use, you can't guarantee that >> someone is actually present behind the console. Imagine a print server >> in a machine room, connected to a park of printers. In that case, when >> one printer fails, the logical behaviour would be to use an other one. >> If you change RxTx the way you propose, the printer queue will simply be >> stuck with a useless "Try again to send data ?" prompt until an >> administrator opens a remote connection to the print server's console >> and clicks "no". >> Second, it would create a dependency upon the existence of a >> graphical console (if you go the graphical "dialogBox" way). On many >> applications (typically server or embedded ones), the JVM is "headless" >> and if you try to pop-up a dialog, your app would throw an exception (at >> best) or just wouldn't display the prompt anywhere... Going the "text >> console" way is not more reliable, because on graphical environments, >> the text console is hidden unless explicitly requested. >> >> My advice would be to think again and find another solution. Ideas are : >> - make the number of retries a parameter so that you can tune it to what >> you think is reasonable >> - throw a more specific exception when the number of retries has been >> reached, so that a specific prompt can be shown at a higher level >> >> Anyway, if you feel that the prompt is the way to go in your case, I >> would at least make that prompt conditional. The least intrusive way >> would probably be using a system property, like >> >> if("true".equals(System.getProperty("org.rxtx.usePrompt")) >> && displayDialogBox("Retry sending data ?")){ >> errorCount = 0; >> } >> else{ >> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >> break; >> } >> >> >> By default, the behaviour would remain as it is now, but you could >> force the prompts by defining the property at VM launch if desired. (for >> example : java.exe -Dorg.rxtx.usePrompt=true myApp) >> >> >> Also, you seemed to say you wanted the printer to start again >> exactly where is stopped. It would indeed be the best way when the >> printer is put offline for a few seconds. On the other hand, if the >> printer is turned off (or the printer runs out of paper, or someone >> steps on the mains cable), then the only way to go back to a "stable" >> situation would be by printing the item (page, label, etc.) again from >> scratch... >> >> >> Just my two cents. >> >> >> Vicne >> >> PS : By the way, the dialog box thing is very platform dependant on the >> C-side, and I think the simplest way would probably be to bridge it to a >> Java call where you can implement it like you proposed : >> >> public boolean displayDialogBox(prompt) { >> return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", >> JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); >> } >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 19:18:51 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 21:18:51 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> Message-ID: <4668AE7B.3060409@gatworks.com> The UNIX version of writeArray is not too great either. It is possible that the write will only process some of the bytes. #else if( write( fd, bytes, count ) < 0 ) throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); #endif -------------------------------- Maybe it might be better to have the native function inform the caller of the # of characters written, then the commapi/output-buffer can be modified to reflect the #of chars written. If an exception is to be thrown, for too many loops of chars written == 0, then exception wont affect the state of the output buffer. Then a ParallelPort.restart() can be called to resume printing whats in the buffer. Trent Jarvi wrote: > An event is possible. I'm amazed this is the largest problem encountered > while using the parallel code. > > How would the write ever exit if we throw events? Isn't this going to > lead to hung applications? Sure. If you dont time out, then there is nothing that will force an EXIT from the write(). Issue is what has the OS done with the write. > > On Thu, 7 Jun 2007, Uncle George wrote: > >> My feeling is that the code that was suggested was for his environs ( >> his shop ). From yvespielusenet at free.fr Fri Jun 8 01:09:01 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Fri, 08 Jun 2007 09:09:01 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4668AE7B.3060409@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> Message-ID: <1181286541.3674.10.camel@localhost.localdomain> It is not possible that the rxtx java method write(byte[], int offset, int length) return anint which contains the number of byte really send to the printer instead of an exception ? So this is the programm which will see if all bytes have been sent. If not it can retry to send the unsended bytes. -------------------------------------------------------- int sended = 0; while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ sended += countWritten; /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } return sended; /*throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break;*/ } ... ... return countWritten; ------------------------------------------------ Le jeudi 07 juin 2007 ? 21:18 -0400, Uncle George a ?crit : > The UNIX version of writeArray is not too great either. It is possible > that the write will only process some of the bytes. > > #else > if( write( fd, bytes, count ) < 0 ) > throw_java_exception_system_msg( env, IO_EXCEPTION, > "writeArray" ); > #endif > -------------------------------- > > Maybe it might be better to have the native function inform the caller > of the # of characters written, then the commapi/output-buffer can be > modified to reflect the #of chars written. If an exception is to be > thrown, for too many loops of chars written == 0, then exception wont > affect the state of the output buffer. Then a ParallelPort.restart() can > be called to resume printing whats in the buffer. > > > Trent Jarvi wrote: > > An event is possible. I'm amazed this is the largest problem encountered > > while using the parallel code. > > > > How would the write ever exit if we throw events? Isn't this going to > > lead to hung applications? > Sure. If you dont time out, then there is nothing that will force an > EXIT from the write(). Issue is what has the OS done with the write. > > > > On Thu, 7 Jun 2007, Uncle George wrote: > > > >> My feeling is that the code that was suggested was for his environs ( > >> his shop ). > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Fri Jun 8 03:45:00 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 11:45:00 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181286541.3674.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> Message-ID: <20070608094500.GC21069@elberon.bln.de.ingenico.com> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > It is not possible that the rxtx java method write(byte[], int offset, > int length) return anint which contains the number of byte really send > to the printer instead of an exception ? > So this is the programm which will see if all bytes have been sent. If > not it can retry to send the unsended bytes. I think write() is void because in Java people love to do this since OutputStream :-) Of course on such interfaces you cannot implement something nice. If you would have a int write, you would not implement the interface and no applications expecting this interface would link/work/compile. oki, Steffen P.S.: (OT) If you propose not to implement the Java interfaces (especially not on JNI level), maybe optionally offering a wrapper that removes e.g. the write return value and so on to downgrade the powerful classic old POSIX read/write style to the modern limited Java style, then I agree :-) Same for read. Instead of things like "int avialable()" it is more powerful to have an approach as select(2) offers (to guarante the caller that read/write will not block [nothing else make sense anyway IMHO] but may read/write less bytes then requested). The caller gets full control and the higher level protocols can care about timeouts, invoking read in some loops and/or implement retransmission. On top of such an implementation, where everything is controlled, defined, guaranteed and reliable, someone could use an InputStream or OutputStream style interface. Or even better: don't use them at all :) just BTW :-) St. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From yvespielusenet at free.fr Fri Jun 8 05:52:45 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Fri, 08 Jun 2007 13:52:45 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <20070608094500.GC21069@elberon.bln.de.ingenico.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> Message-ID: <1181303565.11203.3.camel@localhost.localdomain> So maybe a better way should be to create a new Exception class which has a method "int getWrittenByte()". So the Exception should be use to send again bytes which are not printed yet. yves Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : > * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > > It is not possible that the rxtx java method write(byte[], int offset, > > int length) return anint which contains the number of byte really send > > to the printer instead of an exception ? > > So this is the programm which will see if all bytes have been sent. If > > not it can retry to send the unsended bytes. > > I think write() is void because in Java people love to do this > since OutputStream :-) Of course on such interfaces you cannot > implement something nice. If you would have a int write, you > would not implement the interface and no applications expecting > this interface would link/work/compile. > > oki, > > Steffen > > P.S.: (OT) > If you propose not to implement the Java interfaces (especially > not on JNI level), maybe optionally offering a wrapper that > removes e.g. the write return value and so on to downgrade the > powerful classic old POSIX read/write style to the modern limited > Java style, then I agree :-) Same for read. Instead of things > like "int avialable()" it is more powerful to have an approach as > select(2) offers (to guarante the caller that read/write will not > block [nothing else make sense anyway IMHO] but may read/write > less bytes then requested). The caller gets full control and the > higher level protocols can care about timeouts, invoking read in > some loops and/or implement retransmission. On top of such an > implementation, where everything is controlled, defined, > guaranteed and reliable, someone could use an InputStream or > OutputStream style interface. Or even better: don't use them at > all :) just BTW :-) > St. > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > 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. > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > 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. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Fri Jun 8 06:46:21 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 08:46:21 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181303565.11203.3.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> Message-ID: <46694F9D.5080501@gatworks.com> It seems that with outputstream.write(b[]), you become terribly uncoordinated as soon as an exception is thrown. Docs do not say what happens to the data. Yet from a practicable point of view, one would like to know if the write was accepted in-full, or rejected before any writes. There are no in betweens, as partial writes are not reportable. So for an outputstream.write(), in order for it to return, the full write request has to be taken, and stored in an internal output buffer. If there is no room, the write() is suspended, till there is room. Or throw's an IOException( "no room in buffer") ; As the select() loop for write reports buffer room avail, then more of the internal buffer is sent to the printer. yves pielusenet wrote: > So maybe a better way should be to create a new Exception class which > has a method "int getWrittenByte()". So the Exception should be use to > send again bytes which are not printed yet. > > yves > > Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : >> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: >>> It is not possible that the rxtx java method write(byte[], int offset, >>> int length) return anint which contains the number of byte really send >>> to the printer instead of an exception ? >>> So this is the programm which will see if all bytes have been sent. If >>> not it can retry to send the unsended bytes. >> I think write() is void because in Java people love to do this >> since OutputStream :-) Of course on such interfaces you cannot >> implement something nice. If you would have a int write, you >> would not implement the interface and no applications expecting >> this interface would link/work/compile. >> >> oki, >> >> Steffen >> >> P.S.: (OT) >> If you propose not to implement the Java interfaces (especially >> not on JNI level), maybe optionally offering a wrapper that >> removes e.g. the write return value and so on to downgrade the >> powerful classic old POSIX read/write style to the modern limited >> Java style, then I agree :-) Same for read. Instead of things >> like "int avialable()" it is more powerful to have an approach as >> select(2) offers (to guarante the caller that read/write will not >> block [nothing else make sense anyway IMHO] but may read/write >> less bytes then requested). The caller gets full control and the >> higher level protocols can care about timeouts, invoking read in >> some loops and/or implement retransmission. On top of such an >> implementation, where everything is controlled, defined, >> guaranteed and reliable, someone could use an InputStream or >> OutputStream style interface. Or even better: don't use them at >> all :) just BTW :-) >> St. >> >> About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. >> 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. >> >> About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. >> 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. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From Steffen.DETTMER at ingenico.com Fri Jun 8 08:12:18 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 16:12:18 +0200 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <46694F9D.5080501@gatworks.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: <20070608141218.GE21069@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 08:46 -0400: > It seems that with outputstream.write(b[]), you become terribly > uncoordinated as soon as an exception is thrown. Docs do not say what > happens to the data. (yes, so avoiding it seems to be good :)) > Yet from a practicable point of view, one would like to know if the > write was accepted in-full, or rejected before any writes. There are no > in betweens, as partial writes are not reportable. (which is an artificial API limitation. I never understood how this happend when they invented JDK because the well-known BSD socket API and thus [probably] WinSock does this correct, but anyway) > So for an outputstream.write(), in order for it to return, the full > write request has to be taken, and stored in an internal output buffer. > If there is no room, the write() is suspended, till there is room. Or > throw's an IOException( "no room in buffer") ; As the select() loop for > write reports buffer room avail, then more of the internal buffer is > sent to the printer. yes, might be good in case of a printer. May be horrible in case of PPP/TCP or some other transmission control protocol which may e.g. repeat data or even omit parts of it (e.g. internet realtime radio station broadcasting)... So I think the idea of "int write" (e.g. BSD sockets, linux files and so on) still is the best. A clean API / implementation should guarantee and allow implementations (users) to rely on that; assumptions and automatic background-sending and so on may look pragmatic and may even work on the first look, but may fail in other situations. BTW, if e.g. BSD socket API is known, why not simply copy it (until something better is invented :)) instead of fiddling around with JDK APIs? anyway, have a nice weekend everyone :-) oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Fri Jun 8 08:55:56 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 10:55:56 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070608141218.GE21069@elberon.bln.de.ingenico.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> Message-ID: <46696DFC.7000801@gatworks.com> >> write reports buffer room avail, then more of the internal buffer is >> sent to the printer. > > yes, might be good in case of a printer. May be horrible in case > of PPP/TCP or some other transmission control protocol which > may e.g. repeat data or even omit parts of it (e.g. internet > realtime radio station broadcasting)... So I think the idea of > "int write" (e.g. BSD sockets, linux files and so on) still is > the best. A clean API / implementation should guarantee and allow > implementations (users) to rely on that; assumptions and > automatic background-sending and so on may look pragmatic and may > even work on the first look, but may fail in other situations. > BTW, if e.g. BSD socket API is known, why not simply copy it > (until something better is invented :)) instead of fiddling > around with JDK APIs? But we were talking about the Parallel Port, and the transmission of data over the commapi/parallel-port schema. There isn't much in bi-directional software communication. Its a simple write one byte at a time interface. I'm not looking to change the comm-api. I'm just looking to alter the interaction between the Native ParallelPort functions, and the java ParallelPort functions that call them. This might be more readily doable than to get a committee to re-specify java-API specs. BTW: Whats is off-topic? ( help: not looking for def of off-topic ) From j.kenneth.gentle at acm.org Fri Jun 8 08:58:59 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Fri, 08 Jun 2007 10:58:59 -0400 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <20070608141218.GE21069@elberon.bln.de.ingenico.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> Message-ID: <200706081459.l58Ex5rA019991@qbang.org> Perhaps it is a bit late to jump in on this one, but here goes anyway. If the solutions all seem to "break" the contract with "java.io.outputstream", then, as noted, that may not be the appropriate contract. At the risk of being heretical, JDK1.4 introduced the "nio" package to address some of the compatibility issues with C apis mentioned in previous posts. The interface "java.nio.channels.WriteableByteChannel" defines the following single method: int write(ByteBuffer source); int, strangely enough, is the actual number of bytes written. So, if RXTX as written, against the JavaCOMM api and OutputStream, doesn't do what we want, how about writing a different set of bindings using the java.nio classes and as much of the underlying native code as possible. Note that just because the java.nio.channels.WriteableByteChannel sends back a result, OutputStream.write doesn't have to - and they could both call the same underlying native code. My 2 cents - maybe not worth even that... Ken From netbeans at gatworks.com Fri Jun 8 10:37:28 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 12:37:28 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <200706081459.l58Ex5rA019991@qbang.org> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> Message-ID: <466985C8.8000505@gatworks.com> Ken Gentle wrote: > Perhaps it is a bit late to jump in on this one, but here goes anyway. Common in, the waters fine. > > If the solutions all seem to "break" the contract with > "java.io.outputstream", then, as noted, that may not be the > appropriate contract. > How would the contract be broken? The machinery underneath is handling the contract. From j.kenneth.gentle at acm.org Fri Jun 8 10:48:01 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Fri, 08 Jun 2007 12:48:01 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466985C8.8000505@gatworks.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> Message-ID: <200706081648.l58Gm7YA022904@qbang.org> At 12:37 2007-06-08, you wrote: >Ken Gentle wrote: > > > > If the solutions all seem to "break" the contract with > > "java.io.outputstream", then, as noted, that may not be the > > appropriate contract. > > >How would the contract be broken? The machinery underneath is handling >the contract. It seems that a lot of the discussion has been about not only the timeout and being able to adjust it in the "machinery layer", but also about knowing in the Java layer, in the event of a timeout or exception, how many characters have been written to the device. An OutputStream won't ever do this with out an extension and including a return value "breaks" the contract, right? So, go with a Java IO api that *does* return the number of bytes written, out of the NIO package. I know it doesn't allow for a strict implementation of the JavaCOMM API - however, using NIO classes in place of the IO classes isn't that big a break and would allow those applications that need such information a way to get it. Maybe I'm misunderstanding the problem... Ken From netbeans at gatworks.com Fri Jun 8 11:24:14 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 13:24:14 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <200706081648.l58Gm7YA022904@qbang.org> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> Message-ID: <466990BE.7040100@gatworks.com> Ken Gentle wrote: An > OutputStream won't ever do this with out an extension and including a > return value "breaks" the contract, right? > i was not thinking of change the API to OutputSream. Are there specs for how output stream should work internally? for instance: String data = "Hello this is a line of data"; Outputstream.write( data.getbytes() ); ParallelPort.suspend(); int free = ParallelPort.getoutputbufferfree(); There is a symbiotic relationship between outputstream and the functionality of ParallelPort. From Steffen.DETTMER at ingenico.com Fri Jun 8 11:15:39 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 19:15:39 +0200 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <200706081459.l58Ex5rA019991@qbang.org> References: <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> Message-ID: <20070608171539.GK21069@elberon.bln.de.ingenico.com> * Ken Gentle wrote on Fri, Jun 08, 2007 at 10:58 -0400: > If the solutions all seem to "break" the contract with > "java.io.outputstream", then, as noted, that may not be the > appropriate contract. > > At the risk of being heretical, JDK1.4 introduced the "nio" package > to address some of the compatibility issues with C apis mentioned in > previous posts. The interface > "java.nio.channels.WriteableByteChannel" defines the following single method: > > int write(ByteBuffer source); > > int, strangely enough, is the actual number of bytes written. Yes, AFAIK one of the motivations for the NIO interface was, that the JDK-1.3 APIs (InputStream, e.g.) were not powerfull enough, especially for multi-connection-TCP servers or so. I don't know much about it but I've heard of a project where NIO usage was removed because of stability issues in multi-threaded environments and performance limitations under some circumstances. IIRC the "nio.ByteBuffer" is something very special (namely something you cannot implement in Java, it is "magic" or part of the language itself). Not sure if this is such a great idea (but for performance in the end sometimes heavy prices must be paid) :) > So, if RXTX as written, against the JavaCOMM api and OutputStream, > doesn't do what we want, how about writing a different set of > bindings using the java.nio classes and as much of the underlying > native code as possible. Yes, this would be an idea: use a full-featured interface on JNI, and, if wanted, deliver some wrappers converting this to a less-featured Java-compliant interface. However, powerful things as e.g. "select" are difficult to "emulate" if you are e.g. on some (older?) windows. But if you expose the full-featured APIs, you need to emulate them full-featured, theoretically. In the end it depends what you do on the serial line. If you just want to talk to a modem, then you may not need precise timeouts. But if you need to implement complexer protocols which define response times and timeouts, you may quickly get into difficulties. For instance, AFAIK, rxtx 1.7.2 (?) for windows is very messy with timeouts (there is a maximum, higher values are truncated; resolution is 100ms only; the function may take up to twice the timeout because internally it may be called twice). Probably for most people this is OK, but probably not for all. But having precise timeouts should be OK for all :-) Well, in the end it is nice to wish but somewhat hard to implement (many platforms, connections, USB, BlueTooth, whatever). oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Steffen.DETTMER at ingenico.com Fri Jun 8 11:04:22 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 19:04:22 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <46696DFC.7000801@gatworks.com> References: <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <46696DFC.7000801@gatworks.com> Message-ID: <20070608170422.GJ21069@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 10:55 -0400: > > BTW, if e.g. BSD socket API is known, why not simply copy it > > (until something better is invented :)) instead of fiddling > > around with JDK APIs? > > But we were talking about the Parallel Port, and the > transmission of data over the commapi/parallel-port schema. > There isn't much in bi-directional software communication. Its > a simple write one byte at a time interface. First, there are things like PLIP (http://en.wikipedia.org/wiki/Plip) - well, probably not widely used, sure ;) Second, I think if there is a good simple API known to support all that (with known "best practices") or so and there is no forcing need to invent a new one, why not simply using it? > I'm not looking to change the comm-api. I'm just looking to > alter the interaction between the Native ParallelPort > functions, and the java ParallelPort functions that call them. Ahh, yes. I think this is what I tried to ask. Having an usable JNI interface and on top (in pure java) some wrapper to InputStream or whatever could be done (e.g. by ignoring the return value of write or throwing if != length). Developers could then use the full-featured (non-JAVA-standard) API or select among various wrappers (as InputStream). > This might be more readily doable than to get a committee to > re-specify java-API specs. Yes, of course. I'm afraid that the Java APIs change regularily, but still yet with limited success it seems, so maybe they get it in one of the next iterations; who knows, maybe Java-9 has a BSD-like socket API :) SCNR. > BTW: Whats is off-topic? ( help: not looking for def of > off-topic ) I think I started some "re-specify java-API specs" which was OT probably. oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From lists at iDIAcomputing.com Fri Jun 8 18:48:54 2007 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Fri, 08 Jun 2007 20:48:54 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46684B62.7080802@gmail.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> Message-ID: <4669F8F6.3040101@iDIAcomputing.com> Vicne wrote: > Sorry to step in without a specific solution to your problem, but I > wanted to share my feeling regarding this proposal. AFAIK, it's > generally considered bad practice to pop-up a prompt from a library. ... > > My advice would be to think again and find another solution. Ideas are : > - make the number of retries a parameter so that you can tune it to what > you think is reasonable > - throw a more specific exception when the number of retries has been > reached, so that a specific prompt can be shown at a higher level You could also allow the client code to register a callback class which returns a boolean indicating whether to retry or cancel. This callback class could pop up a dialog, if appropriate, or follow some preset policy, or.... - George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From joachim at buechse.ch Sat Jun 9 09:43:16 2007 From: joachim at buechse.ch (Joachim Buechse) Date: Sat, 9 Jun 2007 17:43:16 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46694F9D.5080501@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: You should not forget, that in the case of an exception it may not even be known what happened to the data. You have a kernel buffer, outgoing chip buffer, incoming chip buffer, etc. So of course, it would be nice to know up to which point data was correctly processed, but this feedback does not exist on the hardware or protocol level and hence can in general not be magicly created on the software level... Regards, Joachim On 08.06.2007, at 14:46, Uncle George wrote: > It seems that with outputstream.write(b[]), you become terribly > uncoordinated as soon as an exception is thrown. Docs do not say what > happens to the data. > > Yet from a practicable point of view, one would like to know if the > write was accepted in-full, or rejected before any writes. There > are no > in betweens, as partial writes are not reportable. > > So for an outputstream.write(), in order for it to return, the full > write request has to be taken, and stored in an internal output > buffer. > If there is no room, the write() is suspended, till there is room. Or > throw's an IOException( "no room in buffer") ; As the select() loop > for > write reports buffer room avail, then more of the internal buffer is > sent to the printer. > > > > yves pielusenet wrote: >> So maybe a better way should be to create a new Exception class which >> has a method "int getWrittenByte()". So the Exception should be >> use to >> send again bytes which are not printed yet. >> >> yves >> >> Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : >>> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: >>>> It is not possible that the rxtx java method write(byte[], int >>>> offset, >>>> int length) return anint which contains the number of byte >>>> really send >>>> to the printer instead of an exception ? >>>> So this is the programm which will see if all bytes have been >>>> sent. If >>>> not it can retry to send the unsended bytes. >>> I think write() is void because in Java people love to do this >>> since OutputStream :-) Of course on such interfaces you cannot >>> implement something nice. If you would have a int write, you >>> would not implement the interface and no applications expecting >>> this interface would link/work/compile. >>> >>> oki, >>> >>> Steffen >>> >>> P.S.: (OT) >>> If you propose not to implement the Java interfaces (especially >>> not on JNI level), maybe optionally offering a wrapper that >>> removes e.g. the write return value and so on to downgrade the >>> powerful classic old POSIX read/write style to the modern limited >>> Java style, then I agree :-) Same for read. Instead of things >>> like "int avialable()" it is more powerful to have an approach as >>> select(2) offers (to guarante the caller that read/write will not >>> block [nothing else make sense anyway IMHO] but may read/write >>> less bytes then requested). The caller gets full control and the >>> higher level protocols can care about timeouts, invoking read in >>> some loops and/or implement retransmission. On top of such an >>> implementation, where everything is controlled, defined, >>> guaranteed and reliable, someone could use an InputStream or >>> OutputStream style interface. Or even better: don't use them at >>> all :) just BTW :-) >>> St. >>> >>> About Ingenico Throughout the world businesses rely on Ingenico >>> for secure and expedient electronic transaction acceptance. >>> Ingenico products leverage proven technology, established >>> standards and unparalleled ergonomics to provide optimal >>> reliability, versatility and usability. This comprehensive range >>> of products is complemented by a global array of services and >>> partnerships, enabling businesses in a number of vertical sectors >>> to accept transactions anywhere their business takes them. >>> 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. >>> >>> About Ingenico Throughout the world businesses rely on Ingenico >>> for secure and expedient electronic transaction acceptance. >>> Ingenico products leverage proven technology, established >>> standards and unparalleled ergonomics to provide optimal >>> reliability, versatility and usability. This comprehensive range >>> of products is complemented by a global array of services and >>> partnerships, enabling businesses in a number of vertical sectors >>> to accept transactions anywhere their business takes them. >>> 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. >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx 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 yvespielusenet at free.fr Mon Jun 11 03:15:12 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Mon, 11 Jun 2007 11:15:12 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: <1181553312.8335.14.camel@localhost.localdomain> So can someone tell a solution for my problem :( Must I say to the user to not put the printer off-line ? I can't since he has to do some pauses, verify print, paper conditioning etc... How do other people ? Before I use the parport librarry to read port status : http://www.geocities.com/Juanga69/parport/ (which doesn't work on windows XP) And I send data into the file LPT1 I use to have no problem when printer was disabled. thanks -- yves piel Le samedi 09 juin 2007 ? 17:43 +0200, Joachim Buechse a ?crit : > You should not forget, that in the case of an exception it may not > even be known what happened to the data. > > You have a kernel buffer, outgoing chip buffer, incoming chip buffer, > etc. So of course, it would be nice to know up to which point data > was correctly processed, but this feedback does not exist on the > hardware or protocol level and hence can in general not be magicly > created on the software level... > > Regards, > Joachim > > On 08.06.2007, at 14:46, Uncle George wrote: > > > It seems that with outputstream.write(b[]), you become terribly > > uncoordinated as soon as an exception is thrown. Docs do not say what > > happens to the data. > > > > Yet from a practicable point of view, one would like to know if the > > write was accepted in-full, or rejected before any writes. There > > are no > > in betweens, as partial writes are not reportable. > > > > So for an outputstream.write(), in order for it to return, the full > > write request has to be taken, and stored in an internal output > > buffer. > > If there is no room, the write() is suspended, till there is room. Or > > throw's an IOException( "no room in buffer") ; As the select() loop > > for > > write reports buffer room avail, then more of the internal buffer is > > sent to the printer. > > > > > > > > yves pielusenet wrote: > >> So maybe a better way should be to create a new Exception class which > >> has a method "int getWrittenByte()". So the Exception should be > >> use to > >> send again bytes which are not printed yet. > >> > >> yves > >> > >> Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : > >>> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > >>>> It is not possible that the rxtx java method write(byte[], int > >>>> offset, > >>>> int length) return anint which contains the number of byte > >>>> really send > >>>> to the printer instead of an exception ? > >>>> So this is the programm which will see if all bytes have been > >>>> sent. If > >>>> not it can retry to send the unsended bytes. > >>> I think write() is void because in Java people love to do this > >>> since OutputStream :-) Of course on such interfaces you cannot > >>> implement something nice. If you would have a int write, you > >>> would not implement the interface and no applications expecting > >>> this interface would link/work/compile. > >>> > >>> oki, > >>> > >>> Steffen > >>> > >>> P.S.: (OT) > >>> If you propose not to implement the Java interfaces (especially > >>> not on JNI level), maybe optionally offering a wrapper that > >>> removes e.g. the write return value and so on to downgrade the > >>> powerful classic old POSIX read/write style to the modern limited > >>> Java style, then I agree :-) Same for read. Instead of things > >>> like "int avialable()" it is more powerful to have an approach as > >>> select(2) offers (to guarante the caller that read/write will not > >>> block [nothing else make sense anyway IMHO] but may read/write > >>> less bytes then requested). The caller gets full control and the > >>> higher level protocols can care about timeouts, invoking read in > >>> some loops and/or implement retransmission. On top of such an > >>> implementation, where everything is controlled, defined, > >>> guaranteed and reliable, someone could use an InputStream or > >>> OutputStream style interface. Or even better: don't use them at > >>> all :) just BTW :-) > >>> St. > >>> > >>> About Ingenico Throughout the world businesses rely on Ingenico > >>> for secure and expedient electronic transaction acceptance. > >>> Ingenico products leverage proven technology, established > >>> standards and unparalleled ergonomics to provide optimal > >>> reliability, versatility and usability. This comprehensive range > >>> of products is complemented by a global array of services and > >>> partnerships, enabling businesses in a number of vertical sectors > >>> to accept transactions anywhere their business takes them. > >>> 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. > >>> > >>> About Ingenico Throughout the world businesses rely on Ingenico > >>> for secure and expedient electronic transaction acceptance. > >>> Ingenico products leverage proven technology, established > >>> standards and unparalleled ergonomics to provide optimal > >>> reliability, versatility and usability. This comprehensive range > >>> of products is complemented by a global array of services and > >>> partnerships, enabling businesses in a number of vertical sectors > >>> to accept transactions anywhere their business takes them. > >>> 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. > >>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx 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 > From Steffen.DETTMER at ingenico.com Mon Jun 11 03:56:18 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 11:56:18 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466990BE.7040100@gatworks.com> References: <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> Message-ID: <20070611095618.GA10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 13:24 -0400: > i was not thinking of change the API to OutputSream. Then I think either someone uses OutputStream (and has no reliable information about incomplete writes) or someone uses somethink else. > Are there specs for how output stream should work internally? > > for instance: > String data = "Hello this is a line of data"; > Outputstream.write( data.getbytes() ); > ParallelPort.suspend(); > int free = ParallelPort.getoutputbufferfree(); > > There is a symbiotic relationship between outputstream and the > functionality of ParallelPort. If you need OutputStream "plus something else", in short you're needing "something else". Personally I dislike the code above a lot. The stream "looks" like if it would be an OutputStream, but in fact it isn't. You need to call getoutputbufferfree later to check if write succeeded (but OutputStream promises that write succeedes synchronous, blocking, or throws an exception). So it is not an OutputStream. No application written for OutputStreams would work without change (because it won't know getoutputbufferfree at all). It is not abstracted from ParallelPort. I think this would be wrong. Then I think an alternative interface instead is better. Let's assume we had some "connection" (to distinguish between OutputStreams and Channels). Then why not working as on a file handle in POSIX: do { // ... select maybe using timer ... readyForWrite = ... if (readyForWrite) { int writtenBytes = connection.write(toWrite); toWrite.remove(0, writtenBytes); } while(readyForWrite && toWrite.length > 0); I think, having such a write isn't the big problem. I think, the difficult thing is around "select" - however this would look like. It should be OO, typesafe, performant, supporting multiple connections/channels/streams in various modes and should be orthogonal to other functionalities. Of course, this heavily depends on what the application is doing; for a simple situation (like reading a small, mandatory file from a local disk) this would be to uncomfortable (and offering unneeded features only). just BTW :) oki, Steffen -- // Modeline for VIM. Please don't remove. // (Help: autoindent, expandtab, shiftwidth=4, tabstop=4, textwidth=75) // vi: set ai et sw=4 ts=4 tw=75 ft=java: About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Mon Jun 11 05:38:33 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 07:38:33 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611095618.GA10821@elberon.bln.de.ingenico.com> References: <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> Message-ID: <466D3439.4020805@gatworks.com> Steffen DETTMER wrote: > (but OutputStream promises that write > succeedes synchronous, blocking, or throws an exception). Where is it so written? From Steffen.DETTMER at ingenico.com Mon Jun 11 06:36:50 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 14:36:50 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466D3439.4020805@gatworks.com> References: <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> <466D3439.4020805@gatworks.com> Message-ID: <20070611123650.GI10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Mon, Jun 11, 2007 at 07:38 -0400: > Steffen DETTMER wrote: > > > (but OutputStream promises that write > > succeedes synchronous, blocking, or throws an exception). > > Where is it so written? Now, as you ask, I think it is not written that clearly but follows from specification. mmm... Am I wrong? I understand the API doc in this way: * http://java.sun.com/j2se/1.4.2/docs/api/java/io/OutputStream.html#write(byte[]) > public void write(byte[] b) > throws IOException > > Writes b.length bytes from the specified byte array to this > output stream. The general contract for write(b) is that > it should have exactly the same effect as the call write(b, > 0, b.length). > > Parameters: > b - the data. > Throws: > IOException - if an I/O error occurs. > See Also: > write(byte[], int, int) and there is: > public void write(byte[] b, > int off, > int len) > throws IOException > > Writes len bytes from the specified byte array starting at > offset off to this output stream. The general contract for > write(b, off, len) is that some of the bytes in the array b > are written to the output stream in order; element b[off] > is the first byte written and b[off+len-1] is the last byte > written by this operation. > > The write method of OutputStream calls the write method of > one argument on each of the bytes to be written out. > Subclasses are encouraged to override this method and > provide a more efficient implementation. > > If b is null, a NullPointerException is thrown. > > If off is negative, or len is negative, or off+len is > greater than the length of the array b, then an > IndexOutOfBoundsException is thrown. > > Parameters: > b - the data. > off - the start offset in the data. > len - the number of bytes to write. > Throws: > IOException - if an I/O error occurs. In particular, an > IOException is thrown if the output stream is closed. In general, any specialisation (derived child class) must comform to this. So write in the end is specified (!) as "The write method ... calls the write method ... on each of the bytes to be written out". This is what must be implemented by ANY OutputStream. Of course, there is: "Subclasses are encouraged to override this method and provide a more efficient implementation." which IMHO does not contradict - the more efficient must behave in exactly the same way of course (just wasting less resources than a simple byte-by-byte write). So it does not matter here I think. The write that finally defines the behavior tells basically: > "Writes the specified byte to this output stream. The general > contract for write is that one byte is written to the output > stream. " > > Throws: > IOException - if an I/O error occurs. which IMHO is another way of saying "write writes the byte immediately and returns on success (only), otherwise an exception is thrown". Especially it cannot happen that zero bytes are written (i.e. the specified byte is NOT written) without an exception. So by this write must be synchronous and blocking, because otherwise it could not reliably know if an asynchronous operation will succeede or not (some getAsyncResult or so would be needed). Since write(byte[]) does this for each byte (or with a behavior beeing exactly the same as if it would do), I think this means that the write(byte[]) succeedes synchronous/blocking or throws an exception. Did I an error in reasoning or confused something or so? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From j.kenneth.gentle at acm.org Mon Jun 11 06:51:25 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 11 Jun 2007 08:51:25 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611123650.GI10821@elberon.bln.de.ingenico.com> References: <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> <466D3439.4020805@gatworks.com> <20070611123650.GI10821@elberon.bln.de.ingenico.com> Message-ID: <200706111251.l5BCpS9T017831@qbang.org> It is as Steffen describes. "InputStream" and "OutputStream" are inherently synchronous (which is why so many java programs resort to threads to use them). Anything outside of this "contract" is *not* an InputStream or OutputStream. That is why there is a new package for things that don't behave like the old *Stream classes - the NIO package. If you look carefully at the IO package, you'll note that almost all the classes are _Decorator_ pattern implementations of the *Stream classes - and the interface presents the _same_ behavior to the calling code in all cases - a synchronous operation that completes successfully or throws an exception (with the one exception of "read" that returns a "-1" on end-of-stream. I know I've read this numerous times - I'd suggest checking the Language Spec or one of the books by Bloch or Gosling. Ken At 08:36 2007-06-11, you wrote: >* Uncle George wrote on Mon, Jun 11, 2007 at 07:38 -0400: > > Steffen DETTMER wrote: > > > > > (but OutputStream promises that write > > > succeedes synchronous, blocking, or throws an exception). > > > > Where is it so written? > >Now, as you ask, I think it is not written that clearly but >follows from specification. mmm... > >Am I wrong? > >I understand the API doc in this way: > >* >http://java.sun.com/j2se/1.4.2/docs/api/java/io/OutputStream.html#write(byte[]) > > public void write(byte[] b) > > throws IOException > > > > Writes b.length bytes from the specified byte array to this > > output stream. The general contract for write(b) is that > > it should have exactly the same effect as the call write(b, > > 0, b.length). > > > > Parameters: > > b - the data. > > Throws: > > IOException - if an I/O error occurs. > > See Also: > > write(byte[], int, int) > > >and there is: > > > > public void write(byte[] b, > > int off, > > int len) > > throws IOException > > > > Writes len bytes from the specified byte array starting at > > offset off to this output stream. The general contract for > > write(b, off, len) is that some of the bytes in the array b > > are written to the output stream in order; element b[off] > > is the first byte written and b[off+len-1] is the last byte > > written by this operation. > > > > The write method of OutputStream calls the write method of > > one argument on each of the bytes to be written out. > > Subclasses are encouraged to override this method and > > provide a more efficient implementation. > > > > If b is null, a NullPointerException is thrown. > > > > If off is negative, or len is negative, or off+len is > > greater than the length of the array b, then an > > IndexOutOfBoundsException is thrown. > > > > Parameters: > > b - the data. > > off - the start offset in the data. > > len - the number of bytes to write. > > Throws: > > IOException - if an I/O error occurs. In particular, an > > IOException is thrown if the output stream is closed. > > >In general, any specialisation (derived child class) must comform >to this. So write in the end is specified (!) as "The write >method ... calls the write method ... on each of the bytes to be >written out". This is what must be implemented by ANY >OutputStream. > >Of course, there is: "Subclasses are encouraged to override this >method and provide a more efficient implementation." which IMHO >does not contradict - the more efficient must behave in exactly >the same way of course (just wasting less resources than a simple >byte-by-byte write). So it does not matter here I think. > > > >The write that finally defines the behavior tells basically: > > > "Writes the specified byte to this output stream. The general > > contract for write is that one byte is written to the output > > stream. " > > > > Throws: > > IOException - if an I/O error occurs. > > >which IMHO is another way of saying "write writes the byte >immediately and returns on success (only), otherwise an exception >is thrown". Especially it cannot happen that zero bytes are >written (i.e. the specified byte is NOT written) without an >exception. So by this write must be synchronous and blocking, >because otherwise it could not reliably know if an asynchronous >operation will succeede or not (some getAsyncResult or so would >be needed). > >Since write(byte[]) does this for each byte (or with a behavior >beeing exactly the same as if it would do), I think this means >that the write(byte[]) succeedes synchronous/blocking or throws >an exception. > >Did I an error in reasoning or confused something or so? > >oki, > >Steffen > >About Ingenico Throughout the world businesses rely on Ingenico for >secure and expedient electronic transaction acceptance. Ingenico >products leverage proven technology, established standards and >unparalleled ergonomics to provide optimal reliability, versatility >and usability. This comprehensive range of products is complemented >by a global array of services and partnerships, enabling businesses >in a number of vertical sectors to accept transactions anywhere >their business takes them. >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. > >About Ingenico Throughout the world businesses rely on Ingenico for >secure and expedient electronic transaction acceptance. Ingenico >products leverage proven technology, established standards and >unparalleled ergonomics to provide optimal reliability, versatility >and usability. This comprehensive range of products is complemented >by a global array of services and partnerships, enabling businesses >in a number of vertical sectors to accept transactions anywhere >their business takes them. >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. > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From alesinskyy at googlemail.com Mon Jun 11 07:25:33 2007 From: alesinskyy at googlemail.com (Oleksandr Alesinskyy) Date: Mon, 11 Jun 2007 15:25:33 +0200 Subject: [Rxtx] [OT] select :-) Message-ID: Sorry, but I have to disagree with following statement: "So write in the end is specified (!) as "The write method ... calls the write method ... on each of the bytes to be written out". This is what must be implemented by ANY OutputStream.". This is not part of the specification or contract, it is just revealed implementation detail of the OutputStream. It is not stated anywhere that behavoiur of derived classes shall conform with this one. Statement concerning "synchronous" nature of the output stream is invalid as well. Really synchronous stream does not require flush() but OutputStream has it. From Steffen.DETTMER at ingenico.com Mon Jun 11 08:21:16 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 16:21:16 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: Message-ID: <20070611142116.GN10821@elberon.bln.de.ingenico.com> * Oleksandr Alesinskyy wrote on Mon, Jun 11, 2007 at 15:25 +0200: > Sorry, but I have to disagree with following statement: > "So write in the end is specified (!) as "The write > method ... calls the write method ... on each of the bytes to be > written out". This is what must be implemented by ANY > OutputStream.". > > This is not part of the specification or contract, it is just > revealed implementation detail of the OutputStream. It is not > stated anywhere that behavoiur of derived classes shall conform > with this one. (I didn't meant that the implementation must really write byte by byte, but that it must "look as if it would do" - because all implementations of OutputStream must "look" in the same way [which is another way of saying "do abstract" I think]) I think the API doc is not "revealing implementation details" but it is the *specification* of that interface and derivations must (should) conform to this specification. Isn't this the idea of interfaces? A function that expects an OutputStream should work on ANY OutputStream, shouldn't it? just kidding: I mean, what would be the point in implementing a checksum function as OutputStream.write which throws its result as IOException? Or which requires to call close() as very first operation to tell that the application is about to transmit confidential data? :-) > Statement concerning "synchronous" nature of the output stream > is invalid as well. Really synchronous stream does not require > flush() but OutputStream has it. ahh, interesting point! I think this is another bug in the API. flush() is wrong. Because write specifies "The general contract for write is that one byte is written to the output stream." but not "a byte may be written or buffered". Actually, an application would need to call flush() after each write (or bunch of write calls) to ensure that write really did something otherwise I think. I didn't found in the spec of OutputStream that it would be required to call flush(). This should mean that calling flush is not required which in turn leads to the conclusion that write must be synchrous (private threads are forbidden because not specified :)) which in turn leads to the conclusion that flush() is not needed at all... I mean, what if someone would only store in write and do the "real write" in flush() and never else? An application could write in one stream and read on another one (e.g. in bidirectional communication) and would never get anything back, because nothing was actually written because no flush was called? Then someone could even think that on error in some write the data could remain buffered AND throw an exception, retrying to send the data in the next write. Ohh, and if there would be some message number inside, and underlaying write (e.g. a protocol offering InputStream/OutputStream) would check this and throw "DuplicatedMessageNumber" the stream would only throw it again and again beeing unusable... In short: I have no clue how someone could be able to implement an asynchrounos write (which is realiable and correct) without beeing specific to anything which is not specified by OutputStream. Well, I think in the end OutputStream was not intended for such communication or protocol implementations - but to read a local disk file or so. In case of I/O errors usually you can abort your application and change the hard disk :-) oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Bob_Jacobsen at lbl.gov Mon Jun 11 09:32:23 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Mon, 11 Jun 2007 08:32:23 -0700 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611142116.GN10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> Message-ID: At 4:21 PM +0200 6/11/07, Steffen DETTMER wrote: > > Statement concerning "synchronous" nature of the output stream >> is invalid as well. Really synchronous stream does not require >> flush() but OutputStream has it. > >ahh, interesting point! > >I think this is another bug in the API. flush() is wrong. Because >write specifies "The general contract for write is that one byte >is written to the output stream." but not "a byte may be written >or buffered". > >Actually, an application would need to call flush() after each >write (or bunch of write calls) to ensure that write really did >something otherwise I think. OutputStreams don't _have_ to be synchronous or asynchronous, but the OutputStream API was be arranged so that subclasses _can_ be synchronous or asynchronous. Such generality is the hardest part of getting an API right. Hence, if at some point a program using an OutputStream wants to be sure that the data has been pushed all the way out, flush() is available. For some subclasses, e.g. the buffered ones, this has important behavior. Others write the data from each call, and flush() doesn't do anything. You _can_ omit it in programs that are known to use this second type, but there's no requirement that you do so; the interface is general in that way. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From Steffen.DETTMER at ingenico.com Mon Jun 11 12:32:39 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 20:32:39 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> Message-ID: <20070611183239.GT10821@elberon.bln.de.ingenico.com> * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: > >Actually, an application would need to call flush() after each > >write (or bunch of write calls) to ensure that write really did > >something otherwise I think. > OutputStreams don't _have_ to be synchronous or asynchronous, > but the OutputStream API was be arranged so that subclasses > _can_ be synchronous or asynchronous. Ahh, oki. Thanks for the clarificaion. So in short, flush() MUST be called on OutputStream, this is just not documented correctly or so clearly (right?). So the overall usage semantics would be: 1. call write (multiple times if desired) 2. call flush only if both succeeded, write was successful. If flush fails it remains unknown if a part of the data was written and/or will be repeated. So the spec (API doc) is wrong. Correct would be to tell that write behaves as told as long as it is followed by a call to flush, otherwise data may or may not get lost (depending wheter close() is called and calls flush(), which seems not to be guaranteed/required). BTW, I think it is a little bit... erm... interesting to find the specification (java API doc reference) wrong, having a need to conclude it from the presence of some methods with "it would make no sense if they behave exactly as specified, so specification must be wrong (incomplete)". > Such generality is the hardest part of getting an API right. Yes, seems to be proven ;) > Hence, if at some point a program using an OutputStream wants > to be sure that the data has been pushed all the way out, > flush() is available. For some subclasses, e.g. the buffered > ones, this has important behavior. Others write the data from > each call, and flush() doesn't do anything. > You _can_ omit it in programs that are known to use this second > type, but there's no requirement that you do so; the interface > is general in that way. I think, it still it must be called always, otherwise the application could break if passing a different runtime type as OutputStream. I think, if the application/method needs a special "type of OutputStream" then the parameter type must be a subclass but not OutputStream, maybe a PrintStream or so - otherwise the compiler could not detect this error (passing wrong type). Is this correct? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Bob_Jacobsen at lbl.gov Mon Jun 11 13:00:52 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Mon, 11 Jun 2007 12:00:52 -0700 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611183239.GT10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> Message-ID: At 8:32 PM +0200 6/11/07, Steffen DETTMER wrote: >So the spec (API doc) is wrong. Correct would be to tell that >write behaves as told as long as it is followed by a call to >flush, otherwise data may or may not get lost (depending wheter >close() is called and calls flush(), which seems not to be >guaranteed/required). I'm not entirely sure that the spec is wrong, but reasonable people can differ on this. In the 1.5 JavaDocs, all that the docs say for the write methods is that they write to the _output_ _stream_; there is no guarantee of anything beyond that. Only the flush method has any guarantee about the data, which is >Flushes this output stream and forces any buffered output bytes to >be written out. The general contract of flush is that calling it is >an indication that, if any bytes previously written have been >buffered by the implementation of the output stream, such bytes >should immediately be written to their intended destination. People commonly use various OutputStreams without using flush(), and it often works, but it's a bad practice and will eventually bite them. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From netbeans at gatworks.com Mon Jun 11 13:31:57 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 15:31:57 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611183239.GT10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> Message-ID: <466DA32D.1010602@gatworks.com> Steffen DETTMER wrote: > * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: >>> Actually, an application would need to call flush() after each >>> write (or bunch of write calls) to ensure that write really did >>> something otherwise I think. > >> OutputStreams don't _have_ to be synchronous or asynchronous, >> but the OutputStream API was be arranged so that subclasses >> _can_ be synchronous or asynchronous. > > Ahh, oki. Thanks for the clarificaion. > > So in short, flush() MUST be called on OutputStream, this is just > not documented correctly or so clearly (right?). No. Flush can be called to force all current data in java buffer's to be written to the kernel - NOW. A flush() can also *imply* that, besides writing out the buffer's that java employs, may also imply/ask the kernel to write all data thusfar written to the kernel, to be physically placed on the destination device - NOW. For some OS's there is no need to do a kernel flush(), as the I/O is synchronized already. Since this is java, you never know what OS your on. From tjarvi at qbang.org Mon Jun 11 19:28:27 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Jun 2007 19:28:27 -0600 (MDT) Subject: [Rxtx] [OT] select :-) In-Reply-To: <466DA32D.1010602@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: On Mon, 11 Jun 2007, Uncle George wrote: > Steffen DETTMER wrote: >> * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: >>>> Actually, an application would need to call flush() after each >>>> write (or bunch of write calls) to ensure that write really did >>>> something otherwise I think. >> >>> OutputStreams don't _have_ to be synchronous or asynchronous, >>> but the OutputStream API was be arranged so that subclasses >>> _can_ be synchronous or asynchronous. >> >> Ahh, oki. Thanks for the clarificaion. >> >> So in short, flush() MUST be called on OutputStream, this is just >> not documented correctly or so clearly (right?). > No. > Flush can be called to force all current data in java buffer's to be > written to the kernel - NOW. > > A flush() can also *imply* that, besides writing out the buffer's that > java employs, may also imply/ask the kernel to write all data thusfar > written to the kernel, to be physically placed on the destination device > - NOW. > For some OS's there is no need to do a kernel flush(), as the I/O is > synchronized already. Since this is java, you never know what OS your on. To add to the confusion, flush on the C side throws away data. drain makes sure it is written. Looking at the ParallelImp.c we can probably do better. /* we set a timeout because all calls are sequentiell (also with asynchron) this means that the default timeout of unlimited blocks all calls (also close and status request) if the device is down */ GetCommTimeouts( (HANDLE)fd, &timeouts ); timeouts.WriteTotalTimeoutMultiplier = 0; timeouts.WriteTotalTimeoutConstant = 2000; /* 2000 is the min value for the default Windows NT and Windows 2000 driver */ SetCommTimeouts( (HANDLE)fd, &timeouts ); while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } errorCount = 0; bytes += countWritten; count -= countWritten; } LPRPort has some timeout code that appears to be doing nothing but flipping bits back and forth right now. The commapi rxtx follows allows for timeout control from javax.comm.CommPort. The above is a solution that worked in one specific use case. With timeouts in place, the original 'old printer going offline' problem could be solved. That printer code isn't written in stone. In fact it was ajusted from being able to print 'asdf' to a daisy wheel printer to working for one person. BTW, I've finished teaching after hours tonight and will be moving forward with a new rxtx release in my free time. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Jun 11 21:28:04 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 23:28:04 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: <466E12C4.1010305@gatworks.com> > Looking at the ParallelImp.c we can probably do better. > The problem stemmed from the possibility that the writev routine could have written some of the buffer, in chunks, printer pauses, refuses any more chunks, and a timeout occurs. Do you or do you not cause an exception to be thrown? Is there a way to set timeout for a ParallelPort data output stream? I cant find it. From tjarvi at qbang.org Mon Jun 11 22:17:23 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Jun 2007 22:17:23 -0600 (MDT) Subject: [Rxtx] [OT] select :-) In-Reply-To: <466E12C4.1010305@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> <466E12C4.1010305@gatworks.com> Message-ID: On Mon, 11 Jun 2007, Uncle George wrote: >> Looking at the ParallelImp.c we can probably do better. >> > The problem stemmed from the possibility that the writev routine could > have written some of the buffer, in chunks, printer pauses, refuses any > more chunks, and a timeout occurs. Do you or do you not cause an > exception to be thrown? > > Is there a way to set timeout for a ParallelPort data output stream? I > cant find it. hmm I looked again after you asked. The timeouts are only controllable on the receive side. This comes from CommPort; the parent. So what we are talking about is some bytes in memory that rxtx has and is supposed to write. A buffer perhaps? The approach with rxtx in the past has been to ignore output buffer sizes. The assumption is that the library does not know how to best handle buffers. There are buffered output streams that can do buffering on top of rxtx for instance. There is also a question regarding what was actually ment when the API was put together. My suspicion is that it was put together while looking at one OS API and was never ment to be anything more than a hook into that API. The comments are fairly telling combined with reading the w32 API. So looking at the problem again.. The current timeout behavior appears fairly arbitrary. Presumably this is to prevent a program from hanging instead of using a helper thread to write - heavy handed for new programmers. Even so, I don't think the write should timeout at all if it is not configurable. >From the API perspective, "What Timeout?" -- Trent Jarvi tjarvi at qbang.org From Steffen.DETTMER at ingenico.com Tue Jun 12 02:14:48 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 12 Jun 2007 10:14:48 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466DA32D.1010602@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: <20070612081447.GU10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Mon, Jun 11, 2007 at 15:31 -0400: > Steffen DETTMER wrote: > > Ahh, oki. Thanks for the clarificaion. > > > > So in short, flush() MUST be called on OutputStream, this is just > > not documented correctly or so clearly (right?). > No. hum (though now I got it, but...). > Flush can be called to force all current data in java buffer's to be > written to the kernel - NOW. > > A flush() can also *imply* that, besides writing out the > buffer's that java employs, may also imply/ask the kernel to > write all data thusfar written to the kernel, to be physically > placed on the destination device - NOW. > > For some OS's there is no need to do a kernel flush(), as the I/O is > synchronized already. Since this is java, you never know what OS your on. (well, but if you're going to kernel level, even flush cannot guarantee that data will "be physically placed". Maybe you're flushing to a file via NFS (and the client "thinks" that it was written, but maybe it was just buffered by the NFS server) or so... but of course such exceptions of the rules are constructable always.) Well, you tell that depending on the OS it can be that flush is needed or it can be that flush is not needed (beacuse the I/O is synchronized already), right? Also, applications should work on any OS, which includes the OSes that do need flush. Since the application cannot know whether flush is needed or not because it doesn't know what the OS is doing, it has to call flush, hasn't it? I mean, if it would not call flush then it would not work on such OSes (except the written data would not be needed at all, but in this would be an artificial example :)). Since applications are supposed to work this would be wrong, wouldn't it? So would it be correct to say: "Applications, that should work under all OSes (including the OSes where the I/O is not synchronised already), have to call flush on OutputStream to ensure the data is transfered to the kernel." or is this wrong? If so, then I'm afraid I missed the point again :( oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Tue Jun 12 04:46:52 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 12 Jun 2007 06:46:52 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070612081447.GU10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> <20070612081447.GU10821@elberon.bln.de.ingenico.com> Message-ID: <466E799C.7060700@gatworks.com> S > (well, but if you're going to kernel level, even flush cannot > guarantee that data will "be physically placed". Thats true now-a-days because ( from "man 2 sync" ) : > According to the standard specification (e.g., SVID), sync() schedules > the writes, but may return before the actual writing is done. However, > since version 1.3.20 Linux does actually wait. (This still does not > guarantee data integrity: modern disks have large caches.) My disk drive has 8mb cache. Maybe you're > flushing to a file via NFS (and the client "thinks" that it was > written, but maybe it was just buffered by the NFS server) or > so... but of course such exceptions of the rules are > constructable always.) > > Well, you tell that depending on the OS it can be that flush is > needed or it can be that flush is not needed (beacuse the I/O is > synchronized already), right? Also, applications should work on > any OS, which includes the OSes that do need flush. Its not OS's that need flush, its applications that want to have some assurance that data is written to the device that really needs to use flush. If your program ( or thread ) dies then it is in your best interest to write out the critical data as soon as possible, as economical as possible. These are trade-off's that the application programmer makes. A big buffer may mean big loss of data, a small buffer may mean spending too much time writing out data. > > > So would it be correct to say: > > "Applications, that should work under all OSes (including the > OSes where the I/O is not synchronised already), have to call > flush on OutputStream to ensure the data is transfered to the > kernel." > > or is this wrong? If so, then I'm afraid I missed the point again > :( > No that is not wrong. Ensuring that data is transfered to the OS is just about what any application can do. From tjarvi at qbang.org Thu Jun 14 08:16:47 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 14 Jun 2007 08:16:47 -0600 (MDT) Subject: [Rxtx] rxtx and usb-serial solution In-Reply-To: References: Message-ID: On Thu, 14 Jun 2007, Vladimir Kirtchev wrote: > Hi Trent, > > I develop a Java application which communicates with devices which have > USB-to-Serial bridge in them. The target OS is Linux. So for this purpose I > use RXTX. > > But I encountered a strange problem - when reading from the InputStream, I > receive series of zeros. I have this problem under Linux only. Under Windows > it is fine. > Actually this problem is the same as the one described here: > http://marc.info/?l=rxtx&m=109703190731748&w=2. > > > So I searched for the problem in the native code. And found that the root of > the problem is in SerialImp.c, > int configure_port( int fd ) > { > ... > ttyset.c_iflag = INPCK; > ... > } > > This line enables input parity checking, and the data sent from the device > is processed by the OS driver before being read with read(). > In this case the driver detects some problem and sets the received bytes to > zero. > > On the other hand in the Java part a set the serial port parameters with > SerialPort.PARITY_NONE. According to me, except all other things, this > should also disable INPCK in c_iflag. > > So I refactored the method translate_parity(...) to the following: > > int translate_parity( JNIEnv *env, struct termios *ttyset, jint parity ) > { > ENTER( "translate_parity" ); > #ifdef CMSPAR > ttyset->c_cflag &= ~(PARENB | PARODD | CMSPAR ); > #endif /* CMSPAR */ > switch( parity ) { > case JPARITY_NONE: > ttyset->c_iflag &= ~INPCK; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_EVEN: > ttyset->c_cflag |= PARENB; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_ODD: > ttyset->c_cflag |= PARENB | PARODD; > LEAVE( "translate_parity" ); > return 0; > #ifdef CMSPAR > case JPARITY_MARK: > ttyset->c_cflag |= PARENB | PARODD | CMSPAR; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_SPACE: > ttyset->c_cflag |= PARENB | CMSPAR; > LEAVE( "translate_parity" ); > return 0; > #endif /* CMSPAR */ > default: > printf("Parity missed %i\n", (int) parity ); > } > > LEAVE( "translate_parity" ); > /* > For some reason the native exceptions are not being caught. Moving this > to the Java side fixed the issue. taj. > throw_java_exception( env, UNSUPPORTED_COMM_OPERATION, > "", "parity value not supported" ); > */ > return 1; > } > > This modification solved the problem and now it works correctly under Linux. > > I think I will be a nice if this is idea is included in a future release of > RXTX. > > Thanks Vadim, I'll try that out. Forwarding to the rxtx mail-list too. This is probably not going to help USB drivers on windows which I'm sure some are looking for. As far as I can tell, windows USB bluetooth and serial dongles are limited by driver functionality. Some are good and others lack key features. -- Trent Jarvi tjarvi at qbang.org From dan.sandberg.lists at gmail.com Mon Jun 18 14:43:39 2007 From: dan.sandberg.lists at gmail.com (Dan Sandberg) Date: Mon, 18 Jun 2007 13:43:39 -0700 Subject: [Rxtx] Fix for JNI Get/Set Field Errors Message-ID: <4676EE7B.7060800@gmail.com> Hi, I've fixed the problems that cause the following JNI error when extra JNI checking ( -Xjni:check ) is turned on. FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) The problem was basically that GetLong was being used to get ints, and SetInt was used for longs. The patch below fixes this. Please let me know if there are any questions / problems. Cheers, -Dan diff -aur old/SerialImp.c src/SerialImp.c --- old/SerialImp.c 2007-06-18 13:24:33.000000000 -0700 +++ src/SerialImp.c 2007-06-18 06:26:26.000000000 -0700 @@ -1337,7 +1337,7 @@ report("init_threads: get eis\n"); jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); report("init_threads: set eis\n"); - (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); + (*eis->env)->SetLongField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); report("init_threads: stop\n"); report_time_end( ); return( 1 ); @@ -1530,7 +1530,7 @@ jobject jobj, jboolean interrupted ) { int fd = get_java_var( env, jobj,"fd","I" ); - struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var( env, jobj, "eis", "J" ); + struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var_long( env, jobj, "eis", "J" ); int result, count=0; char message[80]; @@ -2939,7 +2939,7 @@ /* TRENT */ int flag, count = 0; struct event_info_struct *eis = ( struct event_info_struct * ) - get_java_var( env, *jobj,"eis","J" ); + get_java_var_long( env, *jobj,"eis","J" ); report_time_start(); flag = eis->eventflags[SPE_DATA_AVAILABLE]; @@ -4873,9 +4873,9 @@ exceptions: none comments: ----------------------------------------------------------*/ -size_t get_java_var( JNIEnv *env, jobject jobj, char *id, char *type ) +long get_java_var_long( JNIEnv *env, jobject jobj, char *id, char *type ) { - int result = 0; + long result = 0; jclass jclazz = (*env)->GetObjectClass( env, jobj ); jfieldID jfd = (*env)->GetFieldID( env, jclazz, id, type ); @@ -4889,7 +4889,11 @@ LEAVE( "get_java_var" ); return result; } - result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); + if ( !strcmp( type, "J" ) ) { + result = (long)( (*env)->GetLongField( env, jobj, jfd ) ); + } else { + result = (int) ( (*env)->GetIntField( env, jobj, jfd ) ); + } /* ct7 & gel * Added DeleteLocalRef */ (*env)->DeleteLocalRef( env, jclazz ); if(!strncmp( "fd",id,2) && result == 0) @@ -4900,6 +4904,10 @@ return result; } +int get_java_var( JNIEnv *env, jobject jobj, char *id, char *type ) { + return (int) get_java_var_long( env, jobj, id, type ); +} + /*---------------------------------------------------------- throw_java_exception diff -aur old/SerialImp.h src/SerialImp.h --- old/SerialImp.h 2007-06-18 13:24:39.000000000 -0700 +++ src/SerialImp.h 2007-06-18 06:23:43.000000000 -0700 @@ -413,7 +413,8 @@ void system_wait(); void finalize_event_info_struct( struct event_info_struct * ); int read_byte_array( JNIEnv *, jobject *, int, unsigned char *, int, int ); -size_t get_java_var( JNIEnv *, jobject, char *, char * ); +int get_java_var( JNIEnv *, jobject, char *, char * ); +long get_java_var_long( JNIEnv *, jobject, char *, char * ); jboolean is_interrupted( struct event_info_struct * ); int send_event(struct event_info_struct *, jint, int ); void dump_termios(char *,struct termios *); From yvespielusenet at free.fr Tue Jun 26 03:41:58 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 11:41:58 +0200 Subject: [Rxtx] [PARALLEL] resource in use Message-ID: <1182850918.3483.10.camel@localhost.localdomain> Hello, So now I want to modify the timeout of the library for parallel port. I have downloaded source code. There is a makefile for migw. SO I have installed mingw on ubuntu and modified the makefile.mingw32 to set it for my system. I have no error but some warnings. The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But When I want to use it the jvm crash :( How can I know what is wrong ? How rxtx windows release has been done ? thanks -- yves piel From yvespielusenet at free.fr Tue Jun 26 07:17:02 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 15:17:02 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182850918.3483.10.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> Message-ID: <1182863822.3483.17.camel@localhost.localdomain> Here is the Makefile I use, the output of the 'make' and the log of the jvm when it crashed : - The Makefile : http://yvespiel.free.fr/rxtx/Makefile - The make output : http://yvespiel.free.fr/rxtx/compile.txt - The crash log : http://yvespiel.free.fr/rxtx/hs_err_pid2100.log I have compiled rxtx under Debian testing with mingw : narma at linimi:/tmp/err$ dpkg -l | grep mingw ii mingw32 3.4.5.20060117.1.dfsg-3 ii mingw32-binutils 2.17.50-20070129.1-1 ii mingw32-runtime 3.12-1 thanks fort help :) Le mardi 26 juin 2007 ? 11:41 +0200, yves pielusenet a ?crit : > Hello, > So now I want to modify the timeout of the library for parallel port. I > have downloaded source code. There is a makefile for migw. SO I have > installed mingw on ubuntu and modified the makefile.mingw32 to set it > for my system. > I have no error but some warnings. > The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But > When I want to use it the jvm crash :( > > How can I know what is wrong ? > > How rxtx windows release has been done ? > > thanks > From yvespielusenet at free.fr Tue Jun 26 07:40:11 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 15:40:11 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182863822.3483.17.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> <1182863822.3483.17.camel@localhost.localdomain> Message-ID: <1182865211.3483.21.camel@localhost.localdomain> I have add the options '--enable-stdcall-fixup' to the 'i586-mingw32msvc-ld' commande. Now I have no warning. But the JVM always crashes :( The output seems more detailled, but I don't understand anything... Here is files : http://yvespiel.free.fr/rxtx/2/ -- yves piel Le mardi 26 juin 2007 ? 15:17 +0200, yves pielusenet a ?crit : > Here is the Makefile I use, the output of the 'make' and the log of the > jvm when it crashed : > > - The Makefile : http://yvespiel.free.fr/rxtx/Makefile > - The make output : http://yvespiel.free.fr/rxtx/compile.txt > - The crash log : http://yvespiel.free.fr/rxtx/hs_err_pid2100.log > > I have compiled rxtx under Debian testing with mingw : > narma at linimi:/tmp/err$ dpkg -l | grep mingw > ii mingw32 3.4.5.20060117.1.dfsg-3 > ii mingw32-binutils 2.17.50-20070129.1-1 > ii mingw32-runtime 3.12-1 > > thanks fort help :) > > > Le mardi 26 juin 2007 ? 11:41 +0200, yves pielusenet a ?crit : > > Hello, > > So now I want to modify the timeout of the library for parallel port. I > > have downloaded source code. There is a makefile for migw. SO I have > > installed mingw on ubuntu and modified the makefile.mingw32 to set it > > for my system. > > I have no error but some warnings. > > The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But > > When I want to use it the jvm crash :( > > > > How can I know what is wrong ? > > > > How rxtx windows release has been done ? > > > > thanks > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From yvespielusenet at free.fr Tue Jun 26 08:27:42 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 16:27:42 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182865211.3483.21.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> <1182863822.3483.17.camel@localhost.localdomain> <1182865211.3483.21.camel@localhost.localdomain> Message-ID: <1182868062.3483.24.camel@localhost.localdomain> I think thant the include files of jdk were not for windows but for linux. So I have copied include/ folder from windows to linux and I modified the Makefile to use those file. It compile fine but the JVM always crash :( http://yvespiel.free.fr/rxtx/3/ Le mardi 26 juin 2007 ? 15:40 +0200, yves pielusenet a ?crit : > I have add the options '--enable-stdcall-fixup' to the > 'i586-mingw32msvc-ld' commande. Now I have no warning. But the JVM > always crashes :( The output seems more detailled, but I don't > understand anything... > Here is files : > http://yvespiel.free.fr/rxtx/2/ > From netbeans at gatworks.com Fri Jun 1 05:38:50 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 07:38:50 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <465F7ADD.1010501@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> Message-ID: <4660054A.2040202@gatworks.com> Manuel Naranjo wrote: In the case of my module, you can > unplug the device but it will not delete the symlink until those apps > that had opened the port has closed it. This is done this way to avoid > kernel panics. What does this mean to user code ? I have tried the alternate route ( other than closing ) which is sleep inbetween the I/O errors ( an unplugged USB device). When the device is plugged back in, The writes to the device still get an I/O error. This would seem to be a lost cause for the application. From netbeans at gatworks.com Fri Jun 1 06:35:48 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 08:35:48 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <465F7ADD.1010501@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> Message-ID: <466012A4.90608@gatworks.com> Manuel Naranjo wrote: In the case of my module, you can > unplug the device but it will not delete the symlink until those apps > that had opened the port has closed it. T Did u also mean for this to happen? USB0 was not closed by application. Apparently USB1 got created when USB device was plugged back in. There is only one USB device on a 4 port USB hub. This also seems to suggest that application recovery to be impossible. > Jun 1 07:10:08 mylaptop kernel: garmin_gps 1-1.4:1.0: Garmin GPS usb/tty converter detected > Jun 1 07:10:08 mylaptop kernel: usb 1-1.4: Garmin GPS usb/tty converter now attached to ttyUSB0 > Jun 1 07:15:17 mylaptop kernel: usb 1-1: USB disconnect, address 4 > Jun 1 07:15:17 mylaptop kernel: usb 1-1.4: USB disconnect, address 5 > Jun 1 07:15:17 mylaptop kernel: garmin_gps 1-1.4:1.0: device disconnected > Jun 1 07:15:26 mylaptop kernel: usb 1-1: new full speed USB device using uhci_hcd and address 6 > Jun 1 07:15:26 mylaptop kernel: hub 1-1:1.0: USB hub found > Jun 1 07:15:26 mylaptop kernel: hub 1-1:1.0: 4 ports detected > Jun 1 07:15:27 mylaptop kernel: usb 1-1.4: new full speed USB device using uhci_hcd and address 7 > Jun 1 07:15:27 mylaptop kernel: garmin_gps 1-1.4:1.0: Garmin GPS usb/tty converter detected > Jun 1 07:15:27 mylaptop kernel: usb 1-1.4: Garmin GPS usb/tty converter now attached to ttyUSB1 From naranjo.manuel at gmail.com Fri Jun 1 09:17:22 2007 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Fri, 01 Jun 2007 12:17:22 -0300 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <466012A4.90608@gatworks.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> <466012A4.90608@gatworks.com> Message-ID: <46603882.5050701@gmail.com> Uncle George escribi?: > Manuel Naranjo wrote: > In the case of my module, you can > >> unplug the device but it will not delete the symlink until those apps >> that had opened the port has closed it. T >> > > Did u also mean for this to happen? USB0 was not closed by application. > > Apparently USB1 got created when USB device was plugged back in. There > is only one USB device on a 4 port USB hub. > > This also seems to suggest that application recovery to be impossible. > Exactly there's a dead symlink (you can read and write to it and nothing will happen) and a new port will be created when a new device is connencted. From netbeans at gatworks.com Fri Jun 1 10:20:46 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 12:20:46 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <46603882.5050701@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> <466012A4.90608@gatworks.com> <46603882.5050701@gmail.com> Message-ID: <4660475E.5090202@gatworks.com> Not sure what u mean by "symlink". U cant read/write to it anymore. U get I/O error. In this scenario the device effectively went dead, and only solution is to close the channel. reconnecting the USB device, although dead, but not closed, will create a second device. This does not seem to be a desirable side-effect. The user will now have ttyUSB1, wondering where did ttyUSB0 go to. The application will also be in a confused state, as well as RXTX, because RXTX wont know about ttyUSB1. Manuel Naranjo wrote: > Uncle George escribi?: >> Manuel Naranjo wrote: >> In the case of my module, you can >> >>> unplug the device but it will not delete the symlink until those apps >>> that had opened the port has closed it. T >>> >> Did u also mean for this to happen? USB0 was not closed by application. >> >> Apparently USB1 got created when USB device was plugged back in. There >> is only one USB device on a 4 port USB hub. >> >> This also seems to suggest that application recovery to be impossible. >> > Exactly there's a dead symlink (you can read and write to it and nothing > will happen) and a new port will be created when a new device is connencted. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From arnab.bhaumik at gmail.com Mon Jun 4 01:40:16 2007 From: arnab.bhaumik at gmail.com (arnab bhaumik) Date: Mon, 4 Jun 2007 13:10:16 +0530 Subject: [Rxtx] full duplex com port with rxtx Message-ID: hi , till now i did half duplex communication with rxtx package on com package. my question is : is it possible to use com port with full duplex mode with rxtx package . ther is example of SimpleRead class and SimpleWrite class. it is clear that if i can use both the class simultaneously then full duplex is possible......... arnab/vu2bpw -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070604/6edb0453/attachment.html From lists at iDIAcomputing.com Mon Jun 4 07:53:17 2007 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Mon, 04 Jun 2007 09:53:17 -0400 Subject: [Rxtx] full duplex com port with rxtx In-Reply-To: References: Message-ID: <4664194D.90301@iDIAcomputing.com> arnab bhaumik wrote: > hi , > > till now i did half duplex communication with rxtx package on com > package. > > my question is : is it possible to use com port with full duplex mode > with rxtx package . > > > ther is example of SimpleRead class and SimpleWrite class. it is > clear that if i can use both the class simultaneously then full duplex > is possible......... I haven't looked at the SimpleRead and SimpleWrite classes (I originally wrote my code for the javax.comm api), but full duplex is certainly possible. My CommReader class requires an object analogous to a OutputStream or Writer. When started, it spawns a thread that reads the comm port and writes to that output device. In this way the input is asynchronous and dependent on the actual input data. For full duplex, I extend that class with CommReaderWriter, which adds synchronous output methods. Hope that helps, George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From supsoop at hotmail.com Mon Jun 4 15:21:06 2007 From: supsoop at hotmail.com (soop soop) Date: Mon, 04 Jun 2007 21:21:06 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- Message-ID: Hi Guys, Looked through the archives but still cannot figure this out. I have a Motorola G24 GPRS/GSM modem that I am connecting to my server running Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not detecting the port, CommPortIdentifier.getPortIdentifiers(). I have added the line to RXTXCommDriver: "ttyACM" // for USB Modems Rxtx still does not seem to find the port. Is there something I am missing to make this port visable? [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control Model driver for USB modems and ISDN adapters I really need your help as I have moved my server from windows to Linux and have been down for a few days because of this .. Thanks so much! _________________________________________________________________ PC Magazine’s 2007 editors’ choice for best Web mail—award-winning Windows Live Hotmail. http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 From tjarvi at qbang.org Mon Jun 4 16:17:35 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Jun 2007 16:17:35 -0600 (MDT) Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: On Mon, 4 Jun 2007, soop soop wrote: > Hi Guys, > > Looked through the archives but still cannot figure this out. I have a > Motorola G24 GPRS/GSM modem that I am connecting to my server running Ubuntu. > I can see my modem as is shows up as ttyACM0, but RXTX is not detecting the > port, CommPortIdentifier.getPortIdentifiers(). > > I have added the line to RXTXCommDriver: > > "ttyACM" // for USB Modems > > Rxtx still does not seem to find the port. Is there something I am missing to > make this port visable? > > [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver > [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device > [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control Model > driver for USB modems and ISDN adapters > > I really need your help as I have moved my server from windows to Linux and > have been down for a few days because of this .. Thanks so much! > You could try the INSTALL documentation that comes with the source for possible solutions. Those usually involve lockfile creation, permissions on the device file or the device is in use by another application (even another session of your application). The usual commands: ls -l /dev/ttyACM0 fuser /dev/ttyACM0 touch /var/lock/LCK.testfile && rm -f /var/lock/LCK.testfile whoami To disable lockfiles: ../configure --disable-lockfiles && make install -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Jun 4 16:22:52 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 04 Jun 2007 18:22:52 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <466490BC.3090801@gatworks.com> soop soop wrote: > I really need your help as I have moved my server from windows to Linux > and have been down for a few days because of this .. Thanks so much! can u open the device ? ie is the file protection/permissions keeping you out? From supsoop at hotmail.com Mon Jun 4 16:44:40 2007 From: supsoop at hotmail.com (soop soop) Date: Mon, 04 Jun 2007 22:44:40 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <466490BC.3090801@gatworks.com> Message-ID: Thanks for the reply, I see no exceptions being thrown, just no detection of the port whats so ever. I will run rxtx in debug mode and log. If this were a permissions issue would I not see some exceptions being thrown? >From: Uncle George >Reply-To: RXTX Developers and Users >To: RXTX Developers and Users >Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >Date: Mon, 04 Jun 2007 18:22:52 -0400 > >soop soop wrote: > > > I really need your help as I have moved my server from windows to Linux > > and have been down for a few days because of this .. Thanks so much! > >can u open the device ? ie is the file protection/permissions keeping >you out? >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ Get a preview of Live Earth, the hottest event this summer - only on MSN http://liveearth.msn.com?source=msntaglineliveearthhm From netbeans at gatworks.com Mon Jun 4 17:06:15 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 04 Jun 2007 19:06:15 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <46649AE7.10405@gatworks.com> Exceptions on what? On startup it wants to lookup all devices in /dev that it is capable of opening ( within the list of specific 'comm' devices ). If it cannot open, then does not get onto list. Part of this process, if configured, will also test if the "LOCK" schema can also be opened for the device. then it gets on the list of avail comm port. soop soop wrote: > Thanks for the reply, > > I see no exceptions being thrown, just no detection of the port whats so > ever. I will run rxtx in debug mode and log. If this were a permissions > issue would I not see some exceptions being thrown? > > >> From: Uncle George >> Reply-To: RXTX Developers and Users >> To: RXTX Developers and Users >> Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >> Date: Mon, 04 Jun 2007 18:22:52 -0400 >> >> soop soop wrote: >> >>> I really need your help as I have moved my server from windows to Linux >>> and have been down for a few days because of this .. Thanks so much! >> can u open the device ? ie is the file protection/permissions keeping >> you out? >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _________________________________________________________________ > Get a preview of Live Earth, the hottest event this summer - only on MSN > http://liveearth.msn.com?source=msntaglineliveearthhm > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From alex.flint at gmail.com Mon Jun 4 21:31:49 2007 From: alex.flint at gmail.com (Alex Flint) Date: Tue, 5 Jun 2007 13:01:49 +0930 Subject: [Rxtx] random EXCEPTION_ACCESS_VIOLATION errors Message-ID: Hi All, I'm running winXP and RXTX 2.1-7r2 (the latest from the webpage as of June 2007). I'm sending sequences of 64 lines (each line has about 15 chars) at various intervals. The strings are sent fine, until I get the following error (from hs_err_pid3316.log, at the end of this email). What can I do to avoid the error? Obviously this is a low-level memory exception, but is there any way I can keep the JVM running after such an error? I noticed the exact same problem here: http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20070129/1180520.html Cheers, Alex # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x100034fb, pid=3316, tid=2400 # # Java VM: Java HotSpot(TM) Client VM (1.6.0_01-b06 mixed mode, sharing) # Problematic frame: # C [rxtxSerial.dll+0x34fb] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # --------------- T H R E A D --------------- Current thread (0x00386400): JavaThread "main" [_thread_in_native, id=2400] siginfo: ExceptionCode=0xc0000005, reading address 0x20726f78 Registers: EAX=0x20726f20, EBX=0x6d8922c0, ECX=0x00000005, EDX=0x20726f20 ESP=0x003efa30, EBP=0x003efb68, ESI=0x269728a0, EDI=0x00386400 EIP=0x100034fb, EFLAGS=0x00010212 Top of Stack: (sp=0x003efa30) 0x003efa30: 003efa3c 003efa64 0000000f ffffffff 0x003efa40: 003efa40 2a97f808 003efa6c 2b190ca8 0x003efa50: 00000000 2b190ec0 003efa90 008e2dd7 0x003efa60: 003efa90 008e2dd7 26977f88 6d815e72 0x003efa70: 00000004 2696eae0 0000008a 003efb0c 0x003efa80: 6d852b4a 2696eae0 00000003 26970930 0x003efa90: 000000cb 2696eae0 6d86b264 00385d40 0x003efaa0: 0000003f 003efb0c 26977f90 2ace65d8 Instructions: (pc=0x100034fb) 0x100034eb: ff ff 8d 76 00 eb 02 89 f6 90 8b 45 f8 8b 55 f8 0x100034fb: 8b 4a 58 83 c9 04 89 48 58 83 c4 f8 8b 45 f8 8b Stack: [0x003a0000,0x003f0000), sp=0x003efa30, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x34fb] Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j gnu.io.RXTXPort.writeArray([BIIZ)V+0 j gnu.io.RXTXPort$SerialOutputStream.write([B)V+76 j com.bjt.media.server.CommLink.send(Ljava/lang/String;)V+48 j com.bjt.media.server.DigitoolConnection.select(I)V+73 j com.bjt.media.server.DigitoolConnection.main([Ljava/lang/String;)V+74 v ~StubRoutines::call_stub --------------- P R O C E S S --------------- Java Threads: ( => current thread ) 0x02a69400 JavaThread "Thread-0" [_thread_in_native, id=3052] 0x02a4d000 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=3920] 0x02a48400 JavaThread "CompilerThread0" daemon [_thread_blocked, id=1968] 0x02a47400 JavaThread "Attach Listener" daemon [_thread_blocked, id=2984] 0x02a46400 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=2660] 0x02a41c00 JavaThread "Finalizer" daemon [_thread_blocked, id=3924] 0x02a3d800 JavaThread "Reference Handler" daemon [_thread_blocked, id=4008] =>0x00386400 JavaThread "main" [_thread_in_native, id=2400] Other Threads: 0x02a34400 VMThread [id=3708] 0x02a4e800 WatcherThread [id=3964] VM state:not at safepoint (normal execution) VM Mutex/Monitor currently owned by a thread: None Heap def new generation total 960K, used 131K [0x22960000, 0x22a60000, 0x22e40000) eden space 896K, 7% used [0x22960000, 0x22970ea8, 0x22a40000) from space 64K, 99% used [0x22a50000, 0x22a5fff8, 0x22a60000) to space 64K, 0% used [0x22a40000, 0x22a40000, 0x22a50000) tenured generation total 4096K, used 76K [0x22e40000, 0x23240000, 0x26960000) the space 4096K, 1% used [0x22e40000, 0x22e53060, 0x22e53200, 0x23240000) compacting perm gen total 12288K, used 137K [0x26960000, 0x27560000, 0x2a960000) the space 12288K, 1% used [0x26960000, 0x26982518, 0x26982600, 0x27560000) ro space 8192K, 62% used [0x2a960000, 0x2ae5e4e8, 0x2ae5e600, 0x2b160000) rw space 12288K, 52% used [0x2b160000, 0x2b7a0e78, 0x2b7a1000, 0x2bd60000) Dynamic libraries: 0x00400000 - 0x00423000 C:\Program Files\Java\jre1.6.0_01\bin\javaw.exe 0x7c900000 - 0x7c9b0000 C:\WINDOWS\system32\ntdll.dll 0x7c800000 - 0x7c8f4000 C:\WINDOWS\system32\kernel32.dll 0x77dd0000 - 0x77e6b000 C:\WINDOWS\system32\ADVAPI32.dll 0x77e70000 - 0x77f01000 C:\WINDOWS\system32\RPCRT4.dll 0x7e410000 - 0x7e4a0000 C:\WINDOWS\system32\USER32.dll 0x77f10000 - 0x77f57000 C:\WINDOWS\system32\GDI32.dll 0x76390000 - 0x763ad000 C:\WINDOWS\system32\IMM32.DLL 0x7c340000 - 0x7c396000 C:\Program Files\Java\jre1.6.0_01\bin\msvcr71.dll 0x6d7c0000 - 0x6da07000 C:\Program Files\Java\jre1.6.0_01\bin\client\jvm.dll 0x76b40000 - 0x76b6d000 C:\WINDOWS\system32\WINMM.dll 0x5cd70000 - 0x5cd77000 C:\WINDOWS\system32\serwvdrv.dll 0x5b0a0000 - 0x5b0a7000 C:\WINDOWS\system32\umdmxfrm.dll 0x6d310000 - 0x6d318000 C:\Program Files\Java\jre1.6.0_01\bin\hpi.dll 0x76bf0000 - 0x76bfb000 C:\WINDOWS\system32\PSAPI.DLL 0x6d770000 - 0x6d77c000 C:\Program Files\Java\jre1.6.0_01\bin\verify.dll 0x6d3b0000 - 0x6d3cf000 C:\Program Files\Java\jre1.6.0_01\bin\java.dll 0x6d7b0000 - 0x6d7bf000 C:\Program Files\Java\jre1.6.0_01\bin\zip.dll 0x10000000 - 0x10012000 C:\Documents and Settings\Alex\workspace\MediaServer\rxtxSerial.dll 0x73d90000 - 0x73db7000 C:\WINDOWS\system32\crtdll.dll VM Arguments: jvm_args: -Djava.library.path=C:\Documents and Settings\Alex\workspace\MediaServer java_command: com.bjt.media.server.DigitoolConnection Launcher Type: SUN_STANDARD Environment Variables: CLASSPATH=.;C:\Program Files\Java\j2re1.4.2_07\lib\ext\QTJava.zip PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\wbem;c:\applications\php;C:\Program Files\MATLAB\R2006a\bin\win32;C:\Roger\Projects\UAV\Bin\Debug;C:\Program Files\Microsoft SQL Server\80\Tools\Binn\;c:\Program Files\Microsoft SQL Server\90\Tools\binn\;C:\Program Files\QuickTime\QTSystem\;C:\Pfps\system;C:\Program Files\Java\jdk1.6.0_01\bin;C:\Program Files\Java\jdk1.6.0_01\jre\bin USERNAME=Alex OS=Windows_NT PROCESSOR_IDENTIFIER=x86 Family 15 Model 4 Stepping 1, GenuineIntel --------------- S Y S T E M --------------- OS: Windows XP Build 2600 Service Pack 2 CPU:total 1 family 15, cmov, cx8, fxsr, mmx, sse, sse2 Memory: 4k page, physical 1046508k(275288k free), swap 2522816k(1909176k free) vm_info: Java HotSpot(TM) Client VM (1.6.0_01-b06) for windows-x86, built on Mar 14 2007 00:24:02 by "java_re" with unknown MS VC++:1310 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070604/c87ae1f0/attachment.html From alwyn.schoeman at gmail.com Tue Jun 5 00:10:19 2007 From: alwyn.schoeman at gmail.com (Alwyn Schoeman) Date: Tue, 5 Jun 2007 08:10:19 +0200 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Hi, I'm using a similar modem. By default rxtx doesn't look for devices that start with ACM, so you need to modify the source code and recompile. Look in RXTXCommDriver and add values for ACM in the registerScannedPorts method in the Linux specific parts. Look for osName.equals("Linux")... On 6/4/07, soop soop wrote: > > Hi Guys, > > Looked through the archives but still cannot figure this out. I have a > Motorola G24 GPRS/GSM modem that I am connecting to my server running > Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not > detecting the port, CommPortIdentifier.getPortIdentifiers(). > > I have added the line to RXTXCommDriver: > > "ttyACM" // for USB Modems > > Rxtx still does not seem to find the port. Is there something I am missing > to make this port visable? > > [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver > [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device > [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control > Model > driver for USB modems and ISDN adapters > > I really need your help as I have moved my server from windows to Linux > and > have been down for a few days because of this .. Thanks so much! > > _________________________________________________________________ > PC Magazine's 2007 editors' choice for best Web mail?award-winning Windows > Live Hotmail. > > http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -- Alwyn Schoeman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/b6cb3053/attachment.html From naranjo.manuel at gmail.com Tue Jun 5 06:48:45 2007 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Tue, 05 Jun 2007 09:48:45 -0300 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> References: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Message-ID: <46655BAD.7010501@gmail.com> That's right, an easier solution is creating symlinks to acm. For example make ttyS70 to 79 point to ACM0 to 9 and that will help you a lot, and doesn't even require compile. > Hi, > > I'm using a similar modem. By default rxtx doesn't look for devices > that start with ACM, so you need to modify the > source code and recompile. > > Look in RXTXCommDriver and add values for ACM in the > registerScannedPorts method in the Linux specific parts. Look for > osName.equals("Linux")... > From juanemc2 at gmail.com Tue Jun 5 07:02:43 2007 From: juanemc2 at gmail.com (Juan) Date: Tue, 5 Jun 2007 10:02:43 -0300 Subject: [Rxtx] Problems with Epson TMU220B POSPrinter using XON/XOFF Flow Control and rxtx jar and dll's with the serial port. Message-ID: Hi!, I?m having trouble printing to the serial port using the latest version of rxtx jar and dll's with an Epson POSPrinter. I`ve switched the printer to work with XON/XOFF Flow Control and have watched the serial port to be sure the printer is sending the XON XOFF stop and go characters. I`ve setted the port like this: CommPortIdentifier commPortIdentifier = CommPortIdentifier.* getPortIdentifier*(_portName); SerialPort serialPort = (SerialPort)commPortIdentifier.open(*this*.getClass().getName(), 2000); serialPort.setSerialPortParams(_baudRate, _dataBits, _stopBits, _parity); serialPort.setFlowControlMode( SerialPort.*FLOWCONTROL_XONXOFF_IN* | SerialPort.*FLOWCONTROL_XONXOFF_OUT*); where the baudRate is 9600 the dataBits is 8 the stopBits is 1 and the parity is 0 It seems as the library isn`t taking into account the XON XOFF setting. I would like to know if I`m setting correctly the Flow Control and if you had had any experiences using XON XOFF flow control and could give me some help to solve my problem. I`m very thankful in advance, Yours, Juan Polero -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/b080995a/attachment.html From ehdez.correo at gmail.com Tue Jun 5 07:12:53 2007 From: ehdez.correo at gmail.com (=?ISO-8859-1?Q?Enrique_Hern=E1ndez?=) Date: Tue, 5 Jun 2007 09:12:53 -0400 Subject: [Rxtx] problem with rxtx Message-ID: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Hello: I doing a simple test to show the serial ports. This is the code: import java.util.Enumeration; import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; public class Show { private Enumeration portList; private CommPortIdentifier portId; private SerialPort port; /** Creates a new instance of Show */ public Show() { } public static void main(String args[]){ Show show = new Show(); show.portList = CommPortIdentifier.getPortIdentifiers(); String tPort = ""; System.out.println("========================================="); while(show.portList.hasMoreElements()){ show.portId = (CommPortIdentifier)show.portList.nextElement(); if(show.portId.getPortType() == CommPortIdentifier.PORT_SERIAL) tPort = "Serial"; else tPort = "Parallel"; System.out.println(show.portId.getName() + " " + tPort); } } } whit The problem is that this code not show the serial ports, this show the no use serial ports. I want to connect whit the modem but when windows open and connect the modem my application don't see the port(COMM3) when it is connect. what I can do? Is that the correct way to know the ports? thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/eedd744b/attachment.html From ehdez.correo at gmail.com Tue Jun 5 07:42:13 2007 From: ehdez.correo at gmail.com (=?ISO-8859-1?Q?Enrique_Hern=E1ndez?=) Date: Tue, 5 Jun 2007 09:42:13 -0400 Subject: [Rxtx] serial port Message-ID: <4a814e1f0706050642p4ce9ac7bka80f9479c524c5ea@mail.gmail.com> Hello: How I can ask to the port what device is connect and information about this device. thanks. bye. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/4d10d26a/attachment.html From supsoop at hotmail.com Tue Jun 5 09:29:00 2007 From: supsoop at hotmail.com (soop soop) Date: Tue, 05 Jun 2007 15:29:00 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Message-ID: Hi Guys, Thanks for all your help. I found the problem. I created a user, Tomcat55, for my tomcat but it did not belong to any group. I then added this user to dialout group to have access to the device ttyACM0. Works perfectly! Again permissions was the issue. This also seems to be persistent as a server reboot does not effect the access. Cheers! >From: "Alwyn Schoeman" >Reply-To: RXTX Developers and Users >To: "RXTX Developers and Users" >Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >Date: Tue, 5 Jun 2007 08:10:19 +0200 > >Hi, > >I'm using a similar modem. By default rxtx doesn't look for devices that >start with ACM, so you need to modify the >source code and recompile. > >Look in RXTXCommDriver and add values for ACM in the registerScannedPorts >method in the Linux specific parts. Look for osName.equals("Linux")... > >On 6/4/07, soop soop wrote: >> >>Hi Guys, >> >>Looked through the archives but still cannot figure this out. I have a >>Motorola G24 GPRS/GSM modem that I am connecting to my server running >>Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not >>detecting the port, CommPortIdentifier.getPortIdentifiers(). >> >>I have added the line to RXTXCommDriver: >> >>"ttyACM" // for USB Modems >> >>Rxtx still does not seem to find the port. Is there something I am missing >>to make this port visable? >> >>[ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver >>[ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device >>[ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control >>Model >>driver for USB modems and ISDN adapters >> >>I really need your help as I have moved my server from windows to Linux >>and >>have been down for a few days because of this .. Thanks so much! >> >>_________________________________________________________________ >>PC Magazine's 2007 editors' choice for best Web mail—award-winning Windows >>Live Hotmail. >> >>http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 >> >> >>_______________________________________________ >>Rxtx mailing list >>Rxtx at qbang.org >>http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > >-- >Alwyn Schoeman >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ Need a break? Find your escape route with Live Search Maps. http://maps.live.com/default.aspx?ss=Restaurants~Hotels~Amusement%20Park&cp=33.832922~-117.915659&style=r&lvl=13&tilt=-90&dir=0&alt=-1000&scene=1118863&encType=1&FORM=MGAC01 From netbeans at gatworks.com Tue Jun 5 09:42:31 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 11:42:31 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <46658467.20101@gatworks.com> soop soop wrote: > > Hi Guys, > > Thanks for all your help. I found the problem. I created a user, > Tomcat55, for my tomcat but it did not belong to any group. I then added Look at man pages for the program udev. From tjarvi at qbang.org Tue Jun 5 18:18:17 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Jun 2007 18:18:17 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Message-ID: On Tue, 5 Jun 2007, Enrique Hern?ndez wrote: > The problem is that this code not show the serial ports, this show the no > use serial ports. I want to connect whit the modem but when windows open and > connect the modem my application don't see the port(COMM3) when it is > connect. > what I can do? > Is that the correct way to know the ports? > Hello, We may have problems understanding each other. On windows, the port will not be an available serial port if another application has the port open. That is just how the library behaves. If you can not see the port in the enumerated list, you could not open it. Also note that enumeration only happens once. If you add a port such as a new USB dongle, the port will not be visible until the next time your application runs. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Tue Jun 5 18:45:01 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 20:45:01 -0400 Subject: [Rxtx] problem with rxtx In-Reply-To: References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Message-ID: <4666038D.8090700@gatworks.com> Trent Jarvi wrote: > > > Also note that enumeration only happens once. If you add a port such as > a new USB dongle, the port will not be visible until the next time your > application runs. Is this written in stone ? somewhere? From tjarvi at qbang.org Tue Jun 5 18:54:36 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Jun 2007 18:54:36 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <4666038D.8090700@gatworks.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> Message-ID: On Tue, 5 Jun 2007, Uncle George wrote: > Trent Jarvi wrote: >> >> >> Also note that enumeration only happens once. If you add a port such as >> a new USB dongle, the port will not be visible until the next time your >> application runs. > > Is this written in stone ? somewhere? It is just the current behavior. There is nothing preventing a fix that allows reenumeration. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Tue Jun 5 19:55:19 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 21:55:19 -0400 Subject: [Rxtx] problem with rxtx In-Reply-To: References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> Message-ID: <46661407.4020308@gatworks.com> >> Is this written in stone ? somewhere? > > It is just the current behavior. There is nothing preventing a fix that > allows reenumeration. With usb, ..... , things come and go. Seems a shame that you have to kill application to get at the device u just plugged in. From joachim at buechse.ch Wed Jun 6 01:50:06 2007 From: joachim at buechse.ch (Joachim Buechse) Date: Wed, 6 Jun 2007 09:50:06 +0200 Subject: [Rxtx] problem with rxtx In-Reply-To: <46661407.4020308@gatworks.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> <46661407.4020308@gatworks.com> Message-ID: <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> On MacOS RXTX's enumeration handling is more flexible. It will find new ports that are added during the lifetime of the application. But this is inherently incompatible with suns javax.comm implementation... Regards, Joachim On 06.06.2007, at 03:55, Uncle George wrote: > >>> Is this written in stone ? somewhere? >> >> It is just the current behavior. There is nothing preventing a >> fix that >> allows reenumeration. > > With usb, ..... , things come and go. Seems a shame that you have to > kill application to get at the device u just plugged in. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Jun 6 06:06:48 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Jun 2007 06:06:48 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> <46661407.4020308@gatworks.com> <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> Message-ID: Sun's javax.comm is not a major concern going forward. As long as we do not break old applications using rxtx, I see no reason to limit rxtx to that convention. We have already rejected version 3 from Sun as a dead end and limited our compatability to version 2. That does not mean we will not try to work with Sun and others but the current javax.comm convention (v3) is not a well conceived path. There has been discussion about doing a JSR which is one valid option. On Wed, 6 Jun 2007, Joachim Buechse wrote: > On MacOS RXTX's enumeration handling is more flexible. It will find > new ports that are added during the lifetime of the application. But > this is inherently incompatible with suns javax.comm implementation... > > Regards, > Joachim > > On 06.06.2007, at 03:55, Uncle George wrote: > >> >>>> Is this written in stone ? somewhere? >>> >>> It is just the current behavior. There is nothing preventing a >>> fix that >>> allows reenumeration. >> >> With usb, ..... , things come and go. Seems a shame that you have to >> kill application to get at the device u just plugged in. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From yvespielusenet at free.fr Wed Jun 6 08:46:35 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 16:46:35 +0200 Subject: [Rxtx] [PARALLEL] resource in use Message-ID: <1181141195.3407.20.camel@localhost.localdomain> Hello, I want to use rxtx in my application. I haveto send data to a very old printer (which have a drum and hammers http://perso.orange.fr/tiie/page00010017.html) This is printer is connecter with centronics. It works well but, while it's writting and I putthe printer off-line, after about 45 seconds, I have this error : ------------------------------------- java.io.IOException: La ressource demand?e est en cours d'utilisation. in writeArray at gnu.io.LPRPort.writeArray(Native Method) at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:292) at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:161) at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:156) at mce.buffer.bufferManager.BufferManager$PrintBuffer.run(BufferManager.java:141) The IOexception means "The wanted resource is in use" ------------------------------------- Here is the line 141 of BufferManager : ------------------------------------- while(send){ try{ fos.write(bb); <=== line 141 send = false; } catch(Exception e){ javax.swing.JOptionPane.showMessageDialog(null, "Erreur d'envoie. Veuillez cliquer sur OK pour relancer l'impression de la vignette.\nV?rifiez votre impression !", "Erreur d'envoie", javax.swing.JOptionPane.WARNING_MESSAGE); e.printStackTrace(System.err); System.err.flush(); System.out.println(e); send = true; } } -------------------------------- 'fos' is an outputstream which contains the rxtx stream (this.os is the rxtx outputstream) : -------------------------------- public void write(byte[] bb) throws IOException{ this.write(bb, 0, bb.length); } public void write(byte[] bb, int off, int len) throws IOException{ while(!imp1.isPrinterSelected() || !imp2.isPrinterSelected()){ } this.os.write(bb, off, len); } -------------------------------- Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( can you help me ? thank you :) -- yves piel From yvespielusenet at free.fr Wed Jun 6 09:11:15 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 17:11:15 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181141195.3407.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> Message-ID: <1181142675.3407.23.camel@localhost.localdomain> I forgot to tell that It's under windows XP and java 1.5. Le mercredi 06 juin 2007 ? 16:46 +0200, yves pielusenet a ?crit : > Hello, > I want to use rxtx in my application. I haveto send data to a very old > printer (which have a drum and hammers > http://perso.orange.fr/tiie/page00010017.html) > This is printer is connecter with centronics. It works well but, while > it's writting and I putthe printer off-line, after about 45 seconds, I > have this error : > ------------------------------------- > java.io.IOException: La ressource demand?e est en cours d'utilisation. > in writeArray > at gnu.io.LPRPort.writeArray(Native Method) > at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:292) > at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:161) > at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:156) > at mce.buffer.bufferManager.BufferManager$PrintBuffer.run(BufferManager.java:141) > > The IOexception means "The wanted resource is in use" > ------------------------------------- > > Here is the line 141 of BufferManager : > > ------------------------------------- > while(send){ > try{ > fos.write(bb); <=== line 141 > send = false; > } > catch(Exception e){ > javax.swing.JOptionPane.showMessageDialog(null, "Erreur d'envoie. Veuillez cliquer sur OK pour relancer l'impression de la vignette.\nV?rifiez votre impression !", "Erreur d'envoie", javax.swing.JOptionPane.WARNING_MESSAGE); > e.printStackTrace(System.err); > System.err.flush(); > System.out.println(e); > send = true; > } > } > -------------------------------- > 'fos' is an outputstream which contains the rxtx stream (this.os is the rxtx outputstream) : > > -------------------------------- > public void write(byte[] bb) throws IOException{ > this.write(bb, 0, bb.length); > } > public void write(byte[] bb, int off, int len) throws IOException{ > while(!imp1.isPrinterSelected() || !imp2.isPrinterSelected()){ > } > this.os.write(bb, off, len); > } > -------------------------------- > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > can you help me ? > > thank you :) > From netbeans at gatworks.com Wed Jun 6 09:21:46 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 11:21:46 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181141195.3407.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> Message-ID: <4666D10A.8000507@gatworks.com> } > -------------------------------- > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > can you help me ? > > thank you :) > windoz or linux? ( I guess windoz ) for windoz, there appears to be a timeout ( as Comments suggest ) of about 40seconds. > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } for linux, there is no implied timeout. > if( write( fd, bytes, count ) < 0 ) > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); From netbeans at gatworks.com Wed Jun 6 09:39:41 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 11:39:41 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666D10A.8000507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> Message-ID: <4666D53D.90000@gatworks.com> Uncle George wrote: > } >> -------------------------------- >> >> Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( >> >> can you help me ? From reading the code, I can see your concern. And it appears you are correct, because some of the data will be sent to the OS printer buffers, and then it will refuse to accept anymore. Unfortunately, writeArray does not return the num of characters written :{ So application has no idea to how many characters were accepted by the OS. I dont do windoz, so I cant say with absolute certainty what windoz will do with an off-line condition. If you have the source, and can compile, then maybe u can increase the loop count to hit 4hours? From yvespielusenet at free.fr Wed Jun 6 09:53:25 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 17:53:25 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666D10A.8000507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> Message-ID: <1181145205.3407.35.camel@localhost.localdomain> Thank you for your explanation :) This timeout comes when no data has been send to the printer after 40seconds if I well understand. But why there is such a timeout ? If I setthe printer offline while it's printing I mustn't have an exception. I don't understand why the "printer should solv all problems like buffer full" in 40 seconds. If I pause the printer the buffer will not be emptied, isn't it ? I not very familiar with C/C++, but it seem that the exception is thrown only when countWritten == 0, that means no data at all has been sent. So Is my code is good since when I intercept this exception I send all my buffer again. There is no way that the printer receive two times same bytes ? thanks ps: yes the application is running on windows XP since I developpe under Debian Le mercredi 06 juin 2007 ? 11:21 -0400, Uncle George a ?crit : > } > > -------------------------------- > > > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > > > can you help me ? > > > > thank you :) > > > > windoz or linux? ( I guess windoz ) > > for windoz, there appears to be a timeout ( as Comments suggest ) of > about 40seconds. > > while( count > 0 ){ > > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > > /* > > this are 20 * 2 seconds, in this time a printer (or other parallel device) > > should solv all problems like buffer full, etc > > */ > > if(errorCount++ < 20){ > > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > > continue; > > } > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > for linux, there is no implied timeout. > > if( write( fd, bytes, count ) < 0 ) > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Wed Jun 6 10:34:24 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 12:34:24 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181145205.3407.35.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> Message-ID: <4666E210.30507@gatworks.com> yves pielusenet wrote: > Thank you for your explanation :) > This timeout comes when no data has been send to the printer after > 40seconds if I well understand. But why there is such a timeout ? If I > setthe printer offline while it's printing I mustn't have an exception. > I don't understand why the "printer should solv all problems like buffer > full" in 40 seconds. If I pause the printer the buffer will not be > emptied, isn't it ? > > I not very familiar with C/C++, but it seem that the exception is thrown > only when countWritten == 0, that means no data at all has been sent. So > Is my code is good since when I intercept this exception I send all my > buffer again. There is no way that the printer receive two times same > bytes ? More technically, the function call returns and reports that 0 characters was written in this call. when 0 characters are written, it will check how many times 0 characters was written. If it has tried LESS than 20 times(errorCount), it will sleep() and try to write again. After 20 times, it wont sleep, but throw you the exception. Now suppose you are writing a 120 character line. you off-lined/paused your printer. The OS has room for 80 more characters in it's printer buffer. The WriteFile() will have a char count of 120, but on return the countWritten = 80. You still have 40 more characters to print. Since countWritten != 0, the counters: bytes += countWritten; count -= countWritten; get updated, and the Writefile now has a count of 40 characters. Since the printer is off-line, the countwritten is 0. And so the loop continues, till 40 seconds is up. As to why it is this way, i dont know ( not a windoz maven ); Also the sleep(20) in the loop is not so intuitive to suggest 2 seconds of sleep. I would have guessed 20seconds, or 20milliseconds. But go figure. BTW: Since your computer sends you error messages in French, does it curse in English? :)))) From yvespielusenet at free.fr Thu Jun 7 02:27:44 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Thu, 07 Jun 2007 10:27:44 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666E210.30507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> Message-ID: <1181204864.3501.10.camel@localhost.localdomain> Maybe in my case I should re-compile rxtx and change the code. Instead of send an exception I should display a dialog box to ask if it's printer problem or if it should trie to send bytes. Something like : while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } if(displayDialogBox("Try again to send datas ??")){ errorCount = 0; } else{ throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } } Le mercredi 06 juin 2007 ? 12:34 -0400, Uncle George a ?crit : > yves pielusenet wrote: > > Thank you for your explanation :) > > This timeout comes when no data has been send to the printer after > > 40seconds if I well understand. But why there is such a timeout ? If I > > setthe printer offline while it's printing I mustn't have an exception. > > I don't understand why the "printer should solv all problems like buffer > > full" in 40 seconds. If I pause the printer the buffer will not be > > emptied, isn't it ? > > > > I not very familiar with C/C++, but it seem that the exception is thrown > > only when countWritten == 0, that means no data at all has been sent. So > > Is my code is good since when I intercept this exception I send all my > > buffer again. There is no way that the printer receive two times same > > bytes ? > More technically, the function call returns and reports that 0 > characters was written in this call. > when 0 characters are written, it will check how many times 0 characters > was written. If it has tried LESS than 20 times(errorCount), it will > sleep() and try to write again. > After 20 times, it wont sleep, but throw you the exception. > > Now suppose you are writing a 120 character line. you off-lined/paused > your printer. The OS has room for 80 more characters in it's printer > buffer. The WriteFile() will have a char count of 120, but on return the > countWritten = 80. You still have 40 more characters to print. > Since countWritten != 0, the counters: > bytes += countWritten; > count -= countWritten; > get updated, and the Writefile now has a count of 40 characters. Since > the printer is off-line, the countwritten is 0. And so the loop > continues, till 40 seconds is up. > > As to why it is this way, i dont know ( not a windoz maven ); > Also the sleep(20) in the loop is not so intuitive to suggest 2 seconds > of sleep. I would have guessed 20seconds, or 20milliseconds. But go figure. > > BTW: Since your computer sends you error messages in French, does it > curse in English? :)))) > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 06:11:43 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 08:11:43 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181204864.3501.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> Message-ID: <4667F5FF.8070903@gatworks.com> your suggestion appears good. I dont know what displayDialogBox exactly will do, so all I can say it that it looks good. But I'd like to wait 10min before first dialog box And a 5 min wait for every dialog box there after. And since these are custom solution/choices, maybe a more exact explanation of what the issue is. if(errorCount++ < 300){ // wait 10min ( 10min * 60sec / 2 ) Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } if(displayDialogBox("Printer has Paused. Retry sending data?")){ errorCount = 150; // Wait for 5 min thereafter continue; } > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } yves pielusenet wrote: > Maybe in my case I should re-compile rxtx and change the code. Instead > of send an exception I should display a dialog box to ask if it's > printer problem or if it should trie to send bytes. Something like : > > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > > if(displayDialogBox("Try again to send datas ??")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > } > From yvespielusenet at free.fr Thu Jun 7 07:17:21 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Thu, 07 Jun 2007 15:17:21 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4667F5FF.8070903@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <4667F5FF.8070903@gatworks.com> Message-ID: <1181222241.3501.20.camel@localhost.localdomain> thank you :) 'displayDialogBox()' I think doesn't exist. It was just for the example :) But I think It should not be so complicated to display a dialog box under windows with YES/NO buttons. When yes is clicked it return 0 other it returns 1. Le jeudi 07 juin 2007 ? 08:11 -0400, Uncle George a ?crit : > your suggestion appears good. I dont know what displayDialogBox exactly > will do, so all I can say it that it looks good. > > But I'd like to wait 10min before first dialog box And a 5 min wait for > every dialog box there after. And since these are custom > solution/choices, maybe a more exact explanation of what the issue is. > > if(errorCount++ < 300){ // wait 10min ( 10min * 60sec / 2 ) > Sleep( 20 ); /* make a small pause to execute all other requests > in all other threads */ > continue; > } > > if(displayDialogBox("Printer has Paused. Retry sending data?")){ > errorCount = 150; // Wait for 5 min thereafter > continue; > } > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > > yves pielusenet wrote: > > Maybe in my case I should re-compile rxtx and change the code. Instead > > of send an exception I should display a dialog box to ask if it's > > printer problem or if it should trie to send bytes. Something like : > > > > while( count > 0 ){ > > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > > /* > > this are 20 * 2 seconds, in this time a printer (or other parallel device) > > should solv all problems like buffer full, etc > > */ > > if(errorCount++ < 20){ > > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > > continue; > > } > > > > if(displayDialogBox("Try again to send datas ??")){ > > errorCount = 0; > > } > > else{ > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > } > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 07:41:43 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 09:41:43 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181222241.3501.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <4667F5FF.8070903@gatworks.com> <1181222241.3501.20.camel@localhost.localdomain> Message-ID: <46680B17.8050109@gatworks.com> yves pielusenet wrote: > thank you :) > 'displayDialogBox()' I think doesn't exist. It was just for the > example :) too bad. Good luck. From rtrout at webbresearch.com Thu Jun 7 11:23:04 2007 From: rtrout at webbresearch.com (Robert Trout) Date: Thu, 07 Jun 2007 13:23:04 -0400 Subject: [Rxtx] Disconnected PortServer TS causes Java to hang Message-ID: <1181236984.14186.33.camel@sisyphus.DinkumSoftware.com> I'm running Linux with sun's Java 1.4.2, Java comm API 2.0, RXTX 2.0-7pre1, and the RealPort digi driver. "/dev/ttyrp00" is a RealPort device. My Java application never returns from a ComPortIdentifier.getPortIdentifier("/dev/ttyrp00") call while the Digi PortServer TS 4 is disconnected from the network. If I later re-connect the PortServer, the call returns about 30 seconds later (it's like a serial port read or write is blocking until the PortServer is re- connected). With the PortServer disconnected, minicom immediately responds with "cannot open /dev/ttyrp00: No such file or directory". I would like my Java application to behave similarly. That is, respond with an error condition instead of hanging when the PortServer is not connected. Since minicom and Java behave differently, I think this "hanging" behavior may be due to RXTX or Java? Has anyone had a similar issue? Solutions? Suggestions? Thanks, Robert From vicnevicne at gmail.com Thu Jun 7 12:16:02 2007 From: vicnevicne at gmail.com (Vicne) Date: Thu, 07 Jun 2007 20:16:02 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181204864.3501.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> Message-ID: <46684B62.7080802@gmail.com> yves pielusenet wrote: > Maybe in my case I should re-compile rxtx and change the code. Instead > of send an exception I should display a dialog box to ask if it's > printer problem or if it should trie to send bytes. Something like : > > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > > if(displayDialogBox("Try again to send datas ??")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > } > Sorry to step in without a specific solution to your problem, but I wanted to share my feeling regarding this proposal. AFAIK, it's generally considered bad practice to pop-up a prompt from a library. The main reason is that in general use, you can't guarantee that someone is actually present behind the console. Imagine a print server in a machine room, connected to a park of printers. In that case, when one printer fails, the logical behaviour would be to use an other one. If you change RxTx the way you propose, the printer queue will simply be stuck with a useless "Try again to send data ?" prompt until an administrator opens a remote connection to the print server's console and clicks "no". Second, it would create a dependency upon the existence of a graphical console (if you go the graphical "dialogBox" way). On many applications (typically server or embedded ones), the JVM is "headless" and if you try to pop-up a dialog, your app would throw an exception (at best) or just wouldn't display the prompt anywhere... Going the "text console" way is not more reliable, because on graphical environments, the text console is hidden unless explicitly requested. My advice would be to think again and find another solution. Ideas are : - make the number of retries a parameter so that you can tune it to what you think is reasonable - throw a more specific exception when the number of retries has been reached, so that a specific prompt can be shown at a higher level Anyway, if you feel that the prompt is the way to go in your case, I would at least make that prompt conditional. The least intrusive way would probably be using a system property, like if("true".equals(System.getProperty("org.rxtx.usePrompt")) && displayDialogBox("Retry sending data ?")){ errorCount = 0; } else{ throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } By default, the behaviour would remain as it is now, but you could force the prompts by defining the property at VM launch if desired. (for example : java.exe -Dorg.rxtx.usePrompt=true myApp) Also, you seemed to say you wanted the printer to start again exactly where is stopped. It would indeed be the best way when the printer is put offline for a few seconds. On the other hand, if the printer is turned off (or the printer runs out of paper, or someone steps on the mains cable), then the only way to go back to a "stable" situation would be by printing the item (page, label, etc.) again from scratch... Just my two cents. Vicne PS : By the way, the dialog box thing is very platform dependant on the C-side, and I think the simplest way would probably be to bridge it to a Java call where you can implement it like you proposed : public boolean displayDialogBox(prompt) { return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); } From netbeans at gatworks.com Thu Jun 7 14:08:24 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 16:08:24 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46684B62.7080802@gmail.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> Message-ID: <466865B8.4060004@gatworks.com> My feeling is that the code that was suggested was for his environs ( his shop ). The issue here is that after a 40+ second wait, an exception will be thrown. But you really dont have a way of 'cancelling' all the WriteFiles() that have already occured before the exception so that your writeArray and the Commapi can backtrack to a position in which they are in sync. The main ( really mine ) concern is not to lose data, or replicate data. After 40seconds, 300 seconds, 55min, no matter how long, data should not be lost or duplicated. But as soon as the exception is thrown, that possibility exists. Maybe an event should be thrown instead? Vicne wrote: > yves pielusenet wrote: >> Maybe in my case I should re-compile rxtx and change the code. Instead >> of send an exception I should display a dialog box to ask if it's >> printer problem or if it should trie to send bytes. Something like : >> >> while( count > 0 ){ >> if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ >> /* >> this are 20 * 2 seconds, in this time a printer (or other parallel device) >> should solv all problems like buffer full, etc >> */ >> if(errorCount++ < 20){ >> Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ >> continue; >> } >> >> if(displayDialogBox("Try again to send datas ??")){ >> errorCount = 0; >> } >> else{ >> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >> break; >> } >> } >> > > Sorry to step in without a specific solution to your problem, but I > wanted to share my feeling regarding this proposal. AFAIK, it's > generally considered bad practice to pop-up a prompt from a library. > The main reason is that in general use, you can't guarantee that > someone is actually present behind the console. Imagine a print server > in a machine room, connected to a park of printers. In that case, when > one printer fails, the logical behaviour would be to use an other one. > If you change RxTx the way you propose, the printer queue will simply be > stuck with a useless "Try again to send data ?" prompt until an > administrator opens a remote connection to the print server's console > and clicks "no". > Second, it would create a dependency upon the existence of a > graphical console (if you go the graphical "dialogBox" way). On many > applications (typically server or embedded ones), the JVM is "headless" > and if you try to pop-up a dialog, your app would throw an exception (at > best) or just wouldn't display the prompt anywhere... Going the "text > console" way is not more reliable, because on graphical environments, > the text console is hidden unless explicitly requested. > > My advice would be to think again and find another solution. Ideas are : > - make the number of retries a parameter so that you can tune it to what > you think is reasonable > - throw a more specific exception when the number of retries has been > reached, so that a specific prompt can be shown at a higher level > > Anyway, if you feel that the prompt is the way to go in your case, I > would at least make that prompt conditional. The least intrusive way > would probably be using a system property, like > > if("true".equals(System.getProperty("org.rxtx.usePrompt")) > && displayDialogBox("Retry sending data ?")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > > > By default, the behaviour would remain as it is now, but you could > force the prompts by defining the property at VM launch if desired. (for > example : java.exe -Dorg.rxtx.usePrompt=true myApp) > > > Also, you seemed to say you wanted the printer to start again > exactly where is stopped. It would indeed be the best way when the > printer is put offline for a few seconds. On the other hand, if the > printer is turned off (or the printer runs out of paper, or someone > steps on the mains cable), then the only way to go back to a "stable" > situation would be by printing the item (page, label, etc.) again from > scratch... > > > Just my two cents. > > > Vicne > > PS : By the way, the dialog box thing is very platform dependant on the > C-side, and I think the simplest way would probably be to bridge it to a > Java call where you can implement it like you proposed : > > public boolean displayDialogBox(prompt) { > return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", > JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); > } > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Thu Jun 7 17:48:11 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 Jun 2007 17:48:11 -0600 (MDT) Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <466865B8.4060004@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> Message-ID: An event is possible. I'm amazed this is the largest problem encountered while using the parallel code. How would the write ever exit if we throw events? Isn't this going to lead to hung applications? On Thu, 7 Jun 2007, Uncle George wrote: > My feeling is that the code that was suggested was for his environs ( > his shop ). > > The issue here is that after a 40+ second wait, an exception will be > thrown. But you really dont have a way of 'cancelling' all the > WriteFiles() that have already occured before the exception so that your > writeArray and the Commapi can backtrack to a position in which they are > in sync. > > The main ( really mine ) concern is not to lose data, or replicate data. > After 40seconds, 300 seconds, 55min, no matter how long, data should > not be lost or duplicated. But as soon as the exception is thrown, that > possibility exists. > > Maybe an event should be thrown instead? > > Vicne wrote: >> yves pielusenet wrote: >>> Maybe in my case I should re-compile rxtx and change the code. Instead >>> of send an exception I should display a dialog box to ask if it's >>> printer problem or if it should trie to send bytes. Something like : >>> >>> while( count > 0 ){ >>> if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ >>> /* >>> this are 20 * 2 seconds, in this time a printer (or other parallel device) >>> should solv all problems like buffer full, etc >>> */ >>> if(errorCount++ < 20){ >>> Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ >>> continue; >>> } >>> >>> if(displayDialogBox("Try again to send datas ??")){ >>> errorCount = 0; >>> } >>> else{ >>> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >>> break; >>> } >>> } >>> >> >> Sorry to step in without a specific solution to your problem, but I >> wanted to share my feeling regarding this proposal. AFAIK, it's >> generally considered bad practice to pop-up a prompt from a library. >> The main reason is that in general use, you can't guarantee that >> someone is actually present behind the console. Imagine a print server >> in a machine room, connected to a park of printers. In that case, when >> one printer fails, the logical behaviour would be to use an other one. >> If you change RxTx the way you propose, the printer queue will simply be >> stuck with a useless "Try again to send data ?" prompt until an >> administrator opens a remote connection to the print server's console >> and clicks "no". >> Second, it would create a dependency upon the existence of a >> graphical console (if you go the graphical "dialogBox" way). On many >> applications (typically server or embedded ones), the JVM is "headless" >> and if you try to pop-up a dialog, your app would throw an exception (at >> best) or just wouldn't display the prompt anywhere... Going the "text >> console" way is not more reliable, because on graphical environments, >> the text console is hidden unless explicitly requested. >> >> My advice would be to think again and find another solution. Ideas are : >> - make the number of retries a parameter so that you can tune it to what >> you think is reasonable >> - throw a more specific exception when the number of retries has been >> reached, so that a specific prompt can be shown at a higher level >> >> Anyway, if you feel that the prompt is the way to go in your case, I >> would at least make that prompt conditional. The least intrusive way >> would probably be using a system property, like >> >> if("true".equals(System.getProperty("org.rxtx.usePrompt")) >> && displayDialogBox("Retry sending data ?")){ >> errorCount = 0; >> } >> else{ >> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >> break; >> } >> >> >> By default, the behaviour would remain as it is now, but you could >> force the prompts by defining the property at VM launch if desired. (for >> example : java.exe -Dorg.rxtx.usePrompt=true myApp) >> >> >> Also, you seemed to say you wanted the printer to start again >> exactly where is stopped. It would indeed be the best way when the >> printer is put offline for a few seconds. On the other hand, if the >> printer is turned off (or the printer runs out of paper, or someone >> steps on the mains cable), then the only way to go back to a "stable" >> situation would be by printing the item (page, label, etc.) again from >> scratch... >> >> >> Just my two cents. >> >> >> Vicne >> >> PS : By the way, the dialog box thing is very platform dependant on the >> C-side, and I think the simplest way would probably be to bridge it to a >> Java call where you can implement it like you proposed : >> >> public boolean displayDialogBox(prompt) { >> return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", >> JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); >> } >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 19:18:51 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 21:18:51 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> Message-ID: <4668AE7B.3060409@gatworks.com> The UNIX version of writeArray is not too great either. It is possible that the write will only process some of the bytes. #else if( write( fd, bytes, count ) < 0 ) throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); #endif -------------------------------- Maybe it might be better to have the native function inform the caller of the # of characters written, then the commapi/output-buffer can be modified to reflect the #of chars written. If an exception is to be thrown, for too many loops of chars written == 0, then exception wont affect the state of the output buffer. Then a ParallelPort.restart() can be called to resume printing whats in the buffer. Trent Jarvi wrote: > An event is possible. I'm amazed this is the largest problem encountered > while using the parallel code. > > How would the write ever exit if we throw events? Isn't this going to > lead to hung applications? Sure. If you dont time out, then there is nothing that will force an EXIT from the write(). Issue is what has the OS done with the write. > > On Thu, 7 Jun 2007, Uncle George wrote: > >> My feeling is that the code that was suggested was for his environs ( >> his shop ). From yvespielusenet at free.fr Fri Jun 8 01:09:01 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Fri, 08 Jun 2007 09:09:01 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4668AE7B.3060409@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> Message-ID: <1181286541.3674.10.camel@localhost.localdomain> It is not possible that the rxtx java method write(byte[], int offset, int length) return anint which contains the number of byte really send to the printer instead of an exception ? So this is the programm which will see if all bytes have been sent. If not it can retry to send the unsended bytes. -------------------------------------------------------- int sended = 0; while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ sended += countWritten; /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } return sended; /*throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break;*/ } ... ... return countWritten; ------------------------------------------------ Le jeudi 07 juin 2007 ? 21:18 -0400, Uncle George a ?crit : > The UNIX version of writeArray is not too great either. It is possible > that the write will only process some of the bytes. > > #else > if( write( fd, bytes, count ) < 0 ) > throw_java_exception_system_msg( env, IO_EXCEPTION, > "writeArray" ); > #endif > -------------------------------- > > Maybe it might be better to have the native function inform the caller > of the # of characters written, then the commapi/output-buffer can be > modified to reflect the #of chars written. If an exception is to be > thrown, for too many loops of chars written == 0, then exception wont > affect the state of the output buffer. Then a ParallelPort.restart() can > be called to resume printing whats in the buffer. > > > Trent Jarvi wrote: > > An event is possible. I'm amazed this is the largest problem encountered > > while using the parallel code. > > > > How would the write ever exit if we throw events? Isn't this going to > > lead to hung applications? > Sure. If you dont time out, then there is nothing that will force an > EXIT from the write(). Issue is what has the OS done with the write. > > > > On Thu, 7 Jun 2007, Uncle George wrote: > > > >> My feeling is that the code that was suggested was for his environs ( > >> his shop ). > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Fri Jun 8 03:45:00 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 11:45:00 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181286541.3674.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> Message-ID: <20070608094500.GC21069@elberon.bln.de.ingenico.com> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > It is not possible that the rxtx java method write(byte[], int offset, > int length) return anint which contains the number of byte really send > to the printer instead of an exception ? > So this is the programm which will see if all bytes have been sent. If > not it can retry to send the unsended bytes. I think write() is void because in Java people love to do this since OutputStream :-) Of course on such interfaces you cannot implement something nice. If you would have a int write, you would not implement the interface and no applications expecting this interface would link/work/compile. oki, Steffen P.S.: (OT) If you propose not to implement the Java interfaces (especially not on JNI level), maybe optionally offering a wrapper that removes e.g. the write return value and so on to downgrade the powerful classic old POSIX read/write style to the modern limited Java style, then I agree :-) Same for read. Instead of things like "int avialable()" it is more powerful to have an approach as select(2) offers (to guarante the caller that read/write will not block [nothing else make sense anyway IMHO] but may read/write less bytes then requested). The caller gets full control and the higher level protocols can care about timeouts, invoking read in some loops and/or implement retransmission. On top of such an implementation, where everything is controlled, defined, guaranteed and reliable, someone could use an InputStream or OutputStream style interface. Or even better: don't use them at all :) just BTW :-) St. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From yvespielusenet at free.fr Fri Jun 8 05:52:45 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Fri, 08 Jun 2007 13:52:45 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <20070608094500.GC21069@elberon.bln.de.ingenico.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> Message-ID: <1181303565.11203.3.camel@localhost.localdomain> So maybe a better way should be to create a new Exception class which has a method "int getWrittenByte()". So the Exception should be use to send again bytes which are not printed yet. yves Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : > * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > > It is not possible that the rxtx java method write(byte[], int offset, > > int length) return anint which contains the number of byte really send > > to the printer instead of an exception ? > > So this is the programm which will see if all bytes have been sent. If > > not it can retry to send the unsended bytes. > > I think write() is void because in Java people love to do this > since OutputStream :-) Of course on such interfaces you cannot > implement something nice. If you would have a int write, you > would not implement the interface and no applications expecting > this interface would link/work/compile. > > oki, > > Steffen > > P.S.: (OT) > If you propose not to implement the Java interfaces (especially > not on JNI level), maybe optionally offering a wrapper that > removes e.g. the write return value and so on to downgrade the > powerful classic old POSIX read/write style to the modern limited > Java style, then I agree :-) Same for read. Instead of things > like "int avialable()" it is more powerful to have an approach as > select(2) offers (to guarante the caller that read/write will not > block [nothing else make sense anyway IMHO] but may read/write > less bytes then requested). The caller gets full control and the > higher level protocols can care about timeouts, invoking read in > some loops and/or implement retransmission. On top of such an > implementation, where everything is controlled, defined, > guaranteed and reliable, someone could use an InputStream or > OutputStream style interface. Or even better: don't use them at > all :) just BTW :-) > St. > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > 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. > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > 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. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Fri Jun 8 06:46:21 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 08:46:21 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181303565.11203.3.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> Message-ID: <46694F9D.5080501@gatworks.com> It seems that with outputstream.write(b[]), you become terribly uncoordinated as soon as an exception is thrown. Docs do not say what happens to the data. Yet from a practicable point of view, one would like to know if the write was accepted in-full, or rejected before any writes. There are no in betweens, as partial writes are not reportable. So for an outputstream.write(), in order for it to return, the full write request has to be taken, and stored in an internal output buffer. If there is no room, the write() is suspended, till there is room. Or throw's an IOException( "no room in buffer") ; As the select() loop for write reports buffer room avail, then more of the internal buffer is sent to the printer. yves pielusenet wrote: > So maybe a better way should be to create a new Exception class which > has a method "int getWrittenByte()". So the Exception should be use to > send again bytes which are not printed yet. > > yves > > Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : >> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: >>> It is not possible that the rxtx java method write(byte[], int offset, >>> int length) return anint which contains the number of byte really send >>> to the printer instead of an exception ? >>> So this is the programm which will see if all bytes have been sent. If >>> not it can retry to send the unsended bytes. >> I think write() is void because in Java people love to do this >> since OutputStream :-) Of course on such interfaces you cannot >> implement something nice. If you would have a int write, you >> would not implement the interface and no applications expecting >> this interface would link/work/compile. >> >> oki, >> >> Steffen >> >> P.S.: (OT) >> If you propose not to implement the Java interfaces (especially >> not on JNI level), maybe optionally offering a wrapper that >> removes e.g. the write return value and so on to downgrade the >> powerful classic old POSIX read/write style to the modern limited >> Java style, then I agree :-) Same for read. Instead of things >> like "int avialable()" it is more powerful to have an approach as >> select(2) offers (to guarante the caller that read/write will not >> block [nothing else make sense anyway IMHO] but may read/write >> less bytes then requested). The caller gets full control and the >> higher level protocols can care about timeouts, invoking read in >> some loops and/or implement retransmission. On top of such an >> implementation, where everything is controlled, defined, >> guaranteed and reliable, someone could use an InputStream or >> OutputStream style interface. Or even better: don't use them at >> all :) just BTW :-) >> St. >> >> About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. >> 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. >> >> About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. >> 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. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From Steffen.DETTMER at ingenico.com Fri Jun 8 08:12:18 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 16:12:18 +0200 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <46694F9D.5080501@gatworks.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: <20070608141218.GE21069@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 08:46 -0400: > It seems that with outputstream.write(b[]), you become terribly > uncoordinated as soon as an exception is thrown. Docs do not say what > happens to the data. (yes, so avoiding it seems to be good :)) > Yet from a practicable point of view, one would like to know if the > write was accepted in-full, or rejected before any writes. There are no > in betweens, as partial writes are not reportable. (which is an artificial API limitation. I never understood how this happend when they invented JDK because the well-known BSD socket API and thus [probably] WinSock does this correct, but anyway) > So for an outputstream.write(), in order for it to return, the full > write request has to be taken, and stored in an internal output buffer. > If there is no room, the write() is suspended, till there is room. Or > throw's an IOException( "no room in buffer") ; As the select() loop for > write reports buffer room avail, then more of the internal buffer is > sent to the printer. yes, might be good in case of a printer. May be horrible in case of PPP/TCP or some other transmission control protocol which may e.g. repeat data or even omit parts of it (e.g. internet realtime radio station broadcasting)... So I think the idea of "int write" (e.g. BSD sockets, linux files and so on) still is the best. A clean API / implementation should guarantee and allow implementations (users) to rely on that; assumptions and automatic background-sending and so on may look pragmatic and may even work on the first look, but may fail in other situations. BTW, if e.g. BSD socket API is known, why not simply copy it (until something better is invented :)) instead of fiddling around with JDK APIs? anyway, have a nice weekend everyone :-) oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Fri Jun 8 08:55:56 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 10:55:56 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070608141218.GE21069@elberon.bln.de.ingenico.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> Message-ID: <46696DFC.7000801@gatworks.com> >> write reports buffer room avail, then more of the internal buffer is >> sent to the printer. > > yes, might be good in case of a printer. May be horrible in case > of PPP/TCP or some other transmission control protocol which > may e.g. repeat data or even omit parts of it (e.g. internet > realtime radio station broadcasting)... So I think the idea of > "int write" (e.g. BSD sockets, linux files and so on) still is > the best. A clean API / implementation should guarantee and allow > implementations (users) to rely on that; assumptions and > automatic background-sending and so on may look pragmatic and may > even work on the first look, but may fail in other situations. > BTW, if e.g. BSD socket API is known, why not simply copy it > (until something better is invented :)) instead of fiddling > around with JDK APIs? But we were talking about the Parallel Port, and the transmission of data over the commapi/parallel-port schema. There isn't much in bi-directional software communication. Its a simple write one byte at a time interface. I'm not looking to change the comm-api. I'm just looking to alter the interaction between the Native ParallelPort functions, and the java ParallelPort functions that call them. This might be more readily doable than to get a committee to re-specify java-API specs. BTW: Whats is off-topic? ( help: not looking for def of off-topic ) From j.kenneth.gentle at acm.org Fri Jun 8 08:58:59 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Fri, 08 Jun 2007 10:58:59 -0400 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <20070608141218.GE21069@elberon.bln.de.ingenico.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> Message-ID: <200706081459.l58Ex5rA019991@qbang.org> Perhaps it is a bit late to jump in on this one, but here goes anyway. If the solutions all seem to "break" the contract with "java.io.outputstream", then, as noted, that may not be the appropriate contract. At the risk of being heretical, JDK1.4 introduced the "nio" package to address some of the compatibility issues with C apis mentioned in previous posts. The interface "java.nio.channels.WriteableByteChannel" defines the following single method: int write(ByteBuffer source); int, strangely enough, is the actual number of bytes written. So, if RXTX as written, against the JavaCOMM api and OutputStream, doesn't do what we want, how about writing a different set of bindings using the java.nio classes and as much of the underlying native code as possible. Note that just because the java.nio.channels.WriteableByteChannel sends back a result, OutputStream.write doesn't have to - and they could both call the same underlying native code. My 2 cents - maybe not worth even that... Ken From netbeans at gatworks.com Fri Jun 8 10:37:28 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 12:37:28 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <200706081459.l58Ex5rA019991@qbang.org> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> Message-ID: <466985C8.8000505@gatworks.com> Ken Gentle wrote: > Perhaps it is a bit late to jump in on this one, but here goes anyway. Common in, the waters fine. > > If the solutions all seem to "break" the contract with > "java.io.outputstream", then, as noted, that may not be the > appropriate contract. > How would the contract be broken? The machinery underneath is handling the contract. From j.kenneth.gentle at acm.org Fri Jun 8 10:48:01 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Fri, 08 Jun 2007 12:48:01 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466985C8.8000505@gatworks.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> Message-ID: <200706081648.l58Gm7YA022904@qbang.org> At 12:37 2007-06-08, you wrote: >Ken Gentle wrote: > > > > If the solutions all seem to "break" the contract with > > "java.io.outputstream", then, as noted, that may not be the > > appropriate contract. > > >How would the contract be broken? The machinery underneath is handling >the contract. It seems that a lot of the discussion has been about not only the timeout and being able to adjust it in the "machinery layer", but also about knowing in the Java layer, in the event of a timeout or exception, how many characters have been written to the device. An OutputStream won't ever do this with out an extension and including a return value "breaks" the contract, right? So, go with a Java IO api that *does* return the number of bytes written, out of the NIO package. I know it doesn't allow for a strict implementation of the JavaCOMM API - however, using NIO classes in place of the IO classes isn't that big a break and would allow those applications that need such information a way to get it. Maybe I'm misunderstanding the problem... Ken From netbeans at gatworks.com Fri Jun 8 11:24:14 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 13:24:14 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <200706081648.l58Gm7YA022904@qbang.org> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> Message-ID: <466990BE.7040100@gatworks.com> Ken Gentle wrote: An > OutputStream won't ever do this with out an extension and including a > return value "breaks" the contract, right? > i was not thinking of change the API to OutputSream. Are there specs for how output stream should work internally? for instance: String data = "Hello this is a line of data"; Outputstream.write( data.getbytes() ); ParallelPort.suspend(); int free = ParallelPort.getoutputbufferfree(); There is a symbiotic relationship between outputstream and the functionality of ParallelPort. From Steffen.DETTMER at ingenico.com Fri Jun 8 11:15:39 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 19:15:39 +0200 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <200706081459.l58Ex5rA019991@qbang.org> References: <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> Message-ID: <20070608171539.GK21069@elberon.bln.de.ingenico.com> * Ken Gentle wrote on Fri, Jun 08, 2007 at 10:58 -0400: > If the solutions all seem to "break" the contract with > "java.io.outputstream", then, as noted, that may not be the > appropriate contract. > > At the risk of being heretical, JDK1.4 introduced the "nio" package > to address some of the compatibility issues with C apis mentioned in > previous posts. The interface > "java.nio.channels.WriteableByteChannel" defines the following single method: > > int write(ByteBuffer source); > > int, strangely enough, is the actual number of bytes written. Yes, AFAIK one of the motivations for the NIO interface was, that the JDK-1.3 APIs (InputStream, e.g.) were not powerfull enough, especially for multi-connection-TCP servers or so. I don't know much about it but I've heard of a project where NIO usage was removed because of stability issues in multi-threaded environments and performance limitations under some circumstances. IIRC the "nio.ByteBuffer" is something very special (namely something you cannot implement in Java, it is "magic" or part of the language itself). Not sure if this is such a great idea (but for performance in the end sometimes heavy prices must be paid) :) > So, if RXTX as written, against the JavaCOMM api and OutputStream, > doesn't do what we want, how about writing a different set of > bindings using the java.nio classes and as much of the underlying > native code as possible. Yes, this would be an idea: use a full-featured interface on JNI, and, if wanted, deliver some wrappers converting this to a less-featured Java-compliant interface. However, powerful things as e.g. "select" are difficult to "emulate" if you are e.g. on some (older?) windows. But if you expose the full-featured APIs, you need to emulate them full-featured, theoretically. In the end it depends what you do on the serial line. If you just want to talk to a modem, then you may not need precise timeouts. But if you need to implement complexer protocols which define response times and timeouts, you may quickly get into difficulties. For instance, AFAIK, rxtx 1.7.2 (?) for windows is very messy with timeouts (there is a maximum, higher values are truncated; resolution is 100ms only; the function may take up to twice the timeout because internally it may be called twice). Probably for most people this is OK, but probably not for all. But having precise timeouts should be OK for all :-) Well, in the end it is nice to wish but somewhat hard to implement (many platforms, connections, USB, BlueTooth, whatever). oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Steffen.DETTMER at ingenico.com Fri Jun 8 11:04:22 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 19:04:22 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <46696DFC.7000801@gatworks.com> References: <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <46696DFC.7000801@gatworks.com> Message-ID: <20070608170422.GJ21069@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 10:55 -0400: > > BTW, if e.g. BSD socket API is known, why not simply copy it > > (until something better is invented :)) instead of fiddling > > around with JDK APIs? > > But we were talking about the Parallel Port, and the > transmission of data over the commapi/parallel-port schema. > There isn't much in bi-directional software communication. Its > a simple write one byte at a time interface. First, there are things like PLIP (http://en.wikipedia.org/wiki/Plip) - well, probably not widely used, sure ;) Second, I think if there is a good simple API known to support all that (with known "best practices") or so and there is no forcing need to invent a new one, why not simply using it? > I'm not looking to change the comm-api. I'm just looking to > alter the interaction between the Native ParallelPort > functions, and the java ParallelPort functions that call them. Ahh, yes. I think this is what I tried to ask. Having an usable JNI interface and on top (in pure java) some wrapper to InputStream or whatever could be done (e.g. by ignoring the return value of write or throwing if != length). Developers could then use the full-featured (non-JAVA-standard) API or select among various wrappers (as InputStream). > This might be more readily doable than to get a committee to > re-specify java-API specs. Yes, of course. I'm afraid that the Java APIs change regularily, but still yet with limited success it seems, so maybe they get it in one of the next iterations; who knows, maybe Java-9 has a BSD-like socket API :) SCNR. > BTW: Whats is off-topic? ( help: not looking for def of > off-topic ) I think I started some "re-specify java-API specs" which was OT probably. oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From lists at iDIAcomputing.com Fri Jun 8 18:48:54 2007 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Fri, 08 Jun 2007 20:48:54 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46684B62.7080802@gmail.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> Message-ID: <4669F8F6.3040101@iDIAcomputing.com> Vicne wrote: > Sorry to step in without a specific solution to your problem, but I > wanted to share my feeling regarding this proposal. AFAIK, it's > generally considered bad practice to pop-up a prompt from a library. ... > > My advice would be to think again and find another solution. Ideas are : > - make the number of retries a parameter so that you can tune it to what > you think is reasonable > - throw a more specific exception when the number of retries has been > reached, so that a specific prompt can be shown at a higher level You could also allow the client code to register a callback class which returns a boolean indicating whether to retry or cancel. This callback class could pop up a dialog, if appropriate, or follow some preset policy, or.... - George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From joachim at buechse.ch Sat Jun 9 09:43:16 2007 From: joachim at buechse.ch (Joachim Buechse) Date: Sat, 9 Jun 2007 17:43:16 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46694F9D.5080501@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: You should not forget, that in the case of an exception it may not even be known what happened to the data. You have a kernel buffer, outgoing chip buffer, incoming chip buffer, etc. So of course, it would be nice to know up to which point data was correctly processed, but this feedback does not exist on the hardware or protocol level and hence can in general not be magicly created on the software level... Regards, Joachim On 08.06.2007, at 14:46, Uncle George wrote: > It seems that with outputstream.write(b[]), you become terribly > uncoordinated as soon as an exception is thrown. Docs do not say what > happens to the data. > > Yet from a practicable point of view, one would like to know if the > write was accepted in-full, or rejected before any writes. There > are no > in betweens, as partial writes are not reportable. > > So for an outputstream.write(), in order for it to return, the full > write request has to be taken, and stored in an internal output > buffer. > If there is no room, the write() is suspended, till there is room. Or > throw's an IOException( "no room in buffer") ; As the select() loop > for > write reports buffer room avail, then more of the internal buffer is > sent to the printer. > > > > yves pielusenet wrote: >> So maybe a better way should be to create a new Exception class which >> has a method "int getWrittenByte()". So the Exception should be >> use to >> send again bytes which are not printed yet. >> >> yves >> >> Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : >>> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: >>>> It is not possible that the rxtx java method write(byte[], int >>>> offset, >>>> int length) return anint which contains the number of byte >>>> really send >>>> to the printer instead of an exception ? >>>> So this is the programm which will see if all bytes have been >>>> sent. If >>>> not it can retry to send the unsended bytes. >>> I think write() is void because in Java people love to do this >>> since OutputStream :-) Of course on such interfaces you cannot >>> implement something nice. If you would have a int write, you >>> would not implement the interface and no applications expecting >>> this interface would link/work/compile. >>> >>> oki, >>> >>> Steffen >>> >>> P.S.: (OT) >>> If you propose not to implement the Java interfaces (especially >>> not on JNI level), maybe optionally offering a wrapper that >>> removes e.g. the write return value and so on to downgrade the >>> powerful classic old POSIX read/write style to the modern limited >>> Java style, then I agree :-) Same for read. Instead of things >>> like "int avialable()" it is more powerful to have an approach as >>> select(2) offers (to guarante the caller that read/write will not >>> block [nothing else make sense anyway IMHO] but may read/write >>> less bytes then requested). The caller gets full control and the >>> higher level protocols can care about timeouts, invoking read in >>> some loops and/or implement retransmission. On top of such an >>> implementation, where everything is controlled, defined, >>> guaranteed and reliable, someone could use an InputStream or >>> OutputStream style interface. Or even better: don't use them at >>> all :) just BTW :-) >>> St. >>> >>> About Ingenico Throughout the world businesses rely on Ingenico >>> for secure and expedient electronic transaction acceptance. >>> Ingenico products leverage proven technology, established >>> standards and unparalleled ergonomics to provide optimal >>> reliability, versatility and usability. This comprehensive range >>> of products is complemented by a global array of services and >>> partnerships, enabling businesses in a number of vertical sectors >>> to accept transactions anywhere their business takes them. >>> 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. >>> >>> About Ingenico Throughout the world businesses rely on Ingenico >>> for secure and expedient electronic transaction acceptance. >>> Ingenico products leverage proven technology, established >>> standards and unparalleled ergonomics to provide optimal >>> reliability, versatility and usability. This comprehensive range >>> of products is complemented by a global array of services and >>> partnerships, enabling businesses in a number of vertical sectors >>> to accept transactions anywhere their business takes them. >>> 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. >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx 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 yvespielusenet at free.fr Mon Jun 11 03:15:12 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Mon, 11 Jun 2007 11:15:12 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: <1181553312.8335.14.camel@localhost.localdomain> So can someone tell a solution for my problem :( Must I say to the user to not put the printer off-line ? I can't since he has to do some pauses, verify print, paper conditioning etc... How do other people ? Before I use the parport librarry to read port status : http://www.geocities.com/Juanga69/parport/ (which doesn't work on windows XP) And I send data into the file LPT1 I use to have no problem when printer was disabled. thanks -- yves piel Le samedi 09 juin 2007 ? 17:43 +0200, Joachim Buechse a ?crit : > You should not forget, that in the case of an exception it may not > even be known what happened to the data. > > You have a kernel buffer, outgoing chip buffer, incoming chip buffer, > etc. So of course, it would be nice to know up to which point data > was correctly processed, but this feedback does not exist on the > hardware or protocol level and hence can in general not be magicly > created on the software level... > > Regards, > Joachim > > On 08.06.2007, at 14:46, Uncle George wrote: > > > It seems that with outputstream.write(b[]), you become terribly > > uncoordinated as soon as an exception is thrown. Docs do not say what > > happens to the data. > > > > Yet from a practicable point of view, one would like to know if the > > write was accepted in-full, or rejected before any writes. There > > are no > > in betweens, as partial writes are not reportable. > > > > So for an outputstream.write(), in order for it to return, the full > > write request has to be taken, and stored in an internal output > > buffer. > > If there is no room, the write() is suspended, till there is room. Or > > throw's an IOException( "no room in buffer") ; As the select() loop > > for > > write reports buffer room avail, then more of the internal buffer is > > sent to the printer. > > > > > > > > yves pielusenet wrote: > >> So maybe a better way should be to create a new Exception class which > >> has a method "int getWrittenByte()". So the Exception should be > >> use to > >> send again bytes which are not printed yet. > >> > >> yves > >> > >> Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : > >>> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > >>>> It is not possible that the rxtx java method write(byte[], int > >>>> offset, > >>>> int length) return anint which contains the number of byte > >>>> really send > >>>> to the printer instead of an exception ? > >>>> So this is the programm which will see if all bytes have been > >>>> sent. If > >>>> not it can retry to send the unsended bytes. > >>> I think write() is void because in Java people love to do this > >>> since OutputStream :-) Of course on such interfaces you cannot > >>> implement something nice. If you would have a int write, you > >>> would not implement the interface and no applications expecting > >>> this interface would link/work/compile. > >>> > >>> oki, > >>> > >>> Steffen > >>> > >>> P.S.: (OT) > >>> If you propose not to implement the Java interfaces (especially > >>> not on JNI level), maybe optionally offering a wrapper that > >>> removes e.g. the write return value and so on to downgrade the > >>> powerful classic old POSIX read/write style to the modern limited > >>> Java style, then I agree :-) Same for read. Instead of things > >>> like "int avialable()" it is more powerful to have an approach as > >>> select(2) offers (to guarante the caller that read/write will not > >>> block [nothing else make sense anyway IMHO] but may read/write > >>> less bytes then requested). The caller gets full control and the > >>> higher level protocols can care about timeouts, invoking read in > >>> some loops and/or implement retransmission. On top of such an > >>> implementation, where everything is controlled, defined, > >>> guaranteed and reliable, someone could use an InputStream or > >>> OutputStream style interface. Or even better: don't use them at > >>> all :) just BTW :-) > >>> St. > >>> > >>> About Ingenico Throughout the world businesses rely on Ingenico > >>> for secure and expedient electronic transaction acceptance. > >>> Ingenico products leverage proven technology, established > >>> standards and unparalleled ergonomics to provide optimal > >>> reliability, versatility and usability. This comprehensive range > >>> of products is complemented by a global array of services and > >>> partnerships, enabling businesses in a number of vertical sectors > >>> to accept transactions anywhere their business takes them. > >>> 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. > >>> > >>> About Ingenico Throughout the world businesses rely on Ingenico > >>> for secure and expedient electronic transaction acceptance. > >>> Ingenico products leverage proven technology, established > >>> standards and unparalleled ergonomics to provide optimal > >>> reliability, versatility and usability. This comprehensive range > >>> of products is complemented by a global array of services and > >>> partnerships, enabling businesses in a number of vertical sectors > >>> to accept transactions anywhere their business takes them. > >>> 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. > >>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx 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 > From Steffen.DETTMER at ingenico.com Mon Jun 11 03:56:18 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 11:56:18 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466990BE.7040100@gatworks.com> References: <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> Message-ID: <20070611095618.GA10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 13:24 -0400: > i was not thinking of change the API to OutputSream. Then I think either someone uses OutputStream (and has no reliable information about incomplete writes) or someone uses somethink else. > Are there specs for how output stream should work internally? > > for instance: > String data = "Hello this is a line of data"; > Outputstream.write( data.getbytes() ); > ParallelPort.suspend(); > int free = ParallelPort.getoutputbufferfree(); > > There is a symbiotic relationship between outputstream and the > functionality of ParallelPort. If you need OutputStream "plus something else", in short you're needing "something else". Personally I dislike the code above a lot. The stream "looks" like if it would be an OutputStream, but in fact it isn't. You need to call getoutputbufferfree later to check if write succeeded (but OutputStream promises that write succeedes synchronous, blocking, or throws an exception). So it is not an OutputStream. No application written for OutputStreams would work without change (because it won't know getoutputbufferfree at all). It is not abstracted from ParallelPort. I think this would be wrong. Then I think an alternative interface instead is better. Let's assume we had some "connection" (to distinguish between OutputStreams and Channels). Then why not working as on a file handle in POSIX: do { // ... select maybe using timer ... readyForWrite = ... if (readyForWrite) { int writtenBytes = connection.write(toWrite); toWrite.remove(0, writtenBytes); } while(readyForWrite && toWrite.length > 0); I think, having such a write isn't the big problem. I think, the difficult thing is around "select" - however this would look like. It should be OO, typesafe, performant, supporting multiple connections/channels/streams in various modes and should be orthogonal to other functionalities. Of course, this heavily depends on what the application is doing; for a simple situation (like reading a small, mandatory file from a local disk) this would be to uncomfortable (and offering unneeded features only). just BTW :) oki, Steffen -- // Modeline for VIM. Please don't remove. // (Help: autoindent, expandtab, shiftwidth=4, tabstop=4, textwidth=75) // vi: set ai et sw=4 ts=4 tw=75 ft=java: About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Mon Jun 11 05:38:33 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 07:38:33 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611095618.GA10821@elberon.bln.de.ingenico.com> References: <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> Message-ID: <466D3439.4020805@gatworks.com> Steffen DETTMER wrote: > (but OutputStream promises that write > succeedes synchronous, blocking, or throws an exception). Where is it so written? From Steffen.DETTMER at ingenico.com Mon Jun 11 06:36:50 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 14:36:50 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466D3439.4020805@gatworks.com> References: <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> <466D3439.4020805@gatworks.com> Message-ID: <20070611123650.GI10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Mon, Jun 11, 2007 at 07:38 -0400: > Steffen DETTMER wrote: > > > (but OutputStream promises that write > > succeedes synchronous, blocking, or throws an exception). > > Where is it so written? Now, as you ask, I think it is not written that clearly but follows from specification. mmm... Am I wrong? I understand the API doc in this way: * http://java.sun.com/j2se/1.4.2/docs/api/java/io/OutputStream.html#write(byte[]) > public void write(byte[] b) > throws IOException > > Writes b.length bytes from the specified byte array to this > output stream. The general contract for write(b) is that > it should have exactly the same effect as the call write(b, > 0, b.length). > > Parameters: > b - the data. > Throws: > IOException - if an I/O error occurs. > See Also: > write(byte[], int, int) and there is: > public void write(byte[] b, > int off, > int len) > throws IOException > > Writes len bytes from the specified byte array starting at > offset off to this output stream. The general contract for > write(b, off, len) is that some of the bytes in the array b > are written to the output stream in order; element b[off] > is the first byte written and b[off+len-1] is the last byte > written by this operation. > > The write method of OutputStream calls the write method of > one argument on each of the bytes to be written out. > Subclasses are encouraged to override this method and > provide a more efficient implementation. > > If b is null, a NullPointerException is thrown. > > If off is negative, or len is negative, or off+len is > greater than the length of the array b, then an > IndexOutOfBoundsException is thrown. > > Parameters: > b - the data. > off - the start offset in the data. > len - the number of bytes to write. > Throws: > IOException - if an I/O error occurs. In particular, an > IOException is thrown if the output stream is closed. In general, any specialisation (derived child class) must comform to this. So write in the end is specified (!) as "The write method ... calls the write method ... on each of the bytes to be written out". This is what must be implemented by ANY OutputStream. Of course, there is: "Subclasses are encouraged to override this method and provide a more efficient implementation." which IMHO does not contradict - the more efficient must behave in exactly the same way of course (just wasting less resources than a simple byte-by-byte write). So it does not matter here I think. The write that finally defines the behavior tells basically: > "Writes the specified byte to this output stream. The general > contract for write is that one byte is written to the output > stream. " > > Throws: > IOException - if an I/O error occurs. which IMHO is another way of saying "write writes the byte immediately and returns on success (only), otherwise an exception is thrown". Especially it cannot happen that zero bytes are written (i.e. the specified byte is NOT written) without an exception. So by this write must be synchronous and blocking, because otherwise it could not reliably know if an asynchronous operation will succeede or not (some getAsyncResult or so would be needed). Since write(byte[]) does this for each byte (or with a behavior beeing exactly the same as if it would do), I think this means that the write(byte[]) succeedes synchronous/blocking or throws an exception. Did I an error in reasoning or confused something or so? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From j.kenneth.gentle at acm.org Mon Jun 11 06:51:25 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 11 Jun 2007 08:51:25 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611123650.GI10821@elberon.bln.de.ingenico.com> References: <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> <466D3439.4020805@gatworks.com> <20070611123650.GI10821@elberon.bln.de.ingenico.com> Message-ID: <200706111251.l5BCpS9T017831@qbang.org> It is as Steffen describes. "InputStream" and "OutputStream" are inherently synchronous (which is why so many java programs resort to threads to use them). Anything outside of this "contract" is *not* an InputStream or OutputStream. That is why there is a new package for things that don't behave like the old *Stream classes - the NIO package. If you look carefully at the IO package, you'll note that almost all the classes are _Decorator_ pattern implementations of the *Stream classes - and the interface presents the _same_ behavior to the calling code in all cases - a synchronous operation that completes successfully or throws an exception (with the one exception of "read" that returns a "-1" on end-of-stream. I know I've read this numerous times - I'd suggest checking the Language Spec or one of the books by Bloch or Gosling. Ken At 08:36 2007-06-11, you wrote: >* Uncle George wrote on Mon, Jun 11, 2007 at 07:38 -0400: > > Steffen DETTMER wrote: > > > > > (but OutputStream promises that write > > > succeedes synchronous, blocking, or throws an exception). > > > > Where is it so written? > >Now, as you ask, I think it is not written that clearly but >follows from specification. mmm... > >Am I wrong? > >I understand the API doc in this way: > >* >http://java.sun.com/j2se/1.4.2/docs/api/java/io/OutputStream.html#write(byte[]) > > public void write(byte[] b) > > throws IOException > > > > Writes b.length bytes from the specified byte array to this > > output stream. The general contract for write(b) is that > > it should have exactly the same effect as the call write(b, > > 0, b.length). > > > > Parameters: > > b - the data. > > Throws: > > IOException - if an I/O error occurs. > > See Also: > > write(byte[], int, int) > > >and there is: > > > > public void write(byte[] b, > > int off, > > int len) > > throws IOException > > > > Writes len bytes from the specified byte array starting at > > offset off to this output stream. The general contract for > > write(b, off, len) is that some of the bytes in the array b > > are written to the output stream in order; element b[off] > > is the first byte written and b[off+len-1] is the last byte > > written by this operation. > > > > The write method of OutputStream calls the write method of > > one argument on each of the bytes to be written out. > > Subclasses are encouraged to override this method and > > provide a more efficient implementation. > > > > If b is null, a NullPointerException is thrown. > > > > If off is negative, or len is negative, or off+len is > > greater than the length of the array b, then an > > IndexOutOfBoundsException is thrown. > > > > Parameters: > > b - the data. > > off - the start offset in the data. > > len - the number of bytes to write. > > Throws: > > IOException - if an I/O error occurs. In particular, an > > IOException is thrown if the output stream is closed. > > >In general, any specialisation (derived child class) must comform >to this. So write in the end is specified (!) as "The write >method ... calls the write method ... on each of the bytes to be >written out". This is what must be implemented by ANY >OutputStream. > >Of course, there is: "Subclasses are encouraged to override this >method and provide a more efficient implementation." which IMHO >does not contradict - the more efficient must behave in exactly >the same way of course (just wasting less resources than a simple >byte-by-byte write). So it does not matter here I think. > > > >The write that finally defines the behavior tells basically: > > > "Writes the specified byte to this output stream. The general > > contract for write is that one byte is written to the output > > stream. " > > > > Throws: > > IOException - if an I/O error occurs. > > >which IMHO is another way of saying "write writes the byte >immediately and returns on success (only), otherwise an exception >is thrown". Especially it cannot happen that zero bytes are >written (i.e. the specified byte is NOT written) without an >exception. So by this write must be synchronous and blocking, >because otherwise it could not reliably know if an asynchronous >operation will succeede or not (some getAsyncResult or so would >be needed). > >Since write(byte[]) does this for each byte (or with a behavior >beeing exactly the same as if it would do), I think this means >that the write(byte[]) succeedes synchronous/blocking or throws >an exception. > >Did I an error in reasoning or confused something or so? > >oki, > >Steffen > >About Ingenico Throughout the world businesses rely on Ingenico for >secure and expedient electronic transaction acceptance. Ingenico >products leverage proven technology, established standards and >unparalleled ergonomics to provide optimal reliability, versatility >and usability. This comprehensive range of products is complemented >by a global array of services and partnerships, enabling businesses >in a number of vertical sectors to accept transactions anywhere >their business takes them. >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. > >About Ingenico Throughout the world businesses rely on Ingenico for >secure and expedient electronic transaction acceptance. Ingenico >products leverage proven technology, established standards and >unparalleled ergonomics to provide optimal reliability, versatility >and usability. This comprehensive range of products is complemented >by a global array of services and partnerships, enabling businesses >in a number of vertical sectors to accept transactions anywhere >their business takes them. >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. > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From alesinskyy at googlemail.com Mon Jun 11 07:25:33 2007 From: alesinskyy at googlemail.com (Oleksandr Alesinskyy) Date: Mon, 11 Jun 2007 15:25:33 +0200 Subject: [Rxtx] [OT] select :-) Message-ID: Sorry, but I have to disagree with following statement: "So write in the end is specified (!) as "The write method ... calls the write method ... on each of the bytes to be written out". This is what must be implemented by ANY OutputStream.". This is not part of the specification or contract, it is just revealed implementation detail of the OutputStream. It is not stated anywhere that behavoiur of derived classes shall conform with this one. Statement concerning "synchronous" nature of the output stream is invalid as well. Really synchronous stream does not require flush() but OutputStream has it. From Steffen.DETTMER at ingenico.com Mon Jun 11 08:21:16 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 16:21:16 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: Message-ID: <20070611142116.GN10821@elberon.bln.de.ingenico.com> * Oleksandr Alesinskyy wrote on Mon, Jun 11, 2007 at 15:25 +0200: > Sorry, but I have to disagree with following statement: > "So write in the end is specified (!) as "The write > method ... calls the write method ... on each of the bytes to be > written out". This is what must be implemented by ANY > OutputStream.". > > This is not part of the specification or contract, it is just > revealed implementation detail of the OutputStream. It is not > stated anywhere that behavoiur of derived classes shall conform > with this one. (I didn't meant that the implementation must really write byte by byte, but that it must "look as if it would do" - because all implementations of OutputStream must "look" in the same way [which is another way of saying "do abstract" I think]) I think the API doc is not "revealing implementation details" but it is the *specification* of that interface and derivations must (should) conform to this specification. Isn't this the idea of interfaces? A function that expects an OutputStream should work on ANY OutputStream, shouldn't it? just kidding: I mean, what would be the point in implementing a checksum function as OutputStream.write which throws its result as IOException? Or which requires to call close() as very first operation to tell that the application is about to transmit confidential data? :-) > Statement concerning "synchronous" nature of the output stream > is invalid as well. Really synchronous stream does not require > flush() but OutputStream has it. ahh, interesting point! I think this is another bug in the API. flush() is wrong. Because write specifies "The general contract for write is that one byte is written to the output stream." but not "a byte may be written or buffered". Actually, an application would need to call flush() after each write (or bunch of write calls) to ensure that write really did something otherwise I think. I didn't found in the spec of OutputStream that it would be required to call flush(). This should mean that calling flush is not required which in turn leads to the conclusion that write must be synchrous (private threads are forbidden because not specified :)) which in turn leads to the conclusion that flush() is not needed at all... I mean, what if someone would only store in write and do the "real write" in flush() and never else? An application could write in one stream and read on another one (e.g. in bidirectional communication) and would never get anything back, because nothing was actually written because no flush was called? Then someone could even think that on error in some write the data could remain buffered AND throw an exception, retrying to send the data in the next write. Ohh, and if there would be some message number inside, and underlaying write (e.g. a protocol offering InputStream/OutputStream) would check this and throw "DuplicatedMessageNumber" the stream would only throw it again and again beeing unusable... In short: I have no clue how someone could be able to implement an asynchrounos write (which is realiable and correct) without beeing specific to anything which is not specified by OutputStream. Well, I think in the end OutputStream was not intended for such communication or protocol implementations - but to read a local disk file or so. In case of I/O errors usually you can abort your application and change the hard disk :-) oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Bob_Jacobsen at lbl.gov Mon Jun 11 09:32:23 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Mon, 11 Jun 2007 08:32:23 -0700 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611142116.GN10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> Message-ID: At 4:21 PM +0200 6/11/07, Steffen DETTMER wrote: > > Statement concerning "synchronous" nature of the output stream >> is invalid as well. Really synchronous stream does not require >> flush() but OutputStream has it. > >ahh, interesting point! > >I think this is another bug in the API. flush() is wrong. Because >write specifies "The general contract for write is that one byte >is written to the output stream." but not "a byte may be written >or buffered". > >Actually, an application would need to call flush() after each >write (or bunch of write calls) to ensure that write really did >something otherwise I think. OutputStreams don't _have_ to be synchronous or asynchronous, but the OutputStream API was be arranged so that subclasses _can_ be synchronous or asynchronous. Such generality is the hardest part of getting an API right. Hence, if at some point a program using an OutputStream wants to be sure that the data has been pushed all the way out, flush() is available. For some subclasses, e.g. the buffered ones, this has important behavior. Others write the data from each call, and flush() doesn't do anything. You _can_ omit it in programs that are known to use this second type, but there's no requirement that you do so; the interface is general in that way. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From Steffen.DETTMER at ingenico.com Mon Jun 11 12:32:39 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 20:32:39 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> Message-ID: <20070611183239.GT10821@elberon.bln.de.ingenico.com> * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: > >Actually, an application would need to call flush() after each > >write (or bunch of write calls) to ensure that write really did > >something otherwise I think. > OutputStreams don't _have_ to be synchronous or asynchronous, > but the OutputStream API was be arranged so that subclasses > _can_ be synchronous or asynchronous. Ahh, oki. Thanks for the clarificaion. So in short, flush() MUST be called on OutputStream, this is just not documented correctly or so clearly (right?). So the overall usage semantics would be: 1. call write (multiple times if desired) 2. call flush only if both succeeded, write was successful. If flush fails it remains unknown if a part of the data was written and/or will be repeated. So the spec (API doc) is wrong. Correct would be to tell that write behaves as told as long as it is followed by a call to flush, otherwise data may or may not get lost (depending wheter close() is called and calls flush(), which seems not to be guaranteed/required). BTW, I think it is a little bit... erm... interesting to find the specification (java API doc reference) wrong, having a need to conclude it from the presence of some methods with "it would make no sense if they behave exactly as specified, so specification must be wrong (incomplete)". > Such generality is the hardest part of getting an API right. Yes, seems to be proven ;) > Hence, if at some point a program using an OutputStream wants > to be sure that the data has been pushed all the way out, > flush() is available. For some subclasses, e.g. the buffered > ones, this has important behavior. Others write the data from > each call, and flush() doesn't do anything. > You _can_ omit it in programs that are known to use this second > type, but there's no requirement that you do so; the interface > is general in that way. I think, it still it must be called always, otherwise the application could break if passing a different runtime type as OutputStream. I think, if the application/method needs a special "type of OutputStream" then the parameter type must be a subclass but not OutputStream, maybe a PrintStream or so - otherwise the compiler could not detect this error (passing wrong type). Is this correct? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Bob_Jacobsen at lbl.gov Mon Jun 11 13:00:52 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Mon, 11 Jun 2007 12:00:52 -0700 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611183239.GT10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> Message-ID: At 8:32 PM +0200 6/11/07, Steffen DETTMER wrote: >So the spec (API doc) is wrong. Correct would be to tell that >write behaves as told as long as it is followed by a call to >flush, otherwise data may or may not get lost (depending wheter >close() is called and calls flush(), which seems not to be >guaranteed/required). I'm not entirely sure that the spec is wrong, but reasonable people can differ on this. In the 1.5 JavaDocs, all that the docs say for the write methods is that they write to the _output_ _stream_; there is no guarantee of anything beyond that. Only the flush method has any guarantee about the data, which is >Flushes this output stream and forces any buffered output bytes to >be written out. The general contract of flush is that calling it is >an indication that, if any bytes previously written have been >buffered by the implementation of the output stream, such bytes >should immediately be written to their intended destination. People commonly use various OutputStreams without using flush(), and it often works, but it's a bad practice and will eventually bite them. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From netbeans at gatworks.com Mon Jun 11 13:31:57 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 15:31:57 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611183239.GT10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> Message-ID: <466DA32D.1010602@gatworks.com> Steffen DETTMER wrote: > * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: >>> Actually, an application would need to call flush() after each >>> write (or bunch of write calls) to ensure that write really did >>> something otherwise I think. > >> OutputStreams don't _have_ to be synchronous or asynchronous, >> but the OutputStream API was be arranged so that subclasses >> _can_ be synchronous or asynchronous. > > Ahh, oki. Thanks for the clarificaion. > > So in short, flush() MUST be called on OutputStream, this is just > not documented correctly or so clearly (right?). No. Flush can be called to force all current data in java buffer's to be written to the kernel - NOW. A flush() can also *imply* that, besides writing out the buffer's that java employs, may also imply/ask the kernel to write all data thusfar written to the kernel, to be physically placed on the destination device - NOW. For some OS's there is no need to do a kernel flush(), as the I/O is synchronized already. Since this is java, you never know what OS your on. From tjarvi at qbang.org Mon Jun 11 19:28:27 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Jun 2007 19:28:27 -0600 (MDT) Subject: [Rxtx] [OT] select :-) In-Reply-To: <466DA32D.1010602@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: On Mon, 11 Jun 2007, Uncle George wrote: > Steffen DETTMER wrote: >> * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: >>>> Actually, an application would need to call flush() after each >>>> write (or bunch of write calls) to ensure that write really did >>>> something otherwise I think. >> >>> OutputStreams don't _have_ to be synchronous or asynchronous, >>> but the OutputStream API was be arranged so that subclasses >>> _can_ be synchronous or asynchronous. >> >> Ahh, oki. Thanks for the clarificaion. >> >> So in short, flush() MUST be called on OutputStream, this is just >> not documented correctly or so clearly (right?). > No. > Flush can be called to force all current data in java buffer's to be > written to the kernel - NOW. > > A flush() can also *imply* that, besides writing out the buffer's that > java employs, may also imply/ask the kernel to write all data thusfar > written to the kernel, to be physically placed on the destination device > - NOW. > For some OS's there is no need to do a kernel flush(), as the I/O is > synchronized already. Since this is java, you never know what OS your on. To add to the confusion, flush on the C side throws away data. drain makes sure it is written. Looking at the ParallelImp.c we can probably do better. /* we set a timeout because all calls are sequentiell (also with asynchron) this means that the default timeout of unlimited blocks all calls (also close and status request) if the device is down */ GetCommTimeouts( (HANDLE)fd, &timeouts ); timeouts.WriteTotalTimeoutMultiplier = 0; timeouts.WriteTotalTimeoutConstant = 2000; /* 2000 is the min value for the default Windows NT and Windows 2000 driver */ SetCommTimeouts( (HANDLE)fd, &timeouts ); while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } errorCount = 0; bytes += countWritten; count -= countWritten; } LPRPort has some timeout code that appears to be doing nothing but flipping bits back and forth right now. The commapi rxtx follows allows for timeout control from javax.comm.CommPort. The above is a solution that worked in one specific use case. With timeouts in place, the original 'old printer going offline' problem could be solved. That printer code isn't written in stone. In fact it was ajusted from being able to print 'asdf' to a daisy wheel printer to working for one person. BTW, I've finished teaching after hours tonight and will be moving forward with a new rxtx release in my free time. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Jun 11 21:28:04 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 23:28:04 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: <466E12C4.1010305@gatworks.com> > Looking at the ParallelImp.c we can probably do better. > The problem stemmed from the possibility that the writev routine could have written some of the buffer, in chunks, printer pauses, refuses any more chunks, and a timeout occurs. Do you or do you not cause an exception to be thrown? Is there a way to set timeout for a ParallelPort data output stream? I cant find it. From tjarvi at qbang.org Mon Jun 11 22:17:23 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Jun 2007 22:17:23 -0600 (MDT) Subject: [Rxtx] [OT] select :-) In-Reply-To: <466E12C4.1010305@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> <466E12C4.1010305@gatworks.com> Message-ID: On Mon, 11 Jun 2007, Uncle George wrote: >> Looking at the ParallelImp.c we can probably do better. >> > The problem stemmed from the possibility that the writev routine could > have written some of the buffer, in chunks, printer pauses, refuses any > more chunks, and a timeout occurs. Do you or do you not cause an > exception to be thrown? > > Is there a way to set timeout for a ParallelPort data output stream? I > cant find it. hmm I looked again after you asked. The timeouts are only controllable on the receive side. This comes from CommPort; the parent. So what we are talking about is some bytes in memory that rxtx has and is supposed to write. A buffer perhaps? The approach with rxtx in the past has been to ignore output buffer sizes. The assumption is that the library does not know how to best handle buffers. There are buffered output streams that can do buffering on top of rxtx for instance. There is also a question regarding what was actually ment when the API was put together. My suspicion is that it was put together while looking at one OS API and was never ment to be anything more than a hook into that API. The comments are fairly telling combined with reading the w32 API. So looking at the problem again.. The current timeout behavior appears fairly arbitrary. Presumably this is to prevent a program from hanging instead of using a helper thread to write - heavy handed for new programmers. Even so, I don't think the write should timeout at all if it is not configurable. >From the API perspective, "What Timeout?" -- Trent Jarvi tjarvi at qbang.org From Steffen.DETTMER at ingenico.com Tue Jun 12 02:14:48 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 12 Jun 2007 10:14:48 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466DA32D.1010602@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: <20070612081447.GU10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Mon, Jun 11, 2007 at 15:31 -0400: > Steffen DETTMER wrote: > > Ahh, oki. Thanks for the clarificaion. > > > > So in short, flush() MUST be called on OutputStream, this is just > > not documented correctly or so clearly (right?). > No. hum (though now I got it, but...). > Flush can be called to force all current data in java buffer's to be > written to the kernel - NOW. > > A flush() can also *imply* that, besides writing out the > buffer's that java employs, may also imply/ask the kernel to > write all data thusfar written to the kernel, to be physically > placed on the destination device - NOW. > > For some OS's there is no need to do a kernel flush(), as the I/O is > synchronized already. Since this is java, you never know what OS your on. (well, but if you're going to kernel level, even flush cannot guarantee that data will "be physically placed". Maybe you're flushing to a file via NFS (and the client "thinks" that it was written, but maybe it was just buffered by the NFS server) or so... but of course such exceptions of the rules are constructable always.) Well, you tell that depending on the OS it can be that flush is needed or it can be that flush is not needed (beacuse the I/O is synchronized already), right? Also, applications should work on any OS, which includes the OSes that do need flush. Since the application cannot know whether flush is needed or not because it doesn't know what the OS is doing, it has to call flush, hasn't it? I mean, if it would not call flush then it would not work on such OSes (except the written data would not be needed at all, but in this would be an artificial example :)). Since applications are supposed to work this would be wrong, wouldn't it? So would it be correct to say: "Applications, that should work under all OSes (including the OSes where the I/O is not synchronised already), have to call flush on OutputStream to ensure the data is transfered to the kernel." or is this wrong? If so, then I'm afraid I missed the point again :( oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Tue Jun 12 04:46:52 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 12 Jun 2007 06:46:52 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070612081447.GU10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> <20070612081447.GU10821@elberon.bln.de.ingenico.com> Message-ID: <466E799C.7060700@gatworks.com> S > (well, but if you're going to kernel level, even flush cannot > guarantee that data will "be physically placed". Thats true now-a-days because ( from "man 2 sync" ) : > According to the standard specification (e.g., SVID), sync() schedules > the writes, but may return before the actual writing is done. However, > since version 1.3.20 Linux does actually wait. (This still does not > guarantee data integrity: modern disks have large caches.) My disk drive has 8mb cache. Maybe you're > flushing to a file via NFS (and the client "thinks" that it was > written, but maybe it was just buffered by the NFS server) or > so... but of course such exceptions of the rules are > constructable always.) > > Well, you tell that depending on the OS it can be that flush is > needed or it can be that flush is not needed (beacuse the I/O is > synchronized already), right? Also, applications should work on > any OS, which includes the OSes that do need flush. Its not OS's that need flush, its applications that want to have some assurance that data is written to the device that really needs to use flush. If your program ( or thread ) dies then it is in your best interest to write out the critical data as soon as possible, as economical as possible. These are trade-off's that the application programmer makes. A big buffer may mean big loss of data, a small buffer may mean spending too much time writing out data. > > > So would it be correct to say: > > "Applications, that should work under all OSes (including the > OSes where the I/O is not synchronised already), have to call > flush on OutputStream to ensure the data is transfered to the > kernel." > > or is this wrong? If so, then I'm afraid I missed the point again > :( > No that is not wrong. Ensuring that data is transfered to the OS is just about what any application can do. From tjarvi at qbang.org Thu Jun 14 08:16:47 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 14 Jun 2007 08:16:47 -0600 (MDT) Subject: [Rxtx] rxtx and usb-serial solution In-Reply-To: References: Message-ID: On Thu, 14 Jun 2007, Vladimir Kirtchev wrote: > Hi Trent, > > I develop a Java application which communicates with devices which have > USB-to-Serial bridge in them. The target OS is Linux. So for this purpose I > use RXTX. > > But I encountered a strange problem - when reading from the InputStream, I > receive series of zeros. I have this problem under Linux only. Under Windows > it is fine. > Actually this problem is the same as the one described here: > http://marc.info/?l=rxtx&m=109703190731748&w=2. > > > So I searched for the problem in the native code. And found that the root of > the problem is in SerialImp.c, > int configure_port( int fd ) > { > ... > ttyset.c_iflag = INPCK; > ... > } > > This line enables input parity checking, and the data sent from the device > is processed by the OS driver before being read with read(). > In this case the driver detects some problem and sets the received bytes to > zero. > > On the other hand in the Java part a set the serial port parameters with > SerialPort.PARITY_NONE. According to me, except all other things, this > should also disable INPCK in c_iflag. > > So I refactored the method translate_parity(...) to the following: > > int translate_parity( JNIEnv *env, struct termios *ttyset, jint parity ) > { > ENTER( "translate_parity" ); > #ifdef CMSPAR > ttyset->c_cflag &= ~(PARENB | PARODD | CMSPAR ); > #endif /* CMSPAR */ > switch( parity ) { > case JPARITY_NONE: > ttyset->c_iflag &= ~INPCK; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_EVEN: > ttyset->c_cflag |= PARENB; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_ODD: > ttyset->c_cflag |= PARENB | PARODD; > LEAVE( "translate_parity" ); > return 0; > #ifdef CMSPAR > case JPARITY_MARK: > ttyset->c_cflag |= PARENB | PARODD | CMSPAR; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_SPACE: > ttyset->c_cflag |= PARENB | CMSPAR; > LEAVE( "translate_parity" ); > return 0; > #endif /* CMSPAR */ > default: > printf("Parity missed %i\n", (int) parity ); > } > > LEAVE( "translate_parity" ); > /* > For some reason the native exceptions are not being caught. Moving this > to the Java side fixed the issue. taj. > throw_java_exception( env, UNSUPPORTED_COMM_OPERATION, > "", "parity value not supported" ); > */ > return 1; > } > > This modification solved the problem and now it works correctly under Linux. > > I think I will be a nice if this is idea is included in a future release of > RXTX. > > Thanks Vadim, I'll try that out. Forwarding to the rxtx mail-list too. This is probably not going to help USB drivers on windows which I'm sure some are looking for. As far as I can tell, windows USB bluetooth and serial dongles are limited by driver functionality. Some are good and others lack key features. -- Trent Jarvi tjarvi at qbang.org From dan.sandberg.lists at gmail.com Mon Jun 18 14:43:39 2007 From: dan.sandberg.lists at gmail.com (Dan Sandberg) Date: Mon, 18 Jun 2007 13:43:39 -0700 Subject: [Rxtx] Fix for JNI Get/Set Field Errors Message-ID: <4676EE7B.7060800@gmail.com> Hi, I've fixed the problems that cause the following JNI error when extra JNI checking ( -Xjni:check ) is turned on. FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) The problem was basically that GetLong was being used to get ints, and SetInt was used for longs. The patch below fixes this. Please let me know if there are any questions / problems. Cheers, -Dan diff -aur old/SerialImp.c src/SerialImp.c --- old/SerialImp.c 2007-06-18 13:24:33.000000000 -0700 +++ src/SerialImp.c 2007-06-18 06:26:26.000000000 -0700 @@ -1337,7 +1337,7 @@ report("init_threads: get eis\n"); jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); report("init_threads: set eis\n"); - (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); + (*eis->env)->SetLongField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); report("init_threads: stop\n"); report_time_end( ); return( 1 ); @@ -1530,7 +1530,7 @@ jobject jobj, jboolean interrupted ) { int fd = get_java_var( env, jobj,"fd","I" ); - struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var( env, jobj, "eis", "J" ); + struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var_long( env, jobj, "eis", "J" ); int result, count=0; char message[80]; @@ -2939,7 +2939,7 @@ /* TRENT */ int flag, count = 0; struct event_info_struct *eis = ( struct event_info_struct * ) - get_java_var( env, *jobj,"eis","J" ); + get_java_var_long( env, *jobj,"eis","J" ); report_time_start(); flag = eis->eventflags[SPE_DATA_AVAILABLE]; @@ -4873,9 +4873,9 @@ exceptions: none comments: ----------------------------------------------------------*/ -size_t get_java_var( JNIEnv *env, jobject jobj, char *id, char *type ) +long get_java_var_long( JNIEnv *env, jobject jobj, char *id, char *type ) { - int result = 0; + long result = 0; jclass jclazz = (*env)->GetObjectClass( env, jobj ); jfieldID jfd = (*env)->GetFieldID( env, jclazz, id, type ); @@ -4889,7 +4889,11 @@ LEAVE( "get_java_var" ); return result; } - result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); + if ( !strcmp( type, "J" ) ) { + result = (long)( (*env)->GetLongField( env, jobj, jfd ) ); + } else { + result = (int) ( (*env)->GetIntField( env, jobj, jfd ) ); + } /* ct7 & gel * Added DeleteLocalRef */ (*env)->DeleteLocalRef( env, jclazz ); if(!strncmp( "fd",id,2) && result == 0) @@ -4900,6 +4904,10 @@ return result; } +int get_java_var( JNIEnv *env, jobject jobj, char *id, char *type ) { + return (int) get_java_var_long( env, jobj, id, type ); +} + /*---------------------------------------------------------- throw_java_exception diff -aur old/SerialImp.h src/SerialImp.h --- old/SerialImp.h 2007-06-18 13:24:39.000000000 -0700 +++ src/SerialImp.h 2007-06-18 06:23:43.000000000 -0700 @@ -413,7 +413,8 @@ void system_wait(); void finalize_event_info_struct( struct event_info_struct * ); int read_byte_array( JNIEnv *, jobject *, int, unsigned char *, int, int ); -size_t get_java_var( JNIEnv *, jobject, char *, char * ); +int get_java_var( JNIEnv *, jobject, char *, char * ); +long get_java_var_long( JNIEnv *, jobject, char *, char * ); jboolean is_interrupted( struct event_info_struct * ); int send_event(struct event_info_struct *, jint, int ); void dump_termios(char *,struct termios *); From yvespielusenet at free.fr Tue Jun 26 03:41:58 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 11:41:58 +0200 Subject: [Rxtx] [PARALLEL] resource in use Message-ID: <1182850918.3483.10.camel@localhost.localdomain> Hello, So now I want to modify the timeout of the library for parallel port. I have downloaded source code. There is a makefile for migw. SO I have installed mingw on ubuntu and modified the makefile.mingw32 to set it for my system. I have no error but some warnings. The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But When I want to use it the jvm crash :( How can I know what is wrong ? How rxtx windows release has been done ? thanks -- yves piel From yvespielusenet at free.fr Tue Jun 26 07:17:02 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 15:17:02 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182850918.3483.10.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> Message-ID: <1182863822.3483.17.camel@localhost.localdomain> Here is the Makefile I use, the output of the 'make' and the log of the jvm when it crashed : - The Makefile : http://yvespiel.free.fr/rxtx/Makefile - The make output : http://yvespiel.free.fr/rxtx/compile.txt - The crash log : http://yvespiel.free.fr/rxtx/hs_err_pid2100.log I have compiled rxtx under Debian testing with mingw : narma at linimi:/tmp/err$ dpkg -l | grep mingw ii mingw32 3.4.5.20060117.1.dfsg-3 ii mingw32-binutils 2.17.50-20070129.1-1 ii mingw32-runtime 3.12-1 thanks fort help :) Le mardi 26 juin 2007 ? 11:41 +0200, yves pielusenet a ?crit : > Hello, > So now I want to modify the timeout of the library for parallel port. I > have downloaded source code. There is a makefile for migw. SO I have > installed mingw on ubuntu and modified the makefile.mingw32 to set it > for my system. > I have no error but some warnings. > The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But > When I want to use it the jvm crash :( > > How can I know what is wrong ? > > How rxtx windows release has been done ? > > thanks > From yvespielusenet at free.fr Tue Jun 26 07:40:11 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 15:40:11 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182863822.3483.17.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> <1182863822.3483.17.camel@localhost.localdomain> Message-ID: <1182865211.3483.21.camel@localhost.localdomain> I have add the options '--enable-stdcall-fixup' to the 'i586-mingw32msvc-ld' commande. Now I have no warning. But the JVM always crashes :( The output seems more detailled, but I don't understand anything... Here is files : http://yvespiel.free.fr/rxtx/2/ -- yves piel Le mardi 26 juin 2007 ? 15:17 +0200, yves pielusenet a ?crit : > Here is the Makefile I use, the output of the 'make' and the log of the > jvm when it crashed : > > - The Makefile : http://yvespiel.free.fr/rxtx/Makefile > - The make output : http://yvespiel.free.fr/rxtx/compile.txt > - The crash log : http://yvespiel.free.fr/rxtx/hs_err_pid2100.log > > I have compiled rxtx under Debian testing with mingw : > narma at linimi:/tmp/err$ dpkg -l | grep mingw > ii mingw32 3.4.5.20060117.1.dfsg-3 > ii mingw32-binutils 2.17.50-20070129.1-1 > ii mingw32-runtime 3.12-1 > > thanks fort help :) > > > Le mardi 26 juin 2007 ? 11:41 +0200, yves pielusenet a ?crit : > > Hello, > > So now I want to modify the timeout of the library for parallel port. I > > have downloaded source code. There is a makefile for migw. SO I have > > installed mingw on ubuntu and modified the makefile.mingw32 to set it > > for my system. > > I have no error but some warnings. > > The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But > > When I want to use it the jvm crash :( > > > > How can I know what is wrong ? > > > > How rxtx windows release has been done ? > > > > thanks > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From yvespielusenet at free.fr Tue Jun 26 08:27:42 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 16:27:42 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182865211.3483.21.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> <1182863822.3483.17.camel@localhost.localdomain> <1182865211.3483.21.camel@localhost.localdomain> Message-ID: <1182868062.3483.24.camel@localhost.localdomain> I think thant the include files of jdk were not for windows but for linux. So I have copied include/ folder from windows to linux and I modified the Makefile to use those file. It compile fine but the JVM always crash :( http://yvespiel.free.fr/rxtx/3/ Le mardi 26 juin 2007 ? 15:40 +0200, yves pielusenet a ?crit : > I have add the options '--enable-stdcall-fixup' to the > 'i586-mingw32msvc-ld' commande. Now I have no warning. But the JVM > always crashes :( The output seems more detailled, but I don't > understand anything... > Here is files : > http://yvespiel.free.fr/rxtx/2/ > From netbeans at gatworks.com Fri Jun 1 05:38:50 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 07:38:50 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <465F7ADD.1010501@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> Message-ID: <4660054A.2040202@gatworks.com> Manuel Naranjo wrote: In the case of my module, you can > unplug the device but it will not delete the symlink until those apps > that had opened the port has closed it. This is done this way to avoid > kernel panics. What does this mean to user code ? I have tried the alternate route ( other than closing ) which is sleep inbetween the I/O errors ( an unplugged USB device). When the device is plugged back in, The writes to the device still get an I/O error. This would seem to be a lost cause for the application. From netbeans at gatworks.com Fri Jun 1 06:35:48 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 08:35:48 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <465F7ADD.1010501@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> Message-ID: <466012A4.90608@gatworks.com> Manuel Naranjo wrote: In the case of my module, you can > unplug the device but it will not delete the symlink until those apps > that had opened the port has closed it. T Did u also mean for this to happen? USB0 was not closed by application. Apparently USB1 got created when USB device was plugged back in. There is only one USB device on a 4 port USB hub. This also seems to suggest that application recovery to be impossible. > Jun 1 07:10:08 mylaptop kernel: garmin_gps 1-1.4:1.0: Garmin GPS usb/tty converter detected > Jun 1 07:10:08 mylaptop kernel: usb 1-1.4: Garmin GPS usb/tty converter now attached to ttyUSB0 > Jun 1 07:15:17 mylaptop kernel: usb 1-1: USB disconnect, address 4 > Jun 1 07:15:17 mylaptop kernel: usb 1-1.4: USB disconnect, address 5 > Jun 1 07:15:17 mylaptop kernel: garmin_gps 1-1.4:1.0: device disconnected > Jun 1 07:15:26 mylaptop kernel: usb 1-1: new full speed USB device using uhci_hcd and address 6 > Jun 1 07:15:26 mylaptop kernel: hub 1-1:1.0: USB hub found > Jun 1 07:15:26 mylaptop kernel: hub 1-1:1.0: 4 ports detected > Jun 1 07:15:27 mylaptop kernel: usb 1-1.4: new full speed USB device using uhci_hcd and address 7 > Jun 1 07:15:27 mylaptop kernel: garmin_gps 1-1.4:1.0: Garmin GPS usb/tty converter detected > Jun 1 07:15:27 mylaptop kernel: usb 1-1.4: Garmin GPS usb/tty converter now attached to ttyUSB1 From naranjo.manuel at gmail.com Fri Jun 1 09:17:22 2007 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Fri, 01 Jun 2007 12:17:22 -0300 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <466012A4.90608@gatworks.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> <466012A4.90608@gatworks.com> Message-ID: <46603882.5050701@gmail.com> Uncle George escribi?: > Manuel Naranjo wrote: > In the case of my module, you can > >> unplug the device but it will not delete the symlink until those apps >> that had opened the port has closed it. T >> > > Did u also mean for this to happen? USB0 was not closed by application. > > Apparently USB1 got created when USB device was plugged back in. There > is only one USB device on a 4 port USB hub. > > This also seems to suggest that application recovery to be impossible. > Exactly there's a dead symlink (you can read and write to it and nothing will happen) and a new port will be created when a new device is connencted. From netbeans at gatworks.com Fri Jun 1 10:20:46 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 12:20:46 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <46603882.5050701@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> <466012A4.90608@gatworks.com> <46603882.5050701@gmail.com> Message-ID: <4660475E.5090202@gatworks.com> Not sure what u mean by "symlink". U cant read/write to it anymore. U get I/O error. In this scenario the device effectively went dead, and only solution is to close the channel. reconnecting the USB device, although dead, but not closed, will create a second device. This does not seem to be a desirable side-effect. The user will now have ttyUSB1, wondering where did ttyUSB0 go to. The application will also be in a confused state, as well as RXTX, because RXTX wont know about ttyUSB1. Manuel Naranjo wrote: > Uncle George escribi?: >> Manuel Naranjo wrote: >> In the case of my module, you can >> >>> unplug the device but it will not delete the symlink until those apps >>> that had opened the port has closed it. T >>> >> Did u also mean for this to happen? USB0 was not closed by application. >> >> Apparently USB1 got created when USB device was plugged back in. There >> is only one USB device on a 4 port USB hub. >> >> This also seems to suggest that application recovery to be impossible. >> > Exactly there's a dead symlink (you can read and write to it and nothing > will happen) and a new port will be created when a new device is connencted. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From arnab.bhaumik at gmail.com Mon Jun 4 01:40:16 2007 From: arnab.bhaumik at gmail.com (arnab bhaumik) Date: Mon, 4 Jun 2007 13:10:16 +0530 Subject: [Rxtx] full duplex com port with rxtx Message-ID: hi , till now i did half duplex communication with rxtx package on com package. my question is : is it possible to use com port with full duplex mode with rxtx package . ther is example of SimpleRead class and SimpleWrite class. it is clear that if i can use both the class simultaneously then full duplex is possible......... arnab/vu2bpw -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070604/6edb0453/attachment-0001.html From lists at iDIAcomputing.com Mon Jun 4 07:53:17 2007 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Mon, 04 Jun 2007 09:53:17 -0400 Subject: [Rxtx] full duplex com port with rxtx In-Reply-To: References: Message-ID: <4664194D.90301@iDIAcomputing.com> arnab bhaumik wrote: > hi , > > till now i did half duplex communication with rxtx package on com > package. > > my question is : is it possible to use com port with full duplex mode > with rxtx package . > > > ther is example of SimpleRead class and SimpleWrite class. it is > clear that if i can use both the class simultaneously then full duplex > is possible......... I haven't looked at the SimpleRead and SimpleWrite classes (I originally wrote my code for the javax.comm api), but full duplex is certainly possible. My CommReader class requires an object analogous to a OutputStream or Writer. When started, it spawns a thread that reads the comm port and writes to that output device. In this way the input is asynchronous and dependent on the actual input data. For full duplex, I extend that class with CommReaderWriter, which adds synchronous output methods. Hope that helps, George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From supsoop at hotmail.com Mon Jun 4 15:21:06 2007 From: supsoop at hotmail.com (soop soop) Date: Mon, 04 Jun 2007 21:21:06 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- Message-ID: Hi Guys, Looked through the archives but still cannot figure this out. I have a Motorola G24 GPRS/GSM modem that I am connecting to my server running Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not detecting the port, CommPortIdentifier.getPortIdentifiers(). I have added the line to RXTXCommDriver: "ttyACM" // for USB Modems Rxtx still does not seem to find the port. Is there something I am missing to make this port visable? [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control Model driver for USB modems and ISDN adapters I really need your help as I have moved my server from windows to Linux and have been down for a few days because of this .. Thanks so much! _________________________________________________________________ PC Magazine’s 2007 editors’ choice for best Web mail—award-winning Windows Live Hotmail. http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 From tjarvi at qbang.org Mon Jun 4 16:17:35 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Jun 2007 16:17:35 -0600 (MDT) Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: On Mon, 4 Jun 2007, soop soop wrote: > Hi Guys, > > Looked through the archives but still cannot figure this out. I have a > Motorola G24 GPRS/GSM modem that I am connecting to my server running Ubuntu. > I can see my modem as is shows up as ttyACM0, but RXTX is not detecting the > port, CommPortIdentifier.getPortIdentifiers(). > > I have added the line to RXTXCommDriver: > > "ttyACM" // for USB Modems > > Rxtx still does not seem to find the port. Is there something I am missing to > make this port visable? > > [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver > [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device > [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control Model > driver for USB modems and ISDN adapters > > I really need your help as I have moved my server from windows to Linux and > have been down for a few days because of this .. Thanks so much! > You could try the INSTALL documentation that comes with the source for possible solutions. Those usually involve lockfile creation, permissions on the device file or the device is in use by another application (even another session of your application). The usual commands: ls -l /dev/ttyACM0 fuser /dev/ttyACM0 touch /var/lock/LCK.testfile && rm -f /var/lock/LCK.testfile whoami To disable lockfiles: ../configure --disable-lockfiles && make install -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Jun 4 16:22:52 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 04 Jun 2007 18:22:52 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <466490BC.3090801@gatworks.com> soop soop wrote: > I really need your help as I have moved my server from windows to Linux > and have been down for a few days because of this .. Thanks so much! can u open the device ? ie is the file protection/permissions keeping you out? From supsoop at hotmail.com Mon Jun 4 16:44:40 2007 From: supsoop at hotmail.com (soop soop) Date: Mon, 04 Jun 2007 22:44:40 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <466490BC.3090801@gatworks.com> Message-ID: Thanks for the reply, I see no exceptions being thrown, just no detection of the port whats so ever. I will run rxtx in debug mode and log. If this were a permissions issue would I not see some exceptions being thrown? >From: Uncle George >Reply-To: RXTX Developers and Users >To: RXTX Developers and Users >Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >Date: Mon, 04 Jun 2007 18:22:52 -0400 > >soop soop wrote: > > > I really need your help as I have moved my server from windows to Linux > > and have been down for a few days because of this .. Thanks so much! > >can u open the device ? ie is the file protection/permissions keeping >you out? >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ Get a preview of Live Earth, the hottest event this summer - only on MSN http://liveearth.msn.com?source=msntaglineliveearthhm From netbeans at gatworks.com Mon Jun 4 17:06:15 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 04 Jun 2007 19:06:15 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <46649AE7.10405@gatworks.com> Exceptions on what? On startup it wants to lookup all devices in /dev that it is capable of opening ( within the list of specific 'comm' devices ). If it cannot open, then does not get onto list. Part of this process, if configured, will also test if the "LOCK" schema can also be opened for the device. then it gets on the list of avail comm port. soop soop wrote: > Thanks for the reply, > > I see no exceptions being thrown, just no detection of the port whats so > ever. I will run rxtx in debug mode and log. If this were a permissions > issue would I not see some exceptions being thrown? > > >> From: Uncle George >> Reply-To: RXTX Developers and Users >> To: RXTX Developers and Users >> Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >> Date: Mon, 04 Jun 2007 18:22:52 -0400 >> >> soop soop wrote: >> >>> I really need your help as I have moved my server from windows to Linux >>> and have been down for a few days because of this .. Thanks so much! >> can u open the device ? ie is the file protection/permissions keeping >> you out? >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _________________________________________________________________ > Get a preview of Live Earth, the hottest event this summer - only on MSN > http://liveearth.msn.com?source=msntaglineliveearthhm > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From alex.flint at gmail.com Mon Jun 4 21:31:49 2007 From: alex.flint at gmail.com (Alex Flint) Date: Tue, 5 Jun 2007 13:01:49 +0930 Subject: [Rxtx] random EXCEPTION_ACCESS_VIOLATION errors Message-ID: Hi All, I'm running winXP and RXTX 2.1-7r2 (the latest from the webpage as of June 2007). I'm sending sequences of 64 lines (each line has about 15 chars) at various intervals. The strings are sent fine, until I get the following error (from hs_err_pid3316.log, at the end of this email). What can I do to avoid the error? Obviously this is a low-level memory exception, but is there any way I can keep the JVM running after such an error? I noticed the exact same problem here: http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20070129/1180520.html Cheers, Alex # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x100034fb, pid=3316, tid=2400 # # Java VM: Java HotSpot(TM) Client VM (1.6.0_01-b06 mixed mode, sharing) # Problematic frame: # C [rxtxSerial.dll+0x34fb] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # --------------- T H R E A D --------------- Current thread (0x00386400): JavaThread "main" [_thread_in_native, id=2400] siginfo: ExceptionCode=0xc0000005, reading address 0x20726f78 Registers: EAX=0x20726f20, EBX=0x6d8922c0, ECX=0x00000005, EDX=0x20726f20 ESP=0x003efa30, EBP=0x003efb68, ESI=0x269728a0, EDI=0x00386400 EIP=0x100034fb, EFLAGS=0x00010212 Top of Stack: (sp=0x003efa30) 0x003efa30: 003efa3c 003efa64 0000000f ffffffff 0x003efa40: 003efa40 2a97f808 003efa6c 2b190ca8 0x003efa50: 00000000 2b190ec0 003efa90 008e2dd7 0x003efa60: 003efa90 008e2dd7 26977f88 6d815e72 0x003efa70: 00000004 2696eae0 0000008a 003efb0c 0x003efa80: 6d852b4a 2696eae0 00000003 26970930 0x003efa90: 000000cb 2696eae0 6d86b264 00385d40 0x003efaa0: 0000003f 003efb0c 26977f90 2ace65d8 Instructions: (pc=0x100034fb) 0x100034eb: ff ff 8d 76 00 eb 02 89 f6 90 8b 45 f8 8b 55 f8 0x100034fb: 8b 4a 58 83 c9 04 89 48 58 83 c4 f8 8b 45 f8 8b Stack: [0x003a0000,0x003f0000), sp=0x003efa30, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x34fb] Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j gnu.io.RXTXPort.writeArray([BIIZ)V+0 j gnu.io.RXTXPort$SerialOutputStream.write([B)V+76 j com.bjt.media.server.CommLink.send(Ljava/lang/String;)V+48 j com.bjt.media.server.DigitoolConnection.select(I)V+73 j com.bjt.media.server.DigitoolConnection.main([Ljava/lang/String;)V+74 v ~StubRoutines::call_stub --------------- P R O C E S S --------------- Java Threads: ( => current thread ) 0x02a69400 JavaThread "Thread-0" [_thread_in_native, id=3052] 0x02a4d000 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=3920] 0x02a48400 JavaThread "CompilerThread0" daemon [_thread_blocked, id=1968] 0x02a47400 JavaThread "Attach Listener" daemon [_thread_blocked, id=2984] 0x02a46400 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=2660] 0x02a41c00 JavaThread "Finalizer" daemon [_thread_blocked, id=3924] 0x02a3d800 JavaThread "Reference Handler" daemon [_thread_blocked, id=4008] =>0x00386400 JavaThread "main" [_thread_in_native, id=2400] Other Threads: 0x02a34400 VMThread [id=3708] 0x02a4e800 WatcherThread [id=3964] VM state:not at safepoint (normal execution) VM Mutex/Monitor currently owned by a thread: None Heap def new generation total 960K, used 131K [0x22960000, 0x22a60000, 0x22e40000) eden space 896K, 7% used [0x22960000, 0x22970ea8, 0x22a40000) from space 64K, 99% used [0x22a50000, 0x22a5fff8, 0x22a60000) to space 64K, 0% used [0x22a40000, 0x22a40000, 0x22a50000) tenured generation total 4096K, used 76K [0x22e40000, 0x23240000, 0x26960000) the space 4096K, 1% used [0x22e40000, 0x22e53060, 0x22e53200, 0x23240000) compacting perm gen total 12288K, used 137K [0x26960000, 0x27560000, 0x2a960000) the space 12288K, 1% used [0x26960000, 0x26982518, 0x26982600, 0x27560000) ro space 8192K, 62% used [0x2a960000, 0x2ae5e4e8, 0x2ae5e600, 0x2b160000) rw space 12288K, 52% used [0x2b160000, 0x2b7a0e78, 0x2b7a1000, 0x2bd60000) Dynamic libraries: 0x00400000 - 0x00423000 C:\Program Files\Java\jre1.6.0_01\bin\javaw.exe 0x7c900000 - 0x7c9b0000 C:\WINDOWS\system32\ntdll.dll 0x7c800000 - 0x7c8f4000 C:\WINDOWS\system32\kernel32.dll 0x77dd0000 - 0x77e6b000 C:\WINDOWS\system32\ADVAPI32.dll 0x77e70000 - 0x77f01000 C:\WINDOWS\system32\RPCRT4.dll 0x7e410000 - 0x7e4a0000 C:\WINDOWS\system32\USER32.dll 0x77f10000 - 0x77f57000 C:\WINDOWS\system32\GDI32.dll 0x76390000 - 0x763ad000 C:\WINDOWS\system32\IMM32.DLL 0x7c340000 - 0x7c396000 C:\Program Files\Java\jre1.6.0_01\bin\msvcr71.dll 0x6d7c0000 - 0x6da07000 C:\Program Files\Java\jre1.6.0_01\bin\client\jvm.dll 0x76b40000 - 0x76b6d000 C:\WINDOWS\system32\WINMM.dll 0x5cd70000 - 0x5cd77000 C:\WINDOWS\system32\serwvdrv.dll 0x5b0a0000 - 0x5b0a7000 C:\WINDOWS\system32\umdmxfrm.dll 0x6d310000 - 0x6d318000 C:\Program Files\Java\jre1.6.0_01\bin\hpi.dll 0x76bf0000 - 0x76bfb000 C:\WINDOWS\system32\PSAPI.DLL 0x6d770000 - 0x6d77c000 C:\Program Files\Java\jre1.6.0_01\bin\verify.dll 0x6d3b0000 - 0x6d3cf000 C:\Program Files\Java\jre1.6.0_01\bin\java.dll 0x6d7b0000 - 0x6d7bf000 C:\Program Files\Java\jre1.6.0_01\bin\zip.dll 0x10000000 - 0x10012000 C:\Documents and Settings\Alex\workspace\MediaServer\rxtxSerial.dll 0x73d90000 - 0x73db7000 C:\WINDOWS\system32\crtdll.dll VM Arguments: jvm_args: -Djava.library.path=C:\Documents and Settings\Alex\workspace\MediaServer java_command: com.bjt.media.server.DigitoolConnection Launcher Type: SUN_STANDARD Environment Variables: CLASSPATH=.;C:\Program Files\Java\j2re1.4.2_07\lib\ext\QTJava.zip PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\wbem;c:\applications\php;C:\Program Files\MATLAB\R2006a\bin\win32;C:\Roger\Projects\UAV\Bin\Debug;C:\Program Files\Microsoft SQL Server\80\Tools\Binn\;c:\Program Files\Microsoft SQL Server\90\Tools\binn\;C:\Program Files\QuickTime\QTSystem\;C:\Pfps\system;C:\Program Files\Java\jdk1.6.0_01\bin;C:\Program Files\Java\jdk1.6.0_01\jre\bin USERNAME=Alex OS=Windows_NT PROCESSOR_IDENTIFIER=x86 Family 15 Model 4 Stepping 1, GenuineIntel --------------- S Y S T E M --------------- OS: Windows XP Build 2600 Service Pack 2 CPU:total 1 family 15, cmov, cx8, fxsr, mmx, sse, sse2 Memory: 4k page, physical 1046508k(275288k free), swap 2522816k(1909176k free) vm_info: Java HotSpot(TM) Client VM (1.6.0_01-b06) for windows-x86, built on Mar 14 2007 00:24:02 by "java_re" with unknown MS VC++:1310 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070604/c87ae1f0/attachment-0001.html From alwyn.schoeman at gmail.com Tue Jun 5 00:10:19 2007 From: alwyn.schoeman at gmail.com (Alwyn Schoeman) Date: Tue, 5 Jun 2007 08:10:19 +0200 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Hi, I'm using a similar modem. By default rxtx doesn't look for devices that start with ACM, so you need to modify the source code and recompile. Look in RXTXCommDriver and add values for ACM in the registerScannedPorts method in the Linux specific parts. Look for osName.equals("Linux")... On 6/4/07, soop soop wrote: > > Hi Guys, > > Looked through the archives but still cannot figure this out. I have a > Motorola G24 GPRS/GSM modem that I am connecting to my server running > Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not > detecting the port, CommPortIdentifier.getPortIdentifiers(). > > I have added the line to RXTXCommDriver: > > "ttyACM" // for USB Modems > > Rxtx still does not seem to find the port. Is there something I am missing > to make this port visable? > > [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver > [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device > [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control > Model > driver for USB modems and ISDN adapters > > I really need your help as I have moved my server from windows to Linux > and > have been down for a few days because of this .. Thanks so much! > > _________________________________________________________________ > PC Magazine's 2007 editors' choice for best Web mail?award-winning Windows > Live Hotmail. > > http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -- Alwyn Schoeman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/b6cb3053/attachment-0001.html From naranjo.manuel at gmail.com Tue Jun 5 06:48:45 2007 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Tue, 05 Jun 2007 09:48:45 -0300 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> References: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Message-ID: <46655BAD.7010501@gmail.com> That's right, an easier solution is creating symlinks to acm. For example make ttyS70 to 79 point to ACM0 to 9 and that will help you a lot, and doesn't even require compile. > Hi, > > I'm using a similar modem. By default rxtx doesn't look for devices > that start with ACM, so you need to modify the > source code and recompile. > > Look in RXTXCommDriver and add values for ACM in the > registerScannedPorts method in the Linux specific parts. Look for > osName.equals("Linux")... > From juanemc2 at gmail.com Tue Jun 5 07:02:43 2007 From: juanemc2 at gmail.com (Juan) Date: Tue, 5 Jun 2007 10:02:43 -0300 Subject: [Rxtx] Problems with Epson TMU220B POSPrinter using XON/XOFF Flow Control and rxtx jar and dll's with the serial port. Message-ID: Hi!, I?m having trouble printing to the serial port using the latest version of rxtx jar and dll's with an Epson POSPrinter. I`ve switched the printer to work with XON/XOFF Flow Control and have watched the serial port to be sure the printer is sending the XON XOFF stop and go characters. I`ve setted the port like this: CommPortIdentifier commPortIdentifier = CommPortIdentifier.* getPortIdentifier*(_portName); SerialPort serialPort = (SerialPort)commPortIdentifier.open(*this*.getClass().getName(), 2000); serialPort.setSerialPortParams(_baudRate, _dataBits, _stopBits, _parity); serialPort.setFlowControlMode( SerialPort.*FLOWCONTROL_XONXOFF_IN* | SerialPort.*FLOWCONTROL_XONXOFF_OUT*); where the baudRate is 9600 the dataBits is 8 the stopBits is 1 and the parity is 0 It seems as the library isn`t taking into account the XON XOFF setting. I would like to know if I`m setting correctly the Flow Control and if you had had any experiences using XON XOFF flow control and could give me some help to solve my problem. I`m very thankful in advance, Yours, Juan Polero -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/b080995a/attachment-0001.html From ehdez.correo at gmail.com Tue Jun 5 07:12:53 2007 From: ehdez.correo at gmail.com (=?ISO-8859-1?Q?Enrique_Hern=E1ndez?=) Date: Tue, 5 Jun 2007 09:12:53 -0400 Subject: [Rxtx] problem with rxtx Message-ID: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Hello: I doing a simple test to show the serial ports. This is the code: import java.util.Enumeration; import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; public class Show { private Enumeration portList; private CommPortIdentifier portId; private SerialPort port; /** Creates a new instance of Show */ public Show() { } public static void main(String args[]){ Show show = new Show(); show.portList = CommPortIdentifier.getPortIdentifiers(); String tPort = ""; System.out.println("========================================="); while(show.portList.hasMoreElements()){ show.portId = (CommPortIdentifier)show.portList.nextElement(); if(show.portId.getPortType() == CommPortIdentifier.PORT_SERIAL) tPort = "Serial"; else tPort = "Parallel"; System.out.println(show.portId.getName() + " " + tPort); } } } whit The problem is that this code not show the serial ports, this show the no use serial ports. I want to connect whit the modem but when windows open and connect the modem my application don't see the port(COMM3) when it is connect. what I can do? Is that the correct way to know the ports? thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/eedd744b/attachment-0001.html From ehdez.correo at gmail.com Tue Jun 5 07:42:13 2007 From: ehdez.correo at gmail.com (=?ISO-8859-1?Q?Enrique_Hern=E1ndez?=) Date: Tue, 5 Jun 2007 09:42:13 -0400 Subject: [Rxtx] serial port Message-ID: <4a814e1f0706050642p4ce9ac7bka80f9479c524c5ea@mail.gmail.com> Hello: How I can ask to the port what device is connect and information about this device. thanks. bye. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/4d10d26a/attachment-0001.html From supsoop at hotmail.com Tue Jun 5 09:29:00 2007 From: supsoop at hotmail.com (soop soop) Date: Tue, 05 Jun 2007 15:29:00 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Message-ID: Hi Guys, Thanks for all your help. I found the problem. I created a user, Tomcat55, for my tomcat but it did not belong to any group. I then added this user to dialout group to have access to the device ttyACM0. Works perfectly! Again permissions was the issue. This also seems to be persistent as a server reboot does not effect the access. Cheers! >From: "Alwyn Schoeman" >Reply-To: RXTX Developers and Users >To: "RXTX Developers and Users" >Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >Date: Tue, 5 Jun 2007 08:10:19 +0200 > >Hi, > >I'm using a similar modem. By default rxtx doesn't look for devices that >start with ACM, so you need to modify the >source code and recompile. > >Look in RXTXCommDriver and add values for ACM in the registerScannedPorts >method in the Linux specific parts. Look for osName.equals("Linux")... > >On 6/4/07, soop soop wrote: >> >>Hi Guys, >> >>Looked through the archives but still cannot figure this out. I have a >>Motorola G24 GPRS/GSM modem that I am connecting to my server running >>Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not >>detecting the port, CommPortIdentifier.getPortIdentifiers(). >> >>I have added the line to RXTXCommDriver: >> >>"ttyACM" // for USB Modems >> >>Rxtx still does not seem to find the port. Is there something I am missing >>to make this port visable? >> >>[ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver >>[ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device >>[ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control >>Model >>driver for USB modems and ISDN adapters >> >>I really need your help as I have moved my server from windows to Linux >>and >>have been down for a few days because of this .. Thanks so much! >> >>_________________________________________________________________ >>PC Magazine's 2007 editors' choice for best Web mail—award-winning Windows >>Live Hotmail. >> >>http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 >> >> >>_______________________________________________ >>Rxtx mailing list >>Rxtx at qbang.org >>http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > >-- >Alwyn Schoeman >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ Need a break? Find your escape route with Live Search Maps. http://maps.live.com/default.aspx?ss=Restaurants~Hotels~Amusement%20Park&cp=33.832922~-117.915659&style=r&lvl=13&tilt=-90&dir=0&alt=-1000&scene=1118863&encType=1&FORM=MGAC01 From netbeans at gatworks.com Tue Jun 5 09:42:31 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 11:42:31 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <46658467.20101@gatworks.com> soop soop wrote: > > Hi Guys, > > Thanks for all your help. I found the problem. I created a user, > Tomcat55, for my tomcat but it did not belong to any group. I then added Look at man pages for the program udev. From tjarvi at qbang.org Tue Jun 5 18:18:17 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Jun 2007 18:18:17 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Message-ID: On Tue, 5 Jun 2007, Enrique Hern?ndez wrote: > The problem is that this code not show the serial ports, this show the no > use serial ports. I want to connect whit the modem but when windows open and > connect the modem my application don't see the port(COMM3) when it is > connect. > what I can do? > Is that the correct way to know the ports? > Hello, We may have problems understanding each other. On windows, the port will not be an available serial port if another application has the port open. That is just how the library behaves. If you can not see the port in the enumerated list, you could not open it. Also note that enumeration only happens once. If you add a port such as a new USB dongle, the port will not be visible until the next time your application runs. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Tue Jun 5 18:45:01 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 20:45:01 -0400 Subject: [Rxtx] problem with rxtx In-Reply-To: References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Message-ID: <4666038D.8090700@gatworks.com> Trent Jarvi wrote: > > > Also note that enumeration only happens once. If you add a port such as > a new USB dongle, the port will not be visible until the next time your > application runs. Is this written in stone ? somewhere? From tjarvi at qbang.org Tue Jun 5 18:54:36 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Jun 2007 18:54:36 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <4666038D.8090700@gatworks.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> Message-ID: On Tue, 5 Jun 2007, Uncle George wrote: > Trent Jarvi wrote: >> >> >> Also note that enumeration only happens once. If you add a port such as >> a new USB dongle, the port will not be visible until the next time your >> application runs. > > Is this written in stone ? somewhere? It is just the current behavior. There is nothing preventing a fix that allows reenumeration. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Tue Jun 5 19:55:19 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 21:55:19 -0400 Subject: [Rxtx] problem with rxtx In-Reply-To: References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> Message-ID: <46661407.4020308@gatworks.com> >> Is this written in stone ? somewhere? > > It is just the current behavior. There is nothing preventing a fix that > allows reenumeration. With usb, ..... , things come and go. Seems a shame that you have to kill application to get at the device u just plugged in. From joachim at buechse.ch Wed Jun 6 01:50:06 2007 From: joachim at buechse.ch (Joachim Buechse) Date: Wed, 6 Jun 2007 09:50:06 +0200 Subject: [Rxtx] problem with rxtx In-Reply-To: <46661407.4020308@gatworks.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> <46661407.4020308@gatworks.com> Message-ID: <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> On MacOS RXTX's enumeration handling is more flexible. It will find new ports that are added during the lifetime of the application. But this is inherently incompatible with suns javax.comm implementation... Regards, Joachim On 06.06.2007, at 03:55, Uncle George wrote: > >>> Is this written in stone ? somewhere? >> >> It is just the current behavior. There is nothing preventing a >> fix that >> allows reenumeration. > > With usb, ..... , things come and go. Seems a shame that you have to > kill application to get at the device u just plugged in. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Jun 6 06:06:48 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Jun 2007 06:06:48 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> <46661407.4020308@gatworks.com> <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> Message-ID: Sun's javax.comm is not a major concern going forward. As long as we do not break old applications using rxtx, I see no reason to limit rxtx to that convention. We have already rejected version 3 from Sun as a dead end and limited our compatability to version 2. That does not mean we will not try to work with Sun and others but the current javax.comm convention (v3) is not a well conceived path. There has been discussion about doing a JSR which is one valid option. On Wed, 6 Jun 2007, Joachim Buechse wrote: > On MacOS RXTX's enumeration handling is more flexible. It will find > new ports that are added during the lifetime of the application. But > this is inherently incompatible with suns javax.comm implementation... > > Regards, > Joachim > > On 06.06.2007, at 03:55, Uncle George wrote: > >> >>>> Is this written in stone ? somewhere? >>> >>> It is just the current behavior. There is nothing preventing a >>> fix that >>> allows reenumeration. >> >> With usb, ..... , things come and go. Seems a shame that you have to >> kill application to get at the device u just plugged in. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From yvespielusenet at free.fr Wed Jun 6 08:46:35 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 16:46:35 +0200 Subject: [Rxtx] [PARALLEL] resource in use Message-ID: <1181141195.3407.20.camel@localhost.localdomain> Hello, I want to use rxtx in my application. I haveto send data to a very old printer (which have a drum and hammers http://perso.orange.fr/tiie/page00010017.html) This is printer is connecter with centronics. It works well but, while it's writting and I putthe printer off-line, after about 45 seconds, I have this error : ------------------------------------- java.io.IOException: La ressource demand?e est en cours d'utilisation. in writeArray at gnu.io.LPRPort.writeArray(Native Method) at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:292) at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:161) at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:156) at mce.buffer.bufferManager.BufferManager$PrintBuffer.run(BufferManager.java:141) The IOexception means "The wanted resource is in use" ------------------------------------- Here is the line 141 of BufferManager : ------------------------------------- while(send){ try{ fos.write(bb); <=== line 141 send = false; } catch(Exception e){ javax.swing.JOptionPane.showMessageDialog(null, "Erreur d'envoie. Veuillez cliquer sur OK pour relancer l'impression de la vignette.\nV?rifiez votre impression !", "Erreur d'envoie", javax.swing.JOptionPane.WARNING_MESSAGE); e.printStackTrace(System.err); System.err.flush(); System.out.println(e); send = true; } } -------------------------------- 'fos' is an outputstream which contains the rxtx stream (this.os is the rxtx outputstream) : -------------------------------- public void write(byte[] bb) throws IOException{ this.write(bb, 0, bb.length); } public void write(byte[] bb, int off, int len) throws IOException{ while(!imp1.isPrinterSelected() || !imp2.isPrinterSelected()){ } this.os.write(bb, off, len); } -------------------------------- Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( can you help me ? thank you :) -- yves piel From yvespielusenet at free.fr Wed Jun 6 09:11:15 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 17:11:15 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181141195.3407.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> Message-ID: <1181142675.3407.23.camel@localhost.localdomain> I forgot to tell that It's under windows XP and java 1.5. Le mercredi 06 juin 2007 ? 16:46 +0200, yves pielusenet a ?crit : > Hello, > I want to use rxtx in my application. I haveto send data to a very old > printer (which have a drum and hammers > http://perso.orange.fr/tiie/page00010017.html) > This is printer is connecter with centronics. It works well but, while > it's writting and I putthe printer off-line, after about 45 seconds, I > have this error : > ------------------------------------- > java.io.IOException: La ressource demand?e est en cours d'utilisation. > in writeArray > at gnu.io.LPRPort.writeArray(Native Method) > at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:292) > at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:161) > at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:156) > at mce.buffer.bufferManager.BufferManager$PrintBuffer.run(BufferManager.java:141) > > The IOexception means "The wanted resource is in use" > ------------------------------------- > > Here is the line 141 of BufferManager : > > ------------------------------------- > while(send){ > try{ > fos.write(bb); <=== line 141 > send = false; > } > catch(Exception e){ > javax.swing.JOptionPane.showMessageDialog(null, "Erreur d'envoie. Veuillez cliquer sur OK pour relancer l'impression de la vignette.\nV?rifiez votre impression !", "Erreur d'envoie", javax.swing.JOptionPane.WARNING_MESSAGE); > e.printStackTrace(System.err); > System.err.flush(); > System.out.println(e); > send = true; > } > } > -------------------------------- > 'fos' is an outputstream which contains the rxtx stream (this.os is the rxtx outputstream) : > > -------------------------------- > public void write(byte[] bb) throws IOException{ > this.write(bb, 0, bb.length); > } > public void write(byte[] bb, int off, int len) throws IOException{ > while(!imp1.isPrinterSelected() || !imp2.isPrinterSelected()){ > } > this.os.write(bb, off, len); > } > -------------------------------- > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > can you help me ? > > thank you :) > From netbeans at gatworks.com Wed Jun 6 09:21:46 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 11:21:46 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181141195.3407.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> Message-ID: <4666D10A.8000507@gatworks.com> } > -------------------------------- > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > can you help me ? > > thank you :) > windoz or linux? ( I guess windoz ) for windoz, there appears to be a timeout ( as Comments suggest ) of about 40seconds. > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } for linux, there is no implied timeout. > if( write( fd, bytes, count ) < 0 ) > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); From netbeans at gatworks.com Wed Jun 6 09:39:41 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 11:39:41 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666D10A.8000507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> Message-ID: <4666D53D.90000@gatworks.com> Uncle George wrote: > } >> -------------------------------- >> >> Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( >> >> can you help me ? From reading the code, I can see your concern. And it appears you are correct, because some of the data will be sent to the OS printer buffers, and then it will refuse to accept anymore. Unfortunately, writeArray does not return the num of characters written :{ So application has no idea to how many characters were accepted by the OS. I dont do windoz, so I cant say with absolute certainty what windoz will do with an off-line condition. If you have the source, and can compile, then maybe u can increase the loop count to hit 4hours? From yvespielusenet at free.fr Wed Jun 6 09:53:25 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 17:53:25 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666D10A.8000507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> Message-ID: <1181145205.3407.35.camel@localhost.localdomain> Thank you for your explanation :) This timeout comes when no data has been send to the printer after 40seconds if I well understand. But why there is such a timeout ? If I setthe printer offline while it's printing I mustn't have an exception. I don't understand why the "printer should solv all problems like buffer full" in 40 seconds. If I pause the printer the buffer will not be emptied, isn't it ? I not very familiar with C/C++, but it seem that the exception is thrown only when countWritten == 0, that means no data at all has been sent. So Is my code is good since when I intercept this exception I send all my buffer again. There is no way that the printer receive two times same bytes ? thanks ps: yes the application is running on windows XP since I developpe under Debian Le mercredi 06 juin 2007 ? 11:21 -0400, Uncle George a ?crit : > } > > -------------------------------- > > > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > > > can you help me ? > > > > thank you :) > > > > windoz or linux? ( I guess windoz ) > > for windoz, there appears to be a timeout ( as Comments suggest ) of > about 40seconds. > > while( count > 0 ){ > > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > > /* > > this are 20 * 2 seconds, in this time a printer (or other parallel device) > > should solv all problems like buffer full, etc > > */ > > if(errorCount++ < 20){ > > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > > continue; > > } > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > for linux, there is no implied timeout. > > if( write( fd, bytes, count ) < 0 ) > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Wed Jun 6 10:34:24 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 12:34:24 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181145205.3407.35.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> Message-ID: <4666E210.30507@gatworks.com> yves pielusenet wrote: > Thank you for your explanation :) > This timeout comes when no data has been send to the printer after > 40seconds if I well understand. But why there is such a timeout ? If I > setthe printer offline while it's printing I mustn't have an exception. > I don't understand why the "printer should solv all problems like buffer > full" in 40 seconds. If I pause the printer the buffer will not be > emptied, isn't it ? > > I not very familiar with C/C++, but it seem that the exception is thrown > only when countWritten == 0, that means no data at all has been sent. So > Is my code is good since when I intercept this exception I send all my > buffer again. There is no way that the printer receive two times same > bytes ? More technically, the function call returns and reports that 0 characters was written in this call. when 0 characters are written, it will check how many times 0 characters was written. If it has tried LESS than 20 times(errorCount), it will sleep() and try to write again. After 20 times, it wont sleep, but throw you the exception. Now suppose you are writing a 120 character line. you off-lined/paused your printer. The OS has room for 80 more characters in it's printer buffer. The WriteFile() will have a char count of 120, but on return the countWritten = 80. You still have 40 more characters to print. Since countWritten != 0, the counters: bytes += countWritten; count -= countWritten; get updated, and the Writefile now has a count of 40 characters. Since the printer is off-line, the countwritten is 0. And so the loop continues, till 40 seconds is up. As to why it is this way, i dont know ( not a windoz maven ); Also the sleep(20) in the loop is not so intuitive to suggest 2 seconds of sleep. I would have guessed 20seconds, or 20milliseconds. But go figure. BTW: Since your computer sends you error messages in French, does it curse in English? :)))) From yvespielusenet at free.fr Thu Jun 7 02:27:44 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Thu, 07 Jun 2007 10:27:44 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666E210.30507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> Message-ID: <1181204864.3501.10.camel@localhost.localdomain> Maybe in my case I should re-compile rxtx and change the code. Instead of send an exception I should display a dialog box to ask if it's printer problem or if it should trie to send bytes. Something like : while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } if(displayDialogBox("Try again to send datas ??")){ errorCount = 0; } else{ throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } } Le mercredi 06 juin 2007 ? 12:34 -0400, Uncle George a ?crit : > yves pielusenet wrote: > > Thank you for your explanation :) > > This timeout comes when no data has been send to the printer after > > 40seconds if I well understand. But why there is such a timeout ? If I > > setthe printer offline while it's printing I mustn't have an exception. > > I don't understand why the "printer should solv all problems like buffer > > full" in 40 seconds. If I pause the printer the buffer will not be > > emptied, isn't it ? > > > > I not very familiar with C/C++, but it seem that the exception is thrown > > only when countWritten == 0, that means no data at all has been sent. So > > Is my code is good since when I intercept this exception I send all my > > buffer again. There is no way that the printer receive two times same > > bytes ? > More technically, the function call returns and reports that 0 > characters was written in this call. > when 0 characters are written, it will check how many times 0 characters > was written. If it has tried LESS than 20 times(errorCount), it will > sleep() and try to write again. > After 20 times, it wont sleep, but throw you the exception. > > Now suppose you are writing a 120 character line. you off-lined/paused > your printer. The OS has room for 80 more characters in it's printer > buffer. The WriteFile() will have a char count of 120, but on return the > countWritten = 80. You still have 40 more characters to print. > Since countWritten != 0, the counters: > bytes += countWritten; > count -= countWritten; > get updated, and the Writefile now has a count of 40 characters. Since > the printer is off-line, the countwritten is 0. And so the loop > continues, till 40 seconds is up. > > As to why it is this way, i dont know ( not a windoz maven ); > Also the sleep(20) in the loop is not so intuitive to suggest 2 seconds > of sleep. I would have guessed 20seconds, or 20milliseconds. But go figure. > > BTW: Since your computer sends you error messages in French, does it > curse in English? :)))) > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 06:11:43 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 08:11:43 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181204864.3501.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> Message-ID: <4667F5FF.8070903@gatworks.com> your suggestion appears good. I dont know what displayDialogBox exactly will do, so all I can say it that it looks good. But I'd like to wait 10min before first dialog box And a 5 min wait for every dialog box there after. And since these are custom solution/choices, maybe a more exact explanation of what the issue is. if(errorCount++ < 300){ // wait 10min ( 10min * 60sec / 2 ) Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } if(displayDialogBox("Printer has Paused. Retry sending data?")){ errorCount = 150; // Wait for 5 min thereafter continue; } > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } yves pielusenet wrote: > Maybe in my case I should re-compile rxtx and change the code. Instead > of send an exception I should display a dialog box to ask if it's > printer problem or if it should trie to send bytes. Something like : > > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > > if(displayDialogBox("Try again to send datas ??")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > } > From yvespielusenet at free.fr Thu Jun 7 07:17:21 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Thu, 07 Jun 2007 15:17:21 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4667F5FF.8070903@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <4667F5FF.8070903@gatworks.com> Message-ID: <1181222241.3501.20.camel@localhost.localdomain> thank you :) 'displayDialogBox()' I think doesn't exist. It was just for the example :) But I think It should not be so complicated to display a dialog box under windows with YES/NO buttons. When yes is clicked it return 0 other it returns 1. Le jeudi 07 juin 2007 ? 08:11 -0400, Uncle George a ?crit : > your suggestion appears good. I dont know what displayDialogBox exactly > will do, so all I can say it that it looks good. > > But I'd like to wait 10min before first dialog box And a 5 min wait for > every dialog box there after. And since these are custom > solution/choices, maybe a more exact explanation of what the issue is. > > if(errorCount++ < 300){ // wait 10min ( 10min * 60sec / 2 ) > Sleep( 20 ); /* make a small pause to execute all other requests > in all other threads */ > continue; > } > > if(displayDialogBox("Printer has Paused. Retry sending data?")){ > errorCount = 150; // Wait for 5 min thereafter > continue; > } > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > > yves pielusenet wrote: > > Maybe in my case I should re-compile rxtx and change the code. Instead > > of send an exception I should display a dialog box to ask if it's > > printer problem or if it should trie to send bytes. Something like : > > > > while( count > 0 ){ > > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > > /* > > this are 20 * 2 seconds, in this time a printer (or other parallel device) > > should solv all problems like buffer full, etc > > */ > > if(errorCount++ < 20){ > > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > > continue; > > } > > > > if(displayDialogBox("Try again to send datas ??")){ > > errorCount = 0; > > } > > else{ > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > } > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 07:41:43 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 09:41:43 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181222241.3501.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <4667F5FF.8070903@gatworks.com> <1181222241.3501.20.camel@localhost.localdomain> Message-ID: <46680B17.8050109@gatworks.com> yves pielusenet wrote: > thank you :) > 'displayDialogBox()' I think doesn't exist. It was just for the > example :) too bad. Good luck. From rtrout at webbresearch.com Thu Jun 7 11:23:04 2007 From: rtrout at webbresearch.com (Robert Trout) Date: Thu, 07 Jun 2007 13:23:04 -0400 Subject: [Rxtx] Disconnected PortServer TS causes Java to hang Message-ID: <1181236984.14186.33.camel@sisyphus.DinkumSoftware.com> I'm running Linux with sun's Java 1.4.2, Java comm API 2.0, RXTX 2.0-7pre1, and the RealPort digi driver. "/dev/ttyrp00" is a RealPort device. My Java application never returns from a ComPortIdentifier.getPortIdentifier("/dev/ttyrp00") call while the Digi PortServer TS 4 is disconnected from the network. If I later re-connect the PortServer, the call returns about 30 seconds later (it's like a serial port read or write is blocking until the PortServer is re- connected). With the PortServer disconnected, minicom immediately responds with "cannot open /dev/ttyrp00: No such file or directory". I would like my Java application to behave similarly. That is, respond with an error condition instead of hanging when the PortServer is not connected. Since minicom and Java behave differently, I think this "hanging" behavior may be due to RXTX or Java? Has anyone had a similar issue? Solutions? Suggestions? Thanks, Robert From vicnevicne at gmail.com Thu Jun 7 12:16:02 2007 From: vicnevicne at gmail.com (Vicne) Date: Thu, 07 Jun 2007 20:16:02 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181204864.3501.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> Message-ID: <46684B62.7080802@gmail.com> yves pielusenet wrote: > Maybe in my case I should re-compile rxtx and change the code. Instead > of send an exception I should display a dialog box to ask if it's > printer problem or if it should trie to send bytes. Something like : > > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > > if(displayDialogBox("Try again to send datas ??")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > } > Sorry to step in without a specific solution to your problem, but I wanted to share my feeling regarding this proposal. AFAIK, it's generally considered bad practice to pop-up a prompt from a library. The main reason is that in general use, you can't guarantee that someone is actually present behind the console. Imagine a print server in a machine room, connected to a park of printers. In that case, when one printer fails, the logical behaviour would be to use an other one. If you change RxTx the way you propose, the printer queue will simply be stuck with a useless "Try again to send data ?" prompt until an administrator opens a remote connection to the print server's console and clicks "no". Second, it would create a dependency upon the existence of a graphical console (if you go the graphical "dialogBox" way). On many applications (typically server or embedded ones), the JVM is "headless" and if you try to pop-up a dialog, your app would throw an exception (at best) or just wouldn't display the prompt anywhere... Going the "text console" way is not more reliable, because on graphical environments, the text console is hidden unless explicitly requested. My advice would be to think again and find another solution. Ideas are : - make the number of retries a parameter so that you can tune it to what you think is reasonable - throw a more specific exception when the number of retries has been reached, so that a specific prompt can be shown at a higher level Anyway, if you feel that the prompt is the way to go in your case, I would at least make that prompt conditional. The least intrusive way would probably be using a system property, like if("true".equals(System.getProperty("org.rxtx.usePrompt")) && displayDialogBox("Retry sending data ?")){ errorCount = 0; } else{ throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } By default, the behaviour would remain as it is now, but you could force the prompts by defining the property at VM launch if desired. (for example : java.exe -Dorg.rxtx.usePrompt=true myApp) Also, you seemed to say you wanted the printer to start again exactly where is stopped. It would indeed be the best way when the printer is put offline for a few seconds. On the other hand, if the printer is turned off (or the printer runs out of paper, or someone steps on the mains cable), then the only way to go back to a "stable" situation would be by printing the item (page, label, etc.) again from scratch... Just my two cents. Vicne PS : By the way, the dialog box thing is very platform dependant on the C-side, and I think the simplest way would probably be to bridge it to a Java call where you can implement it like you proposed : public boolean displayDialogBox(prompt) { return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); } From netbeans at gatworks.com Thu Jun 7 14:08:24 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 16:08:24 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46684B62.7080802@gmail.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> Message-ID: <466865B8.4060004@gatworks.com> My feeling is that the code that was suggested was for his environs ( his shop ). The issue here is that after a 40+ second wait, an exception will be thrown. But you really dont have a way of 'cancelling' all the WriteFiles() that have already occured before the exception so that your writeArray and the Commapi can backtrack to a position in which they are in sync. The main ( really mine ) concern is not to lose data, or replicate data. After 40seconds, 300 seconds, 55min, no matter how long, data should not be lost or duplicated. But as soon as the exception is thrown, that possibility exists. Maybe an event should be thrown instead? Vicne wrote: > yves pielusenet wrote: >> Maybe in my case I should re-compile rxtx and change the code. Instead >> of send an exception I should display a dialog box to ask if it's >> printer problem or if it should trie to send bytes. Something like : >> >> while( count > 0 ){ >> if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ >> /* >> this are 20 * 2 seconds, in this time a printer (or other parallel device) >> should solv all problems like buffer full, etc >> */ >> if(errorCount++ < 20){ >> Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ >> continue; >> } >> >> if(displayDialogBox("Try again to send datas ??")){ >> errorCount = 0; >> } >> else{ >> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >> break; >> } >> } >> > > Sorry to step in without a specific solution to your problem, but I > wanted to share my feeling regarding this proposal. AFAIK, it's > generally considered bad practice to pop-up a prompt from a library. > The main reason is that in general use, you can't guarantee that > someone is actually present behind the console. Imagine a print server > in a machine room, connected to a park of printers. In that case, when > one printer fails, the logical behaviour would be to use an other one. > If you change RxTx the way you propose, the printer queue will simply be > stuck with a useless "Try again to send data ?" prompt until an > administrator opens a remote connection to the print server's console > and clicks "no". > Second, it would create a dependency upon the existence of a > graphical console (if you go the graphical "dialogBox" way). On many > applications (typically server or embedded ones), the JVM is "headless" > and if you try to pop-up a dialog, your app would throw an exception (at > best) or just wouldn't display the prompt anywhere... Going the "text > console" way is not more reliable, because on graphical environments, > the text console is hidden unless explicitly requested. > > My advice would be to think again and find another solution. Ideas are : > - make the number of retries a parameter so that you can tune it to what > you think is reasonable > - throw a more specific exception when the number of retries has been > reached, so that a specific prompt can be shown at a higher level > > Anyway, if you feel that the prompt is the way to go in your case, I > would at least make that prompt conditional. The least intrusive way > would probably be using a system property, like > > if("true".equals(System.getProperty("org.rxtx.usePrompt")) > && displayDialogBox("Retry sending data ?")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > > > By default, the behaviour would remain as it is now, but you could > force the prompts by defining the property at VM launch if desired. (for > example : java.exe -Dorg.rxtx.usePrompt=true myApp) > > > Also, you seemed to say you wanted the printer to start again > exactly where is stopped. It would indeed be the best way when the > printer is put offline for a few seconds. On the other hand, if the > printer is turned off (or the printer runs out of paper, or someone > steps on the mains cable), then the only way to go back to a "stable" > situation would be by printing the item (page, label, etc.) again from > scratch... > > > Just my two cents. > > > Vicne > > PS : By the way, the dialog box thing is very platform dependant on the > C-side, and I think the simplest way would probably be to bridge it to a > Java call where you can implement it like you proposed : > > public boolean displayDialogBox(prompt) { > return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", > JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); > } > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Thu Jun 7 17:48:11 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 Jun 2007 17:48:11 -0600 (MDT) Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <466865B8.4060004@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> Message-ID: An event is possible. I'm amazed this is the largest problem encountered while using the parallel code. How would the write ever exit if we throw events? Isn't this going to lead to hung applications? On Thu, 7 Jun 2007, Uncle George wrote: > My feeling is that the code that was suggested was for his environs ( > his shop ). > > The issue here is that after a 40+ second wait, an exception will be > thrown. But you really dont have a way of 'cancelling' all the > WriteFiles() that have already occured before the exception so that your > writeArray and the Commapi can backtrack to a position in which they are > in sync. > > The main ( really mine ) concern is not to lose data, or replicate data. > After 40seconds, 300 seconds, 55min, no matter how long, data should > not be lost or duplicated. But as soon as the exception is thrown, that > possibility exists. > > Maybe an event should be thrown instead? > > Vicne wrote: >> yves pielusenet wrote: >>> Maybe in my case I should re-compile rxtx and change the code. Instead >>> of send an exception I should display a dialog box to ask if it's >>> printer problem or if it should trie to send bytes. Something like : >>> >>> while( count > 0 ){ >>> if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ >>> /* >>> this are 20 * 2 seconds, in this time a printer (or other parallel device) >>> should solv all problems like buffer full, etc >>> */ >>> if(errorCount++ < 20){ >>> Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ >>> continue; >>> } >>> >>> if(displayDialogBox("Try again to send datas ??")){ >>> errorCount = 0; >>> } >>> else{ >>> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >>> break; >>> } >>> } >>> >> >> Sorry to step in without a specific solution to your problem, but I >> wanted to share my feeling regarding this proposal. AFAIK, it's >> generally considered bad practice to pop-up a prompt from a library. >> The main reason is that in general use, you can't guarantee that >> someone is actually present behind the console. Imagine a print server >> in a machine room, connected to a park of printers. In that case, when >> one printer fails, the logical behaviour would be to use an other one. >> If you change RxTx the way you propose, the printer queue will simply be >> stuck with a useless "Try again to send data ?" prompt until an >> administrator opens a remote connection to the print server's console >> and clicks "no". >> Second, it would create a dependency upon the existence of a >> graphical console (if you go the graphical "dialogBox" way). On many >> applications (typically server or embedded ones), the JVM is "headless" >> and if you try to pop-up a dialog, your app would throw an exception (at >> best) or just wouldn't display the prompt anywhere... Going the "text >> console" way is not more reliable, because on graphical environments, >> the text console is hidden unless explicitly requested. >> >> My advice would be to think again and find another solution. Ideas are : >> - make the number of retries a parameter so that you can tune it to what >> you think is reasonable >> - throw a more specific exception when the number of retries has been >> reached, so that a specific prompt can be shown at a higher level >> >> Anyway, if you feel that the prompt is the way to go in your case, I >> would at least make that prompt conditional. The least intrusive way >> would probably be using a system property, like >> >> if("true".equals(System.getProperty("org.rxtx.usePrompt")) >> && displayDialogBox("Retry sending data ?")){ >> errorCount = 0; >> } >> else{ >> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >> break; >> } >> >> >> By default, the behaviour would remain as it is now, but you could >> force the prompts by defining the property at VM launch if desired. (for >> example : java.exe -Dorg.rxtx.usePrompt=true myApp) >> >> >> Also, you seemed to say you wanted the printer to start again >> exactly where is stopped. It would indeed be the best way when the >> printer is put offline for a few seconds. On the other hand, if the >> printer is turned off (or the printer runs out of paper, or someone >> steps on the mains cable), then the only way to go back to a "stable" >> situation would be by printing the item (page, label, etc.) again from >> scratch... >> >> >> Just my two cents. >> >> >> Vicne >> >> PS : By the way, the dialog box thing is very platform dependant on the >> C-side, and I think the simplest way would probably be to bridge it to a >> Java call where you can implement it like you proposed : >> >> public boolean displayDialogBox(prompt) { >> return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", >> JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); >> } >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 19:18:51 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 21:18:51 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> Message-ID: <4668AE7B.3060409@gatworks.com> The UNIX version of writeArray is not too great either. It is possible that the write will only process some of the bytes. #else if( write( fd, bytes, count ) < 0 ) throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); #endif -------------------------------- Maybe it might be better to have the native function inform the caller of the # of characters written, then the commapi/output-buffer can be modified to reflect the #of chars written. If an exception is to be thrown, for too many loops of chars written == 0, then exception wont affect the state of the output buffer. Then a ParallelPort.restart() can be called to resume printing whats in the buffer. Trent Jarvi wrote: > An event is possible. I'm amazed this is the largest problem encountered > while using the parallel code. > > How would the write ever exit if we throw events? Isn't this going to > lead to hung applications? Sure. If you dont time out, then there is nothing that will force an EXIT from the write(). Issue is what has the OS done with the write. > > On Thu, 7 Jun 2007, Uncle George wrote: > >> My feeling is that the code that was suggested was for his environs ( >> his shop ). From yvespielusenet at free.fr Fri Jun 8 01:09:01 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Fri, 08 Jun 2007 09:09:01 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4668AE7B.3060409@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> Message-ID: <1181286541.3674.10.camel@localhost.localdomain> It is not possible that the rxtx java method write(byte[], int offset, int length) return anint which contains the number of byte really send to the printer instead of an exception ? So this is the programm which will see if all bytes have been sent. If not it can retry to send the unsended bytes. -------------------------------------------------------- int sended = 0; while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ sended += countWritten; /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } return sended; /*throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break;*/ } ... ... return countWritten; ------------------------------------------------ Le jeudi 07 juin 2007 ? 21:18 -0400, Uncle George a ?crit : > The UNIX version of writeArray is not too great either. It is possible > that the write will only process some of the bytes. > > #else > if( write( fd, bytes, count ) < 0 ) > throw_java_exception_system_msg( env, IO_EXCEPTION, > "writeArray" ); > #endif > -------------------------------- > > Maybe it might be better to have the native function inform the caller > of the # of characters written, then the commapi/output-buffer can be > modified to reflect the #of chars written. If an exception is to be > thrown, for too many loops of chars written == 0, then exception wont > affect the state of the output buffer. Then a ParallelPort.restart() can > be called to resume printing whats in the buffer. > > > Trent Jarvi wrote: > > An event is possible. I'm amazed this is the largest problem encountered > > while using the parallel code. > > > > How would the write ever exit if we throw events? Isn't this going to > > lead to hung applications? > Sure. If you dont time out, then there is nothing that will force an > EXIT from the write(). Issue is what has the OS done with the write. > > > > On Thu, 7 Jun 2007, Uncle George wrote: > > > >> My feeling is that the code that was suggested was for his environs ( > >> his shop ). > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Fri Jun 8 03:45:00 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 11:45:00 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181286541.3674.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> Message-ID: <20070608094500.GC21069@elberon.bln.de.ingenico.com> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > It is not possible that the rxtx java method write(byte[], int offset, > int length) return anint which contains the number of byte really send > to the printer instead of an exception ? > So this is the programm which will see if all bytes have been sent. If > not it can retry to send the unsended bytes. I think write() is void because in Java people love to do this since OutputStream :-) Of course on such interfaces you cannot implement something nice. If you would have a int write, you would not implement the interface and no applications expecting this interface would link/work/compile. oki, Steffen P.S.: (OT) If you propose not to implement the Java interfaces (especially not on JNI level), maybe optionally offering a wrapper that removes e.g. the write return value and so on to downgrade the powerful classic old POSIX read/write style to the modern limited Java style, then I agree :-) Same for read. Instead of things like "int avialable()" it is more powerful to have an approach as select(2) offers (to guarante the caller that read/write will not block [nothing else make sense anyway IMHO] but may read/write less bytes then requested). The caller gets full control and the higher level protocols can care about timeouts, invoking read in some loops and/or implement retransmission. On top of such an implementation, where everything is controlled, defined, guaranteed and reliable, someone could use an InputStream or OutputStream style interface. Or even better: don't use them at all :) just BTW :-) St. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From yvespielusenet at free.fr Fri Jun 8 05:52:45 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Fri, 08 Jun 2007 13:52:45 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <20070608094500.GC21069@elberon.bln.de.ingenico.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> Message-ID: <1181303565.11203.3.camel@localhost.localdomain> So maybe a better way should be to create a new Exception class which has a method "int getWrittenByte()". So the Exception should be use to send again bytes which are not printed yet. yves Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : > * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > > It is not possible that the rxtx java method write(byte[], int offset, > > int length) return anint which contains the number of byte really send > > to the printer instead of an exception ? > > So this is the programm which will see if all bytes have been sent. If > > not it can retry to send the unsended bytes. > > I think write() is void because in Java people love to do this > since OutputStream :-) Of course on such interfaces you cannot > implement something nice. If you would have a int write, you > would not implement the interface and no applications expecting > this interface would link/work/compile. > > oki, > > Steffen > > P.S.: (OT) > If you propose not to implement the Java interfaces (especially > not on JNI level), maybe optionally offering a wrapper that > removes e.g. the write return value and so on to downgrade the > powerful classic old POSIX read/write style to the modern limited > Java style, then I agree :-) Same for read. Instead of things > like "int avialable()" it is more powerful to have an approach as > select(2) offers (to guarante the caller that read/write will not > block [nothing else make sense anyway IMHO] but may read/write > less bytes then requested). The caller gets full control and the > higher level protocols can care about timeouts, invoking read in > some loops and/or implement retransmission. On top of such an > implementation, where everything is controlled, defined, > guaranteed and reliable, someone could use an InputStream or > OutputStream style interface. Or even better: don't use them at > all :) just BTW :-) > St. > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > 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. > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > 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. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Fri Jun 8 06:46:21 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 08:46:21 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181303565.11203.3.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> Message-ID: <46694F9D.5080501@gatworks.com> It seems that with outputstream.write(b[]), you become terribly uncoordinated as soon as an exception is thrown. Docs do not say what happens to the data. Yet from a practicable point of view, one would like to know if the write was accepted in-full, or rejected before any writes. There are no in betweens, as partial writes are not reportable. So for an outputstream.write(), in order for it to return, the full write request has to be taken, and stored in an internal output buffer. If there is no room, the write() is suspended, till there is room. Or throw's an IOException( "no room in buffer") ; As the select() loop for write reports buffer room avail, then more of the internal buffer is sent to the printer. yves pielusenet wrote: > So maybe a better way should be to create a new Exception class which > has a method "int getWrittenByte()". So the Exception should be use to > send again bytes which are not printed yet. > > yves > > Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : >> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: >>> It is not possible that the rxtx java method write(byte[], int offset, >>> int length) return anint which contains the number of byte really send >>> to the printer instead of an exception ? >>> So this is the programm which will see if all bytes have been sent. If >>> not it can retry to send the unsended bytes. >> I think write() is void because in Java people love to do this >> since OutputStream :-) Of course on such interfaces you cannot >> implement something nice. If you would have a int write, you >> would not implement the interface and no applications expecting >> this interface would link/work/compile. >> >> oki, >> >> Steffen >> >> P.S.: (OT) >> If you propose not to implement the Java interfaces (especially >> not on JNI level), maybe optionally offering a wrapper that >> removes e.g. the write return value and so on to downgrade the >> powerful classic old POSIX read/write style to the modern limited >> Java style, then I agree :-) Same for read. Instead of things >> like "int avialable()" it is more powerful to have an approach as >> select(2) offers (to guarante the caller that read/write will not >> block [nothing else make sense anyway IMHO] but may read/write >> less bytes then requested). The caller gets full control and the >> higher level protocols can care about timeouts, invoking read in >> some loops and/or implement retransmission. On top of such an >> implementation, where everything is controlled, defined, >> guaranteed and reliable, someone could use an InputStream or >> OutputStream style interface. Or even better: don't use them at >> all :) just BTW :-) >> St. >> >> About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. >> 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. >> >> About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. >> 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. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From Steffen.DETTMER at ingenico.com Fri Jun 8 08:12:18 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 16:12:18 +0200 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <46694F9D.5080501@gatworks.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: <20070608141218.GE21069@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 08:46 -0400: > It seems that with outputstream.write(b[]), you become terribly > uncoordinated as soon as an exception is thrown. Docs do not say what > happens to the data. (yes, so avoiding it seems to be good :)) > Yet from a practicable point of view, one would like to know if the > write was accepted in-full, or rejected before any writes. There are no > in betweens, as partial writes are not reportable. (which is an artificial API limitation. I never understood how this happend when they invented JDK because the well-known BSD socket API and thus [probably] WinSock does this correct, but anyway) > So for an outputstream.write(), in order for it to return, the full > write request has to be taken, and stored in an internal output buffer. > If there is no room, the write() is suspended, till there is room. Or > throw's an IOException( "no room in buffer") ; As the select() loop for > write reports buffer room avail, then more of the internal buffer is > sent to the printer. yes, might be good in case of a printer. May be horrible in case of PPP/TCP or some other transmission control protocol which may e.g. repeat data or even omit parts of it (e.g. internet realtime radio station broadcasting)... So I think the idea of "int write" (e.g. BSD sockets, linux files and so on) still is the best. A clean API / implementation should guarantee and allow implementations (users) to rely on that; assumptions and automatic background-sending and so on may look pragmatic and may even work on the first look, but may fail in other situations. BTW, if e.g. BSD socket API is known, why not simply copy it (until something better is invented :)) instead of fiddling around with JDK APIs? anyway, have a nice weekend everyone :-) oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Fri Jun 8 08:55:56 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 10:55:56 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070608141218.GE21069@elberon.bln.de.ingenico.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> Message-ID: <46696DFC.7000801@gatworks.com> >> write reports buffer room avail, then more of the internal buffer is >> sent to the printer. > > yes, might be good in case of a printer. May be horrible in case > of PPP/TCP or some other transmission control protocol which > may e.g. repeat data or even omit parts of it (e.g. internet > realtime radio station broadcasting)... So I think the idea of > "int write" (e.g. BSD sockets, linux files and so on) still is > the best. A clean API / implementation should guarantee and allow > implementations (users) to rely on that; assumptions and > automatic background-sending and so on may look pragmatic and may > even work on the first look, but may fail in other situations. > BTW, if e.g. BSD socket API is known, why not simply copy it > (until something better is invented :)) instead of fiddling > around with JDK APIs? But we were talking about the Parallel Port, and the transmission of data over the commapi/parallel-port schema. There isn't much in bi-directional software communication. Its a simple write one byte at a time interface. I'm not looking to change the comm-api. I'm just looking to alter the interaction between the Native ParallelPort functions, and the java ParallelPort functions that call them. This might be more readily doable than to get a committee to re-specify java-API specs. BTW: Whats is off-topic? ( help: not looking for def of off-topic ) From j.kenneth.gentle at acm.org Fri Jun 8 08:58:59 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Fri, 08 Jun 2007 10:58:59 -0400 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <20070608141218.GE21069@elberon.bln.de.ingenico.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> Message-ID: <200706081459.l58Ex5rA019991@qbang.org> Perhaps it is a bit late to jump in on this one, but here goes anyway. If the solutions all seem to "break" the contract with "java.io.outputstream", then, as noted, that may not be the appropriate contract. At the risk of being heretical, JDK1.4 introduced the "nio" package to address some of the compatibility issues with C apis mentioned in previous posts. The interface "java.nio.channels.WriteableByteChannel" defines the following single method: int write(ByteBuffer source); int, strangely enough, is the actual number of bytes written. So, if RXTX as written, against the JavaCOMM api and OutputStream, doesn't do what we want, how about writing a different set of bindings using the java.nio classes and as much of the underlying native code as possible. Note that just because the java.nio.channels.WriteableByteChannel sends back a result, OutputStream.write doesn't have to - and they could both call the same underlying native code. My 2 cents - maybe not worth even that... Ken From netbeans at gatworks.com Fri Jun 8 10:37:28 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 12:37:28 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <200706081459.l58Ex5rA019991@qbang.org> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> Message-ID: <466985C8.8000505@gatworks.com> Ken Gentle wrote: > Perhaps it is a bit late to jump in on this one, but here goes anyway. Common in, the waters fine. > > If the solutions all seem to "break" the contract with > "java.io.outputstream", then, as noted, that may not be the > appropriate contract. > How would the contract be broken? The machinery underneath is handling the contract. From j.kenneth.gentle at acm.org Fri Jun 8 10:48:01 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Fri, 08 Jun 2007 12:48:01 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466985C8.8000505@gatworks.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> Message-ID: <200706081648.l58Gm7YA022904@qbang.org> At 12:37 2007-06-08, you wrote: >Ken Gentle wrote: > > > > If the solutions all seem to "break" the contract with > > "java.io.outputstream", then, as noted, that may not be the > > appropriate contract. > > >How would the contract be broken? The machinery underneath is handling >the contract. It seems that a lot of the discussion has been about not only the timeout and being able to adjust it in the "machinery layer", but also about knowing in the Java layer, in the event of a timeout or exception, how many characters have been written to the device. An OutputStream won't ever do this with out an extension and including a return value "breaks" the contract, right? So, go with a Java IO api that *does* return the number of bytes written, out of the NIO package. I know it doesn't allow for a strict implementation of the JavaCOMM API - however, using NIO classes in place of the IO classes isn't that big a break and would allow those applications that need such information a way to get it. Maybe I'm misunderstanding the problem... Ken From netbeans at gatworks.com Fri Jun 8 11:24:14 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 13:24:14 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <200706081648.l58Gm7YA022904@qbang.org> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> Message-ID: <466990BE.7040100@gatworks.com> Ken Gentle wrote: An > OutputStream won't ever do this with out an extension and including a > return value "breaks" the contract, right? > i was not thinking of change the API to OutputSream. Are there specs for how output stream should work internally? for instance: String data = "Hello this is a line of data"; Outputstream.write( data.getbytes() ); ParallelPort.suspend(); int free = ParallelPort.getoutputbufferfree(); There is a symbiotic relationship between outputstream and the functionality of ParallelPort. From Steffen.DETTMER at ingenico.com Fri Jun 8 11:15:39 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 19:15:39 +0200 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <200706081459.l58Ex5rA019991@qbang.org> References: <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> Message-ID: <20070608171539.GK21069@elberon.bln.de.ingenico.com> * Ken Gentle wrote on Fri, Jun 08, 2007 at 10:58 -0400: > If the solutions all seem to "break" the contract with > "java.io.outputstream", then, as noted, that may not be the > appropriate contract. > > At the risk of being heretical, JDK1.4 introduced the "nio" package > to address some of the compatibility issues with C apis mentioned in > previous posts. The interface > "java.nio.channels.WriteableByteChannel" defines the following single method: > > int write(ByteBuffer source); > > int, strangely enough, is the actual number of bytes written. Yes, AFAIK one of the motivations for the NIO interface was, that the JDK-1.3 APIs (InputStream, e.g.) were not powerfull enough, especially for multi-connection-TCP servers or so. I don't know much about it but I've heard of a project where NIO usage was removed because of stability issues in multi-threaded environments and performance limitations under some circumstances. IIRC the "nio.ByteBuffer" is something very special (namely something you cannot implement in Java, it is "magic" or part of the language itself). Not sure if this is such a great idea (but for performance in the end sometimes heavy prices must be paid) :) > So, if RXTX as written, against the JavaCOMM api and OutputStream, > doesn't do what we want, how about writing a different set of > bindings using the java.nio classes and as much of the underlying > native code as possible. Yes, this would be an idea: use a full-featured interface on JNI, and, if wanted, deliver some wrappers converting this to a less-featured Java-compliant interface. However, powerful things as e.g. "select" are difficult to "emulate" if you are e.g. on some (older?) windows. But if you expose the full-featured APIs, you need to emulate them full-featured, theoretically. In the end it depends what you do on the serial line. If you just want to talk to a modem, then you may not need precise timeouts. But if you need to implement complexer protocols which define response times and timeouts, you may quickly get into difficulties. For instance, AFAIK, rxtx 1.7.2 (?) for windows is very messy with timeouts (there is a maximum, higher values are truncated; resolution is 100ms only; the function may take up to twice the timeout because internally it may be called twice). Probably for most people this is OK, but probably not for all. But having precise timeouts should be OK for all :-) Well, in the end it is nice to wish but somewhat hard to implement (many platforms, connections, USB, BlueTooth, whatever). oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Steffen.DETTMER at ingenico.com Fri Jun 8 11:04:22 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 19:04:22 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <46696DFC.7000801@gatworks.com> References: <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <46696DFC.7000801@gatworks.com> Message-ID: <20070608170422.GJ21069@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 10:55 -0400: > > BTW, if e.g. BSD socket API is known, why not simply copy it > > (until something better is invented :)) instead of fiddling > > around with JDK APIs? > > But we were talking about the Parallel Port, and the > transmission of data over the commapi/parallel-port schema. > There isn't much in bi-directional software communication. Its > a simple write one byte at a time interface. First, there are things like PLIP (http://en.wikipedia.org/wiki/Plip) - well, probably not widely used, sure ;) Second, I think if there is a good simple API known to support all that (with known "best practices") or so and there is no forcing need to invent a new one, why not simply using it? > I'm not looking to change the comm-api. I'm just looking to > alter the interaction between the Native ParallelPort > functions, and the java ParallelPort functions that call them. Ahh, yes. I think this is what I tried to ask. Having an usable JNI interface and on top (in pure java) some wrapper to InputStream or whatever could be done (e.g. by ignoring the return value of write or throwing if != length). Developers could then use the full-featured (non-JAVA-standard) API or select among various wrappers (as InputStream). > This might be more readily doable than to get a committee to > re-specify java-API specs. Yes, of course. I'm afraid that the Java APIs change regularily, but still yet with limited success it seems, so maybe they get it in one of the next iterations; who knows, maybe Java-9 has a BSD-like socket API :) SCNR. > BTW: Whats is off-topic? ( help: not looking for def of > off-topic ) I think I started some "re-specify java-API specs" which was OT probably. oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From lists at iDIAcomputing.com Fri Jun 8 18:48:54 2007 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Fri, 08 Jun 2007 20:48:54 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46684B62.7080802@gmail.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> Message-ID: <4669F8F6.3040101@iDIAcomputing.com> Vicne wrote: > Sorry to step in without a specific solution to your problem, but I > wanted to share my feeling regarding this proposal. AFAIK, it's > generally considered bad practice to pop-up a prompt from a library. ... > > My advice would be to think again and find another solution. Ideas are : > - make the number of retries a parameter so that you can tune it to what > you think is reasonable > - throw a more specific exception when the number of retries has been > reached, so that a specific prompt can be shown at a higher level You could also allow the client code to register a callback class which returns a boolean indicating whether to retry or cancel. This callback class could pop up a dialog, if appropriate, or follow some preset policy, or.... - George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From joachim at buechse.ch Sat Jun 9 09:43:16 2007 From: joachim at buechse.ch (Joachim Buechse) Date: Sat, 9 Jun 2007 17:43:16 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46694F9D.5080501@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: You should not forget, that in the case of an exception it may not even be known what happened to the data. You have a kernel buffer, outgoing chip buffer, incoming chip buffer, etc. So of course, it would be nice to know up to which point data was correctly processed, but this feedback does not exist on the hardware or protocol level and hence can in general not be magicly created on the software level... Regards, Joachim On 08.06.2007, at 14:46, Uncle George wrote: > It seems that with outputstream.write(b[]), you become terribly > uncoordinated as soon as an exception is thrown. Docs do not say what > happens to the data. > > Yet from a practicable point of view, one would like to know if the > write was accepted in-full, or rejected before any writes. There > are no > in betweens, as partial writes are not reportable. > > So for an outputstream.write(), in order for it to return, the full > write request has to be taken, and stored in an internal output > buffer. > If there is no room, the write() is suspended, till there is room. Or > throw's an IOException( "no room in buffer") ; As the select() loop > for > write reports buffer room avail, then more of the internal buffer is > sent to the printer. > > > > yves pielusenet wrote: >> So maybe a better way should be to create a new Exception class which >> has a method "int getWrittenByte()". So the Exception should be >> use to >> send again bytes which are not printed yet. >> >> yves >> >> Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : >>> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: >>>> It is not possible that the rxtx java method write(byte[], int >>>> offset, >>>> int length) return anint which contains the number of byte >>>> really send >>>> to the printer instead of an exception ? >>>> So this is the programm which will see if all bytes have been >>>> sent. If >>>> not it can retry to send the unsended bytes. >>> I think write() is void because in Java people love to do this >>> since OutputStream :-) Of course on such interfaces you cannot >>> implement something nice. If you would have a int write, you >>> would not implement the interface and no applications expecting >>> this interface would link/work/compile. >>> >>> oki, >>> >>> Steffen >>> >>> P.S.: (OT) >>> If you propose not to implement the Java interfaces (especially >>> not on JNI level), maybe optionally offering a wrapper that >>> removes e.g. the write return value and so on to downgrade the >>> powerful classic old POSIX read/write style to the modern limited >>> Java style, then I agree :-) Same for read. Instead of things >>> like "int avialable()" it is more powerful to have an approach as >>> select(2) offers (to guarante the caller that read/write will not >>> block [nothing else make sense anyway IMHO] but may read/write >>> less bytes then requested). The caller gets full control and the >>> higher level protocols can care about timeouts, invoking read in >>> some loops and/or implement retransmission. On top of such an >>> implementation, where everything is controlled, defined, >>> guaranteed and reliable, someone could use an InputStream or >>> OutputStream style interface. Or even better: don't use them at >>> all :) just BTW :-) >>> St. >>> >>> About Ingenico Throughout the world businesses rely on Ingenico >>> for secure and expedient electronic transaction acceptance. >>> Ingenico products leverage proven technology, established >>> standards and unparalleled ergonomics to provide optimal >>> reliability, versatility and usability. This comprehensive range >>> of products is complemented by a global array of services and >>> partnerships, enabling businesses in a number of vertical sectors >>> to accept transactions anywhere their business takes them. >>> 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. >>> >>> About Ingenico Throughout the world businesses rely on Ingenico >>> for secure and expedient electronic transaction acceptance. >>> Ingenico products leverage proven technology, established >>> standards and unparalleled ergonomics to provide optimal >>> reliability, versatility and usability. This comprehensive range >>> of products is complemented by a global array of services and >>> partnerships, enabling businesses in a number of vertical sectors >>> to accept transactions anywhere their business takes them. >>> 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. >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx 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 yvespielusenet at free.fr Mon Jun 11 03:15:12 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Mon, 11 Jun 2007 11:15:12 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: <1181553312.8335.14.camel@localhost.localdomain> So can someone tell a solution for my problem :( Must I say to the user to not put the printer off-line ? I can't since he has to do some pauses, verify print, paper conditioning etc... How do other people ? Before I use the parport librarry to read port status : http://www.geocities.com/Juanga69/parport/ (which doesn't work on windows XP) And I send data into the file LPT1 I use to have no problem when printer was disabled. thanks -- yves piel Le samedi 09 juin 2007 ? 17:43 +0200, Joachim Buechse a ?crit : > You should not forget, that in the case of an exception it may not > even be known what happened to the data. > > You have a kernel buffer, outgoing chip buffer, incoming chip buffer, > etc. So of course, it would be nice to know up to which point data > was correctly processed, but this feedback does not exist on the > hardware or protocol level and hence can in general not be magicly > created on the software level... > > Regards, > Joachim > > On 08.06.2007, at 14:46, Uncle George wrote: > > > It seems that with outputstream.write(b[]), you become terribly > > uncoordinated as soon as an exception is thrown. Docs do not say what > > happens to the data. > > > > Yet from a practicable point of view, one would like to know if the > > write was accepted in-full, or rejected before any writes. There > > are no > > in betweens, as partial writes are not reportable. > > > > So for an outputstream.write(), in order for it to return, the full > > write request has to be taken, and stored in an internal output > > buffer. > > If there is no room, the write() is suspended, till there is room. Or > > throw's an IOException( "no room in buffer") ; As the select() loop > > for > > write reports buffer room avail, then more of the internal buffer is > > sent to the printer. > > > > > > > > yves pielusenet wrote: > >> So maybe a better way should be to create a new Exception class which > >> has a method "int getWrittenByte()". So the Exception should be > >> use to > >> send again bytes which are not printed yet. > >> > >> yves > >> > >> Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : > >>> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > >>>> It is not possible that the rxtx java method write(byte[], int > >>>> offset, > >>>> int length) return anint which contains the number of byte > >>>> really send > >>>> to the printer instead of an exception ? > >>>> So this is the programm which will see if all bytes have been > >>>> sent. If > >>>> not it can retry to send the unsended bytes. > >>> I think write() is void because in Java people love to do this > >>> since OutputStream :-) Of course on such interfaces you cannot > >>> implement something nice. If you would have a int write, you > >>> would not implement the interface and no applications expecting > >>> this interface would link/work/compile. > >>> > >>> oki, > >>> > >>> Steffen > >>> > >>> P.S.: (OT) > >>> If you propose not to implement the Java interfaces (especially > >>> not on JNI level), maybe optionally offering a wrapper that > >>> removes e.g. the write return value and so on to downgrade the > >>> powerful classic old POSIX read/write style to the modern limited > >>> Java style, then I agree :-) Same for read. Instead of things > >>> like "int avialable()" it is more powerful to have an approach as > >>> select(2) offers (to guarante the caller that read/write will not > >>> block [nothing else make sense anyway IMHO] but may read/write > >>> less bytes then requested). The caller gets full control and the > >>> higher level protocols can care about timeouts, invoking read in > >>> some loops and/or implement retransmission. On top of such an > >>> implementation, where everything is controlled, defined, > >>> guaranteed and reliable, someone could use an InputStream or > >>> OutputStream style interface. Or even better: don't use them at > >>> all :) just BTW :-) > >>> St. > >>> > >>> About Ingenico Throughout the world businesses rely on Ingenico > >>> for secure and expedient electronic transaction acceptance. > >>> Ingenico products leverage proven technology, established > >>> standards and unparalleled ergonomics to provide optimal > >>> reliability, versatility and usability. This comprehensive range > >>> of products is complemented by a global array of services and > >>> partnerships, enabling businesses in a number of vertical sectors > >>> to accept transactions anywhere their business takes them. > >>> 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. > >>> > >>> About Ingenico Throughout the world businesses rely on Ingenico > >>> for secure and expedient electronic transaction acceptance. > >>> Ingenico products leverage proven technology, established > >>> standards and unparalleled ergonomics to provide optimal > >>> reliability, versatility and usability. This comprehensive range > >>> of products is complemented by a global array of services and > >>> partnerships, enabling businesses in a number of vertical sectors > >>> to accept transactions anywhere their business takes them. > >>> 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. > >>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx 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 > From Steffen.DETTMER at ingenico.com Mon Jun 11 03:56:18 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 11:56:18 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466990BE.7040100@gatworks.com> References: <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> Message-ID: <20070611095618.GA10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 13:24 -0400: > i was not thinking of change the API to OutputSream. Then I think either someone uses OutputStream (and has no reliable information about incomplete writes) or someone uses somethink else. > Are there specs for how output stream should work internally? > > for instance: > String data = "Hello this is a line of data"; > Outputstream.write( data.getbytes() ); > ParallelPort.suspend(); > int free = ParallelPort.getoutputbufferfree(); > > There is a symbiotic relationship between outputstream and the > functionality of ParallelPort. If you need OutputStream "plus something else", in short you're needing "something else". Personally I dislike the code above a lot. The stream "looks" like if it would be an OutputStream, but in fact it isn't. You need to call getoutputbufferfree later to check if write succeeded (but OutputStream promises that write succeedes synchronous, blocking, or throws an exception). So it is not an OutputStream. No application written for OutputStreams would work without change (because it won't know getoutputbufferfree at all). It is not abstracted from ParallelPort. I think this would be wrong. Then I think an alternative interface instead is better. Let's assume we had some "connection" (to distinguish between OutputStreams and Channels). Then why not working as on a file handle in POSIX: do { // ... select maybe using timer ... readyForWrite = ... if (readyForWrite) { int writtenBytes = connection.write(toWrite); toWrite.remove(0, writtenBytes); } while(readyForWrite && toWrite.length > 0); I think, having such a write isn't the big problem. I think, the difficult thing is around "select" - however this would look like. It should be OO, typesafe, performant, supporting multiple connections/channels/streams in various modes and should be orthogonal to other functionalities. Of course, this heavily depends on what the application is doing; for a simple situation (like reading a small, mandatory file from a local disk) this would be to uncomfortable (and offering unneeded features only). just BTW :) oki, Steffen -- // Modeline for VIM. Please don't remove. // (Help: autoindent, expandtab, shiftwidth=4, tabstop=4, textwidth=75) // vi: set ai et sw=4 ts=4 tw=75 ft=java: About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Mon Jun 11 05:38:33 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 07:38:33 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611095618.GA10821@elberon.bln.de.ingenico.com> References: <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> Message-ID: <466D3439.4020805@gatworks.com> Steffen DETTMER wrote: > (but OutputStream promises that write > succeedes synchronous, blocking, or throws an exception). Where is it so written? From Steffen.DETTMER at ingenico.com Mon Jun 11 06:36:50 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 14:36:50 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466D3439.4020805@gatworks.com> References: <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> <466D3439.4020805@gatworks.com> Message-ID: <20070611123650.GI10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Mon, Jun 11, 2007 at 07:38 -0400: > Steffen DETTMER wrote: > > > (but OutputStream promises that write > > succeedes synchronous, blocking, or throws an exception). > > Where is it so written? Now, as you ask, I think it is not written that clearly but follows from specification. mmm... Am I wrong? I understand the API doc in this way: * http://java.sun.com/j2se/1.4.2/docs/api/java/io/OutputStream.html#write(byte[]) > public void write(byte[] b) > throws IOException > > Writes b.length bytes from the specified byte array to this > output stream. The general contract for write(b) is that > it should have exactly the same effect as the call write(b, > 0, b.length). > > Parameters: > b - the data. > Throws: > IOException - if an I/O error occurs. > See Also: > write(byte[], int, int) and there is: > public void write(byte[] b, > int off, > int len) > throws IOException > > Writes len bytes from the specified byte array starting at > offset off to this output stream. The general contract for > write(b, off, len) is that some of the bytes in the array b > are written to the output stream in order; element b[off] > is the first byte written and b[off+len-1] is the last byte > written by this operation. > > The write method of OutputStream calls the write method of > one argument on each of the bytes to be written out. > Subclasses are encouraged to override this method and > provide a more efficient implementation. > > If b is null, a NullPointerException is thrown. > > If off is negative, or len is negative, or off+len is > greater than the length of the array b, then an > IndexOutOfBoundsException is thrown. > > Parameters: > b - the data. > off - the start offset in the data. > len - the number of bytes to write. > Throws: > IOException - if an I/O error occurs. In particular, an > IOException is thrown if the output stream is closed. In general, any specialisation (derived child class) must comform to this. So write in the end is specified (!) as "The write method ... calls the write method ... on each of the bytes to be written out". This is what must be implemented by ANY OutputStream. Of course, there is: "Subclasses are encouraged to override this method and provide a more efficient implementation." which IMHO does not contradict - the more efficient must behave in exactly the same way of course (just wasting less resources than a simple byte-by-byte write). So it does not matter here I think. The write that finally defines the behavior tells basically: > "Writes the specified byte to this output stream. The general > contract for write is that one byte is written to the output > stream. " > > Throws: > IOException - if an I/O error occurs. which IMHO is another way of saying "write writes the byte immediately and returns on success (only), otherwise an exception is thrown". Especially it cannot happen that zero bytes are written (i.e. the specified byte is NOT written) without an exception. So by this write must be synchronous and blocking, because otherwise it could not reliably know if an asynchronous operation will succeede or not (some getAsyncResult or so would be needed). Since write(byte[]) does this for each byte (or with a behavior beeing exactly the same as if it would do), I think this means that the write(byte[]) succeedes synchronous/blocking or throws an exception. Did I an error in reasoning or confused something or so? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From j.kenneth.gentle at acm.org Mon Jun 11 06:51:25 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 11 Jun 2007 08:51:25 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611123650.GI10821@elberon.bln.de.ingenico.com> References: <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> <466D3439.4020805@gatworks.com> <20070611123650.GI10821@elberon.bln.de.ingenico.com> Message-ID: <200706111251.l5BCpS9T017831@qbang.org> It is as Steffen describes. "InputStream" and "OutputStream" are inherently synchronous (which is why so many java programs resort to threads to use them). Anything outside of this "contract" is *not* an InputStream or OutputStream. That is why there is a new package for things that don't behave like the old *Stream classes - the NIO package. If you look carefully at the IO package, you'll note that almost all the classes are _Decorator_ pattern implementations of the *Stream classes - and the interface presents the _same_ behavior to the calling code in all cases - a synchronous operation that completes successfully or throws an exception (with the one exception of "read" that returns a "-1" on end-of-stream. I know I've read this numerous times - I'd suggest checking the Language Spec or one of the books by Bloch or Gosling. Ken At 08:36 2007-06-11, you wrote: >* Uncle George wrote on Mon, Jun 11, 2007 at 07:38 -0400: > > Steffen DETTMER wrote: > > > > > (but OutputStream promises that write > > > succeedes synchronous, blocking, or throws an exception). > > > > Where is it so written? > >Now, as you ask, I think it is not written that clearly but >follows from specification. mmm... > >Am I wrong? > >I understand the API doc in this way: > >* >http://java.sun.com/j2se/1.4.2/docs/api/java/io/OutputStream.html#write(byte[]) > > public void write(byte[] b) > > throws IOException > > > > Writes b.length bytes from the specified byte array to this > > output stream. The general contract for write(b) is that > > it should have exactly the same effect as the call write(b, > > 0, b.length). > > > > Parameters: > > b - the data. > > Throws: > > IOException - if an I/O error occurs. > > See Also: > > write(byte[], int, int) > > >and there is: > > > > public void write(byte[] b, > > int off, > > int len) > > throws IOException > > > > Writes len bytes from the specified byte array starting at > > offset off to this output stream. The general contract for > > write(b, off, len) is that some of the bytes in the array b > > are written to the output stream in order; element b[off] > > is the first byte written and b[off+len-1] is the last byte > > written by this operation. > > > > The write method of OutputStream calls the write method of > > one argument on each of the bytes to be written out. > > Subclasses are encouraged to override this method and > > provide a more efficient implementation. > > > > If b is null, a NullPointerException is thrown. > > > > If off is negative, or len is negative, or off+len is > > greater than the length of the array b, then an > > IndexOutOfBoundsException is thrown. > > > > Parameters: > > b - the data. > > off - the start offset in the data. > > len - the number of bytes to write. > > Throws: > > IOException - if an I/O error occurs. In particular, an > > IOException is thrown if the output stream is closed. > > >In general, any specialisation (derived child class) must comform >to this. So write in the end is specified (!) as "The write >method ... calls the write method ... on each of the bytes to be >written out". This is what must be implemented by ANY >OutputStream. > >Of course, there is: "Subclasses are encouraged to override this >method and provide a more efficient implementation." which IMHO >does not contradict - the more efficient must behave in exactly >the same way of course (just wasting less resources than a simple >byte-by-byte write). So it does not matter here I think. > > > >The write that finally defines the behavior tells basically: > > > "Writes the specified byte to this output stream. The general > > contract for write is that one byte is written to the output > > stream. " > > > > Throws: > > IOException - if an I/O error occurs. > > >which IMHO is another way of saying "write writes the byte >immediately and returns on success (only), otherwise an exception >is thrown". Especially it cannot happen that zero bytes are >written (i.e. the specified byte is NOT written) without an >exception. So by this write must be synchronous and blocking, >because otherwise it could not reliably know if an asynchronous >operation will succeede or not (some getAsyncResult or so would >be needed). > >Since write(byte[]) does this for each byte (or with a behavior >beeing exactly the same as if it would do), I think this means >that the write(byte[]) succeedes synchronous/blocking or throws >an exception. > >Did I an error in reasoning or confused something or so? > >oki, > >Steffen > >About Ingenico Throughout the world businesses rely on Ingenico for >secure and expedient electronic transaction acceptance. Ingenico >products leverage proven technology, established standards and >unparalleled ergonomics to provide optimal reliability, versatility >and usability. This comprehensive range of products is complemented >by a global array of services and partnerships, enabling businesses >in a number of vertical sectors to accept transactions anywhere >their business takes them. >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. > >About Ingenico Throughout the world businesses rely on Ingenico for >secure and expedient electronic transaction acceptance. Ingenico >products leverage proven technology, established standards and >unparalleled ergonomics to provide optimal reliability, versatility >and usability. This comprehensive range of products is complemented >by a global array of services and partnerships, enabling businesses >in a number of vertical sectors to accept transactions anywhere >their business takes them. >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. > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From alesinskyy at googlemail.com Mon Jun 11 07:25:33 2007 From: alesinskyy at googlemail.com (Oleksandr Alesinskyy) Date: Mon, 11 Jun 2007 15:25:33 +0200 Subject: [Rxtx] [OT] select :-) Message-ID: Sorry, but I have to disagree with following statement: "So write in the end is specified (!) as "The write method ... calls the write method ... on each of the bytes to be written out". This is what must be implemented by ANY OutputStream.". This is not part of the specification or contract, it is just revealed implementation detail of the OutputStream. It is not stated anywhere that behavoiur of derived classes shall conform with this one. Statement concerning "synchronous" nature of the output stream is invalid as well. Really synchronous stream does not require flush() but OutputStream has it. From Steffen.DETTMER at ingenico.com Mon Jun 11 08:21:16 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 16:21:16 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: Message-ID: <20070611142116.GN10821@elberon.bln.de.ingenico.com> * Oleksandr Alesinskyy wrote on Mon, Jun 11, 2007 at 15:25 +0200: > Sorry, but I have to disagree with following statement: > "So write in the end is specified (!) as "The write > method ... calls the write method ... on each of the bytes to be > written out". This is what must be implemented by ANY > OutputStream.". > > This is not part of the specification or contract, it is just > revealed implementation detail of the OutputStream. It is not > stated anywhere that behavoiur of derived classes shall conform > with this one. (I didn't meant that the implementation must really write byte by byte, but that it must "look as if it would do" - because all implementations of OutputStream must "look" in the same way [which is another way of saying "do abstract" I think]) I think the API doc is not "revealing implementation details" but it is the *specification* of that interface and derivations must (should) conform to this specification. Isn't this the idea of interfaces? A function that expects an OutputStream should work on ANY OutputStream, shouldn't it? just kidding: I mean, what would be the point in implementing a checksum function as OutputStream.write which throws its result as IOException? Or which requires to call close() as very first operation to tell that the application is about to transmit confidential data? :-) > Statement concerning "synchronous" nature of the output stream > is invalid as well. Really synchronous stream does not require > flush() but OutputStream has it. ahh, interesting point! I think this is another bug in the API. flush() is wrong. Because write specifies "The general contract for write is that one byte is written to the output stream." but not "a byte may be written or buffered". Actually, an application would need to call flush() after each write (or bunch of write calls) to ensure that write really did something otherwise I think. I didn't found in the spec of OutputStream that it would be required to call flush(). This should mean that calling flush is not required which in turn leads to the conclusion that write must be synchrous (private threads are forbidden because not specified :)) which in turn leads to the conclusion that flush() is not needed at all... I mean, what if someone would only store in write and do the "real write" in flush() and never else? An application could write in one stream and read on another one (e.g. in bidirectional communication) and would never get anything back, because nothing was actually written because no flush was called? Then someone could even think that on error in some write the data could remain buffered AND throw an exception, retrying to send the data in the next write. Ohh, and if there would be some message number inside, and underlaying write (e.g. a protocol offering InputStream/OutputStream) would check this and throw "DuplicatedMessageNumber" the stream would only throw it again and again beeing unusable... In short: I have no clue how someone could be able to implement an asynchrounos write (which is realiable and correct) without beeing specific to anything which is not specified by OutputStream. Well, I think in the end OutputStream was not intended for such communication or protocol implementations - but to read a local disk file or so. In case of I/O errors usually you can abort your application and change the hard disk :-) oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Bob_Jacobsen at lbl.gov Mon Jun 11 09:32:23 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Mon, 11 Jun 2007 08:32:23 -0700 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611142116.GN10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> Message-ID: At 4:21 PM +0200 6/11/07, Steffen DETTMER wrote: > > Statement concerning "synchronous" nature of the output stream >> is invalid as well. Really synchronous stream does not require >> flush() but OutputStream has it. > >ahh, interesting point! > >I think this is another bug in the API. flush() is wrong. Because >write specifies "The general contract for write is that one byte >is written to the output stream." but not "a byte may be written >or buffered". > >Actually, an application would need to call flush() after each >write (or bunch of write calls) to ensure that write really did >something otherwise I think. OutputStreams don't _have_ to be synchronous or asynchronous, but the OutputStream API was be arranged so that subclasses _can_ be synchronous or asynchronous. Such generality is the hardest part of getting an API right. Hence, if at some point a program using an OutputStream wants to be sure that the data has been pushed all the way out, flush() is available. For some subclasses, e.g. the buffered ones, this has important behavior. Others write the data from each call, and flush() doesn't do anything. You _can_ omit it in programs that are known to use this second type, but there's no requirement that you do so; the interface is general in that way. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From Steffen.DETTMER at ingenico.com Mon Jun 11 12:32:39 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 20:32:39 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> Message-ID: <20070611183239.GT10821@elberon.bln.de.ingenico.com> * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: > >Actually, an application would need to call flush() after each > >write (or bunch of write calls) to ensure that write really did > >something otherwise I think. > OutputStreams don't _have_ to be synchronous or asynchronous, > but the OutputStream API was be arranged so that subclasses > _can_ be synchronous or asynchronous. Ahh, oki. Thanks for the clarificaion. So in short, flush() MUST be called on OutputStream, this is just not documented correctly or so clearly (right?). So the overall usage semantics would be: 1. call write (multiple times if desired) 2. call flush only if both succeeded, write was successful. If flush fails it remains unknown if a part of the data was written and/or will be repeated. So the spec (API doc) is wrong. Correct would be to tell that write behaves as told as long as it is followed by a call to flush, otherwise data may or may not get lost (depending wheter close() is called and calls flush(), which seems not to be guaranteed/required). BTW, I think it is a little bit... erm... interesting to find the specification (java API doc reference) wrong, having a need to conclude it from the presence of some methods with "it would make no sense if they behave exactly as specified, so specification must be wrong (incomplete)". > Such generality is the hardest part of getting an API right. Yes, seems to be proven ;) > Hence, if at some point a program using an OutputStream wants > to be sure that the data has been pushed all the way out, > flush() is available. For some subclasses, e.g. the buffered > ones, this has important behavior. Others write the data from > each call, and flush() doesn't do anything. > You _can_ omit it in programs that are known to use this second > type, but there's no requirement that you do so; the interface > is general in that way. I think, it still it must be called always, otherwise the application could break if passing a different runtime type as OutputStream. I think, if the application/method needs a special "type of OutputStream" then the parameter type must be a subclass but not OutputStream, maybe a PrintStream or so - otherwise the compiler could not detect this error (passing wrong type). Is this correct? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Bob_Jacobsen at lbl.gov Mon Jun 11 13:00:52 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Mon, 11 Jun 2007 12:00:52 -0700 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611183239.GT10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> Message-ID: At 8:32 PM +0200 6/11/07, Steffen DETTMER wrote: >So the spec (API doc) is wrong. Correct would be to tell that >write behaves as told as long as it is followed by a call to >flush, otherwise data may or may not get lost (depending wheter >close() is called and calls flush(), which seems not to be >guaranteed/required). I'm not entirely sure that the spec is wrong, but reasonable people can differ on this. In the 1.5 JavaDocs, all that the docs say for the write methods is that they write to the _output_ _stream_; there is no guarantee of anything beyond that. Only the flush method has any guarantee about the data, which is >Flushes this output stream and forces any buffered output bytes to >be written out. The general contract of flush is that calling it is >an indication that, if any bytes previously written have been >buffered by the implementation of the output stream, such bytes >should immediately be written to their intended destination. People commonly use various OutputStreams without using flush(), and it often works, but it's a bad practice and will eventually bite them. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From netbeans at gatworks.com Mon Jun 11 13:31:57 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 15:31:57 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611183239.GT10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> Message-ID: <466DA32D.1010602@gatworks.com> Steffen DETTMER wrote: > * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: >>> Actually, an application would need to call flush() after each >>> write (or bunch of write calls) to ensure that write really did >>> something otherwise I think. > >> OutputStreams don't _have_ to be synchronous or asynchronous, >> but the OutputStream API was be arranged so that subclasses >> _can_ be synchronous or asynchronous. > > Ahh, oki. Thanks for the clarificaion. > > So in short, flush() MUST be called on OutputStream, this is just > not documented correctly or so clearly (right?). No. Flush can be called to force all current data in java buffer's to be written to the kernel - NOW. A flush() can also *imply* that, besides writing out the buffer's that java employs, may also imply/ask the kernel to write all data thusfar written to the kernel, to be physically placed on the destination device - NOW. For some OS's there is no need to do a kernel flush(), as the I/O is synchronized already. Since this is java, you never know what OS your on. From tjarvi at qbang.org Mon Jun 11 19:28:27 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Jun 2007 19:28:27 -0600 (MDT) Subject: [Rxtx] [OT] select :-) In-Reply-To: <466DA32D.1010602@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: On Mon, 11 Jun 2007, Uncle George wrote: > Steffen DETTMER wrote: >> * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: >>>> Actually, an application would need to call flush() after each >>>> write (or bunch of write calls) to ensure that write really did >>>> something otherwise I think. >> >>> OutputStreams don't _have_ to be synchronous or asynchronous, >>> but the OutputStream API was be arranged so that subclasses >>> _can_ be synchronous or asynchronous. >> >> Ahh, oki. Thanks for the clarificaion. >> >> So in short, flush() MUST be called on OutputStream, this is just >> not documented correctly or so clearly (right?). > No. > Flush can be called to force all current data in java buffer's to be > written to the kernel - NOW. > > A flush() can also *imply* that, besides writing out the buffer's that > java employs, may also imply/ask the kernel to write all data thusfar > written to the kernel, to be physically placed on the destination device > - NOW. > For some OS's there is no need to do a kernel flush(), as the I/O is > synchronized already. Since this is java, you never know what OS your on. To add to the confusion, flush on the C side throws away data. drain makes sure it is written. Looking at the ParallelImp.c we can probably do better. /* we set a timeout because all calls are sequentiell (also with asynchron) this means that the default timeout of unlimited blocks all calls (also close and status request) if the device is down */ GetCommTimeouts( (HANDLE)fd, &timeouts ); timeouts.WriteTotalTimeoutMultiplier = 0; timeouts.WriteTotalTimeoutConstant = 2000; /* 2000 is the min value for the default Windows NT and Windows 2000 driver */ SetCommTimeouts( (HANDLE)fd, &timeouts ); while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } errorCount = 0; bytes += countWritten; count -= countWritten; } LPRPort has some timeout code that appears to be doing nothing but flipping bits back and forth right now. The commapi rxtx follows allows for timeout control from javax.comm.CommPort. The above is a solution that worked in one specific use case. With timeouts in place, the original 'old printer going offline' problem could be solved. That printer code isn't written in stone. In fact it was ajusted from being able to print 'asdf' to a daisy wheel printer to working for one person. BTW, I've finished teaching after hours tonight and will be moving forward with a new rxtx release in my free time. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Jun 11 21:28:04 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 23:28:04 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: <466E12C4.1010305@gatworks.com> > Looking at the ParallelImp.c we can probably do better. > The problem stemmed from the possibility that the writev routine could have written some of the buffer, in chunks, printer pauses, refuses any more chunks, and a timeout occurs. Do you or do you not cause an exception to be thrown? Is there a way to set timeout for a ParallelPort data output stream? I cant find it. From tjarvi at qbang.org Mon Jun 11 22:17:23 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Jun 2007 22:17:23 -0600 (MDT) Subject: [Rxtx] [OT] select :-) In-Reply-To: <466E12C4.1010305@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> <466E12C4.1010305@gatworks.com> Message-ID: On Mon, 11 Jun 2007, Uncle George wrote: >> Looking at the ParallelImp.c we can probably do better. >> > The problem stemmed from the possibility that the writev routine could > have written some of the buffer, in chunks, printer pauses, refuses any > more chunks, and a timeout occurs. Do you or do you not cause an > exception to be thrown? > > Is there a way to set timeout for a ParallelPort data output stream? I > cant find it. hmm I looked again after you asked. The timeouts are only controllable on the receive side. This comes from CommPort; the parent. So what we are talking about is some bytes in memory that rxtx has and is supposed to write. A buffer perhaps? The approach with rxtx in the past has been to ignore output buffer sizes. The assumption is that the library does not know how to best handle buffers. There are buffered output streams that can do buffering on top of rxtx for instance. There is also a question regarding what was actually ment when the API was put together. My suspicion is that it was put together while looking at one OS API and was never ment to be anything more than a hook into that API. The comments are fairly telling combined with reading the w32 API. So looking at the problem again.. The current timeout behavior appears fairly arbitrary. Presumably this is to prevent a program from hanging instead of using a helper thread to write - heavy handed for new programmers. Even so, I don't think the write should timeout at all if it is not configurable. >From the API perspective, "What Timeout?" -- Trent Jarvi tjarvi at qbang.org From Steffen.DETTMER at ingenico.com Tue Jun 12 02:14:48 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 12 Jun 2007 10:14:48 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466DA32D.1010602@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: <20070612081447.GU10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Mon, Jun 11, 2007 at 15:31 -0400: > Steffen DETTMER wrote: > > Ahh, oki. Thanks for the clarificaion. > > > > So in short, flush() MUST be called on OutputStream, this is just > > not documented correctly or so clearly (right?). > No. hum (though now I got it, but...). > Flush can be called to force all current data in java buffer's to be > written to the kernel - NOW. > > A flush() can also *imply* that, besides writing out the > buffer's that java employs, may also imply/ask the kernel to > write all data thusfar written to the kernel, to be physically > placed on the destination device - NOW. > > For some OS's there is no need to do a kernel flush(), as the I/O is > synchronized already. Since this is java, you never know what OS your on. (well, but if you're going to kernel level, even flush cannot guarantee that data will "be physically placed". Maybe you're flushing to a file via NFS (and the client "thinks" that it was written, but maybe it was just buffered by the NFS server) or so... but of course such exceptions of the rules are constructable always.) Well, you tell that depending on the OS it can be that flush is needed or it can be that flush is not needed (beacuse the I/O is synchronized already), right? Also, applications should work on any OS, which includes the OSes that do need flush. Since the application cannot know whether flush is needed or not because it doesn't know what the OS is doing, it has to call flush, hasn't it? I mean, if it would not call flush then it would not work on such OSes (except the written data would not be needed at all, but in this would be an artificial example :)). Since applications are supposed to work this would be wrong, wouldn't it? So would it be correct to say: "Applications, that should work under all OSes (including the OSes where the I/O is not synchronised already), have to call flush on OutputStream to ensure the data is transfered to the kernel." or is this wrong? If so, then I'm afraid I missed the point again :( oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Tue Jun 12 04:46:52 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 12 Jun 2007 06:46:52 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070612081447.GU10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> <20070612081447.GU10821@elberon.bln.de.ingenico.com> Message-ID: <466E799C.7060700@gatworks.com> S > (well, but if you're going to kernel level, even flush cannot > guarantee that data will "be physically placed". Thats true now-a-days because ( from "man 2 sync" ) : > According to the standard specification (e.g., SVID), sync() schedules > the writes, but may return before the actual writing is done. However, > since version 1.3.20 Linux does actually wait. (This still does not > guarantee data integrity: modern disks have large caches.) My disk drive has 8mb cache. Maybe you're > flushing to a file via NFS (and the client "thinks" that it was > written, but maybe it was just buffered by the NFS server) or > so... but of course such exceptions of the rules are > constructable always.) > > Well, you tell that depending on the OS it can be that flush is > needed or it can be that flush is not needed (beacuse the I/O is > synchronized already), right? Also, applications should work on > any OS, which includes the OSes that do need flush. Its not OS's that need flush, its applications that want to have some assurance that data is written to the device that really needs to use flush. If your program ( or thread ) dies then it is in your best interest to write out the critical data as soon as possible, as economical as possible. These are trade-off's that the application programmer makes. A big buffer may mean big loss of data, a small buffer may mean spending too much time writing out data. > > > So would it be correct to say: > > "Applications, that should work under all OSes (including the > OSes where the I/O is not synchronised already), have to call > flush on OutputStream to ensure the data is transfered to the > kernel." > > or is this wrong? If so, then I'm afraid I missed the point again > :( > No that is not wrong. Ensuring that data is transfered to the OS is just about what any application can do. From tjarvi at qbang.org Thu Jun 14 08:16:47 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 14 Jun 2007 08:16:47 -0600 (MDT) Subject: [Rxtx] rxtx and usb-serial solution In-Reply-To: References: Message-ID: On Thu, 14 Jun 2007, Vladimir Kirtchev wrote: > Hi Trent, > > I develop a Java application which communicates with devices which have > USB-to-Serial bridge in them. The target OS is Linux. So for this purpose I > use RXTX. > > But I encountered a strange problem - when reading from the InputStream, I > receive series of zeros. I have this problem under Linux only. Under Windows > it is fine. > Actually this problem is the same as the one described here: > http://marc.info/?l=rxtx&m=109703190731748&w=2. > > > So I searched for the problem in the native code. And found that the root of > the problem is in SerialImp.c, > int configure_port( int fd ) > { > ... > ttyset.c_iflag = INPCK; > ... > } > > This line enables input parity checking, and the data sent from the device > is processed by the OS driver before being read with read(). > In this case the driver detects some problem and sets the received bytes to > zero. > > On the other hand in the Java part a set the serial port parameters with > SerialPort.PARITY_NONE. According to me, except all other things, this > should also disable INPCK in c_iflag. > > So I refactored the method translate_parity(...) to the following: > > int translate_parity( JNIEnv *env, struct termios *ttyset, jint parity ) > { > ENTER( "translate_parity" ); > #ifdef CMSPAR > ttyset->c_cflag &= ~(PARENB | PARODD | CMSPAR ); > #endif /* CMSPAR */ > switch( parity ) { > case JPARITY_NONE: > ttyset->c_iflag &= ~INPCK; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_EVEN: > ttyset->c_cflag |= PARENB; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_ODD: > ttyset->c_cflag |= PARENB | PARODD; > LEAVE( "translate_parity" ); > return 0; > #ifdef CMSPAR > case JPARITY_MARK: > ttyset->c_cflag |= PARENB | PARODD | CMSPAR; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_SPACE: > ttyset->c_cflag |= PARENB | CMSPAR; > LEAVE( "translate_parity" ); > return 0; > #endif /* CMSPAR */ > default: > printf("Parity missed %i\n", (int) parity ); > } > > LEAVE( "translate_parity" ); > /* > For some reason the native exceptions are not being caught. Moving this > to the Java side fixed the issue. taj. > throw_java_exception( env, UNSUPPORTED_COMM_OPERATION, > "", "parity value not supported" ); > */ > return 1; > } > > This modification solved the problem and now it works correctly under Linux. > > I think I will be a nice if this is idea is included in a future release of > RXTX. > > Thanks Vadim, I'll try that out. Forwarding to the rxtx mail-list too. This is probably not going to help USB drivers on windows which I'm sure some are looking for. As far as I can tell, windows USB bluetooth and serial dongles are limited by driver functionality. Some are good and others lack key features. -- Trent Jarvi tjarvi at qbang.org From dan.sandberg.lists at gmail.com Mon Jun 18 14:43:39 2007 From: dan.sandberg.lists at gmail.com (Dan Sandberg) Date: Mon, 18 Jun 2007 13:43:39 -0700 Subject: [Rxtx] Fix for JNI Get/Set Field Errors Message-ID: <4676EE7B.7060800@gmail.com> Hi, I've fixed the problems that cause the following JNI error when extra JNI checking ( -Xjni:check ) is turned on. FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) The problem was basically that GetLong was being used to get ints, and SetInt was used for longs. The patch below fixes this. Please let me know if there are any questions / problems. Cheers, -Dan diff -aur old/SerialImp.c src/SerialImp.c --- old/SerialImp.c 2007-06-18 13:24:33.000000000 -0700 +++ src/SerialImp.c 2007-06-18 06:26:26.000000000 -0700 @@ -1337,7 +1337,7 @@ report("init_threads: get eis\n"); jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); report("init_threads: set eis\n"); - (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); + (*eis->env)->SetLongField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); report("init_threads: stop\n"); report_time_end( ); return( 1 ); @@ -1530,7 +1530,7 @@ jobject jobj, jboolean interrupted ) { int fd = get_java_var( env, jobj,"fd","I" ); - struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var( env, jobj, "eis", "J" ); + struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var_long( env, jobj, "eis", "J" ); int result, count=0; char message[80]; @@ -2939,7 +2939,7 @@ /* TRENT */ int flag, count = 0; struct event_info_struct *eis = ( struct event_info_struct * ) - get_java_var( env, *jobj,"eis","J" ); + get_java_var_long( env, *jobj,"eis","J" ); report_time_start(); flag = eis->eventflags[SPE_DATA_AVAILABLE]; @@ -4873,9 +4873,9 @@ exceptions: none comments: ----------------------------------------------------------*/ -size_t get_java_var( JNIEnv *env, jobject jobj, char *id, char *type ) +long get_java_var_long( JNIEnv *env, jobject jobj, char *id, char *type ) { - int result = 0; + long result = 0; jclass jclazz = (*env)->GetObjectClass( env, jobj ); jfieldID jfd = (*env)->GetFieldID( env, jclazz, id, type ); @@ -4889,7 +4889,11 @@ LEAVE( "get_java_var" ); return result; } - result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); + if ( !strcmp( type, "J" ) ) { + result = (long)( (*env)->GetLongField( env, jobj, jfd ) ); + } else { + result = (int) ( (*env)->GetIntField( env, jobj, jfd ) ); + } /* ct7 & gel * Added DeleteLocalRef */ (*env)->DeleteLocalRef( env, jclazz ); if(!strncmp( "fd",id,2) && result == 0) @@ -4900,6 +4904,10 @@ return result; } +int get_java_var( JNIEnv *env, jobject jobj, char *id, char *type ) { + return (int) get_java_var_long( env, jobj, id, type ); +} + /*---------------------------------------------------------- throw_java_exception diff -aur old/SerialImp.h src/SerialImp.h --- old/SerialImp.h 2007-06-18 13:24:39.000000000 -0700 +++ src/SerialImp.h 2007-06-18 06:23:43.000000000 -0700 @@ -413,7 +413,8 @@ void system_wait(); void finalize_event_info_struct( struct event_info_struct * ); int read_byte_array( JNIEnv *, jobject *, int, unsigned char *, int, int ); -size_t get_java_var( JNIEnv *, jobject, char *, char * ); +int get_java_var( JNIEnv *, jobject, char *, char * ); +long get_java_var_long( JNIEnv *, jobject, char *, char * ); jboolean is_interrupted( struct event_info_struct * ); int send_event(struct event_info_struct *, jint, int ); void dump_termios(char *,struct termios *); From yvespielusenet at free.fr Tue Jun 26 03:41:58 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 11:41:58 +0200 Subject: [Rxtx] [PARALLEL] resource in use Message-ID: <1182850918.3483.10.camel@localhost.localdomain> Hello, So now I want to modify the timeout of the library for parallel port. I have downloaded source code. There is a makefile for migw. SO I have installed mingw on ubuntu and modified the makefile.mingw32 to set it for my system. I have no error but some warnings. The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But When I want to use it the jvm crash :( How can I know what is wrong ? How rxtx windows release has been done ? thanks -- yves piel From yvespielusenet at free.fr Tue Jun 26 07:17:02 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 15:17:02 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182850918.3483.10.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> Message-ID: <1182863822.3483.17.camel@localhost.localdomain> Here is the Makefile I use, the output of the 'make' and the log of the jvm when it crashed : - The Makefile : http://yvespiel.free.fr/rxtx/Makefile - The make output : http://yvespiel.free.fr/rxtx/compile.txt - The crash log : http://yvespiel.free.fr/rxtx/hs_err_pid2100.log I have compiled rxtx under Debian testing with mingw : narma at linimi:/tmp/err$ dpkg -l | grep mingw ii mingw32 3.4.5.20060117.1.dfsg-3 ii mingw32-binutils 2.17.50-20070129.1-1 ii mingw32-runtime 3.12-1 thanks fort help :) Le mardi 26 juin 2007 ? 11:41 +0200, yves pielusenet a ?crit : > Hello, > So now I want to modify the timeout of the library for parallel port. I > have downloaded source code. There is a makefile for migw. SO I have > installed mingw on ubuntu and modified the makefile.mingw32 to set it > for my system. > I have no error but some warnings. > The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But > When I want to use it the jvm crash :( > > How can I know what is wrong ? > > How rxtx windows release has been done ? > > thanks > From yvespielusenet at free.fr Tue Jun 26 07:40:11 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 15:40:11 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182863822.3483.17.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> <1182863822.3483.17.camel@localhost.localdomain> Message-ID: <1182865211.3483.21.camel@localhost.localdomain> I have add the options '--enable-stdcall-fixup' to the 'i586-mingw32msvc-ld' commande. Now I have no warning. But the JVM always crashes :( The output seems more detailled, but I don't understand anything... Here is files : http://yvespiel.free.fr/rxtx/2/ -- yves piel Le mardi 26 juin 2007 ? 15:17 +0200, yves pielusenet a ?crit : > Here is the Makefile I use, the output of the 'make' and the log of the > jvm when it crashed : > > - The Makefile : http://yvespiel.free.fr/rxtx/Makefile > - The make output : http://yvespiel.free.fr/rxtx/compile.txt > - The crash log : http://yvespiel.free.fr/rxtx/hs_err_pid2100.log > > I have compiled rxtx under Debian testing with mingw : > narma at linimi:/tmp/err$ dpkg -l | grep mingw > ii mingw32 3.4.5.20060117.1.dfsg-3 > ii mingw32-binutils 2.17.50-20070129.1-1 > ii mingw32-runtime 3.12-1 > > thanks fort help :) > > > Le mardi 26 juin 2007 ? 11:41 +0200, yves pielusenet a ?crit : > > Hello, > > So now I want to modify the timeout of the library for parallel port. I > > have downloaded source code. There is a makefile for migw. SO I have > > installed mingw on ubuntu and modified the makefile.mingw32 to set it > > for my system. > > I have no error but some warnings. > > The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But > > When I want to use it the jvm crash :( > > > > How can I know what is wrong ? > > > > How rxtx windows release has been done ? > > > > thanks > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From yvespielusenet at free.fr Tue Jun 26 08:27:42 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 16:27:42 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182865211.3483.21.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> <1182863822.3483.17.camel@localhost.localdomain> <1182865211.3483.21.camel@localhost.localdomain> Message-ID: <1182868062.3483.24.camel@localhost.localdomain> I think thant the include files of jdk were not for windows but for linux. So I have copied include/ folder from windows to linux and I modified the Makefile to use those file. It compile fine but the JVM always crash :( http://yvespiel.free.fr/rxtx/3/ Le mardi 26 juin 2007 ? 15:40 +0200, yves pielusenet a ?crit : > I have add the options '--enable-stdcall-fixup' to the > 'i586-mingw32msvc-ld' commande. Now I have no warning. But the JVM > always crashes :( The output seems more detailled, but I don't > understand anything... > Here is files : > http://yvespiel.free.fr/rxtx/2/ > From netbeans at gatworks.com Fri Jun 1 05:38:50 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 07:38:50 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <465F7ADD.1010501@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> Message-ID: <4660054A.2040202@gatworks.com> Manuel Naranjo wrote: In the case of my module, you can > unplug the device but it will not delete the symlink until those apps > that had opened the port has closed it. This is done this way to avoid > kernel panics. What does this mean to user code ? I have tried the alternate route ( other than closing ) which is sleep inbetween the I/O errors ( an unplugged USB device). When the device is plugged back in, The writes to the device still get an I/O error. This would seem to be a lost cause for the application. From netbeans at gatworks.com Fri Jun 1 06:35:48 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 08:35:48 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <465F7ADD.1010501@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> Message-ID: <466012A4.90608@gatworks.com> Manuel Naranjo wrote: In the case of my module, you can > unplug the device but it will not delete the symlink until those apps > that had opened the port has closed it. T Did u also mean for this to happen? USB0 was not closed by application. Apparently USB1 got created when USB device was plugged back in. There is only one USB device on a 4 port USB hub. This also seems to suggest that application recovery to be impossible. > Jun 1 07:10:08 mylaptop kernel: garmin_gps 1-1.4:1.0: Garmin GPS usb/tty converter detected > Jun 1 07:10:08 mylaptop kernel: usb 1-1.4: Garmin GPS usb/tty converter now attached to ttyUSB0 > Jun 1 07:15:17 mylaptop kernel: usb 1-1: USB disconnect, address 4 > Jun 1 07:15:17 mylaptop kernel: usb 1-1.4: USB disconnect, address 5 > Jun 1 07:15:17 mylaptop kernel: garmin_gps 1-1.4:1.0: device disconnected > Jun 1 07:15:26 mylaptop kernel: usb 1-1: new full speed USB device using uhci_hcd and address 6 > Jun 1 07:15:26 mylaptop kernel: hub 1-1:1.0: USB hub found > Jun 1 07:15:26 mylaptop kernel: hub 1-1:1.0: 4 ports detected > Jun 1 07:15:27 mylaptop kernel: usb 1-1.4: new full speed USB device using uhci_hcd and address 7 > Jun 1 07:15:27 mylaptop kernel: garmin_gps 1-1.4:1.0: Garmin GPS usb/tty converter detected > Jun 1 07:15:27 mylaptop kernel: usb 1-1.4: Garmin GPS usb/tty converter now attached to ttyUSB1 From naranjo.manuel at gmail.com Fri Jun 1 09:17:22 2007 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Fri, 01 Jun 2007 12:17:22 -0300 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <466012A4.90608@gatworks.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> <466012A4.90608@gatworks.com> Message-ID: <46603882.5050701@gmail.com> Uncle George escribi?: > Manuel Naranjo wrote: > In the case of my module, you can > >> unplug the device but it will not delete the symlink until those apps >> that had opened the port has closed it. T >> > > Did u also mean for this to happen? USB0 was not closed by application. > > Apparently USB1 got created when USB device was plugged back in. There > is only one USB device on a 4 port USB hub. > > This also seems to suggest that application recovery to be impossible. > Exactly there's a dead symlink (you can read and write to it and nothing will happen) and a new port will be created when a new device is connencted. From netbeans at gatworks.com Fri Jun 1 10:20:46 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 12:20:46 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <46603882.5050701@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> <466012A4.90608@gatworks.com> <46603882.5050701@gmail.com> Message-ID: <4660475E.5090202@gatworks.com> Not sure what u mean by "symlink". U cant read/write to it anymore. U get I/O error. In this scenario the device effectively went dead, and only solution is to close the channel. reconnecting the USB device, although dead, but not closed, will create a second device. This does not seem to be a desirable side-effect. The user will now have ttyUSB1, wondering where did ttyUSB0 go to. The application will also be in a confused state, as well as RXTX, because RXTX wont know about ttyUSB1. Manuel Naranjo wrote: > Uncle George escribi?: >> Manuel Naranjo wrote: >> In the case of my module, you can >> >>> unplug the device but it will not delete the symlink until those apps >>> that had opened the port has closed it. T >>> >> Did u also mean for this to happen? USB0 was not closed by application. >> >> Apparently USB1 got created when USB device was plugged back in. There >> is only one USB device on a 4 port USB hub. >> >> This also seems to suggest that application recovery to be impossible. >> > Exactly there's a dead symlink (you can read and write to it and nothing > will happen) and a new port will be created when a new device is connencted. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From arnab.bhaumik at gmail.com Mon Jun 4 01:40:16 2007 From: arnab.bhaumik at gmail.com (arnab bhaumik) Date: Mon, 4 Jun 2007 13:10:16 +0530 Subject: [Rxtx] full duplex com port with rxtx Message-ID: hi , till now i did half duplex communication with rxtx package on com package. my question is : is it possible to use com port with full duplex mode with rxtx package . ther is example of SimpleRead class and SimpleWrite class. it is clear that if i can use both the class simultaneously then full duplex is possible......... arnab/vu2bpw -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070604/6edb0453/attachment-0002.html From lists at iDIAcomputing.com Mon Jun 4 07:53:17 2007 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Mon, 04 Jun 2007 09:53:17 -0400 Subject: [Rxtx] full duplex com port with rxtx In-Reply-To: References: Message-ID: <4664194D.90301@iDIAcomputing.com> arnab bhaumik wrote: > hi , > > till now i did half duplex communication with rxtx package on com > package. > > my question is : is it possible to use com port with full duplex mode > with rxtx package . > > > ther is example of SimpleRead class and SimpleWrite class. it is > clear that if i can use both the class simultaneously then full duplex > is possible......... I haven't looked at the SimpleRead and SimpleWrite classes (I originally wrote my code for the javax.comm api), but full duplex is certainly possible. My CommReader class requires an object analogous to a OutputStream or Writer. When started, it spawns a thread that reads the comm port and writes to that output device. In this way the input is asynchronous and dependent on the actual input data. For full duplex, I extend that class with CommReaderWriter, which adds synchronous output methods. Hope that helps, George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From supsoop at hotmail.com Mon Jun 4 15:21:06 2007 From: supsoop at hotmail.com (soop soop) Date: Mon, 04 Jun 2007 21:21:06 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- Message-ID: Hi Guys, Looked through the archives but still cannot figure this out. I have a Motorola G24 GPRS/GSM modem that I am connecting to my server running Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not detecting the port, CommPortIdentifier.getPortIdentifiers(). I have added the line to RXTXCommDriver: "ttyACM" // for USB Modems Rxtx still does not seem to find the port. Is there something I am missing to make this port visable? [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control Model driver for USB modems and ISDN adapters I really need your help as I have moved my server from windows to Linux and have been down for a few days because of this .. Thanks so much! _________________________________________________________________ PC Magazine’s 2007 editors’ choice for best Web mail—award-winning Windows Live Hotmail. http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 From tjarvi at qbang.org Mon Jun 4 16:17:35 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Jun 2007 16:17:35 -0600 (MDT) Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: On Mon, 4 Jun 2007, soop soop wrote: > Hi Guys, > > Looked through the archives but still cannot figure this out. I have a > Motorola G24 GPRS/GSM modem that I am connecting to my server running Ubuntu. > I can see my modem as is shows up as ttyACM0, but RXTX is not detecting the > port, CommPortIdentifier.getPortIdentifiers(). > > I have added the line to RXTXCommDriver: > > "ttyACM" // for USB Modems > > Rxtx still does not seem to find the port. Is there something I am missing to > make this port visable? > > [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver > [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device > [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control Model > driver for USB modems and ISDN adapters > > I really need your help as I have moved my server from windows to Linux and > have been down for a few days because of this .. Thanks so much! > You could try the INSTALL documentation that comes with the source for possible solutions. Those usually involve lockfile creation, permissions on the device file or the device is in use by another application (even another session of your application). The usual commands: ls -l /dev/ttyACM0 fuser /dev/ttyACM0 touch /var/lock/LCK.testfile && rm -f /var/lock/LCK.testfile whoami To disable lockfiles: ../configure --disable-lockfiles && make install -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Jun 4 16:22:52 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 04 Jun 2007 18:22:52 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <466490BC.3090801@gatworks.com> soop soop wrote: > I really need your help as I have moved my server from windows to Linux > and have been down for a few days because of this .. Thanks so much! can u open the device ? ie is the file protection/permissions keeping you out? From supsoop at hotmail.com Mon Jun 4 16:44:40 2007 From: supsoop at hotmail.com (soop soop) Date: Mon, 04 Jun 2007 22:44:40 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <466490BC.3090801@gatworks.com> Message-ID: Thanks for the reply, I see no exceptions being thrown, just no detection of the port whats so ever. I will run rxtx in debug mode and log. If this were a permissions issue would I not see some exceptions being thrown? >From: Uncle George >Reply-To: RXTX Developers and Users >To: RXTX Developers and Users >Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >Date: Mon, 04 Jun 2007 18:22:52 -0400 > >soop soop wrote: > > > I really need your help as I have moved my server from windows to Linux > > and have been down for a few days because of this .. Thanks so much! > >can u open the device ? ie is the file protection/permissions keeping >you out? >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ Get a preview of Live Earth, the hottest event this summer - only on MSN http://liveearth.msn.com?source=msntaglineliveearthhm From netbeans at gatworks.com Mon Jun 4 17:06:15 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 04 Jun 2007 19:06:15 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <46649AE7.10405@gatworks.com> Exceptions on what? On startup it wants to lookup all devices in /dev that it is capable of opening ( within the list of specific 'comm' devices ). If it cannot open, then does not get onto list. Part of this process, if configured, will also test if the "LOCK" schema can also be opened for the device. then it gets on the list of avail comm port. soop soop wrote: > Thanks for the reply, > > I see no exceptions being thrown, just no detection of the port whats so > ever. I will run rxtx in debug mode and log. If this were a permissions > issue would I not see some exceptions being thrown? > > >> From: Uncle George >> Reply-To: RXTX Developers and Users >> To: RXTX Developers and Users >> Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >> Date: Mon, 04 Jun 2007 18:22:52 -0400 >> >> soop soop wrote: >> >>> I really need your help as I have moved my server from windows to Linux >>> and have been down for a few days because of this .. Thanks so much! >> can u open the device ? ie is the file protection/permissions keeping >> you out? >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _________________________________________________________________ > Get a preview of Live Earth, the hottest event this summer - only on MSN > http://liveearth.msn.com?source=msntaglineliveearthhm > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From alex.flint at gmail.com Mon Jun 4 21:31:49 2007 From: alex.flint at gmail.com (Alex Flint) Date: Tue, 5 Jun 2007 13:01:49 +0930 Subject: [Rxtx] random EXCEPTION_ACCESS_VIOLATION errors Message-ID: Hi All, I'm running winXP and RXTX 2.1-7r2 (the latest from the webpage as of June 2007). I'm sending sequences of 64 lines (each line has about 15 chars) at various intervals. The strings are sent fine, until I get the following error (from hs_err_pid3316.log, at the end of this email). What can I do to avoid the error? Obviously this is a low-level memory exception, but is there any way I can keep the JVM running after such an error? I noticed the exact same problem here: http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20070129/1180520.html Cheers, Alex # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x100034fb, pid=3316, tid=2400 # # Java VM: Java HotSpot(TM) Client VM (1.6.0_01-b06 mixed mode, sharing) # Problematic frame: # C [rxtxSerial.dll+0x34fb] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # --------------- T H R E A D --------------- Current thread (0x00386400): JavaThread "main" [_thread_in_native, id=2400] siginfo: ExceptionCode=0xc0000005, reading address 0x20726f78 Registers: EAX=0x20726f20, EBX=0x6d8922c0, ECX=0x00000005, EDX=0x20726f20 ESP=0x003efa30, EBP=0x003efb68, ESI=0x269728a0, EDI=0x00386400 EIP=0x100034fb, EFLAGS=0x00010212 Top of Stack: (sp=0x003efa30) 0x003efa30: 003efa3c 003efa64 0000000f ffffffff 0x003efa40: 003efa40 2a97f808 003efa6c 2b190ca8 0x003efa50: 00000000 2b190ec0 003efa90 008e2dd7 0x003efa60: 003efa90 008e2dd7 26977f88 6d815e72 0x003efa70: 00000004 2696eae0 0000008a 003efb0c 0x003efa80: 6d852b4a 2696eae0 00000003 26970930 0x003efa90: 000000cb 2696eae0 6d86b264 00385d40 0x003efaa0: 0000003f 003efb0c 26977f90 2ace65d8 Instructions: (pc=0x100034fb) 0x100034eb: ff ff 8d 76 00 eb 02 89 f6 90 8b 45 f8 8b 55 f8 0x100034fb: 8b 4a 58 83 c9 04 89 48 58 83 c4 f8 8b 45 f8 8b Stack: [0x003a0000,0x003f0000), sp=0x003efa30, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x34fb] Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j gnu.io.RXTXPort.writeArray([BIIZ)V+0 j gnu.io.RXTXPort$SerialOutputStream.write([B)V+76 j com.bjt.media.server.CommLink.send(Ljava/lang/String;)V+48 j com.bjt.media.server.DigitoolConnection.select(I)V+73 j com.bjt.media.server.DigitoolConnection.main([Ljava/lang/String;)V+74 v ~StubRoutines::call_stub --------------- P R O C E S S --------------- Java Threads: ( => current thread ) 0x02a69400 JavaThread "Thread-0" [_thread_in_native, id=3052] 0x02a4d000 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=3920] 0x02a48400 JavaThread "CompilerThread0" daemon [_thread_blocked, id=1968] 0x02a47400 JavaThread "Attach Listener" daemon [_thread_blocked, id=2984] 0x02a46400 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=2660] 0x02a41c00 JavaThread "Finalizer" daemon [_thread_blocked, id=3924] 0x02a3d800 JavaThread "Reference Handler" daemon [_thread_blocked, id=4008] =>0x00386400 JavaThread "main" [_thread_in_native, id=2400] Other Threads: 0x02a34400 VMThread [id=3708] 0x02a4e800 WatcherThread [id=3964] VM state:not at safepoint (normal execution) VM Mutex/Monitor currently owned by a thread: None Heap def new generation total 960K, used 131K [0x22960000, 0x22a60000, 0x22e40000) eden space 896K, 7% used [0x22960000, 0x22970ea8, 0x22a40000) from space 64K, 99% used [0x22a50000, 0x22a5fff8, 0x22a60000) to space 64K, 0% used [0x22a40000, 0x22a40000, 0x22a50000) tenured generation total 4096K, used 76K [0x22e40000, 0x23240000, 0x26960000) the space 4096K, 1% used [0x22e40000, 0x22e53060, 0x22e53200, 0x23240000) compacting perm gen total 12288K, used 137K [0x26960000, 0x27560000, 0x2a960000) the space 12288K, 1% used [0x26960000, 0x26982518, 0x26982600, 0x27560000) ro space 8192K, 62% used [0x2a960000, 0x2ae5e4e8, 0x2ae5e600, 0x2b160000) rw space 12288K, 52% used [0x2b160000, 0x2b7a0e78, 0x2b7a1000, 0x2bd60000) Dynamic libraries: 0x00400000 - 0x00423000 C:\Program Files\Java\jre1.6.0_01\bin\javaw.exe 0x7c900000 - 0x7c9b0000 C:\WINDOWS\system32\ntdll.dll 0x7c800000 - 0x7c8f4000 C:\WINDOWS\system32\kernel32.dll 0x77dd0000 - 0x77e6b000 C:\WINDOWS\system32\ADVAPI32.dll 0x77e70000 - 0x77f01000 C:\WINDOWS\system32\RPCRT4.dll 0x7e410000 - 0x7e4a0000 C:\WINDOWS\system32\USER32.dll 0x77f10000 - 0x77f57000 C:\WINDOWS\system32\GDI32.dll 0x76390000 - 0x763ad000 C:\WINDOWS\system32\IMM32.DLL 0x7c340000 - 0x7c396000 C:\Program Files\Java\jre1.6.0_01\bin\msvcr71.dll 0x6d7c0000 - 0x6da07000 C:\Program Files\Java\jre1.6.0_01\bin\client\jvm.dll 0x76b40000 - 0x76b6d000 C:\WINDOWS\system32\WINMM.dll 0x5cd70000 - 0x5cd77000 C:\WINDOWS\system32\serwvdrv.dll 0x5b0a0000 - 0x5b0a7000 C:\WINDOWS\system32\umdmxfrm.dll 0x6d310000 - 0x6d318000 C:\Program Files\Java\jre1.6.0_01\bin\hpi.dll 0x76bf0000 - 0x76bfb000 C:\WINDOWS\system32\PSAPI.DLL 0x6d770000 - 0x6d77c000 C:\Program Files\Java\jre1.6.0_01\bin\verify.dll 0x6d3b0000 - 0x6d3cf000 C:\Program Files\Java\jre1.6.0_01\bin\java.dll 0x6d7b0000 - 0x6d7bf000 C:\Program Files\Java\jre1.6.0_01\bin\zip.dll 0x10000000 - 0x10012000 C:\Documents and Settings\Alex\workspace\MediaServer\rxtxSerial.dll 0x73d90000 - 0x73db7000 C:\WINDOWS\system32\crtdll.dll VM Arguments: jvm_args: -Djava.library.path=C:\Documents and Settings\Alex\workspace\MediaServer java_command: com.bjt.media.server.DigitoolConnection Launcher Type: SUN_STANDARD Environment Variables: CLASSPATH=.;C:\Program Files\Java\j2re1.4.2_07\lib\ext\QTJava.zip PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\wbem;c:\applications\php;C:\Program Files\MATLAB\R2006a\bin\win32;C:\Roger\Projects\UAV\Bin\Debug;C:\Program Files\Microsoft SQL Server\80\Tools\Binn\;c:\Program Files\Microsoft SQL Server\90\Tools\binn\;C:\Program Files\QuickTime\QTSystem\;C:\Pfps\system;C:\Program Files\Java\jdk1.6.0_01\bin;C:\Program Files\Java\jdk1.6.0_01\jre\bin USERNAME=Alex OS=Windows_NT PROCESSOR_IDENTIFIER=x86 Family 15 Model 4 Stepping 1, GenuineIntel --------------- S Y S T E M --------------- OS: Windows XP Build 2600 Service Pack 2 CPU:total 1 family 15, cmov, cx8, fxsr, mmx, sse, sse2 Memory: 4k page, physical 1046508k(275288k free), swap 2522816k(1909176k free) vm_info: Java HotSpot(TM) Client VM (1.6.0_01-b06) for windows-x86, built on Mar 14 2007 00:24:02 by "java_re" with unknown MS VC++:1310 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070604/c87ae1f0/attachment-0002.html From alwyn.schoeman at gmail.com Tue Jun 5 00:10:19 2007 From: alwyn.schoeman at gmail.com (Alwyn Schoeman) Date: Tue, 5 Jun 2007 08:10:19 +0200 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Hi, I'm using a similar modem. By default rxtx doesn't look for devices that start with ACM, so you need to modify the source code and recompile. Look in RXTXCommDriver and add values for ACM in the registerScannedPorts method in the Linux specific parts. Look for osName.equals("Linux")... On 6/4/07, soop soop wrote: > > Hi Guys, > > Looked through the archives but still cannot figure this out. I have a > Motorola G24 GPRS/GSM modem that I am connecting to my server running > Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not > detecting the port, CommPortIdentifier.getPortIdentifiers(). > > I have added the line to RXTXCommDriver: > > "ttyACM" // for USB Modems > > Rxtx still does not seem to find the port. Is there something I am missing > to make this port visable? > > [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver > [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device > [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control > Model > driver for USB modems and ISDN adapters > > I really need your help as I have moved my server from windows to Linux > and > have been down for a few days because of this .. Thanks so much! > > _________________________________________________________________ > PC Magazine's 2007 editors' choice for best Web mail?award-winning Windows > Live Hotmail. > > http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -- Alwyn Schoeman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/b6cb3053/attachment-0002.html From naranjo.manuel at gmail.com Tue Jun 5 06:48:45 2007 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Tue, 05 Jun 2007 09:48:45 -0300 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> References: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Message-ID: <46655BAD.7010501@gmail.com> That's right, an easier solution is creating symlinks to acm. For example make ttyS70 to 79 point to ACM0 to 9 and that will help you a lot, and doesn't even require compile. > Hi, > > I'm using a similar modem. By default rxtx doesn't look for devices > that start with ACM, so you need to modify the > source code and recompile. > > Look in RXTXCommDriver and add values for ACM in the > registerScannedPorts method in the Linux specific parts. Look for > osName.equals("Linux")... > From juanemc2 at gmail.com Tue Jun 5 07:02:43 2007 From: juanemc2 at gmail.com (Juan) Date: Tue, 5 Jun 2007 10:02:43 -0300 Subject: [Rxtx] Problems with Epson TMU220B POSPrinter using XON/XOFF Flow Control and rxtx jar and dll's with the serial port. Message-ID: Hi!, I?m having trouble printing to the serial port using the latest version of rxtx jar and dll's with an Epson POSPrinter. I`ve switched the printer to work with XON/XOFF Flow Control and have watched the serial port to be sure the printer is sending the XON XOFF stop and go characters. I`ve setted the port like this: CommPortIdentifier commPortIdentifier = CommPortIdentifier.* getPortIdentifier*(_portName); SerialPort serialPort = (SerialPort)commPortIdentifier.open(*this*.getClass().getName(), 2000); serialPort.setSerialPortParams(_baudRate, _dataBits, _stopBits, _parity); serialPort.setFlowControlMode( SerialPort.*FLOWCONTROL_XONXOFF_IN* | SerialPort.*FLOWCONTROL_XONXOFF_OUT*); where the baudRate is 9600 the dataBits is 8 the stopBits is 1 and the parity is 0 It seems as the library isn`t taking into account the XON XOFF setting. I would like to know if I`m setting correctly the Flow Control and if you had had any experiences using XON XOFF flow control and could give me some help to solve my problem. I`m very thankful in advance, Yours, Juan Polero -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/b080995a/attachment-0002.html From ehdez.correo at gmail.com Tue Jun 5 07:12:53 2007 From: ehdez.correo at gmail.com (=?ISO-8859-1?Q?Enrique_Hern=E1ndez?=) Date: Tue, 5 Jun 2007 09:12:53 -0400 Subject: [Rxtx] problem with rxtx Message-ID: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Hello: I doing a simple test to show the serial ports. This is the code: import java.util.Enumeration; import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; public class Show { private Enumeration portList; private CommPortIdentifier portId; private SerialPort port; /** Creates a new instance of Show */ public Show() { } public static void main(String args[]){ Show show = new Show(); show.portList = CommPortIdentifier.getPortIdentifiers(); String tPort = ""; System.out.println("========================================="); while(show.portList.hasMoreElements()){ show.portId = (CommPortIdentifier)show.portList.nextElement(); if(show.portId.getPortType() == CommPortIdentifier.PORT_SERIAL) tPort = "Serial"; else tPort = "Parallel"; System.out.println(show.portId.getName() + " " + tPort); } } } whit The problem is that this code not show the serial ports, this show the no use serial ports. I want to connect whit the modem but when windows open and connect the modem my application don't see the port(COMM3) when it is connect. what I can do? Is that the correct way to know the ports? thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/eedd744b/attachment-0002.html From ehdez.correo at gmail.com Tue Jun 5 07:42:13 2007 From: ehdez.correo at gmail.com (=?ISO-8859-1?Q?Enrique_Hern=E1ndez?=) Date: Tue, 5 Jun 2007 09:42:13 -0400 Subject: [Rxtx] serial port Message-ID: <4a814e1f0706050642p4ce9ac7bka80f9479c524c5ea@mail.gmail.com> Hello: How I can ask to the port what device is connect and information about this device. thanks. bye. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/4d10d26a/attachment-0002.html From supsoop at hotmail.com Tue Jun 5 09:29:00 2007 From: supsoop at hotmail.com (soop soop) Date: Tue, 05 Jun 2007 15:29:00 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Message-ID: Hi Guys, Thanks for all your help. I found the problem. I created a user, Tomcat55, for my tomcat but it did not belong to any group. I then added this user to dialout group to have access to the device ttyACM0. Works perfectly! Again permissions was the issue. This also seems to be persistent as a server reboot does not effect the access. Cheers! >From: "Alwyn Schoeman" >Reply-To: RXTX Developers and Users >To: "RXTX Developers and Users" >Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >Date: Tue, 5 Jun 2007 08:10:19 +0200 > >Hi, > >I'm using a similar modem. By default rxtx doesn't look for devices that >start with ACM, so you need to modify the >source code and recompile. > >Look in RXTXCommDriver and add values for ACM in the registerScannedPorts >method in the Linux specific parts. Look for osName.equals("Linux")... > >On 6/4/07, soop soop wrote: >> >>Hi Guys, >> >>Looked through the archives but still cannot figure this out. I have a >>Motorola G24 GPRS/GSM modem that I am connecting to my server running >>Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not >>detecting the port, CommPortIdentifier.getPortIdentifiers(). >> >>I have added the line to RXTXCommDriver: >> >>"ttyACM" // for USB Modems >> >>Rxtx still does not seem to find the port. Is there something I am missing >>to make this port visable? >> >>[ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver >>[ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device >>[ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control >>Model >>driver for USB modems and ISDN adapters >> >>I really need your help as I have moved my server from windows to Linux >>and >>have been down for a few days because of this .. Thanks so much! >> >>_________________________________________________________________ >>PC Magazine's 2007 editors' choice for best Web mail—award-winning Windows >>Live Hotmail. >> >>http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 >> >> >>_______________________________________________ >>Rxtx mailing list >>Rxtx at qbang.org >>http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > >-- >Alwyn Schoeman >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ Need a break? Find your escape route with Live Search Maps. http://maps.live.com/default.aspx?ss=Restaurants~Hotels~Amusement%20Park&cp=33.832922~-117.915659&style=r&lvl=13&tilt=-90&dir=0&alt=-1000&scene=1118863&encType=1&FORM=MGAC01 From netbeans at gatworks.com Tue Jun 5 09:42:31 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 11:42:31 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <46658467.20101@gatworks.com> soop soop wrote: > > Hi Guys, > > Thanks for all your help. I found the problem. I created a user, > Tomcat55, for my tomcat but it did not belong to any group. I then added Look at man pages for the program udev. From tjarvi at qbang.org Tue Jun 5 18:18:17 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Jun 2007 18:18:17 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Message-ID: On Tue, 5 Jun 2007, Enrique Hern?ndez wrote: > The problem is that this code not show the serial ports, this show the no > use serial ports. I want to connect whit the modem but when windows open and > connect the modem my application don't see the port(COMM3) when it is > connect. > what I can do? > Is that the correct way to know the ports? > Hello, We may have problems understanding each other. On windows, the port will not be an available serial port if another application has the port open. That is just how the library behaves. If you can not see the port in the enumerated list, you could not open it. Also note that enumeration only happens once. If you add a port such as a new USB dongle, the port will not be visible until the next time your application runs. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Tue Jun 5 18:45:01 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 20:45:01 -0400 Subject: [Rxtx] problem with rxtx In-Reply-To: References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Message-ID: <4666038D.8090700@gatworks.com> Trent Jarvi wrote: > > > Also note that enumeration only happens once. If you add a port such as > a new USB dongle, the port will not be visible until the next time your > application runs. Is this written in stone ? somewhere? From tjarvi at qbang.org Tue Jun 5 18:54:36 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Jun 2007 18:54:36 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <4666038D.8090700@gatworks.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> Message-ID: On Tue, 5 Jun 2007, Uncle George wrote: > Trent Jarvi wrote: >> >> >> Also note that enumeration only happens once. If you add a port such as >> a new USB dongle, the port will not be visible until the next time your >> application runs. > > Is this written in stone ? somewhere? It is just the current behavior. There is nothing preventing a fix that allows reenumeration. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Tue Jun 5 19:55:19 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 21:55:19 -0400 Subject: [Rxtx] problem with rxtx In-Reply-To: References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> Message-ID: <46661407.4020308@gatworks.com> >> Is this written in stone ? somewhere? > > It is just the current behavior. There is nothing preventing a fix that > allows reenumeration. With usb, ..... , things come and go. Seems a shame that you have to kill application to get at the device u just plugged in. From joachim at buechse.ch Wed Jun 6 01:50:06 2007 From: joachim at buechse.ch (Joachim Buechse) Date: Wed, 6 Jun 2007 09:50:06 +0200 Subject: [Rxtx] problem with rxtx In-Reply-To: <46661407.4020308@gatworks.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> <46661407.4020308@gatworks.com> Message-ID: <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> On MacOS RXTX's enumeration handling is more flexible. It will find new ports that are added during the lifetime of the application. But this is inherently incompatible with suns javax.comm implementation... Regards, Joachim On 06.06.2007, at 03:55, Uncle George wrote: > >>> Is this written in stone ? somewhere? >> >> It is just the current behavior. There is nothing preventing a >> fix that >> allows reenumeration. > > With usb, ..... , things come and go. Seems a shame that you have to > kill application to get at the device u just plugged in. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Jun 6 06:06:48 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Jun 2007 06:06:48 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> <46661407.4020308@gatworks.com> <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> Message-ID: Sun's javax.comm is not a major concern going forward. As long as we do not break old applications using rxtx, I see no reason to limit rxtx to that convention. We have already rejected version 3 from Sun as a dead end and limited our compatability to version 2. That does not mean we will not try to work with Sun and others but the current javax.comm convention (v3) is not a well conceived path. There has been discussion about doing a JSR which is one valid option. On Wed, 6 Jun 2007, Joachim Buechse wrote: > On MacOS RXTX's enumeration handling is more flexible. It will find > new ports that are added during the lifetime of the application. But > this is inherently incompatible with suns javax.comm implementation... > > Regards, > Joachim > > On 06.06.2007, at 03:55, Uncle George wrote: > >> >>>> Is this written in stone ? somewhere? >>> >>> It is just the current behavior. There is nothing preventing a >>> fix that >>> allows reenumeration. >> >> With usb, ..... , things come and go. Seems a shame that you have to >> kill application to get at the device u just plugged in. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From yvespielusenet at free.fr Wed Jun 6 08:46:35 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 16:46:35 +0200 Subject: [Rxtx] [PARALLEL] resource in use Message-ID: <1181141195.3407.20.camel@localhost.localdomain> Hello, I want to use rxtx in my application. I haveto send data to a very old printer (which have a drum and hammers http://perso.orange.fr/tiie/page00010017.html) This is printer is connecter with centronics. It works well but, while it's writting and I putthe printer off-line, after about 45 seconds, I have this error : ------------------------------------- java.io.IOException: La ressource demand?e est en cours d'utilisation. in writeArray at gnu.io.LPRPort.writeArray(Native Method) at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:292) at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:161) at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:156) at mce.buffer.bufferManager.BufferManager$PrintBuffer.run(BufferManager.java:141) The IOexception means "The wanted resource is in use" ------------------------------------- Here is the line 141 of BufferManager : ------------------------------------- while(send){ try{ fos.write(bb); <=== line 141 send = false; } catch(Exception e){ javax.swing.JOptionPane.showMessageDialog(null, "Erreur d'envoie. Veuillez cliquer sur OK pour relancer l'impression de la vignette.\nV?rifiez votre impression !", "Erreur d'envoie", javax.swing.JOptionPane.WARNING_MESSAGE); e.printStackTrace(System.err); System.err.flush(); System.out.println(e); send = true; } } -------------------------------- 'fos' is an outputstream which contains the rxtx stream (this.os is the rxtx outputstream) : -------------------------------- public void write(byte[] bb) throws IOException{ this.write(bb, 0, bb.length); } public void write(byte[] bb, int off, int len) throws IOException{ while(!imp1.isPrinterSelected() || !imp2.isPrinterSelected()){ } this.os.write(bb, off, len); } -------------------------------- Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( can you help me ? thank you :) -- yves piel From yvespielusenet at free.fr Wed Jun 6 09:11:15 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 17:11:15 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181141195.3407.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> Message-ID: <1181142675.3407.23.camel@localhost.localdomain> I forgot to tell that It's under windows XP and java 1.5. Le mercredi 06 juin 2007 ? 16:46 +0200, yves pielusenet a ?crit : > Hello, > I want to use rxtx in my application. I haveto send data to a very old > printer (which have a drum and hammers > http://perso.orange.fr/tiie/page00010017.html) > This is printer is connecter with centronics. It works well but, while > it's writting and I putthe printer off-line, after about 45 seconds, I > have this error : > ------------------------------------- > java.io.IOException: La ressource demand?e est en cours d'utilisation. > in writeArray > at gnu.io.LPRPort.writeArray(Native Method) > at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:292) > at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:161) > at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:156) > at mce.buffer.bufferManager.BufferManager$PrintBuffer.run(BufferManager.java:141) > > The IOexception means "The wanted resource is in use" > ------------------------------------- > > Here is the line 141 of BufferManager : > > ------------------------------------- > while(send){ > try{ > fos.write(bb); <=== line 141 > send = false; > } > catch(Exception e){ > javax.swing.JOptionPane.showMessageDialog(null, "Erreur d'envoie. Veuillez cliquer sur OK pour relancer l'impression de la vignette.\nV?rifiez votre impression !", "Erreur d'envoie", javax.swing.JOptionPane.WARNING_MESSAGE); > e.printStackTrace(System.err); > System.err.flush(); > System.out.println(e); > send = true; > } > } > -------------------------------- > 'fos' is an outputstream which contains the rxtx stream (this.os is the rxtx outputstream) : > > -------------------------------- > public void write(byte[] bb) throws IOException{ > this.write(bb, 0, bb.length); > } > public void write(byte[] bb, int off, int len) throws IOException{ > while(!imp1.isPrinterSelected() || !imp2.isPrinterSelected()){ > } > this.os.write(bb, off, len); > } > -------------------------------- > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > can you help me ? > > thank you :) > From netbeans at gatworks.com Wed Jun 6 09:21:46 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 11:21:46 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181141195.3407.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> Message-ID: <4666D10A.8000507@gatworks.com> } > -------------------------------- > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > can you help me ? > > thank you :) > windoz or linux? ( I guess windoz ) for windoz, there appears to be a timeout ( as Comments suggest ) of about 40seconds. > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } for linux, there is no implied timeout. > if( write( fd, bytes, count ) < 0 ) > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); From netbeans at gatworks.com Wed Jun 6 09:39:41 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 11:39:41 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666D10A.8000507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> Message-ID: <4666D53D.90000@gatworks.com> Uncle George wrote: > } >> -------------------------------- >> >> Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( >> >> can you help me ? From reading the code, I can see your concern. And it appears you are correct, because some of the data will be sent to the OS printer buffers, and then it will refuse to accept anymore. Unfortunately, writeArray does not return the num of characters written :{ So application has no idea to how many characters were accepted by the OS. I dont do windoz, so I cant say with absolute certainty what windoz will do with an off-line condition. If you have the source, and can compile, then maybe u can increase the loop count to hit 4hours? From yvespielusenet at free.fr Wed Jun 6 09:53:25 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 17:53:25 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666D10A.8000507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> Message-ID: <1181145205.3407.35.camel@localhost.localdomain> Thank you for your explanation :) This timeout comes when no data has been send to the printer after 40seconds if I well understand. But why there is such a timeout ? If I setthe printer offline while it's printing I mustn't have an exception. I don't understand why the "printer should solv all problems like buffer full" in 40 seconds. If I pause the printer the buffer will not be emptied, isn't it ? I not very familiar with C/C++, but it seem that the exception is thrown only when countWritten == 0, that means no data at all has been sent. So Is my code is good since when I intercept this exception I send all my buffer again. There is no way that the printer receive two times same bytes ? thanks ps: yes the application is running on windows XP since I developpe under Debian Le mercredi 06 juin 2007 ? 11:21 -0400, Uncle George a ?crit : > } > > -------------------------------- > > > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > > > can you help me ? > > > > thank you :) > > > > windoz or linux? ( I guess windoz ) > > for windoz, there appears to be a timeout ( as Comments suggest ) of > about 40seconds. > > while( count > 0 ){ > > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > > /* > > this are 20 * 2 seconds, in this time a printer (or other parallel device) > > should solv all problems like buffer full, etc > > */ > > if(errorCount++ < 20){ > > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > > continue; > > } > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > for linux, there is no implied timeout. > > if( write( fd, bytes, count ) < 0 ) > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Wed Jun 6 10:34:24 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 12:34:24 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181145205.3407.35.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> Message-ID: <4666E210.30507@gatworks.com> yves pielusenet wrote: > Thank you for your explanation :) > This timeout comes when no data has been send to the printer after > 40seconds if I well understand. But why there is such a timeout ? If I > setthe printer offline while it's printing I mustn't have an exception. > I don't understand why the "printer should solv all problems like buffer > full" in 40 seconds. If I pause the printer the buffer will not be > emptied, isn't it ? > > I not very familiar with C/C++, but it seem that the exception is thrown > only when countWritten == 0, that means no data at all has been sent. So > Is my code is good since when I intercept this exception I send all my > buffer again. There is no way that the printer receive two times same > bytes ? More technically, the function call returns and reports that 0 characters was written in this call. when 0 characters are written, it will check how many times 0 characters was written. If it has tried LESS than 20 times(errorCount), it will sleep() and try to write again. After 20 times, it wont sleep, but throw you the exception. Now suppose you are writing a 120 character line. you off-lined/paused your printer. The OS has room for 80 more characters in it's printer buffer. The WriteFile() will have a char count of 120, but on return the countWritten = 80. You still have 40 more characters to print. Since countWritten != 0, the counters: bytes += countWritten; count -= countWritten; get updated, and the Writefile now has a count of 40 characters. Since the printer is off-line, the countwritten is 0. And so the loop continues, till 40 seconds is up. As to why it is this way, i dont know ( not a windoz maven ); Also the sleep(20) in the loop is not so intuitive to suggest 2 seconds of sleep. I would have guessed 20seconds, or 20milliseconds. But go figure. BTW: Since your computer sends you error messages in French, does it curse in English? :)))) From yvespielusenet at free.fr Thu Jun 7 02:27:44 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Thu, 07 Jun 2007 10:27:44 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666E210.30507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> Message-ID: <1181204864.3501.10.camel@localhost.localdomain> Maybe in my case I should re-compile rxtx and change the code. Instead of send an exception I should display a dialog box to ask if it's printer problem or if it should trie to send bytes. Something like : while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } if(displayDialogBox("Try again to send datas ??")){ errorCount = 0; } else{ throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } } Le mercredi 06 juin 2007 ? 12:34 -0400, Uncle George a ?crit : > yves pielusenet wrote: > > Thank you for your explanation :) > > This timeout comes when no data has been send to the printer after > > 40seconds if I well understand. But why there is such a timeout ? If I > > setthe printer offline while it's printing I mustn't have an exception. > > I don't understand why the "printer should solv all problems like buffer > > full" in 40 seconds. If I pause the printer the buffer will not be > > emptied, isn't it ? > > > > I not very familiar with C/C++, but it seem that the exception is thrown > > only when countWritten == 0, that means no data at all has been sent. So > > Is my code is good since when I intercept this exception I send all my > > buffer again. There is no way that the printer receive two times same > > bytes ? > More technically, the function call returns and reports that 0 > characters was written in this call. > when 0 characters are written, it will check how many times 0 characters > was written. If it has tried LESS than 20 times(errorCount), it will > sleep() and try to write again. > After 20 times, it wont sleep, but throw you the exception. > > Now suppose you are writing a 120 character line. you off-lined/paused > your printer. The OS has room for 80 more characters in it's printer > buffer. The WriteFile() will have a char count of 120, but on return the > countWritten = 80. You still have 40 more characters to print. > Since countWritten != 0, the counters: > bytes += countWritten; > count -= countWritten; > get updated, and the Writefile now has a count of 40 characters. Since > the printer is off-line, the countwritten is 0. And so the loop > continues, till 40 seconds is up. > > As to why it is this way, i dont know ( not a windoz maven ); > Also the sleep(20) in the loop is not so intuitive to suggest 2 seconds > of sleep. I would have guessed 20seconds, or 20milliseconds. But go figure. > > BTW: Since your computer sends you error messages in French, does it > curse in English? :)))) > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 06:11:43 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 08:11:43 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181204864.3501.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> Message-ID: <4667F5FF.8070903@gatworks.com> your suggestion appears good. I dont know what displayDialogBox exactly will do, so all I can say it that it looks good. But I'd like to wait 10min before first dialog box And a 5 min wait for every dialog box there after. And since these are custom solution/choices, maybe a more exact explanation of what the issue is. if(errorCount++ < 300){ // wait 10min ( 10min * 60sec / 2 ) Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } if(displayDialogBox("Printer has Paused. Retry sending data?")){ errorCount = 150; // Wait for 5 min thereafter continue; } > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } yves pielusenet wrote: > Maybe in my case I should re-compile rxtx and change the code. Instead > of send an exception I should display a dialog box to ask if it's > printer problem or if it should trie to send bytes. Something like : > > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > > if(displayDialogBox("Try again to send datas ??")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > } > From yvespielusenet at free.fr Thu Jun 7 07:17:21 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Thu, 07 Jun 2007 15:17:21 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4667F5FF.8070903@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <4667F5FF.8070903@gatworks.com> Message-ID: <1181222241.3501.20.camel@localhost.localdomain> thank you :) 'displayDialogBox()' I think doesn't exist. It was just for the example :) But I think It should not be so complicated to display a dialog box under windows with YES/NO buttons. When yes is clicked it return 0 other it returns 1. Le jeudi 07 juin 2007 ? 08:11 -0400, Uncle George a ?crit : > your suggestion appears good. I dont know what displayDialogBox exactly > will do, so all I can say it that it looks good. > > But I'd like to wait 10min before first dialog box And a 5 min wait for > every dialog box there after. And since these are custom > solution/choices, maybe a more exact explanation of what the issue is. > > if(errorCount++ < 300){ // wait 10min ( 10min * 60sec / 2 ) > Sleep( 20 ); /* make a small pause to execute all other requests > in all other threads */ > continue; > } > > if(displayDialogBox("Printer has Paused. Retry sending data?")){ > errorCount = 150; // Wait for 5 min thereafter > continue; > } > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > > yves pielusenet wrote: > > Maybe in my case I should re-compile rxtx and change the code. Instead > > of send an exception I should display a dialog box to ask if it's > > printer problem or if it should trie to send bytes. Something like : > > > > while( count > 0 ){ > > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > > /* > > this are 20 * 2 seconds, in this time a printer (or other parallel device) > > should solv all problems like buffer full, etc > > */ > > if(errorCount++ < 20){ > > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > > continue; > > } > > > > if(displayDialogBox("Try again to send datas ??")){ > > errorCount = 0; > > } > > else{ > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > } > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 07:41:43 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 09:41:43 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181222241.3501.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <4667F5FF.8070903@gatworks.com> <1181222241.3501.20.camel@localhost.localdomain> Message-ID: <46680B17.8050109@gatworks.com> yves pielusenet wrote: > thank you :) > 'displayDialogBox()' I think doesn't exist. It was just for the > example :) too bad. Good luck. From rtrout at webbresearch.com Thu Jun 7 11:23:04 2007 From: rtrout at webbresearch.com (Robert Trout) Date: Thu, 07 Jun 2007 13:23:04 -0400 Subject: [Rxtx] Disconnected PortServer TS causes Java to hang Message-ID: <1181236984.14186.33.camel@sisyphus.DinkumSoftware.com> I'm running Linux with sun's Java 1.4.2, Java comm API 2.0, RXTX 2.0-7pre1, and the RealPort digi driver. "/dev/ttyrp00" is a RealPort device. My Java application never returns from a ComPortIdentifier.getPortIdentifier("/dev/ttyrp00") call while the Digi PortServer TS 4 is disconnected from the network. If I later re-connect the PortServer, the call returns about 30 seconds later (it's like a serial port read or write is blocking until the PortServer is re- connected). With the PortServer disconnected, minicom immediately responds with "cannot open /dev/ttyrp00: No such file or directory". I would like my Java application to behave similarly. That is, respond with an error condition instead of hanging when the PortServer is not connected. Since minicom and Java behave differently, I think this "hanging" behavior may be due to RXTX or Java? Has anyone had a similar issue? Solutions? Suggestions? Thanks, Robert From vicnevicne at gmail.com Thu Jun 7 12:16:02 2007 From: vicnevicne at gmail.com (Vicne) Date: Thu, 07 Jun 2007 20:16:02 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181204864.3501.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> Message-ID: <46684B62.7080802@gmail.com> yves pielusenet wrote: > Maybe in my case I should re-compile rxtx and change the code. Instead > of send an exception I should display a dialog box to ask if it's > printer problem or if it should trie to send bytes. Something like : > > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > > if(displayDialogBox("Try again to send datas ??")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > } > Sorry to step in without a specific solution to your problem, but I wanted to share my feeling regarding this proposal. AFAIK, it's generally considered bad practice to pop-up a prompt from a library. The main reason is that in general use, you can't guarantee that someone is actually present behind the console. Imagine a print server in a machine room, connected to a park of printers. In that case, when one printer fails, the logical behaviour would be to use an other one. If you change RxTx the way you propose, the printer queue will simply be stuck with a useless "Try again to send data ?" prompt until an administrator opens a remote connection to the print server's console and clicks "no". Second, it would create a dependency upon the existence of a graphical console (if you go the graphical "dialogBox" way). On many applications (typically server or embedded ones), the JVM is "headless" and if you try to pop-up a dialog, your app would throw an exception (at best) or just wouldn't display the prompt anywhere... Going the "text console" way is not more reliable, because on graphical environments, the text console is hidden unless explicitly requested. My advice would be to think again and find another solution. Ideas are : - make the number of retries a parameter so that you can tune it to what you think is reasonable - throw a more specific exception when the number of retries has been reached, so that a specific prompt can be shown at a higher level Anyway, if you feel that the prompt is the way to go in your case, I would at least make that prompt conditional. The least intrusive way would probably be using a system property, like if("true".equals(System.getProperty("org.rxtx.usePrompt")) && displayDialogBox("Retry sending data ?")){ errorCount = 0; } else{ throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } By default, the behaviour would remain as it is now, but you could force the prompts by defining the property at VM launch if desired. (for example : java.exe -Dorg.rxtx.usePrompt=true myApp) Also, you seemed to say you wanted the printer to start again exactly where is stopped. It would indeed be the best way when the printer is put offline for a few seconds. On the other hand, if the printer is turned off (or the printer runs out of paper, or someone steps on the mains cable), then the only way to go back to a "stable" situation would be by printing the item (page, label, etc.) again from scratch... Just my two cents. Vicne PS : By the way, the dialog box thing is very platform dependant on the C-side, and I think the simplest way would probably be to bridge it to a Java call where you can implement it like you proposed : public boolean displayDialogBox(prompt) { return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); } From netbeans at gatworks.com Thu Jun 7 14:08:24 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 16:08:24 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46684B62.7080802@gmail.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> Message-ID: <466865B8.4060004@gatworks.com> My feeling is that the code that was suggested was for his environs ( his shop ). The issue here is that after a 40+ second wait, an exception will be thrown. But you really dont have a way of 'cancelling' all the WriteFiles() that have already occured before the exception so that your writeArray and the Commapi can backtrack to a position in which they are in sync. The main ( really mine ) concern is not to lose data, or replicate data. After 40seconds, 300 seconds, 55min, no matter how long, data should not be lost or duplicated. But as soon as the exception is thrown, that possibility exists. Maybe an event should be thrown instead? Vicne wrote: > yves pielusenet wrote: >> Maybe in my case I should re-compile rxtx and change the code. Instead >> of send an exception I should display a dialog box to ask if it's >> printer problem or if it should trie to send bytes. Something like : >> >> while( count > 0 ){ >> if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ >> /* >> this are 20 * 2 seconds, in this time a printer (or other parallel device) >> should solv all problems like buffer full, etc >> */ >> if(errorCount++ < 20){ >> Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ >> continue; >> } >> >> if(displayDialogBox("Try again to send datas ??")){ >> errorCount = 0; >> } >> else{ >> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >> break; >> } >> } >> > > Sorry to step in without a specific solution to your problem, but I > wanted to share my feeling regarding this proposal. AFAIK, it's > generally considered bad practice to pop-up a prompt from a library. > The main reason is that in general use, you can't guarantee that > someone is actually present behind the console. Imagine a print server > in a machine room, connected to a park of printers. In that case, when > one printer fails, the logical behaviour would be to use an other one. > If you change RxTx the way you propose, the printer queue will simply be > stuck with a useless "Try again to send data ?" prompt until an > administrator opens a remote connection to the print server's console > and clicks "no". > Second, it would create a dependency upon the existence of a > graphical console (if you go the graphical "dialogBox" way). On many > applications (typically server or embedded ones), the JVM is "headless" > and if you try to pop-up a dialog, your app would throw an exception (at > best) or just wouldn't display the prompt anywhere... Going the "text > console" way is not more reliable, because on graphical environments, > the text console is hidden unless explicitly requested. > > My advice would be to think again and find another solution. Ideas are : > - make the number of retries a parameter so that you can tune it to what > you think is reasonable > - throw a more specific exception when the number of retries has been > reached, so that a specific prompt can be shown at a higher level > > Anyway, if you feel that the prompt is the way to go in your case, I > would at least make that prompt conditional. The least intrusive way > would probably be using a system property, like > > if("true".equals(System.getProperty("org.rxtx.usePrompt")) > && displayDialogBox("Retry sending data ?")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > > > By default, the behaviour would remain as it is now, but you could > force the prompts by defining the property at VM launch if desired. (for > example : java.exe -Dorg.rxtx.usePrompt=true myApp) > > > Also, you seemed to say you wanted the printer to start again > exactly where is stopped. It would indeed be the best way when the > printer is put offline for a few seconds. On the other hand, if the > printer is turned off (or the printer runs out of paper, or someone > steps on the mains cable), then the only way to go back to a "stable" > situation would be by printing the item (page, label, etc.) again from > scratch... > > > Just my two cents. > > > Vicne > > PS : By the way, the dialog box thing is very platform dependant on the > C-side, and I think the simplest way would probably be to bridge it to a > Java call where you can implement it like you proposed : > > public boolean displayDialogBox(prompt) { > return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", > JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); > } > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Thu Jun 7 17:48:11 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 Jun 2007 17:48:11 -0600 (MDT) Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <466865B8.4060004@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> Message-ID: An event is possible. I'm amazed this is the largest problem encountered while using the parallel code. How would the write ever exit if we throw events? Isn't this going to lead to hung applications? On Thu, 7 Jun 2007, Uncle George wrote: > My feeling is that the code that was suggested was for his environs ( > his shop ). > > The issue here is that after a 40+ second wait, an exception will be > thrown. But you really dont have a way of 'cancelling' all the > WriteFiles() that have already occured before the exception so that your > writeArray and the Commapi can backtrack to a position in which they are > in sync. > > The main ( really mine ) concern is not to lose data, or replicate data. > After 40seconds, 300 seconds, 55min, no matter how long, data should > not be lost or duplicated. But as soon as the exception is thrown, that > possibility exists. > > Maybe an event should be thrown instead? > > Vicne wrote: >> yves pielusenet wrote: >>> Maybe in my case I should re-compile rxtx and change the code. Instead >>> of send an exception I should display a dialog box to ask if it's >>> printer problem or if it should trie to send bytes. Something like : >>> >>> while( count > 0 ){ >>> if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ >>> /* >>> this are 20 * 2 seconds, in this time a printer (or other parallel device) >>> should solv all problems like buffer full, etc >>> */ >>> if(errorCount++ < 20){ >>> Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ >>> continue; >>> } >>> >>> if(displayDialogBox("Try again to send datas ??")){ >>> errorCount = 0; >>> } >>> else{ >>> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >>> break; >>> } >>> } >>> >> >> Sorry to step in without a specific solution to your problem, but I >> wanted to share my feeling regarding this proposal. AFAIK, it's >> generally considered bad practice to pop-up a prompt from a library. >> The main reason is that in general use, you can't guarantee that >> someone is actually present behind the console. Imagine a print server >> in a machine room, connected to a park of printers. In that case, when >> one printer fails, the logical behaviour would be to use an other one. >> If you change RxTx the way you propose, the printer queue will simply be >> stuck with a useless "Try again to send data ?" prompt until an >> administrator opens a remote connection to the print server's console >> and clicks "no". >> Second, it would create a dependency upon the existence of a >> graphical console (if you go the graphical "dialogBox" way). On many >> applications (typically server or embedded ones), the JVM is "headless" >> and if you try to pop-up a dialog, your app would throw an exception (at >> best) or just wouldn't display the prompt anywhere... Going the "text >> console" way is not more reliable, because on graphical environments, >> the text console is hidden unless explicitly requested. >> >> My advice would be to think again and find another solution. Ideas are : >> - make the number of retries a parameter so that you can tune it to what >> you think is reasonable >> - throw a more specific exception when the number of retries has been >> reached, so that a specific prompt can be shown at a higher level >> >> Anyway, if you feel that the prompt is the way to go in your case, I >> would at least make that prompt conditional. The least intrusive way >> would probably be using a system property, like >> >> if("true".equals(System.getProperty("org.rxtx.usePrompt")) >> && displayDialogBox("Retry sending data ?")){ >> errorCount = 0; >> } >> else{ >> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >> break; >> } >> >> >> By default, the behaviour would remain as it is now, but you could >> force the prompts by defining the property at VM launch if desired. (for >> example : java.exe -Dorg.rxtx.usePrompt=true myApp) >> >> >> Also, you seemed to say you wanted the printer to start again >> exactly where is stopped. It would indeed be the best way when the >> printer is put offline for a few seconds. On the other hand, if the >> printer is turned off (or the printer runs out of paper, or someone >> steps on the mains cable), then the only way to go back to a "stable" >> situation would be by printing the item (page, label, etc.) again from >> scratch... >> >> >> Just my two cents. >> >> >> Vicne >> >> PS : By the way, the dialog box thing is very platform dependant on the >> C-side, and I think the simplest way would probably be to bridge it to a >> Java call where you can implement it like you proposed : >> >> public boolean displayDialogBox(prompt) { >> return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", >> JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); >> } >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 19:18:51 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 21:18:51 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> Message-ID: <4668AE7B.3060409@gatworks.com> The UNIX version of writeArray is not too great either. It is possible that the write will only process some of the bytes. #else if( write( fd, bytes, count ) < 0 ) throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); #endif -------------------------------- Maybe it might be better to have the native function inform the caller of the # of characters written, then the commapi/output-buffer can be modified to reflect the #of chars written. If an exception is to be thrown, for too many loops of chars written == 0, then exception wont affect the state of the output buffer. Then a ParallelPort.restart() can be called to resume printing whats in the buffer. Trent Jarvi wrote: > An event is possible. I'm amazed this is the largest problem encountered > while using the parallel code. > > How would the write ever exit if we throw events? Isn't this going to > lead to hung applications? Sure. If you dont time out, then there is nothing that will force an EXIT from the write(). Issue is what has the OS done with the write. > > On Thu, 7 Jun 2007, Uncle George wrote: > >> My feeling is that the code that was suggested was for his environs ( >> his shop ). From yvespielusenet at free.fr Fri Jun 8 01:09:01 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Fri, 08 Jun 2007 09:09:01 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4668AE7B.3060409@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> Message-ID: <1181286541.3674.10.camel@localhost.localdomain> It is not possible that the rxtx java method write(byte[], int offset, int length) return anint which contains the number of byte really send to the printer instead of an exception ? So this is the programm which will see if all bytes have been sent. If not it can retry to send the unsended bytes. -------------------------------------------------------- int sended = 0; while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ sended += countWritten; /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } return sended; /*throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break;*/ } ... ... return countWritten; ------------------------------------------------ Le jeudi 07 juin 2007 ? 21:18 -0400, Uncle George a ?crit : > The UNIX version of writeArray is not too great either. It is possible > that the write will only process some of the bytes. > > #else > if( write( fd, bytes, count ) < 0 ) > throw_java_exception_system_msg( env, IO_EXCEPTION, > "writeArray" ); > #endif > -------------------------------- > > Maybe it might be better to have the native function inform the caller > of the # of characters written, then the commapi/output-buffer can be > modified to reflect the #of chars written. If an exception is to be > thrown, for too many loops of chars written == 0, then exception wont > affect the state of the output buffer. Then a ParallelPort.restart() can > be called to resume printing whats in the buffer. > > > Trent Jarvi wrote: > > An event is possible. I'm amazed this is the largest problem encountered > > while using the parallel code. > > > > How would the write ever exit if we throw events? Isn't this going to > > lead to hung applications? > Sure. If you dont time out, then there is nothing that will force an > EXIT from the write(). Issue is what has the OS done with the write. > > > > On Thu, 7 Jun 2007, Uncle George wrote: > > > >> My feeling is that the code that was suggested was for his environs ( > >> his shop ). > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Fri Jun 8 03:45:00 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 11:45:00 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181286541.3674.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> Message-ID: <20070608094500.GC21069@elberon.bln.de.ingenico.com> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > It is not possible that the rxtx java method write(byte[], int offset, > int length) return anint which contains the number of byte really send > to the printer instead of an exception ? > So this is the programm which will see if all bytes have been sent. If > not it can retry to send the unsended bytes. I think write() is void because in Java people love to do this since OutputStream :-) Of course on such interfaces you cannot implement something nice. If you would have a int write, you would not implement the interface and no applications expecting this interface would link/work/compile. oki, Steffen P.S.: (OT) If you propose not to implement the Java interfaces (especially not on JNI level), maybe optionally offering a wrapper that removes e.g. the write return value and so on to downgrade the powerful classic old POSIX read/write style to the modern limited Java style, then I agree :-) Same for read. Instead of things like "int avialable()" it is more powerful to have an approach as select(2) offers (to guarante the caller that read/write will not block [nothing else make sense anyway IMHO] but may read/write less bytes then requested). The caller gets full control and the higher level protocols can care about timeouts, invoking read in some loops and/or implement retransmission. On top of such an implementation, where everything is controlled, defined, guaranteed and reliable, someone could use an InputStream or OutputStream style interface. Or even better: don't use them at all :) just BTW :-) St. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From yvespielusenet at free.fr Fri Jun 8 05:52:45 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Fri, 08 Jun 2007 13:52:45 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <20070608094500.GC21069@elberon.bln.de.ingenico.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> Message-ID: <1181303565.11203.3.camel@localhost.localdomain> So maybe a better way should be to create a new Exception class which has a method "int getWrittenByte()". So the Exception should be use to send again bytes which are not printed yet. yves Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : > * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > > It is not possible that the rxtx java method write(byte[], int offset, > > int length) return anint which contains the number of byte really send > > to the printer instead of an exception ? > > So this is the programm which will see if all bytes have been sent. If > > not it can retry to send the unsended bytes. > > I think write() is void because in Java people love to do this > since OutputStream :-) Of course on such interfaces you cannot > implement something nice. If you would have a int write, you > would not implement the interface and no applications expecting > this interface would link/work/compile. > > oki, > > Steffen > > P.S.: (OT) > If you propose not to implement the Java interfaces (especially > not on JNI level), maybe optionally offering a wrapper that > removes e.g. the write return value and so on to downgrade the > powerful classic old POSIX read/write style to the modern limited > Java style, then I agree :-) Same for read. Instead of things > like "int avialable()" it is more powerful to have an approach as > select(2) offers (to guarante the caller that read/write will not > block [nothing else make sense anyway IMHO] but may read/write > less bytes then requested). The caller gets full control and the > higher level protocols can care about timeouts, invoking read in > some loops and/or implement retransmission. On top of such an > implementation, where everything is controlled, defined, > guaranteed and reliable, someone could use an InputStream or > OutputStream style interface. Or even better: don't use them at > all :) just BTW :-) > St. > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > 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. > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > 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. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Fri Jun 8 06:46:21 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 08:46:21 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181303565.11203.3.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> Message-ID: <46694F9D.5080501@gatworks.com> It seems that with outputstream.write(b[]), you become terribly uncoordinated as soon as an exception is thrown. Docs do not say what happens to the data. Yet from a practicable point of view, one would like to know if the write was accepted in-full, or rejected before any writes. There are no in betweens, as partial writes are not reportable. So for an outputstream.write(), in order for it to return, the full write request has to be taken, and stored in an internal output buffer. If there is no room, the write() is suspended, till there is room. Or throw's an IOException( "no room in buffer") ; As the select() loop for write reports buffer room avail, then more of the internal buffer is sent to the printer. yves pielusenet wrote: > So maybe a better way should be to create a new Exception class which > has a method "int getWrittenByte()". So the Exception should be use to > send again bytes which are not printed yet. > > yves > > Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : >> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: >>> It is not possible that the rxtx java method write(byte[], int offset, >>> int length) return anint which contains the number of byte really send >>> to the printer instead of an exception ? >>> So this is the programm which will see if all bytes have been sent. If >>> not it can retry to send the unsended bytes. >> I think write() is void because in Java people love to do this >> since OutputStream :-) Of course on such interfaces you cannot >> implement something nice. If you would have a int write, you >> would not implement the interface and no applications expecting >> this interface would link/work/compile. >> >> oki, >> >> Steffen >> >> P.S.: (OT) >> If you propose not to implement the Java interfaces (especially >> not on JNI level), maybe optionally offering a wrapper that >> removes e.g. the write return value and so on to downgrade the >> powerful classic old POSIX read/write style to the modern limited >> Java style, then I agree :-) Same for read. Instead of things >> like "int avialable()" it is more powerful to have an approach as >> select(2) offers (to guarante the caller that read/write will not >> block [nothing else make sense anyway IMHO] but may read/write >> less bytes then requested). The caller gets full control and the >> higher level protocols can care about timeouts, invoking read in >> some loops and/or implement retransmission. On top of such an >> implementation, where everything is controlled, defined, >> guaranteed and reliable, someone could use an InputStream or >> OutputStream style interface. Or even better: don't use them at >> all :) just BTW :-) >> St. >> >> About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. >> 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. >> >> About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. >> 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. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From Steffen.DETTMER at ingenico.com Fri Jun 8 08:12:18 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 16:12:18 +0200 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <46694F9D.5080501@gatworks.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: <20070608141218.GE21069@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 08:46 -0400: > It seems that with outputstream.write(b[]), you become terribly > uncoordinated as soon as an exception is thrown. Docs do not say what > happens to the data. (yes, so avoiding it seems to be good :)) > Yet from a practicable point of view, one would like to know if the > write was accepted in-full, or rejected before any writes. There are no > in betweens, as partial writes are not reportable. (which is an artificial API limitation. I never understood how this happend when they invented JDK because the well-known BSD socket API and thus [probably] WinSock does this correct, but anyway) > So for an outputstream.write(), in order for it to return, the full > write request has to be taken, and stored in an internal output buffer. > If there is no room, the write() is suspended, till there is room. Or > throw's an IOException( "no room in buffer") ; As the select() loop for > write reports buffer room avail, then more of the internal buffer is > sent to the printer. yes, might be good in case of a printer. May be horrible in case of PPP/TCP or some other transmission control protocol which may e.g. repeat data or even omit parts of it (e.g. internet realtime radio station broadcasting)... So I think the idea of "int write" (e.g. BSD sockets, linux files and so on) still is the best. A clean API / implementation should guarantee and allow implementations (users) to rely on that; assumptions and automatic background-sending and so on may look pragmatic and may even work on the first look, but may fail in other situations. BTW, if e.g. BSD socket API is known, why not simply copy it (until something better is invented :)) instead of fiddling around with JDK APIs? anyway, have a nice weekend everyone :-) oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Fri Jun 8 08:55:56 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 10:55:56 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070608141218.GE21069@elberon.bln.de.ingenico.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> Message-ID: <46696DFC.7000801@gatworks.com> >> write reports buffer room avail, then more of the internal buffer is >> sent to the printer. > > yes, might be good in case of a printer. May be horrible in case > of PPP/TCP or some other transmission control protocol which > may e.g. repeat data or even omit parts of it (e.g. internet > realtime radio station broadcasting)... So I think the idea of > "int write" (e.g. BSD sockets, linux files and so on) still is > the best. A clean API / implementation should guarantee and allow > implementations (users) to rely on that; assumptions and > automatic background-sending and so on may look pragmatic and may > even work on the first look, but may fail in other situations. > BTW, if e.g. BSD socket API is known, why not simply copy it > (until something better is invented :)) instead of fiddling > around with JDK APIs? But we were talking about the Parallel Port, and the transmission of data over the commapi/parallel-port schema. There isn't much in bi-directional software communication. Its a simple write one byte at a time interface. I'm not looking to change the comm-api. I'm just looking to alter the interaction between the Native ParallelPort functions, and the java ParallelPort functions that call them. This might be more readily doable than to get a committee to re-specify java-API specs. BTW: Whats is off-topic? ( help: not looking for def of off-topic ) From j.kenneth.gentle at acm.org Fri Jun 8 08:58:59 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Fri, 08 Jun 2007 10:58:59 -0400 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <20070608141218.GE21069@elberon.bln.de.ingenico.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> Message-ID: <200706081459.l58Ex5rA019991@qbang.org> Perhaps it is a bit late to jump in on this one, but here goes anyway. If the solutions all seem to "break" the contract with "java.io.outputstream", then, as noted, that may not be the appropriate contract. At the risk of being heretical, JDK1.4 introduced the "nio" package to address some of the compatibility issues with C apis mentioned in previous posts. The interface "java.nio.channels.WriteableByteChannel" defines the following single method: int write(ByteBuffer source); int, strangely enough, is the actual number of bytes written. So, if RXTX as written, against the JavaCOMM api and OutputStream, doesn't do what we want, how about writing a different set of bindings using the java.nio classes and as much of the underlying native code as possible. Note that just because the java.nio.channels.WriteableByteChannel sends back a result, OutputStream.write doesn't have to - and they could both call the same underlying native code. My 2 cents - maybe not worth even that... Ken From netbeans at gatworks.com Fri Jun 8 10:37:28 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 12:37:28 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <200706081459.l58Ex5rA019991@qbang.org> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> Message-ID: <466985C8.8000505@gatworks.com> Ken Gentle wrote: > Perhaps it is a bit late to jump in on this one, but here goes anyway. Common in, the waters fine. > > If the solutions all seem to "break" the contract with > "java.io.outputstream", then, as noted, that may not be the > appropriate contract. > How would the contract be broken? The machinery underneath is handling the contract. From j.kenneth.gentle at acm.org Fri Jun 8 10:48:01 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Fri, 08 Jun 2007 12:48:01 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466985C8.8000505@gatworks.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> Message-ID: <200706081648.l58Gm7YA022904@qbang.org> At 12:37 2007-06-08, you wrote: >Ken Gentle wrote: > > > > If the solutions all seem to "break" the contract with > > "java.io.outputstream", then, as noted, that may not be the > > appropriate contract. > > >How would the contract be broken? The machinery underneath is handling >the contract. It seems that a lot of the discussion has been about not only the timeout and being able to adjust it in the "machinery layer", but also about knowing in the Java layer, in the event of a timeout or exception, how many characters have been written to the device. An OutputStream won't ever do this with out an extension and including a return value "breaks" the contract, right? So, go with a Java IO api that *does* return the number of bytes written, out of the NIO package. I know it doesn't allow for a strict implementation of the JavaCOMM API - however, using NIO classes in place of the IO classes isn't that big a break and would allow those applications that need such information a way to get it. Maybe I'm misunderstanding the problem... Ken From netbeans at gatworks.com Fri Jun 8 11:24:14 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 13:24:14 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <200706081648.l58Gm7YA022904@qbang.org> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> Message-ID: <466990BE.7040100@gatworks.com> Ken Gentle wrote: An > OutputStream won't ever do this with out an extension and including a > return value "breaks" the contract, right? > i was not thinking of change the API to OutputSream. Are there specs for how output stream should work internally? for instance: String data = "Hello this is a line of data"; Outputstream.write( data.getbytes() ); ParallelPort.suspend(); int free = ParallelPort.getoutputbufferfree(); There is a symbiotic relationship between outputstream and the functionality of ParallelPort. From Steffen.DETTMER at ingenico.com Fri Jun 8 11:15:39 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 19:15:39 +0200 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <200706081459.l58Ex5rA019991@qbang.org> References: <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> Message-ID: <20070608171539.GK21069@elberon.bln.de.ingenico.com> * Ken Gentle wrote on Fri, Jun 08, 2007 at 10:58 -0400: > If the solutions all seem to "break" the contract with > "java.io.outputstream", then, as noted, that may not be the > appropriate contract. > > At the risk of being heretical, JDK1.4 introduced the "nio" package > to address some of the compatibility issues with C apis mentioned in > previous posts. The interface > "java.nio.channels.WriteableByteChannel" defines the following single method: > > int write(ByteBuffer source); > > int, strangely enough, is the actual number of bytes written. Yes, AFAIK one of the motivations for the NIO interface was, that the JDK-1.3 APIs (InputStream, e.g.) were not powerfull enough, especially for multi-connection-TCP servers or so. I don't know much about it but I've heard of a project where NIO usage was removed because of stability issues in multi-threaded environments and performance limitations under some circumstances. IIRC the "nio.ByteBuffer" is something very special (namely something you cannot implement in Java, it is "magic" or part of the language itself). Not sure if this is such a great idea (but for performance in the end sometimes heavy prices must be paid) :) > So, if RXTX as written, against the JavaCOMM api and OutputStream, > doesn't do what we want, how about writing a different set of > bindings using the java.nio classes and as much of the underlying > native code as possible. Yes, this would be an idea: use a full-featured interface on JNI, and, if wanted, deliver some wrappers converting this to a less-featured Java-compliant interface. However, powerful things as e.g. "select" are difficult to "emulate" if you are e.g. on some (older?) windows. But if you expose the full-featured APIs, you need to emulate them full-featured, theoretically. In the end it depends what you do on the serial line. If you just want to talk to a modem, then you may not need precise timeouts. But if you need to implement complexer protocols which define response times and timeouts, you may quickly get into difficulties. For instance, AFAIK, rxtx 1.7.2 (?) for windows is very messy with timeouts (there is a maximum, higher values are truncated; resolution is 100ms only; the function may take up to twice the timeout because internally it may be called twice). Probably for most people this is OK, but probably not for all. But having precise timeouts should be OK for all :-) Well, in the end it is nice to wish but somewhat hard to implement (many platforms, connections, USB, BlueTooth, whatever). oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Steffen.DETTMER at ingenico.com Fri Jun 8 11:04:22 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 19:04:22 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <46696DFC.7000801@gatworks.com> References: <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <46696DFC.7000801@gatworks.com> Message-ID: <20070608170422.GJ21069@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 10:55 -0400: > > BTW, if e.g. BSD socket API is known, why not simply copy it > > (until something better is invented :)) instead of fiddling > > around with JDK APIs? > > But we were talking about the Parallel Port, and the > transmission of data over the commapi/parallel-port schema. > There isn't much in bi-directional software communication. Its > a simple write one byte at a time interface. First, there are things like PLIP (http://en.wikipedia.org/wiki/Plip) - well, probably not widely used, sure ;) Second, I think if there is a good simple API known to support all that (with known "best practices") or so and there is no forcing need to invent a new one, why not simply using it? > I'm not looking to change the comm-api. I'm just looking to > alter the interaction between the Native ParallelPort > functions, and the java ParallelPort functions that call them. Ahh, yes. I think this is what I tried to ask. Having an usable JNI interface and on top (in pure java) some wrapper to InputStream or whatever could be done (e.g. by ignoring the return value of write or throwing if != length). Developers could then use the full-featured (non-JAVA-standard) API or select among various wrappers (as InputStream). > This might be more readily doable than to get a committee to > re-specify java-API specs. Yes, of course. I'm afraid that the Java APIs change regularily, but still yet with limited success it seems, so maybe they get it in one of the next iterations; who knows, maybe Java-9 has a BSD-like socket API :) SCNR. > BTW: Whats is off-topic? ( help: not looking for def of > off-topic ) I think I started some "re-specify java-API specs" which was OT probably. oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From lists at iDIAcomputing.com Fri Jun 8 18:48:54 2007 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Fri, 08 Jun 2007 20:48:54 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46684B62.7080802@gmail.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> Message-ID: <4669F8F6.3040101@iDIAcomputing.com> Vicne wrote: > Sorry to step in without a specific solution to your problem, but I > wanted to share my feeling regarding this proposal. AFAIK, it's > generally considered bad practice to pop-up a prompt from a library. ... > > My advice would be to think again and find another solution. Ideas are : > - make the number of retries a parameter so that you can tune it to what > you think is reasonable > - throw a more specific exception when the number of retries has been > reached, so that a specific prompt can be shown at a higher level You could also allow the client code to register a callback class which returns a boolean indicating whether to retry or cancel. This callback class could pop up a dialog, if appropriate, or follow some preset policy, or.... - George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From joachim at buechse.ch Sat Jun 9 09:43:16 2007 From: joachim at buechse.ch (Joachim Buechse) Date: Sat, 9 Jun 2007 17:43:16 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46694F9D.5080501@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: You should not forget, that in the case of an exception it may not even be known what happened to the data. You have a kernel buffer, outgoing chip buffer, incoming chip buffer, etc. So of course, it would be nice to know up to which point data was correctly processed, but this feedback does not exist on the hardware or protocol level and hence can in general not be magicly created on the software level... Regards, Joachim On 08.06.2007, at 14:46, Uncle George wrote: > It seems that with outputstream.write(b[]), you become terribly > uncoordinated as soon as an exception is thrown. Docs do not say what > happens to the data. > > Yet from a practicable point of view, one would like to know if the > write was accepted in-full, or rejected before any writes. There > are no > in betweens, as partial writes are not reportable. > > So for an outputstream.write(), in order for it to return, the full > write request has to be taken, and stored in an internal output > buffer. > If there is no room, the write() is suspended, till there is room. Or > throw's an IOException( "no room in buffer") ; As the select() loop > for > write reports buffer room avail, then more of the internal buffer is > sent to the printer. > > > > yves pielusenet wrote: >> So maybe a better way should be to create a new Exception class which >> has a method "int getWrittenByte()". So the Exception should be >> use to >> send again bytes which are not printed yet. >> >> yves >> >> Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : >>> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: >>>> It is not possible that the rxtx java method write(byte[], int >>>> offset, >>>> int length) return anint which contains the number of byte >>>> really send >>>> to the printer instead of an exception ? >>>> So this is the programm which will see if all bytes have been >>>> sent. If >>>> not it can retry to send the unsended bytes. >>> I think write() is void because in Java people love to do this >>> since OutputStream :-) Of course on such interfaces you cannot >>> implement something nice. If you would have a int write, you >>> would not implement the interface and no applications expecting >>> this interface would link/work/compile. >>> >>> oki, >>> >>> Steffen >>> >>> P.S.: (OT) >>> If you propose not to implement the Java interfaces (especially >>> not on JNI level), maybe optionally offering a wrapper that >>> removes e.g. the write return value and so on to downgrade the >>> powerful classic old POSIX read/write style to the modern limited >>> Java style, then I agree :-) Same for read. Instead of things >>> like "int avialable()" it is more powerful to have an approach as >>> select(2) offers (to guarante the caller that read/write will not >>> block [nothing else make sense anyway IMHO] but may read/write >>> less bytes then requested). The caller gets full control and the >>> higher level protocols can care about timeouts, invoking read in >>> some loops and/or implement retransmission. On top of such an >>> implementation, where everything is controlled, defined, >>> guaranteed and reliable, someone could use an InputStream or >>> OutputStream style interface. Or even better: don't use them at >>> all :) just BTW :-) >>> St. >>> >>> About Ingenico Throughout the world businesses rely on Ingenico >>> for secure and expedient electronic transaction acceptance. >>> Ingenico products leverage proven technology, established >>> standards and unparalleled ergonomics to provide optimal >>> reliability, versatility and usability. This comprehensive range >>> of products is complemented by a global array of services and >>> partnerships, enabling businesses in a number of vertical sectors >>> to accept transactions anywhere their business takes them. >>> 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. >>> >>> About Ingenico Throughout the world businesses rely on Ingenico >>> for secure and expedient electronic transaction acceptance. >>> Ingenico products leverage proven technology, established >>> standards and unparalleled ergonomics to provide optimal >>> reliability, versatility and usability. This comprehensive range >>> of products is complemented by a global array of services and >>> partnerships, enabling businesses in a number of vertical sectors >>> to accept transactions anywhere their business takes them. >>> 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. >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx 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 yvespielusenet at free.fr Mon Jun 11 03:15:12 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Mon, 11 Jun 2007 11:15:12 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: <1181553312.8335.14.camel@localhost.localdomain> So can someone tell a solution for my problem :( Must I say to the user to not put the printer off-line ? I can't since he has to do some pauses, verify print, paper conditioning etc... How do other people ? Before I use the parport librarry to read port status : http://www.geocities.com/Juanga69/parport/ (which doesn't work on windows XP) And I send data into the file LPT1 I use to have no problem when printer was disabled. thanks -- yves piel Le samedi 09 juin 2007 ? 17:43 +0200, Joachim Buechse a ?crit : > You should not forget, that in the case of an exception it may not > even be known what happened to the data. > > You have a kernel buffer, outgoing chip buffer, incoming chip buffer, > etc. So of course, it would be nice to know up to which point data > was correctly processed, but this feedback does not exist on the > hardware or protocol level and hence can in general not be magicly > created on the software level... > > Regards, > Joachim > > On 08.06.2007, at 14:46, Uncle George wrote: > > > It seems that with outputstream.write(b[]), you become terribly > > uncoordinated as soon as an exception is thrown. Docs do not say what > > happens to the data. > > > > Yet from a practicable point of view, one would like to know if the > > write was accepted in-full, or rejected before any writes. There > > are no > > in betweens, as partial writes are not reportable. > > > > So for an outputstream.write(), in order for it to return, the full > > write request has to be taken, and stored in an internal output > > buffer. > > If there is no room, the write() is suspended, till there is room. Or > > throw's an IOException( "no room in buffer") ; As the select() loop > > for > > write reports buffer room avail, then more of the internal buffer is > > sent to the printer. > > > > > > > > yves pielusenet wrote: > >> So maybe a better way should be to create a new Exception class which > >> has a method "int getWrittenByte()". So the Exception should be > >> use to > >> send again bytes which are not printed yet. > >> > >> yves > >> > >> Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : > >>> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > >>>> It is not possible that the rxtx java method write(byte[], int > >>>> offset, > >>>> int length) return anint which contains the number of byte > >>>> really send > >>>> to the printer instead of an exception ? > >>>> So this is the programm which will see if all bytes have been > >>>> sent. If > >>>> not it can retry to send the unsended bytes. > >>> I think write() is void because in Java people love to do this > >>> since OutputStream :-) Of course on such interfaces you cannot > >>> implement something nice. If you would have a int write, you > >>> would not implement the interface and no applications expecting > >>> this interface would link/work/compile. > >>> > >>> oki, > >>> > >>> Steffen > >>> > >>> P.S.: (OT) > >>> If you propose not to implement the Java interfaces (especially > >>> not on JNI level), maybe optionally offering a wrapper that > >>> removes e.g. the write return value and so on to downgrade the > >>> powerful classic old POSIX read/write style to the modern limited > >>> Java style, then I agree :-) Same for read. Instead of things > >>> like "int avialable()" it is more powerful to have an approach as > >>> select(2) offers (to guarante the caller that read/write will not > >>> block [nothing else make sense anyway IMHO] but may read/write > >>> less bytes then requested). The caller gets full control and the > >>> higher level protocols can care about timeouts, invoking read in > >>> some loops and/or implement retransmission. On top of such an > >>> implementation, where everything is controlled, defined, > >>> guaranteed and reliable, someone could use an InputStream or > >>> OutputStream style interface. Or even better: don't use them at > >>> all :) just BTW :-) > >>> St. > >>> > >>> About Ingenico Throughout the world businesses rely on Ingenico > >>> for secure and expedient electronic transaction acceptance. > >>> Ingenico products leverage proven technology, established > >>> standards and unparalleled ergonomics to provide optimal > >>> reliability, versatility and usability. This comprehensive range > >>> of products is complemented by a global array of services and > >>> partnerships, enabling businesses in a number of vertical sectors > >>> to accept transactions anywhere their business takes them. > >>> 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. > >>> > >>> About Ingenico Throughout the world businesses rely on Ingenico > >>> for secure and expedient electronic transaction acceptance. > >>> Ingenico products leverage proven technology, established > >>> standards and unparalleled ergonomics to provide optimal > >>> reliability, versatility and usability. This comprehensive range > >>> of products is complemented by a global array of services and > >>> partnerships, enabling businesses in a number of vertical sectors > >>> to accept transactions anywhere their business takes them. > >>> 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. > >>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx 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 > From Steffen.DETTMER at ingenico.com Mon Jun 11 03:56:18 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 11:56:18 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466990BE.7040100@gatworks.com> References: <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> Message-ID: <20070611095618.GA10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 13:24 -0400: > i was not thinking of change the API to OutputSream. Then I think either someone uses OutputStream (and has no reliable information about incomplete writes) or someone uses somethink else. > Are there specs for how output stream should work internally? > > for instance: > String data = "Hello this is a line of data"; > Outputstream.write( data.getbytes() ); > ParallelPort.suspend(); > int free = ParallelPort.getoutputbufferfree(); > > There is a symbiotic relationship between outputstream and the > functionality of ParallelPort. If you need OutputStream "plus something else", in short you're needing "something else". Personally I dislike the code above a lot. The stream "looks" like if it would be an OutputStream, but in fact it isn't. You need to call getoutputbufferfree later to check if write succeeded (but OutputStream promises that write succeedes synchronous, blocking, or throws an exception). So it is not an OutputStream. No application written for OutputStreams would work without change (because it won't know getoutputbufferfree at all). It is not abstracted from ParallelPort. I think this would be wrong. Then I think an alternative interface instead is better. Let's assume we had some "connection" (to distinguish between OutputStreams and Channels). Then why not working as on a file handle in POSIX: do { // ... select maybe using timer ... readyForWrite = ... if (readyForWrite) { int writtenBytes = connection.write(toWrite); toWrite.remove(0, writtenBytes); } while(readyForWrite && toWrite.length > 0); I think, having such a write isn't the big problem. I think, the difficult thing is around "select" - however this would look like. It should be OO, typesafe, performant, supporting multiple connections/channels/streams in various modes and should be orthogonal to other functionalities. Of course, this heavily depends on what the application is doing; for a simple situation (like reading a small, mandatory file from a local disk) this would be to uncomfortable (and offering unneeded features only). just BTW :) oki, Steffen -- // Modeline for VIM. Please don't remove. // (Help: autoindent, expandtab, shiftwidth=4, tabstop=4, textwidth=75) // vi: set ai et sw=4 ts=4 tw=75 ft=java: About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Mon Jun 11 05:38:33 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 07:38:33 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611095618.GA10821@elberon.bln.de.ingenico.com> References: <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> Message-ID: <466D3439.4020805@gatworks.com> Steffen DETTMER wrote: > (but OutputStream promises that write > succeedes synchronous, blocking, or throws an exception). Where is it so written? From Steffen.DETTMER at ingenico.com Mon Jun 11 06:36:50 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 14:36:50 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466D3439.4020805@gatworks.com> References: <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> <466D3439.4020805@gatworks.com> Message-ID: <20070611123650.GI10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Mon, Jun 11, 2007 at 07:38 -0400: > Steffen DETTMER wrote: > > > (but OutputStream promises that write > > succeedes synchronous, blocking, or throws an exception). > > Where is it so written? Now, as you ask, I think it is not written that clearly but follows from specification. mmm... Am I wrong? I understand the API doc in this way: * http://java.sun.com/j2se/1.4.2/docs/api/java/io/OutputStream.html#write(byte[]) > public void write(byte[] b) > throws IOException > > Writes b.length bytes from the specified byte array to this > output stream. The general contract for write(b) is that > it should have exactly the same effect as the call write(b, > 0, b.length). > > Parameters: > b - the data. > Throws: > IOException - if an I/O error occurs. > See Also: > write(byte[], int, int) and there is: > public void write(byte[] b, > int off, > int len) > throws IOException > > Writes len bytes from the specified byte array starting at > offset off to this output stream. The general contract for > write(b, off, len) is that some of the bytes in the array b > are written to the output stream in order; element b[off] > is the first byte written and b[off+len-1] is the last byte > written by this operation. > > The write method of OutputStream calls the write method of > one argument on each of the bytes to be written out. > Subclasses are encouraged to override this method and > provide a more efficient implementation. > > If b is null, a NullPointerException is thrown. > > If off is negative, or len is negative, or off+len is > greater than the length of the array b, then an > IndexOutOfBoundsException is thrown. > > Parameters: > b - the data. > off - the start offset in the data. > len - the number of bytes to write. > Throws: > IOException - if an I/O error occurs. In particular, an > IOException is thrown if the output stream is closed. In general, any specialisation (derived child class) must comform to this. So write in the end is specified (!) as "The write method ... calls the write method ... on each of the bytes to be written out". This is what must be implemented by ANY OutputStream. Of course, there is: "Subclasses are encouraged to override this method and provide a more efficient implementation." which IMHO does not contradict - the more efficient must behave in exactly the same way of course (just wasting less resources than a simple byte-by-byte write). So it does not matter here I think. The write that finally defines the behavior tells basically: > "Writes the specified byte to this output stream. The general > contract for write is that one byte is written to the output > stream. " > > Throws: > IOException - if an I/O error occurs. which IMHO is another way of saying "write writes the byte immediately and returns on success (only), otherwise an exception is thrown". Especially it cannot happen that zero bytes are written (i.e. the specified byte is NOT written) without an exception. So by this write must be synchronous and blocking, because otherwise it could not reliably know if an asynchronous operation will succeede or not (some getAsyncResult or so would be needed). Since write(byte[]) does this for each byte (or with a behavior beeing exactly the same as if it would do), I think this means that the write(byte[]) succeedes synchronous/blocking or throws an exception. Did I an error in reasoning or confused something or so? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From j.kenneth.gentle at acm.org Mon Jun 11 06:51:25 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 11 Jun 2007 08:51:25 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611123650.GI10821@elberon.bln.de.ingenico.com> References: <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> <466D3439.4020805@gatworks.com> <20070611123650.GI10821@elberon.bln.de.ingenico.com> Message-ID: <200706111251.l5BCpS9T017831@qbang.org> It is as Steffen describes. "InputStream" and "OutputStream" are inherently synchronous (which is why so many java programs resort to threads to use them). Anything outside of this "contract" is *not* an InputStream or OutputStream. That is why there is a new package for things that don't behave like the old *Stream classes - the NIO package. If you look carefully at the IO package, you'll note that almost all the classes are _Decorator_ pattern implementations of the *Stream classes - and the interface presents the _same_ behavior to the calling code in all cases - a synchronous operation that completes successfully or throws an exception (with the one exception of "read" that returns a "-1" on end-of-stream. I know I've read this numerous times - I'd suggest checking the Language Spec or one of the books by Bloch or Gosling. Ken At 08:36 2007-06-11, you wrote: >* Uncle George wrote on Mon, Jun 11, 2007 at 07:38 -0400: > > Steffen DETTMER wrote: > > > > > (but OutputStream promises that write > > > succeedes synchronous, blocking, or throws an exception). > > > > Where is it so written? > >Now, as you ask, I think it is not written that clearly but >follows from specification. mmm... > >Am I wrong? > >I understand the API doc in this way: > >* >http://java.sun.com/j2se/1.4.2/docs/api/java/io/OutputStream.html#write(byte[]) > > public void write(byte[] b) > > throws IOException > > > > Writes b.length bytes from the specified byte array to this > > output stream. The general contract for write(b) is that > > it should have exactly the same effect as the call write(b, > > 0, b.length). > > > > Parameters: > > b - the data. > > Throws: > > IOException - if an I/O error occurs. > > See Also: > > write(byte[], int, int) > > >and there is: > > > > public void write(byte[] b, > > int off, > > int len) > > throws IOException > > > > Writes len bytes from the specified byte array starting at > > offset off to this output stream. The general contract for > > write(b, off, len) is that some of the bytes in the array b > > are written to the output stream in order; element b[off] > > is the first byte written and b[off+len-1] is the last byte > > written by this operation. > > > > The write method of OutputStream calls the write method of > > one argument on each of the bytes to be written out. > > Subclasses are encouraged to override this method and > > provide a more efficient implementation. > > > > If b is null, a NullPointerException is thrown. > > > > If off is negative, or len is negative, or off+len is > > greater than the length of the array b, then an > > IndexOutOfBoundsException is thrown. > > > > Parameters: > > b - the data. > > off - the start offset in the data. > > len - the number of bytes to write. > > Throws: > > IOException - if an I/O error occurs. In particular, an > > IOException is thrown if the output stream is closed. > > >In general, any specialisation (derived child class) must comform >to this. So write in the end is specified (!) as "The write >method ... calls the write method ... on each of the bytes to be >written out". This is what must be implemented by ANY >OutputStream. > >Of course, there is: "Subclasses are encouraged to override this >method and provide a more efficient implementation." which IMHO >does not contradict - the more efficient must behave in exactly >the same way of course (just wasting less resources than a simple >byte-by-byte write). So it does not matter here I think. > > > >The write that finally defines the behavior tells basically: > > > "Writes the specified byte to this output stream. The general > > contract for write is that one byte is written to the output > > stream. " > > > > Throws: > > IOException - if an I/O error occurs. > > >which IMHO is another way of saying "write writes the byte >immediately and returns on success (only), otherwise an exception >is thrown". Especially it cannot happen that zero bytes are >written (i.e. the specified byte is NOT written) without an >exception. So by this write must be synchronous and blocking, >because otherwise it could not reliably know if an asynchronous >operation will succeede or not (some getAsyncResult or so would >be needed). > >Since write(byte[]) does this for each byte (or with a behavior >beeing exactly the same as if it would do), I think this means >that the write(byte[]) succeedes synchronous/blocking or throws >an exception. > >Did I an error in reasoning or confused something or so? > >oki, > >Steffen > >About Ingenico Throughout the world businesses rely on Ingenico for >secure and expedient electronic transaction acceptance. Ingenico >products leverage proven technology, established standards and >unparalleled ergonomics to provide optimal reliability, versatility >and usability. This comprehensive range of products is complemented >by a global array of services and partnerships, enabling businesses >in a number of vertical sectors to accept transactions anywhere >their business takes them. >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. > >About Ingenico Throughout the world businesses rely on Ingenico for >secure and expedient electronic transaction acceptance. Ingenico >products leverage proven technology, established standards and >unparalleled ergonomics to provide optimal reliability, versatility >and usability. This comprehensive range of products is complemented >by a global array of services and partnerships, enabling businesses >in a number of vertical sectors to accept transactions anywhere >their business takes them. >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. > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From alesinskyy at googlemail.com Mon Jun 11 07:25:33 2007 From: alesinskyy at googlemail.com (Oleksandr Alesinskyy) Date: Mon, 11 Jun 2007 15:25:33 +0200 Subject: [Rxtx] [OT] select :-) Message-ID: Sorry, but I have to disagree with following statement: "So write in the end is specified (!) as "The write method ... calls the write method ... on each of the bytes to be written out". This is what must be implemented by ANY OutputStream.". This is not part of the specification or contract, it is just revealed implementation detail of the OutputStream. It is not stated anywhere that behavoiur of derived classes shall conform with this one. Statement concerning "synchronous" nature of the output stream is invalid as well. Really synchronous stream does not require flush() but OutputStream has it. From Steffen.DETTMER at ingenico.com Mon Jun 11 08:21:16 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 16:21:16 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: Message-ID: <20070611142116.GN10821@elberon.bln.de.ingenico.com> * Oleksandr Alesinskyy wrote on Mon, Jun 11, 2007 at 15:25 +0200: > Sorry, but I have to disagree with following statement: > "So write in the end is specified (!) as "The write > method ... calls the write method ... on each of the bytes to be > written out". This is what must be implemented by ANY > OutputStream.". > > This is not part of the specification or contract, it is just > revealed implementation detail of the OutputStream. It is not > stated anywhere that behavoiur of derived classes shall conform > with this one. (I didn't meant that the implementation must really write byte by byte, but that it must "look as if it would do" - because all implementations of OutputStream must "look" in the same way [which is another way of saying "do abstract" I think]) I think the API doc is not "revealing implementation details" but it is the *specification* of that interface and derivations must (should) conform to this specification. Isn't this the idea of interfaces? A function that expects an OutputStream should work on ANY OutputStream, shouldn't it? just kidding: I mean, what would be the point in implementing a checksum function as OutputStream.write which throws its result as IOException? Or which requires to call close() as very first operation to tell that the application is about to transmit confidential data? :-) > Statement concerning "synchronous" nature of the output stream > is invalid as well. Really synchronous stream does not require > flush() but OutputStream has it. ahh, interesting point! I think this is another bug in the API. flush() is wrong. Because write specifies "The general contract for write is that one byte is written to the output stream." but not "a byte may be written or buffered". Actually, an application would need to call flush() after each write (or bunch of write calls) to ensure that write really did something otherwise I think. I didn't found in the spec of OutputStream that it would be required to call flush(). This should mean that calling flush is not required which in turn leads to the conclusion that write must be synchrous (private threads are forbidden because not specified :)) which in turn leads to the conclusion that flush() is not needed at all... I mean, what if someone would only store in write and do the "real write" in flush() and never else? An application could write in one stream and read on another one (e.g. in bidirectional communication) and would never get anything back, because nothing was actually written because no flush was called? Then someone could even think that on error in some write the data could remain buffered AND throw an exception, retrying to send the data in the next write. Ohh, and if there would be some message number inside, and underlaying write (e.g. a protocol offering InputStream/OutputStream) would check this and throw "DuplicatedMessageNumber" the stream would only throw it again and again beeing unusable... In short: I have no clue how someone could be able to implement an asynchrounos write (which is realiable and correct) without beeing specific to anything which is not specified by OutputStream. Well, I think in the end OutputStream was not intended for such communication or protocol implementations - but to read a local disk file or so. In case of I/O errors usually you can abort your application and change the hard disk :-) oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Bob_Jacobsen at lbl.gov Mon Jun 11 09:32:23 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Mon, 11 Jun 2007 08:32:23 -0700 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611142116.GN10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> Message-ID: At 4:21 PM +0200 6/11/07, Steffen DETTMER wrote: > > Statement concerning "synchronous" nature of the output stream >> is invalid as well. Really synchronous stream does not require >> flush() but OutputStream has it. > >ahh, interesting point! > >I think this is another bug in the API. flush() is wrong. Because >write specifies "The general contract for write is that one byte >is written to the output stream." but not "a byte may be written >or buffered". > >Actually, an application would need to call flush() after each >write (or bunch of write calls) to ensure that write really did >something otherwise I think. OutputStreams don't _have_ to be synchronous or asynchronous, but the OutputStream API was be arranged so that subclasses _can_ be synchronous or asynchronous. Such generality is the hardest part of getting an API right. Hence, if at some point a program using an OutputStream wants to be sure that the data has been pushed all the way out, flush() is available. For some subclasses, e.g. the buffered ones, this has important behavior. Others write the data from each call, and flush() doesn't do anything. You _can_ omit it in programs that are known to use this second type, but there's no requirement that you do so; the interface is general in that way. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From Steffen.DETTMER at ingenico.com Mon Jun 11 12:32:39 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 20:32:39 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> Message-ID: <20070611183239.GT10821@elberon.bln.de.ingenico.com> * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: > >Actually, an application would need to call flush() after each > >write (or bunch of write calls) to ensure that write really did > >something otherwise I think. > OutputStreams don't _have_ to be synchronous or asynchronous, > but the OutputStream API was be arranged so that subclasses > _can_ be synchronous or asynchronous. Ahh, oki. Thanks for the clarificaion. So in short, flush() MUST be called on OutputStream, this is just not documented correctly or so clearly (right?). So the overall usage semantics would be: 1. call write (multiple times if desired) 2. call flush only if both succeeded, write was successful. If flush fails it remains unknown if a part of the data was written and/or will be repeated. So the spec (API doc) is wrong. Correct would be to tell that write behaves as told as long as it is followed by a call to flush, otherwise data may or may not get lost (depending wheter close() is called and calls flush(), which seems not to be guaranteed/required). BTW, I think it is a little bit... erm... interesting to find the specification (java API doc reference) wrong, having a need to conclude it from the presence of some methods with "it would make no sense if they behave exactly as specified, so specification must be wrong (incomplete)". > Such generality is the hardest part of getting an API right. Yes, seems to be proven ;) > Hence, if at some point a program using an OutputStream wants > to be sure that the data has been pushed all the way out, > flush() is available. For some subclasses, e.g. the buffered > ones, this has important behavior. Others write the data from > each call, and flush() doesn't do anything. > You _can_ omit it in programs that are known to use this second > type, but there's no requirement that you do so; the interface > is general in that way. I think, it still it must be called always, otherwise the application could break if passing a different runtime type as OutputStream. I think, if the application/method needs a special "type of OutputStream" then the parameter type must be a subclass but not OutputStream, maybe a PrintStream or so - otherwise the compiler could not detect this error (passing wrong type). Is this correct? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Bob_Jacobsen at lbl.gov Mon Jun 11 13:00:52 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Mon, 11 Jun 2007 12:00:52 -0700 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611183239.GT10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> Message-ID: At 8:32 PM +0200 6/11/07, Steffen DETTMER wrote: >So the spec (API doc) is wrong. Correct would be to tell that >write behaves as told as long as it is followed by a call to >flush, otherwise data may or may not get lost (depending wheter >close() is called and calls flush(), which seems not to be >guaranteed/required). I'm not entirely sure that the spec is wrong, but reasonable people can differ on this. In the 1.5 JavaDocs, all that the docs say for the write methods is that they write to the _output_ _stream_; there is no guarantee of anything beyond that. Only the flush method has any guarantee about the data, which is >Flushes this output stream and forces any buffered output bytes to >be written out. The general contract of flush is that calling it is >an indication that, if any bytes previously written have been >buffered by the implementation of the output stream, such bytes >should immediately be written to their intended destination. People commonly use various OutputStreams without using flush(), and it often works, but it's a bad practice and will eventually bite them. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From netbeans at gatworks.com Mon Jun 11 13:31:57 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 15:31:57 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611183239.GT10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> Message-ID: <466DA32D.1010602@gatworks.com> Steffen DETTMER wrote: > * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: >>> Actually, an application would need to call flush() after each >>> write (or bunch of write calls) to ensure that write really did >>> something otherwise I think. > >> OutputStreams don't _have_ to be synchronous or asynchronous, >> but the OutputStream API was be arranged so that subclasses >> _can_ be synchronous or asynchronous. > > Ahh, oki. Thanks for the clarificaion. > > So in short, flush() MUST be called on OutputStream, this is just > not documented correctly or so clearly (right?). No. Flush can be called to force all current data in java buffer's to be written to the kernel - NOW. A flush() can also *imply* that, besides writing out the buffer's that java employs, may also imply/ask the kernel to write all data thusfar written to the kernel, to be physically placed on the destination device - NOW. For some OS's there is no need to do a kernel flush(), as the I/O is synchronized already. Since this is java, you never know what OS your on. From tjarvi at qbang.org Mon Jun 11 19:28:27 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Jun 2007 19:28:27 -0600 (MDT) Subject: [Rxtx] [OT] select :-) In-Reply-To: <466DA32D.1010602@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: On Mon, 11 Jun 2007, Uncle George wrote: > Steffen DETTMER wrote: >> * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: >>>> Actually, an application would need to call flush() after each >>>> write (or bunch of write calls) to ensure that write really did >>>> something otherwise I think. >> >>> OutputStreams don't _have_ to be synchronous or asynchronous, >>> but the OutputStream API was be arranged so that subclasses >>> _can_ be synchronous or asynchronous. >> >> Ahh, oki. Thanks for the clarificaion. >> >> So in short, flush() MUST be called on OutputStream, this is just >> not documented correctly or so clearly (right?). > No. > Flush can be called to force all current data in java buffer's to be > written to the kernel - NOW. > > A flush() can also *imply* that, besides writing out the buffer's that > java employs, may also imply/ask the kernel to write all data thusfar > written to the kernel, to be physically placed on the destination device > - NOW. > For some OS's there is no need to do a kernel flush(), as the I/O is > synchronized already. Since this is java, you never know what OS your on. To add to the confusion, flush on the C side throws away data. drain makes sure it is written. Looking at the ParallelImp.c we can probably do better. /* we set a timeout because all calls are sequentiell (also with asynchron) this means that the default timeout of unlimited blocks all calls (also close and status request) if the device is down */ GetCommTimeouts( (HANDLE)fd, &timeouts ); timeouts.WriteTotalTimeoutMultiplier = 0; timeouts.WriteTotalTimeoutConstant = 2000; /* 2000 is the min value for the default Windows NT and Windows 2000 driver */ SetCommTimeouts( (HANDLE)fd, &timeouts ); while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } errorCount = 0; bytes += countWritten; count -= countWritten; } LPRPort has some timeout code that appears to be doing nothing but flipping bits back and forth right now. The commapi rxtx follows allows for timeout control from javax.comm.CommPort. The above is a solution that worked in one specific use case. With timeouts in place, the original 'old printer going offline' problem could be solved. That printer code isn't written in stone. In fact it was ajusted from being able to print 'asdf' to a daisy wheel printer to working for one person. BTW, I've finished teaching after hours tonight and will be moving forward with a new rxtx release in my free time. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Jun 11 21:28:04 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 23:28:04 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: <466E12C4.1010305@gatworks.com> > Looking at the ParallelImp.c we can probably do better. > The problem stemmed from the possibility that the writev routine could have written some of the buffer, in chunks, printer pauses, refuses any more chunks, and a timeout occurs. Do you or do you not cause an exception to be thrown? Is there a way to set timeout for a ParallelPort data output stream? I cant find it. From tjarvi at qbang.org Mon Jun 11 22:17:23 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Jun 2007 22:17:23 -0600 (MDT) Subject: [Rxtx] [OT] select :-) In-Reply-To: <466E12C4.1010305@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> <466E12C4.1010305@gatworks.com> Message-ID: On Mon, 11 Jun 2007, Uncle George wrote: >> Looking at the ParallelImp.c we can probably do better. >> > The problem stemmed from the possibility that the writev routine could > have written some of the buffer, in chunks, printer pauses, refuses any > more chunks, and a timeout occurs. Do you or do you not cause an > exception to be thrown? > > Is there a way to set timeout for a ParallelPort data output stream? I > cant find it. hmm I looked again after you asked. The timeouts are only controllable on the receive side. This comes from CommPort; the parent. So what we are talking about is some bytes in memory that rxtx has and is supposed to write. A buffer perhaps? The approach with rxtx in the past has been to ignore output buffer sizes. The assumption is that the library does not know how to best handle buffers. There are buffered output streams that can do buffering on top of rxtx for instance. There is also a question regarding what was actually ment when the API was put together. My suspicion is that it was put together while looking at one OS API and was never ment to be anything more than a hook into that API. The comments are fairly telling combined with reading the w32 API. So looking at the problem again.. The current timeout behavior appears fairly arbitrary. Presumably this is to prevent a program from hanging instead of using a helper thread to write - heavy handed for new programmers. Even so, I don't think the write should timeout at all if it is not configurable. >From the API perspective, "What Timeout?" -- Trent Jarvi tjarvi at qbang.org From Steffen.DETTMER at ingenico.com Tue Jun 12 02:14:48 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 12 Jun 2007 10:14:48 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466DA32D.1010602@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: <20070612081447.GU10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Mon, Jun 11, 2007 at 15:31 -0400: > Steffen DETTMER wrote: > > Ahh, oki. Thanks for the clarificaion. > > > > So in short, flush() MUST be called on OutputStream, this is just > > not documented correctly or so clearly (right?). > No. hum (though now I got it, but...). > Flush can be called to force all current data in java buffer's to be > written to the kernel - NOW. > > A flush() can also *imply* that, besides writing out the > buffer's that java employs, may also imply/ask the kernel to > write all data thusfar written to the kernel, to be physically > placed on the destination device - NOW. > > For some OS's there is no need to do a kernel flush(), as the I/O is > synchronized already. Since this is java, you never know what OS your on. (well, but if you're going to kernel level, even flush cannot guarantee that data will "be physically placed". Maybe you're flushing to a file via NFS (and the client "thinks" that it was written, but maybe it was just buffered by the NFS server) or so... but of course such exceptions of the rules are constructable always.) Well, you tell that depending on the OS it can be that flush is needed or it can be that flush is not needed (beacuse the I/O is synchronized already), right? Also, applications should work on any OS, which includes the OSes that do need flush. Since the application cannot know whether flush is needed or not because it doesn't know what the OS is doing, it has to call flush, hasn't it? I mean, if it would not call flush then it would not work on such OSes (except the written data would not be needed at all, but in this would be an artificial example :)). Since applications are supposed to work this would be wrong, wouldn't it? So would it be correct to say: "Applications, that should work under all OSes (including the OSes where the I/O is not synchronised already), have to call flush on OutputStream to ensure the data is transfered to the kernel." or is this wrong? If so, then I'm afraid I missed the point again :( oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Tue Jun 12 04:46:52 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 12 Jun 2007 06:46:52 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070612081447.GU10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> <20070612081447.GU10821@elberon.bln.de.ingenico.com> Message-ID: <466E799C.7060700@gatworks.com> S > (well, but if you're going to kernel level, even flush cannot > guarantee that data will "be physically placed". Thats true now-a-days because ( from "man 2 sync" ) : > According to the standard specification (e.g., SVID), sync() schedules > the writes, but may return before the actual writing is done. However, > since version 1.3.20 Linux does actually wait. (This still does not > guarantee data integrity: modern disks have large caches.) My disk drive has 8mb cache. Maybe you're > flushing to a file via NFS (and the client "thinks" that it was > written, but maybe it was just buffered by the NFS server) or > so... but of course such exceptions of the rules are > constructable always.) > > Well, you tell that depending on the OS it can be that flush is > needed or it can be that flush is not needed (beacuse the I/O is > synchronized already), right? Also, applications should work on > any OS, which includes the OSes that do need flush. Its not OS's that need flush, its applications that want to have some assurance that data is written to the device that really needs to use flush. If your program ( or thread ) dies then it is in your best interest to write out the critical data as soon as possible, as economical as possible. These are trade-off's that the application programmer makes. A big buffer may mean big loss of data, a small buffer may mean spending too much time writing out data. > > > So would it be correct to say: > > "Applications, that should work under all OSes (including the > OSes where the I/O is not synchronised already), have to call > flush on OutputStream to ensure the data is transfered to the > kernel." > > or is this wrong? If so, then I'm afraid I missed the point again > :( > No that is not wrong. Ensuring that data is transfered to the OS is just about what any application can do. From tjarvi at qbang.org Thu Jun 14 08:16:47 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 14 Jun 2007 08:16:47 -0600 (MDT) Subject: [Rxtx] rxtx and usb-serial solution In-Reply-To: References: Message-ID: On Thu, 14 Jun 2007, Vladimir Kirtchev wrote: > Hi Trent, > > I develop a Java application which communicates with devices which have > USB-to-Serial bridge in them. The target OS is Linux. So for this purpose I > use RXTX. > > But I encountered a strange problem - when reading from the InputStream, I > receive series of zeros. I have this problem under Linux only. Under Windows > it is fine. > Actually this problem is the same as the one described here: > http://marc.info/?l=rxtx&m=109703190731748&w=2. > > > So I searched for the problem in the native code. And found that the root of > the problem is in SerialImp.c, > int configure_port( int fd ) > { > ... > ttyset.c_iflag = INPCK; > ... > } > > This line enables input parity checking, and the data sent from the device > is processed by the OS driver before being read with read(). > In this case the driver detects some problem and sets the received bytes to > zero. > > On the other hand in the Java part a set the serial port parameters with > SerialPort.PARITY_NONE. According to me, except all other things, this > should also disable INPCK in c_iflag. > > So I refactored the method translate_parity(...) to the following: > > int translate_parity( JNIEnv *env, struct termios *ttyset, jint parity ) > { > ENTER( "translate_parity" ); > #ifdef CMSPAR > ttyset->c_cflag &= ~(PARENB | PARODD | CMSPAR ); > #endif /* CMSPAR */ > switch( parity ) { > case JPARITY_NONE: > ttyset->c_iflag &= ~INPCK; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_EVEN: > ttyset->c_cflag |= PARENB; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_ODD: > ttyset->c_cflag |= PARENB | PARODD; > LEAVE( "translate_parity" ); > return 0; > #ifdef CMSPAR > case JPARITY_MARK: > ttyset->c_cflag |= PARENB | PARODD | CMSPAR; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_SPACE: > ttyset->c_cflag |= PARENB | CMSPAR; > LEAVE( "translate_parity" ); > return 0; > #endif /* CMSPAR */ > default: > printf("Parity missed %i\n", (int) parity ); > } > > LEAVE( "translate_parity" ); > /* > For some reason the native exceptions are not being caught. Moving this > to the Java side fixed the issue. taj. > throw_java_exception( env, UNSUPPORTED_COMM_OPERATION, > "", "parity value not supported" ); > */ > return 1; > } > > This modification solved the problem and now it works correctly under Linux. > > I think I will be a nice if this is idea is included in a future release of > RXTX. > > Thanks Vadim, I'll try that out. Forwarding to the rxtx mail-list too. This is probably not going to help USB drivers on windows which I'm sure some are looking for. As far as I can tell, windows USB bluetooth and serial dongles are limited by driver functionality. Some are good and others lack key features. -- Trent Jarvi tjarvi at qbang.org From dan.sandberg.lists at gmail.com Mon Jun 18 14:43:39 2007 From: dan.sandberg.lists at gmail.com (Dan Sandberg) Date: Mon, 18 Jun 2007 13:43:39 -0700 Subject: [Rxtx] Fix for JNI Get/Set Field Errors Message-ID: <4676EE7B.7060800@gmail.com> Hi, I've fixed the problems that cause the following JNI error when extra JNI checking ( -Xjni:check ) is turned on. FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) The problem was basically that GetLong was being used to get ints, and SetInt was used for longs. The patch below fixes this. Please let me know if there are any questions / problems. Cheers, -Dan diff -aur old/SerialImp.c src/SerialImp.c --- old/SerialImp.c 2007-06-18 13:24:33.000000000 -0700 +++ src/SerialImp.c 2007-06-18 06:26:26.000000000 -0700 @@ -1337,7 +1337,7 @@ report("init_threads: get eis\n"); jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); report("init_threads: set eis\n"); - (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); + (*eis->env)->SetLongField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); report("init_threads: stop\n"); report_time_end( ); return( 1 ); @@ -1530,7 +1530,7 @@ jobject jobj, jboolean interrupted ) { int fd = get_java_var( env, jobj,"fd","I" ); - struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var( env, jobj, "eis", "J" ); + struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var_long( env, jobj, "eis", "J" ); int result, count=0; char message[80]; @@ -2939,7 +2939,7 @@ /* TRENT */ int flag, count = 0; struct event_info_struct *eis = ( struct event_info_struct * ) - get_java_var( env, *jobj,"eis","J" ); + get_java_var_long( env, *jobj,"eis","J" ); report_time_start(); flag = eis->eventflags[SPE_DATA_AVAILABLE]; @@ -4873,9 +4873,9 @@ exceptions: none comments: ----------------------------------------------------------*/ -size_t get_java_var( JNIEnv *env, jobject jobj, char *id, char *type ) +long get_java_var_long( JNIEnv *env, jobject jobj, char *id, char *type ) { - int result = 0; + long result = 0; jclass jclazz = (*env)->GetObjectClass( env, jobj ); jfieldID jfd = (*env)->GetFieldID( env, jclazz, id, type ); @@ -4889,7 +4889,11 @@ LEAVE( "get_java_var" ); return result; } - result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); + if ( !strcmp( type, "J" ) ) { + result = (long)( (*env)->GetLongField( env, jobj, jfd ) ); + } else { + result = (int) ( (*env)->GetIntField( env, jobj, jfd ) ); + } /* ct7 & gel * Added DeleteLocalRef */ (*env)->DeleteLocalRef( env, jclazz ); if(!strncmp( "fd",id,2) && result == 0) @@ -4900,6 +4904,10 @@ return result; } +int get_java_var( JNIEnv *env, jobject jobj, char *id, char *type ) { + return (int) get_java_var_long( env, jobj, id, type ); +} + /*---------------------------------------------------------- throw_java_exception diff -aur old/SerialImp.h src/SerialImp.h --- old/SerialImp.h 2007-06-18 13:24:39.000000000 -0700 +++ src/SerialImp.h 2007-06-18 06:23:43.000000000 -0700 @@ -413,7 +413,8 @@ void system_wait(); void finalize_event_info_struct( struct event_info_struct * ); int read_byte_array( JNIEnv *, jobject *, int, unsigned char *, int, int ); -size_t get_java_var( JNIEnv *, jobject, char *, char * ); +int get_java_var( JNIEnv *, jobject, char *, char * ); +long get_java_var_long( JNIEnv *, jobject, char *, char * ); jboolean is_interrupted( struct event_info_struct * ); int send_event(struct event_info_struct *, jint, int ); void dump_termios(char *,struct termios *); From yvespielusenet at free.fr Tue Jun 26 03:41:58 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 11:41:58 +0200 Subject: [Rxtx] [PARALLEL] resource in use Message-ID: <1182850918.3483.10.camel@localhost.localdomain> Hello, So now I want to modify the timeout of the library for parallel port. I have downloaded source code. There is a makefile for migw. SO I have installed mingw on ubuntu and modified the makefile.mingw32 to set it for my system. I have no error but some warnings. The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But When I want to use it the jvm crash :( How can I know what is wrong ? How rxtx windows release has been done ? thanks -- yves piel From yvespielusenet at free.fr Tue Jun 26 07:17:02 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 15:17:02 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182850918.3483.10.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> Message-ID: <1182863822.3483.17.camel@localhost.localdomain> Here is the Makefile I use, the output of the 'make' and the log of the jvm when it crashed : - The Makefile : http://yvespiel.free.fr/rxtx/Makefile - The make output : http://yvespiel.free.fr/rxtx/compile.txt - The crash log : http://yvespiel.free.fr/rxtx/hs_err_pid2100.log I have compiled rxtx under Debian testing with mingw : narma at linimi:/tmp/err$ dpkg -l | grep mingw ii mingw32 3.4.5.20060117.1.dfsg-3 ii mingw32-binutils 2.17.50-20070129.1-1 ii mingw32-runtime 3.12-1 thanks fort help :) Le mardi 26 juin 2007 ? 11:41 +0200, yves pielusenet a ?crit : > Hello, > So now I want to modify the timeout of the library for parallel port. I > have downloaded source code. There is a makefile for migw. SO I have > installed mingw on ubuntu and modified the makefile.mingw32 to set it > for my system. > I have no error but some warnings. > The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But > When I want to use it the jvm crash :( > > How can I know what is wrong ? > > How rxtx windows release has been done ? > > thanks > From yvespielusenet at free.fr Tue Jun 26 07:40:11 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 15:40:11 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182863822.3483.17.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> <1182863822.3483.17.camel@localhost.localdomain> Message-ID: <1182865211.3483.21.camel@localhost.localdomain> I have add the options '--enable-stdcall-fixup' to the 'i586-mingw32msvc-ld' commande. Now I have no warning. But the JVM always crashes :( The output seems more detailled, but I don't understand anything... Here is files : http://yvespiel.free.fr/rxtx/2/ -- yves piel Le mardi 26 juin 2007 ? 15:17 +0200, yves pielusenet a ?crit : > Here is the Makefile I use, the output of the 'make' and the log of the > jvm when it crashed : > > - The Makefile : http://yvespiel.free.fr/rxtx/Makefile > - The make output : http://yvespiel.free.fr/rxtx/compile.txt > - The crash log : http://yvespiel.free.fr/rxtx/hs_err_pid2100.log > > I have compiled rxtx under Debian testing with mingw : > narma at linimi:/tmp/err$ dpkg -l | grep mingw > ii mingw32 3.4.5.20060117.1.dfsg-3 > ii mingw32-binutils 2.17.50-20070129.1-1 > ii mingw32-runtime 3.12-1 > > thanks fort help :) > > > Le mardi 26 juin 2007 ? 11:41 +0200, yves pielusenet a ?crit : > > Hello, > > So now I want to modify the timeout of the library for parallel port. I > > have downloaded source code. There is a makefile for migw. SO I have > > installed mingw on ubuntu and modified the makefile.mingw32 to set it > > for my system. > > I have no error but some warnings. > > The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But > > When I want to use it the jvm crash :( > > > > How can I know what is wrong ? > > > > How rxtx windows release has been done ? > > > > thanks > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From yvespielusenet at free.fr Tue Jun 26 08:27:42 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 16:27:42 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182865211.3483.21.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> <1182863822.3483.17.camel@localhost.localdomain> <1182865211.3483.21.camel@localhost.localdomain> Message-ID: <1182868062.3483.24.camel@localhost.localdomain> I think thant the include files of jdk were not for windows but for linux. So I have copied include/ folder from windows to linux and I modified the Makefile to use those file. It compile fine but the JVM always crash :( http://yvespiel.free.fr/rxtx/3/ Le mardi 26 juin 2007 ? 15:40 +0200, yves pielusenet a ?crit : > I have add the options '--enable-stdcall-fixup' to the > 'i586-mingw32msvc-ld' commande. Now I have no warning. But the JVM > always crashes :( The output seems more detailled, but I don't > understand anything... > Here is files : > http://yvespiel.free.fr/rxtx/2/ > From netbeans at gatworks.com Fri Jun 1 05:38:50 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 07:38:50 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <465F7ADD.1010501@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> Message-ID: <4660054A.2040202@gatworks.com> Manuel Naranjo wrote: In the case of my module, you can > unplug the device but it will not delete the symlink until those apps > that had opened the port has closed it. This is done this way to avoid > kernel panics. What does this mean to user code ? I have tried the alternate route ( other than closing ) which is sleep inbetween the I/O errors ( an unplugged USB device). When the device is plugged back in, The writes to the device still get an I/O error. This would seem to be a lost cause for the application. From netbeans at gatworks.com Fri Jun 1 06:35:48 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 08:35:48 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <465F7ADD.1010501@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> Message-ID: <466012A4.90608@gatworks.com> Manuel Naranjo wrote: In the case of my module, you can > unplug the device but it will not delete the symlink until those apps > that had opened the port has closed it. T Did u also mean for this to happen? USB0 was not closed by application. Apparently USB1 got created when USB device was plugged back in. There is only one USB device on a 4 port USB hub. This also seems to suggest that application recovery to be impossible. > Jun 1 07:10:08 mylaptop kernel: garmin_gps 1-1.4:1.0: Garmin GPS usb/tty converter detected > Jun 1 07:10:08 mylaptop kernel: usb 1-1.4: Garmin GPS usb/tty converter now attached to ttyUSB0 > Jun 1 07:15:17 mylaptop kernel: usb 1-1: USB disconnect, address 4 > Jun 1 07:15:17 mylaptop kernel: usb 1-1.4: USB disconnect, address 5 > Jun 1 07:15:17 mylaptop kernel: garmin_gps 1-1.4:1.0: device disconnected > Jun 1 07:15:26 mylaptop kernel: usb 1-1: new full speed USB device using uhci_hcd and address 6 > Jun 1 07:15:26 mylaptop kernel: hub 1-1:1.0: USB hub found > Jun 1 07:15:26 mylaptop kernel: hub 1-1:1.0: 4 ports detected > Jun 1 07:15:27 mylaptop kernel: usb 1-1.4: new full speed USB device using uhci_hcd and address 7 > Jun 1 07:15:27 mylaptop kernel: garmin_gps 1-1.4:1.0: Garmin GPS usb/tty converter detected > Jun 1 07:15:27 mylaptop kernel: usb 1-1.4: Garmin GPS usb/tty converter now attached to ttyUSB1 From naranjo.manuel at gmail.com Fri Jun 1 09:17:22 2007 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Fri, 01 Jun 2007 12:17:22 -0300 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <466012A4.90608@gatworks.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> <466012A4.90608@gatworks.com> Message-ID: <46603882.5050701@gmail.com> Uncle George escribi?: > Manuel Naranjo wrote: > In the case of my module, you can > >> unplug the device but it will not delete the symlink until those apps >> that had opened the port has closed it. T >> > > Did u also mean for this to happen? USB0 was not closed by application. > > Apparently USB1 got created when USB device was plugged back in. There > is only one USB device on a 4 port USB hub. > > This also seems to suggest that application recovery to be impossible. > Exactly there's a dead symlink (you can read and write to it and nothing will happen) and a new port will be created when a new device is connencted. From netbeans at gatworks.com Fri Jun 1 10:20:46 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 12:20:46 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <46603882.5050701@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> <466012A4.90608@gatworks.com> <46603882.5050701@gmail.com> Message-ID: <4660475E.5090202@gatworks.com> Not sure what u mean by "symlink". U cant read/write to it anymore. U get I/O error. In this scenario the device effectively went dead, and only solution is to close the channel. reconnecting the USB device, although dead, but not closed, will create a second device. This does not seem to be a desirable side-effect. The user will now have ttyUSB1, wondering where did ttyUSB0 go to. The application will also be in a confused state, as well as RXTX, because RXTX wont know about ttyUSB1. Manuel Naranjo wrote: > Uncle George escribi?: >> Manuel Naranjo wrote: >> In the case of my module, you can >> >>> unplug the device but it will not delete the symlink until those apps >>> that had opened the port has closed it. T >>> >> Did u also mean for this to happen? USB0 was not closed by application. >> >> Apparently USB1 got created when USB device was plugged back in. There >> is only one USB device on a 4 port USB hub. >> >> This also seems to suggest that application recovery to be impossible. >> > Exactly there's a dead symlink (you can read and write to it and nothing > will happen) and a new port will be created when a new device is connencted. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From arnab.bhaumik at gmail.com Mon Jun 4 01:40:16 2007 From: arnab.bhaumik at gmail.com (arnab bhaumik) Date: Mon, 4 Jun 2007 13:10:16 +0530 Subject: [Rxtx] full duplex com port with rxtx Message-ID: hi , till now i did half duplex communication with rxtx package on com package. my question is : is it possible to use com port with full duplex mode with rxtx package . ther is example of SimpleRead class and SimpleWrite class. it is clear that if i can use both the class simultaneously then full duplex is possible......... arnab/vu2bpw -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070604/6edb0453/attachment-0003.html From lists at iDIAcomputing.com Mon Jun 4 07:53:17 2007 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Mon, 04 Jun 2007 09:53:17 -0400 Subject: [Rxtx] full duplex com port with rxtx In-Reply-To: References: Message-ID: <4664194D.90301@iDIAcomputing.com> arnab bhaumik wrote: > hi , > > till now i did half duplex communication with rxtx package on com > package. > > my question is : is it possible to use com port with full duplex mode > with rxtx package . > > > ther is example of SimpleRead class and SimpleWrite class. it is > clear that if i can use both the class simultaneously then full duplex > is possible......... I haven't looked at the SimpleRead and SimpleWrite classes (I originally wrote my code for the javax.comm api), but full duplex is certainly possible. My CommReader class requires an object analogous to a OutputStream or Writer. When started, it spawns a thread that reads the comm port and writes to that output device. In this way the input is asynchronous and dependent on the actual input data. For full duplex, I extend that class with CommReaderWriter, which adds synchronous output methods. Hope that helps, George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From supsoop at hotmail.com Mon Jun 4 15:21:06 2007 From: supsoop at hotmail.com (soop soop) Date: Mon, 04 Jun 2007 21:21:06 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- Message-ID: Hi Guys, Looked through the archives but still cannot figure this out. I have a Motorola G24 GPRS/GSM modem that I am connecting to my server running Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not detecting the port, CommPortIdentifier.getPortIdentifiers(). I have added the line to RXTXCommDriver: "ttyACM" // for USB Modems Rxtx still does not seem to find the port. Is there something I am missing to make this port visable? [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control Model driver for USB modems and ISDN adapters I really need your help as I have moved my server from windows to Linux and have been down for a few days because of this .. Thanks so much! _________________________________________________________________ PC Magazine’s 2007 editors’ choice for best Web mail—award-winning Windows Live Hotmail. http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 From tjarvi at qbang.org Mon Jun 4 16:17:35 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Jun 2007 16:17:35 -0600 (MDT) Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: On Mon, 4 Jun 2007, soop soop wrote: > Hi Guys, > > Looked through the archives but still cannot figure this out. I have a > Motorola G24 GPRS/GSM modem that I am connecting to my server running Ubuntu. > I can see my modem as is shows up as ttyACM0, but RXTX is not detecting the > port, CommPortIdentifier.getPortIdentifiers(). > > I have added the line to RXTXCommDriver: > > "ttyACM" // for USB Modems > > Rxtx still does not seem to find the port. Is there something I am missing to > make this port visable? > > [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver > [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device > [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control Model > driver for USB modems and ISDN adapters > > I really need your help as I have moved my server from windows to Linux and > have been down for a few days because of this .. Thanks so much! > You could try the INSTALL documentation that comes with the source for possible solutions. Those usually involve lockfile creation, permissions on the device file or the device is in use by another application (even another session of your application). The usual commands: ls -l /dev/ttyACM0 fuser /dev/ttyACM0 touch /var/lock/LCK.testfile && rm -f /var/lock/LCK.testfile whoami To disable lockfiles: ../configure --disable-lockfiles && make install -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Jun 4 16:22:52 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 04 Jun 2007 18:22:52 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <466490BC.3090801@gatworks.com> soop soop wrote: > I really need your help as I have moved my server from windows to Linux > and have been down for a few days because of this .. Thanks so much! can u open the device ? ie is the file protection/permissions keeping you out? From supsoop at hotmail.com Mon Jun 4 16:44:40 2007 From: supsoop at hotmail.com (soop soop) Date: Mon, 04 Jun 2007 22:44:40 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <466490BC.3090801@gatworks.com> Message-ID: Thanks for the reply, I see no exceptions being thrown, just no detection of the port whats so ever. I will run rxtx in debug mode and log. If this were a permissions issue would I not see some exceptions being thrown? >From: Uncle George >Reply-To: RXTX Developers and Users >To: RXTX Developers and Users >Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >Date: Mon, 04 Jun 2007 18:22:52 -0400 > >soop soop wrote: > > > I really need your help as I have moved my server from windows to Linux > > and have been down for a few days because of this .. Thanks so much! > >can u open the device ? ie is the file protection/permissions keeping >you out? >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ Get a preview of Live Earth, the hottest event this summer - only on MSN http://liveearth.msn.com?source=msntaglineliveearthhm From netbeans at gatworks.com Mon Jun 4 17:06:15 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 04 Jun 2007 19:06:15 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <46649AE7.10405@gatworks.com> Exceptions on what? On startup it wants to lookup all devices in /dev that it is capable of opening ( within the list of specific 'comm' devices ). If it cannot open, then does not get onto list. Part of this process, if configured, will also test if the "LOCK" schema can also be opened for the device. then it gets on the list of avail comm port. soop soop wrote: > Thanks for the reply, > > I see no exceptions being thrown, just no detection of the port whats so > ever. I will run rxtx in debug mode and log. If this were a permissions > issue would I not see some exceptions being thrown? > > >> From: Uncle George >> Reply-To: RXTX Developers and Users >> To: RXTX Developers and Users >> Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >> Date: Mon, 04 Jun 2007 18:22:52 -0400 >> >> soop soop wrote: >> >>> I really need your help as I have moved my server from windows to Linux >>> and have been down for a few days because of this .. Thanks so much! >> can u open the device ? ie is the file protection/permissions keeping >> you out? >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _________________________________________________________________ > Get a preview of Live Earth, the hottest event this summer - only on MSN > http://liveearth.msn.com?source=msntaglineliveearthhm > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From alex.flint at gmail.com Mon Jun 4 21:31:49 2007 From: alex.flint at gmail.com (Alex Flint) Date: Tue, 5 Jun 2007 13:01:49 +0930 Subject: [Rxtx] random EXCEPTION_ACCESS_VIOLATION errors Message-ID: Hi All, I'm running winXP and RXTX 2.1-7r2 (the latest from the webpage as of June 2007). I'm sending sequences of 64 lines (each line has about 15 chars) at various intervals. The strings are sent fine, until I get the following error (from hs_err_pid3316.log, at the end of this email). What can I do to avoid the error? Obviously this is a low-level memory exception, but is there any way I can keep the JVM running after such an error? I noticed the exact same problem here: http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20070129/1180520.html Cheers, Alex # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x100034fb, pid=3316, tid=2400 # # Java VM: Java HotSpot(TM) Client VM (1.6.0_01-b06 mixed mode, sharing) # Problematic frame: # C [rxtxSerial.dll+0x34fb] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # --------------- T H R E A D --------------- Current thread (0x00386400): JavaThread "main" [_thread_in_native, id=2400] siginfo: ExceptionCode=0xc0000005, reading address 0x20726f78 Registers: EAX=0x20726f20, EBX=0x6d8922c0, ECX=0x00000005, EDX=0x20726f20 ESP=0x003efa30, EBP=0x003efb68, ESI=0x269728a0, EDI=0x00386400 EIP=0x100034fb, EFLAGS=0x00010212 Top of Stack: (sp=0x003efa30) 0x003efa30: 003efa3c 003efa64 0000000f ffffffff 0x003efa40: 003efa40 2a97f808 003efa6c 2b190ca8 0x003efa50: 00000000 2b190ec0 003efa90 008e2dd7 0x003efa60: 003efa90 008e2dd7 26977f88 6d815e72 0x003efa70: 00000004 2696eae0 0000008a 003efb0c 0x003efa80: 6d852b4a 2696eae0 00000003 26970930 0x003efa90: 000000cb 2696eae0 6d86b264 00385d40 0x003efaa0: 0000003f 003efb0c 26977f90 2ace65d8 Instructions: (pc=0x100034fb) 0x100034eb: ff ff 8d 76 00 eb 02 89 f6 90 8b 45 f8 8b 55 f8 0x100034fb: 8b 4a 58 83 c9 04 89 48 58 83 c4 f8 8b 45 f8 8b Stack: [0x003a0000,0x003f0000), sp=0x003efa30, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x34fb] Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j gnu.io.RXTXPort.writeArray([BIIZ)V+0 j gnu.io.RXTXPort$SerialOutputStream.write([B)V+76 j com.bjt.media.server.CommLink.send(Ljava/lang/String;)V+48 j com.bjt.media.server.DigitoolConnection.select(I)V+73 j com.bjt.media.server.DigitoolConnection.main([Ljava/lang/String;)V+74 v ~StubRoutines::call_stub --------------- P R O C E S S --------------- Java Threads: ( => current thread ) 0x02a69400 JavaThread "Thread-0" [_thread_in_native, id=3052] 0x02a4d000 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=3920] 0x02a48400 JavaThread "CompilerThread0" daemon [_thread_blocked, id=1968] 0x02a47400 JavaThread "Attach Listener" daemon [_thread_blocked, id=2984] 0x02a46400 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=2660] 0x02a41c00 JavaThread "Finalizer" daemon [_thread_blocked, id=3924] 0x02a3d800 JavaThread "Reference Handler" daemon [_thread_blocked, id=4008] =>0x00386400 JavaThread "main" [_thread_in_native, id=2400] Other Threads: 0x02a34400 VMThread [id=3708] 0x02a4e800 WatcherThread [id=3964] VM state:not at safepoint (normal execution) VM Mutex/Monitor currently owned by a thread: None Heap def new generation total 960K, used 131K [0x22960000, 0x22a60000, 0x22e40000) eden space 896K, 7% used [0x22960000, 0x22970ea8, 0x22a40000) from space 64K, 99% used [0x22a50000, 0x22a5fff8, 0x22a60000) to space 64K, 0% used [0x22a40000, 0x22a40000, 0x22a50000) tenured generation total 4096K, used 76K [0x22e40000, 0x23240000, 0x26960000) the space 4096K, 1% used [0x22e40000, 0x22e53060, 0x22e53200, 0x23240000) compacting perm gen total 12288K, used 137K [0x26960000, 0x27560000, 0x2a960000) the space 12288K, 1% used [0x26960000, 0x26982518, 0x26982600, 0x27560000) ro space 8192K, 62% used [0x2a960000, 0x2ae5e4e8, 0x2ae5e600, 0x2b160000) rw space 12288K, 52% used [0x2b160000, 0x2b7a0e78, 0x2b7a1000, 0x2bd60000) Dynamic libraries: 0x00400000 - 0x00423000 C:\Program Files\Java\jre1.6.0_01\bin\javaw.exe 0x7c900000 - 0x7c9b0000 C:\WINDOWS\system32\ntdll.dll 0x7c800000 - 0x7c8f4000 C:\WINDOWS\system32\kernel32.dll 0x77dd0000 - 0x77e6b000 C:\WINDOWS\system32\ADVAPI32.dll 0x77e70000 - 0x77f01000 C:\WINDOWS\system32\RPCRT4.dll 0x7e410000 - 0x7e4a0000 C:\WINDOWS\system32\USER32.dll 0x77f10000 - 0x77f57000 C:\WINDOWS\system32\GDI32.dll 0x76390000 - 0x763ad000 C:\WINDOWS\system32\IMM32.DLL 0x7c340000 - 0x7c396000 C:\Program Files\Java\jre1.6.0_01\bin\msvcr71.dll 0x6d7c0000 - 0x6da07000 C:\Program Files\Java\jre1.6.0_01\bin\client\jvm.dll 0x76b40000 - 0x76b6d000 C:\WINDOWS\system32\WINMM.dll 0x5cd70000 - 0x5cd77000 C:\WINDOWS\system32\serwvdrv.dll 0x5b0a0000 - 0x5b0a7000 C:\WINDOWS\system32\umdmxfrm.dll 0x6d310000 - 0x6d318000 C:\Program Files\Java\jre1.6.0_01\bin\hpi.dll 0x76bf0000 - 0x76bfb000 C:\WINDOWS\system32\PSAPI.DLL 0x6d770000 - 0x6d77c000 C:\Program Files\Java\jre1.6.0_01\bin\verify.dll 0x6d3b0000 - 0x6d3cf000 C:\Program Files\Java\jre1.6.0_01\bin\java.dll 0x6d7b0000 - 0x6d7bf000 C:\Program Files\Java\jre1.6.0_01\bin\zip.dll 0x10000000 - 0x10012000 C:\Documents and Settings\Alex\workspace\MediaServer\rxtxSerial.dll 0x73d90000 - 0x73db7000 C:\WINDOWS\system32\crtdll.dll VM Arguments: jvm_args: -Djava.library.path=C:\Documents and Settings\Alex\workspace\MediaServer java_command: com.bjt.media.server.DigitoolConnection Launcher Type: SUN_STANDARD Environment Variables: CLASSPATH=.;C:\Program Files\Java\j2re1.4.2_07\lib\ext\QTJava.zip PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\wbem;c:\applications\php;C:\Program Files\MATLAB\R2006a\bin\win32;C:\Roger\Projects\UAV\Bin\Debug;C:\Program Files\Microsoft SQL Server\80\Tools\Binn\;c:\Program Files\Microsoft SQL Server\90\Tools\binn\;C:\Program Files\QuickTime\QTSystem\;C:\Pfps\system;C:\Program Files\Java\jdk1.6.0_01\bin;C:\Program Files\Java\jdk1.6.0_01\jre\bin USERNAME=Alex OS=Windows_NT PROCESSOR_IDENTIFIER=x86 Family 15 Model 4 Stepping 1, GenuineIntel --------------- S Y S T E M --------------- OS: Windows XP Build 2600 Service Pack 2 CPU:total 1 family 15, cmov, cx8, fxsr, mmx, sse, sse2 Memory: 4k page, physical 1046508k(275288k free), swap 2522816k(1909176k free) vm_info: Java HotSpot(TM) Client VM (1.6.0_01-b06) for windows-x86, built on Mar 14 2007 00:24:02 by "java_re" with unknown MS VC++:1310 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070604/c87ae1f0/attachment-0003.html From alwyn.schoeman at gmail.com Tue Jun 5 00:10:19 2007 From: alwyn.schoeman at gmail.com (Alwyn Schoeman) Date: Tue, 5 Jun 2007 08:10:19 +0200 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Hi, I'm using a similar modem. By default rxtx doesn't look for devices that start with ACM, so you need to modify the source code and recompile. Look in RXTXCommDriver and add values for ACM in the registerScannedPorts method in the Linux specific parts. Look for osName.equals("Linux")... On 6/4/07, soop soop wrote: > > Hi Guys, > > Looked through the archives but still cannot figure this out. I have a > Motorola G24 GPRS/GSM modem that I am connecting to my server running > Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not > detecting the port, CommPortIdentifier.getPortIdentifiers(). > > I have added the line to RXTXCommDriver: > > "ttyACM" // for USB Modems > > Rxtx still does not seem to find the port. Is there something I am missing > to make this port visable? > > [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver > [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device > [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control > Model > driver for USB modems and ISDN adapters > > I really need your help as I have moved my server from windows to Linux > and > have been down for a few days because of this .. Thanks so much! > > _________________________________________________________________ > PC Magazine's 2007 editors' choice for best Web mail?award-winning Windows > Live Hotmail. > > http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -- Alwyn Schoeman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/b6cb3053/attachment-0003.html From naranjo.manuel at gmail.com Tue Jun 5 06:48:45 2007 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Tue, 05 Jun 2007 09:48:45 -0300 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> References: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Message-ID: <46655BAD.7010501@gmail.com> That's right, an easier solution is creating symlinks to acm. For example make ttyS70 to 79 point to ACM0 to 9 and that will help you a lot, and doesn't even require compile. > Hi, > > I'm using a similar modem. By default rxtx doesn't look for devices > that start with ACM, so you need to modify the > source code and recompile. > > Look in RXTXCommDriver and add values for ACM in the > registerScannedPorts method in the Linux specific parts. Look for > osName.equals("Linux")... > From juanemc2 at gmail.com Tue Jun 5 07:02:43 2007 From: juanemc2 at gmail.com (Juan) Date: Tue, 5 Jun 2007 10:02:43 -0300 Subject: [Rxtx] Problems with Epson TMU220B POSPrinter using XON/XOFF Flow Control and rxtx jar and dll's with the serial port. Message-ID: Hi!, I?m having trouble printing to the serial port using the latest version of rxtx jar and dll's with an Epson POSPrinter. I`ve switched the printer to work with XON/XOFF Flow Control and have watched the serial port to be sure the printer is sending the XON XOFF stop and go characters. I`ve setted the port like this: CommPortIdentifier commPortIdentifier = CommPortIdentifier.* getPortIdentifier*(_portName); SerialPort serialPort = (SerialPort)commPortIdentifier.open(*this*.getClass().getName(), 2000); serialPort.setSerialPortParams(_baudRate, _dataBits, _stopBits, _parity); serialPort.setFlowControlMode( SerialPort.*FLOWCONTROL_XONXOFF_IN* | SerialPort.*FLOWCONTROL_XONXOFF_OUT*); where the baudRate is 9600 the dataBits is 8 the stopBits is 1 and the parity is 0 It seems as the library isn`t taking into account the XON XOFF setting. I would like to know if I`m setting correctly the Flow Control and if you had had any experiences using XON XOFF flow control and could give me some help to solve my problem. I`m very thankful in advance, Yours, Juan Polero -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/b080995a/attachment-0003.html From ehdez.correo at gmail.com Tue Jun 5 07:12:53 2007 From: ehdez.correo at gmail.com (=?ISO-8859-1?Q?Enrique_Hern=E1ndez?=) Date: Tue, 5 Jun 2007 09:12:53 -0400 Subject: [Rxtx] problem with rxtx Message-ID: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Hello: I doing a simple test to show the serial ports. This is the code: import java.util.Enumeration; import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; public class Show { private Enumeration portList; private CommPortIdentifier portId; private SerialPort port; /** Creates a new instance of Show */ public Show() { } public static void main(String args[]){ Show show = new Show(); show.portList = CommPortIdentifier.getPortIdentifiers(); String tPort = ""; System.out.println("========================================="); while(show.portList.hasMoreElements()){ show.portId = (CommPortIdentifier)show.portList.nextElement(); if(show.portId.getPortType() == CommPortIdentifier.PORT_SERIAL) tPort = "Serial"; else tPort = "Parallel"; System.out.println(show.portId.getName() + " " + tPort); } } } whit The problem is that this code not show the serial ports, this show the no use serial ports. I want to connect whit the modem but when windows open and connect the modem my application don't see the port(COMM3) when it is connect. what I can do? Is that the correct way to know the ports? thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/eedd744b/attachment-0003.html From ehdez.correo at gmail.com Tue Jun 5 07:42:13 2007 From: ehdez.correo at gmail.com (=?ISO-8859-1?Q?Enrique_Hern=E1ndez?=) Date: Tue, 5 Jun 2007 09:42:13 -0400 Subject: [Rxtx] serial port Message-ID: <4a814e1f0706050642p4ce9ac7bka80f9479c524c5ea@mail.gmail.com> Hello: How I can ask to the port what device is connect and information about this device. thanks. bye. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/4d10d26a/attachment-0003.html From supsoop at hotmail.com Tue Jun 5 09:29:00 2007 From: supsoop at hotmail.com (soop soop) Date: Tue, 05 Jun 2007 15:29:00 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Message-ID: Hi Guys, Thanks for all your help. I found the problem. I created a user, Tomcat55, for my tomcat but it did not belong to any group. I then added this user to dialout group to have access to the device ttyACM0. Works perfectly! Again permissions was the issue. This also seems to be persistent as a server reboot does not effect the access. Cheers! >From: "Alwyn Schoeman" >Reply-To: RXTX Developers and Users >To: "RXTX Developers and Users" >Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >Date: Tue, 5 Jun 2007 08:10:19 +0200 > >Hi, > >I'm using a similar modem. By default rxtx doesn't look for devices that >start with ACM, so you need to modify the >source code and recompile. > >Look in RXTXCommDriver and add values for ACM in the registerScannedPorts >method in the Linux specific parts. Look for osName.equals("Linux")... > >On 6/4/07, soop soop wrote: >> >>Hi Guys, >> >>Looked through the archives but still cannot figure this out. I have a >>Motorola G24 GPRS/GSM modem that I am connecting to my server running >>Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not >>detecting the port, CommPortIdentifier.getPortIdentifiers(). >> >>I have added the line to RXTXCommDriver: >> >>"ttyACM" // for USB Modems >> >>Rxtx still does not seem to find the port. Is there something I am missing >>to make this port visable? >> >>[ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver >>[ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device >>[ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control >>Model >>driver for USB modems and ISDN adapters >> >>I really need your help as I have moved my server from windows to Linux >>and >>have been down for a few days because of this .. Thanks so much! >> >>_________________________________________________________________ >>PC Magazine's 2007 editors' choice for best Web mail—award-winning Windows >>Live Hotmail. >> >>http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 >> >> >>_______________________________________________ >>Rxtx mailing list >>Rxtx at qbang.org >>http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > >-- >Alwyn Schoeman >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ Need a break? Find your escape route with Live Search Maps. http://maps.live.com/default.aspx?ss=Restaurants~Hotels~Amusement%20Park&cp=33.832922~-117.915659&style=r&lvl=13&tilt=-90&dir=0&alt=-1000&scene=1118863&encType=1&FORM=MGAC01 From netbeans at gatworks.com Tue Jun 5 09:42:31 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 11:42:31 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <46658467.20101@gatworks.com> soop soop wrote: > > Hi Guys, > > Thanks for all your help. I found the problem. I created a user, > Tomcat55, for my tomcat but it did not belong to any group. I then added Look at man pages for the program udev. From tjarvi at qbang.org Tue Jun 5 18:18:17 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Jun 2007 18:18:17 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Message-ID: On Tue, 5 Jun 2007, Enrique Hern?ndez wrote: > The problem is that this code not show the serial ports, this show the no > use serial ports. I want to connect whit the modem but when windows open and > connect the modem my application don't see the port(COMM3) when it is > connect. > what I can do? > Is that the correct way to know the ports? > Hello, We may have problems understanding each other. On windows, the port will not be an available serial port if another application has the port open. That is just how the library behaves. If you can not see the port in the enumerated list, you could not open it. Also note that enumeration only happens once. If you add a port such as a new USB dongle, the port will not be visible until the next time your application runs. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Tue Jun 5 18:45:01 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 20:45:01 -0400 Subject: [Rxtx] problem with rxtx In-Reply-To: References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Message-ID: <4666038D.8090700@gatworks.com> Trent Jarvi wrote: > > > Also note that enumeration only happens once. If you add a port such as > a new USB dongle, the port will not be visible until the next time your > application runs. Is this written in stone ? somewhere? From tjarvi at qbang.org Tue Jun 5 18:54:36 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Jun 2007 18:54:36 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <4666038D.8090700@gatworks.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> Message-ID: On Tue, 5 Jun 2007, Uncle George wrote: > Trent Jarvi wrote: >> >> >> Also note that enumeration only happens once. If you add a port such as >> a new USB dongle, the port will not be visible until the next time your >> application runs. > > Is this written in stone ? somewhere? It is just the current behavior. There is nothing preventing a fix that allows reenumeration. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Tue Jun 5 19:55:19 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 21:55:19 -0400 Subject: [Rxtx] problem with rxtx In-Reply-To: References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> Message-ID: <46661407.4020308@gatworks.com> >> Is this written in stone ? somewhere? > > It is just the current behavior. There is nothing preventing a fix that > allows reenumeration. With usb, ..... , things come and go. Seems a shame that you have to kill application to get at the device u just plugged in. From joachim at buechse.ch Wed Jun 6 01:50:06 2007 From: joachim at buechse.ch (Joachim Buechse) Date: Wed, 6 Jun 2007 09:50:06 +0200 Subject: [Rxtx] problem with rxtx In-Reply-To: <46661407.4020308@gatworks.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> <46661407.4020308@gatworks.com> Message-ID: <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> On MacOS RXTX's enumeration handling is more flexible. It will find new ports that are added during the lifetime of the application. But this is inherently incompatible with suns javax.comm implementation... Regards, Joachim On 06.06.2007, at 03:55, Uncle George wrote: > >>> Is this written in stone ? somewhere? >> >> It is just the current behavior. There is nothing preventing a >> fix that >> allows reenumeration. > > With usb, ..... , things come and go. Seems a shame that you have to > kill application to get at the device u just plugged in. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Jun 6 06:06:48 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Jun 2007 06:06:48 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> <46661407.4020308@gatworks.com> <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> Message-ID: Sun's javax.comm is not a major concern going forward. As long as we do not break old applications using rxtx, I see no reason to limit rxtx to that convention. We have already rejected version 3 from Sun as a dead end and limited our compatability to version 2. That does not mean we will not try to work with Sun and others but the current javax.comm convention (v3) is not a well conceived path. There has been discussion about doing a JSR which is one valid option. On Wed, 6 Jun 2007, Joachim Buechse wrote: > On MacOS RXTX's enumeration handling is more flexible. It will find > new ports that are added during the lifetime of the application. But > this is inherently incompatible with suns javax.comm implementation... > > Regards, > Joachim > > On 06.06.2007, at 03:55, Uncle George wrote: > >> >>>> Is this written in stone ? somewhere? >>> >>> It is just the current behavior. There is nothing preventing a >>> fix that >>> allows reenumeration. >> >> With usb, ..... , things come and go. Seems a shame that you have to >> kill application to get at the device u just plugged in. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From yvespielusenet at free.fr Wed Jun 6 08:46:35 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 16:46:35 +0200 Subject: [Rxtx] [PARALLEL] resource in use Message-ID: <1181141195.3407.20.camel@localhost.localdomain> Hello, I want to use rxtx in my application. I haveto send data to a very old printer (which have a drum and hammers http://perso.orange.fr/tiie/page00010017.html) This is printer is connecter with centronics. It works well but, while it's writting and I putthe printer off-line, after about 45 seconds, I have this error : ------------------------------------- java.io.IOException: La ressource demand?e est en cours d'utilisation. in writeArray at gnu.io.LPRPort.writeArray(Native Method) at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:292) at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:161) at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:156) at mce.buffer.bufferManager.BufferManager$PrintBuffer.run(BufferManager.java:141) The IOexception means "The wanted resource is in use" ------------------------------------- Here is the line 141 of BufferManager : ------------------------------------- while(send){ try{ fos.write(bb); <=== line 141 send = false; } catch(Exception e){ javax.swing.JOptionPane.showMessageDialog(null, "Erreur d'envoie. Veuillez cliquer sur OK pour relancer l'impression de la vignette.\nV?rifiez votre impression !", "Erreur d'envoie", javax.swing.JOptionPane.WARNING_MESSAGE); e.printStackTrace(System.err); System.err.flush(); System.out.println(e); send = true; } } -------------------------------- 'fos' is an outputstream which contains the rxtx stream (this.os is the rxtx outputstream) : -------------------------------- public void write(byte[] bb) throws IOException{ this.write(bb, 0, bb.length); } public void write(byte[] bb, int off, int len) throws IOException{ while(!imp1.isPrinterSelected() || !imp2.isPrinterSelected()){ } this.os.write(bb, off, len); } -------------------------------- Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( can you help me ? thank you :) -- yves piel From yvespielusenet at free.fr Wed Jun 6 09:11:15 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 17:11:15 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181141195.3407.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> Message-ID: <1181142675.3407.23.camel@localhost.localdomain> I forgot to tell that It's under windows XP and java 1.5. Le mercredi 06 juin 2007 ? 16:46 +0200, yves pielusenet a ?crit : > Hello, > I want to use rxtx in my application. I haveto send data to a very old > printer (which have a drum and hammers > http://perso.orange.fr/tiie/page00010017.html) > This is printer is connecter with centronics. It works well but, while > it's writting and I putthe printer off-line, after about 45 seconds, I > have this error : > ------------------------------------- > java.io.IOException: La ressource demand?e est en cours d'utilisation. > in writeArray > at gnu.io.LPRPort.writeArray(Native Method) > at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:292) > at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:161) > at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:156) > at mce.buffer.bufferManager.BufferManager$PrintBuffer.run(BufferManager.java:141) > > The IOexception means "The wanted resource is in use" > ------------------------------------- > > Here is the line 141 of BufferManager : > > ------------------------------------- > while(send){ > try{ > fos.write(bb); <=== line 141 > send = false; > } > catch(Exception e){ > javax.swing.JOptionPane.showMessageDialog(null, "Erreur d'envoie. Veuillez cliquer sur OK pour relancer l'impression de la vignette.\nV?rifiez votre impression !", "Erreur d'envoie", javax.swing.JOptionPane.WARNING_MESSAGE); > e.printStackTrace(System.err); > System.err.flush(); > System.out.println(e); > send = true; > } > } > -------------------------------- > 'fos' is an outputstream which contains the rxtx stream (this.os is the rxtx outputstream) : > > -------------------------------- > public void write(byte[] bb) throws IOException{ > this.write(bb, 0, bb.length); > } > public void write(byte[] bb, int off, int len) throws IOException{ > while(!imp1.isPrinterSelected() || !imp2.isPrinterSelected()){ > } > this.os.write(bb, off, len); > } > -------------------------------- > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > can you help me ? > > thank you :) > From netbeans at gatworks.com Wed Jun 6 09:21:46 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 11:21:46 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181141195.3407.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> Message-ID: <4666D10A.8000507@gatworks.com> } > -------------------------------- > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > can you help me ? > > thank you :) > windoz or linux? ( I guess windoz ) for windoz, there appears to be a timeout ( as Comments suggest ) of about 40seconds. > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } for linux, there is no implied timeout. > if( write( fd, bytes, count ) < 0 ) > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); From netbeans at gatworks.com Wed Jun 6 09:39:41 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 11:39:41 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666D10A.8000507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> Message-ID: <4666D53D.90000@gatworks.com> Uncle George wrote: > } >> -------------------------------- >> >> Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( >> >> can you help me ? From reading the code, I can see your concern. And it appears you are correct, because some of the data will be sent to the OS printer buffers, and then it will refuse to accept anymore. Unfortunately, writeArray does not return the num of characters written :{ So application has no idea to how many characters were accepted by the OS. I dont do windoz, so I cant say with absolute certainty what windoz will do with an off-line condition. If you have the source, and can compile, then maybe u can increase the loop count to hit 4hours? From yvespielusenet at free.fr Wed Jun 6 09:53:25 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 17:53:25 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666D10A.8000507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> Message-ID: <1181145205.3407.35.camel@localhost.localdomain> Thank you for your explanation :) This timeout comes when no data has been send to the printer after 40seconds if I well understand. But why there is such a timeout ? If I setthe printer offline while it's printing I mustn't have an exception. I don't understand why the "printer should solv all problems like buffer full" in 40 seconds. If I pause the printer the buffer will not be emptied, isn't it ? I not very familiar with C/C++, but it seem that the exception is thrown only when countWritten == 0, that means no data at all has been sent. So Is my code is good since when I intercept this exception I send all my buffer again. There is no way that the printer receive two times same bytes ? thanks ps: yes the application is running on windows XP since I developpe under Debian Le mercredi 06 juin 2007 ? 11:21 -0400, Uncle George a ?crit : > } > > -------------------------------- > > > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > > > can you help me ? > > > > thank you :) > > > > windoz or linux? ( I guess windoz ) > > for windoz, there appears to be a timeout ( as Comments suggest ) of > about 40seconds. > > while( count > 0 ){ > > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > > /* > > this are 20 * 2 seconds, in this time a printer (or other parallel device) > > should solv all problems like buffer full, etc > > */ > > if(errorCount++ < 20){ > > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > > continue; > > } > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > for linux, there is no implied timeout. > > if( write( fd, bytes, count ) < 0 ) > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Wed Jun 6 10:34:24 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 12:34:24 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181145205.3407.35.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> Message-ID: <4666E210.30507@gatworks.com> yves pielusenet wrote: > Thank you for your explanation :) > This timeout comes when no data has been send to the printer after > 40seconds if I well understand. But why there is such a timeout ? If I > setthe printer offline while it's printing I mustn't have an exception. > I don't understand why the "printer should solv all problems like buffer > full" in 40 seconds. If I pause the printer the buffer will not be > emptied, isn't it ? > > I not very familiar with C/C++, but it seem that the exception is thrown > only when countWritten == 0, that means no data at all has been sent. So > Is my code is good since when I intercept this exception I send all my > buffer again. There is no way that the printer receive two times same > bytes ? More technically, the function call returns and reports that 0 characters was written in this call. when 0 characters are written, it will check how many times 0 characters was written. If it has tried LESS than 20 times(errorCount), it will sleep() and try to write again. After 20 times, it wont sleep, but throw you the exception. Now suppose you are writing a 120 character line. you off-lined/paused your printer. The OS has room for 80 more characters in it's printer buffer. The WriteFile() will have a char count of 120, but on return the countWritten = 80. You still have 40 more characters to print. Since countWritten != 0, the counters: bytes += countWritten; count -= countWritten; get updated, and the Writefile now has a count of 40 characters. Since the printer is off-line, the countwritten is 0. And so the loop continues, till 40 seconds is up. As to why it is this way, i dont know ( not a windoz maven ); Also the sleep(20) in the loop is not so intuitive to suggest 2 seconds of sleep. I would have guessed 20seconds, or 20milliseconds. But go figure. BTW: Since your computer sends you error messages in French, does it curse in English? :)))) From yvespielusenet at free.fr Thu Jun 7 02:27:44 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Thu, 07 Jun 2007 10:27:44 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666E210.30507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> Message-ID: <1181204864.3501.10.camel@localhost.localdomain> Maybe in my case I should re-compile rxtx and change the code. Instead of send an exception I should display a dialog box to ask if it's printer problem or if it should trie to send bytes. Something like : while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } if(displayDialogBox("Try again to send datas ??")){ errorCount = 0; } else{ throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } } Le mercredi 06 juin 2007 ? 12:34 -0400, Uncle George a ?crit : > yves pielusenet wrote: > > Thank you for your explanation :) > > This timeout comes when no data has been send to the printer after > > 40seconds if I well understand. But why there is such a timeout ? If I > > setthe printer offline while it's printing I mustn't have an exception. > > I don't understand why the "printer should solv all problems like buffer > > full" in 40 seconds. If I pause the printer the buffer will not be > > emptied, isn't it ? > > > > I not very familiar with C/C++, but it seem that the exception is thrown > > only when countWritten == 0, that means no data at all has been sent. So > > Is my code is good since when I intercept this exception I send all my > > buffer again. There is no way that the printer receive two times same > > bytes ? > More technically, the function call returns and reports that 0 > characters was written in this call. > when 0 characters are written, it will check how many times 0 characters > was written. If it has tried LESS than 20 times(errorCount), it will > sleep() and try to write again. > After 20 times, it wont sleep, but throw you the exception. > > Now suppose you are writing a 120 character line. you off-lined/paused > your printer. The OS has room for 80 more characters in it's printer > buffer. The WriteFile() will have a char count of 120, but on return the > countWritten = 80. You still have 40 more characters to print. > Since countWritten != 0, the counters: > bytes += countWritten; > count -= countWritten; > get updated, and the Writefile now has a count of 40 characters. Since > the printer is off-line, the countwritten is 0. And so the loop > continues, till 40 seconds is up. > > As to why it is this way, i dont know ( not a windoz maven ); > Also the sleep(20) in the loop is not so intuitive to suggest 2 seconds > of sleep. I would have guessed 20seconds, or 20milliseconds. But go figure. > > BTW: Since your computer sends you error messages in French, does it > curse in English? :)))) > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 06:11:43 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 08:11:43 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181204864.3501.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> Message-ID: <4667F5FF.8070903@gatworks.com> your suggestion appears good. I dont know what displayDialogBox exactly will do, so all I can say it that it looks good. But I'd like to wait 10min before first dialog box And a 5 min wait for every dialog box there after. And since these are custom solution/choices, maybe a more exact explanation of what the issue is. if(errorCount++ < 300){ // wait 10min ( 10min * 60sec / 2 ) Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } if(displayDialogBox("Printer has Paused. Retry sending data?")){ errorCount = 150; // Wait for 5 min thereafter continue; } > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } yves pielusenet wrote: > Maybe in my case I should re-compile rxtx and change the code. Instead > of send an exception I should display a dialog box to ask if it's > printer problem or if it should trie to send bytes. Something like : > > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > > if(displayDialogBox("Try again to send datas ??")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > } > From yvespielusenet at free.fr Thu Jun 7 07:17:21 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Thu, 07 Jun 2007 15:17:21 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4667F5FF.8070903@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <4667F5FF.8070903@gatworks.com> Message-ID: <1181222241.3501.20.camel@localhost.localdomain> thank you :) 'displayDialogBox()' I think doesn't exist. It was just for the example :) But I think It should not be so complicated to display a dialog box under windows with YES/NO buttons. When yes is clicked it return 0 other it returns 1. Le jeudi 07 juin 2007 ? 08:11 -0400, Uncle George a ?crit : > your suggestion appears good. I dont know what displayDialogBox exactly > will do, so all I can say it that it looks good. > > But I'd like to wait 10min before first dialog box And a 5 min wait for > every dialog box there after. And since these are custom > solution/choices, maybe a more exact explanation of what the issue is. > > if(errorCount++ < 300){ // wait 10min ( 10min * 60sec / 2 ) > Sleep( 20 ); /* make a small pause to execute all other requests > in all other threads */ > continue; > } > > if(displayDialogBox("Printer has Paused. Retry sending data?")){ > errorCount = 150; // Wait for 5 min thereafter > continue; > } > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > > yves pielusenet wrote: > > Maybe in my case I should re-compile rxtx and change the code. Instead > > of send an exception I should display a dialog box to ask if it's > > printer problem or if it should trie to send bytes. Something like : > > > > while( count > 0 ){ > > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > > /* > > this are 20 * 2 seconds, in this time a printer (or other parallel device) > > should solv all problems like buffer full, etc > > */ > > if(errorCount++ < 20){ > > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > > continue; > > } > > > > if(displayDialogBox("Try again to send datas ??")){ > > errorCount = 0; > > } > > else{ > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > } > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 07:41:43 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 09:41:43 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181222241.3501.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <4667F5FF.8070903@gatworks.com> <1181222241.3501.20.camel@localhost.localdomain> Message-ID: <46680B17.8050109@gatworks.com> yves pielusenet wrote: > thank you :) > 'displayDialogBox()' I think doesn't exist. It was just for the > example :) too bad. Good luck. From rtrout at webbresearch.com Thu Jun 7 11:23:04 2007 From: rtrout at webbresearch.com (Robert Trout) Date: Thu, 07 Jun 2007 13:23:04 -0400 Subject: [Rxtx] Disconnected PortServer TS causes Java to hang Message-ID: <1181236984.14186.33.camel@sisyphus.DinkumSoftware.com> I'm running Linux with sun's Java 1.4.2, Java comm API 2.0, RXTX 2.0-7pre1, and the RealPort digi driver. "/dev/ttyrp00" is a RealPort device. My Java application never returns from a ComPortIdentifier.getPortIdentifier("/dev/ttyrp00") call while the Digi PortServer TS 4 is disconnected from the network. If I later re-connect the PortServer, the call returns about 30 seconds later (it's like a serial port read or write is blocking until the PortServer is re- connected). With the PortServer disconnected, minicom immediately responds with "cannot open /dev/ttyrp00: No such file or directory". I would like my Java application to behave similarly. That is, respond with an error condition instead of hanging when the PortServer is not connected. Since minicom and Java behave differently, I think this "hanging" behavior may be due to RXTX or Java? Has anyone had a similar issue? Solutions? Suggestions? Thanks, Robert From vicnevicne at gmail.com Thu Jun 7 12:16:02 2007 From: vicnevicne at gmail.com (Vicne) Date: Thu, 07 Jun 2007 20:16:02 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181204864.3501.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> Message-ID: <46684B62.7080802@gmail.com> yves pielusenet wrote: > Maybe in my case I should re-compile rxtx and change the code. Instead > of send an exception I should display a dialog box to ask if it's > printer problem or if it should trie to send bytes. Something like : > > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > > if(displayDialogBox("Try again to send datas ??")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > } > Sorry to step in without a specific solution to your problem, but I wanted to share my feeling regarding this proposal. AFAIK, it's generally considered bad practice to pop-up a prompt from a library. The main reason is that in general use, you can't guarantee that someone is actually present behind the console. Imagine a print server in a machine room, connected to a park of printers. In that case, when one printer fails, the logical behaviour would be to use an other one. If you change RxTx the way you propose, the printer queue will simply be stuck with a useless "Try again to send data ?" prompt until an administrator opens a remote connection to the print server's console and clicks "no". Second, it would create a dependency upon the existence of a graphical console (if you go the graphical "dialogBox" way). On many applications (typically server or embedded ones), the JVM is "headless" and if you try to pop-up a dialog, your app would throw an exception (at best) or just wouldn't display the prompt anywhere... Going the "text console" way is not more reliable, because on graphical environments, the text console is hidden unless explicitly requested. My advice would be to think again and find another solution. Ideas are : - make the number of retries a parameter so that you can tune it to what you think is reasonable - throw a more specific exception when the number of retries has been reached, so that a specific prompt can be shown at a higher level Anyway, if you feel that the prompt is the way to go in your case, I would at least make that prompt conditional. The least intrusive way would probably be using a system property, like if("true".equals(System.getProperty("org.rxtx.usePrompt")) && displayDialogBox("Retry sending data ?")){ errorCount = 0; } else{ throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } By default, the behaviour would remain as it is now, but you could force the prompts by defining the property at VM launch if desired. (for example : java.exe -Dorg.rxtx.usePrompt=true myApp) Also, you seemed to say you wanted the printer to start again exactly where is stopped. It would indeed be the best way when the printer is put offline for a few seconds. On the other hand, if the printer is turned off (or the printer runs out of paper, or someone steps on the mains cable), then the only way to go back to a "stable" situation would be by printing the item (page, label, etc.) again from scratch... Just my two cents. Vicne PS : By the way, the dialog box thing is very platform dependant on the C-side, and I think the simplest way would probably be to bridge it to a Java call where you can implement it like you proposed : public boolean displayDialogBox(prompt) { return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); } From netbeans at gatworks.com Thu Jun 7 14:08:24 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 16:08:24 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46684B62.7080802@gmail.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> Message-ID: <466865B8.4060004@gatworks.com> My feeling is that the code that was suggested was for his environs ( his shop ). The issue here is that after a 40+ second wait, an exception will be thrown. But you really dont have a way of 'cancelling' all the WriteFiles() that have already occured before the exception so that your writeArray and the Commapi can backtrack to a position in which they are in sync. The main ( really mine ) concern is not to lose data, or replicate data. After 40seconds, 300 seconds, 55min, no matter how long, data should not be lost or duplicated. But as soon as the exception is thrown, that possibility exists. Maybe an event should be thrown instead? Vicne wrote: > yves pielusenet wrote: >> Maybe in my case I should re-compile rxtx and change the code. Instead >> of send an exception I should display a dialog box to ask if it's >> printer problem or if it should trie to send bytes. Something like : >> >> while( count > 0 ){ >> if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ >> /* >> this are 20 * 2 seconds, in this time a printer (or other parallel device) >> should solv all problems like buffer full, etc >> */ >> if(errorCount++ < 20){ >> Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ >> continue; >> } >> >> if(displayDialogBox("Try again to send datas ??")){ >> errorCount = 0; >> } >> else{ >> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >> break; >> } >> } >> > > Sorry to step in without a specific solution to your problem, but I > wanted to share my feeling regarding this proposal. AFAIK, it's > generally considered bad practice to pop-up a prompt from a library. > The main reason is that in general use, you can't guarantee that > someone is actually present behind the console. Imagine a print server > in a machine room, connected to a park of printers. In that case, when > one printer fails, the logical behaviour would be to use an other one. > If you change RxTx the way you propose, the printer queue will simply be > stuck with a useless "Try again to send data ?" prompt until an > administrator opens a remote connection to the print server's console > and clicks "no". > Second, it would create a dependency upon the existence of a > graphical console (if you go the graphical "dialogBox" way). On many > applications (typically server or embedded ones), the JVM is "headless" > and if you try to pop-up a dialog, your app would throw an exception (at > best) or just wouldn't display the prompt anywhere... Going the "text > console" way is not more reliable, because on graphical environments, > the text console is hidden unless explicitly requested. > > My advice would be to think again and find another solution. Ideas are : > - make the number of retries a parameter so that you can tune it to what > you think is reasonable > - throw a more specific exception when the number of retries has been > reached, so that a specific prompt can be shown at a higher level > > Anyway, if you feel that the prompt is the way to go in your case, I > would at least make that prompt conditional. The least intrusive way > would probably be using a system property, like > > if("true".equals(System.getProperty("org.rxtx.usePrompt")) > && displayDialogBox("Retry sending data ?")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > > > By default, the behaviour would remain as it is now, but you could > force the prompts by defining the property at VM launch if desired. (for > example : java.exe -Dorg.rxtx.usePrompt=true myApp) > > > Also, you seemed to say you wanted the printer to start again > exactly where is stopped. It would indeed be the best way when the > printer is put offline for a few seconds. On the other hand, if the > printer is turned off (or the printer runs out of paper, or someone > steps on the mains cable), then the only way to go back to a "stable" > situation would be by printing the item (page, label, etc.) again from > scratch... > > > Just my two cents. > > > Vicne > > PS : By the way, the dialog box thing is very platform dependant on the > C-side, and I think the simplest way would probably be to bridge it to a > Java call where you can implement it like you proposed : > > public boolean displayDialogBox(prompt) { > return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", > JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); > } > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Thu Jun 7 17:48:11 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 Jun 2007 17:48:11 -0600 (MDT) Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <466865B8.4060004@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> Message-ID: An event is possible. I'm amazed this is the largest problem encountered while using the parallel code. How would the write ever exit if we throw events? Isn't this going to lead to hung applications? On Thu, 7 Jun 2007, Uncle George wrote: > My feeling is that the code that was suggested was for his environs ( > his shop ). > > The issue here is that after a 40+ second wait, an exception will be > thrown. But you really dont have a way of 'cancelling' all the > WriteFiles() that have already occured before the exception so that your > writeArray and the Commapi can backtrack to a position in which they are > in sync. > > The main ( really mine ) concern is not to lose data, or replicate data. > After 40seconds, 300 seconds, 55min, no matter how long, data should > not be lost or duplicated. But as soon as the exception is thrown, that > possibility exists. > > Maybe an event should be thrown instead? > > Vicne wrote: >> yves pielusenet wrote: >>> Maybe in my case I should re-compile rxtx and change the code. Instead >>> of send an exception I should display a dialog box to ask if it's >>> printer problem or if it should trie to send bytes. Something like : >>> >>> while( count > 0 ){ >>> if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ >>> /* >>> this are 20 * 2 seconds, in this time a printer (or other parallel device) >>> should solv all problems like buffer full, etc >>> */ >>> if(errorCount++ < 20){ >>> Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ >>> continue; >>> } >>> >>> if(displayDialogBox("Try again to send datas ??")){ >>> errorCount = 0; >>> } >>> else{ >>> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >>> break; >>> } >>> } >>> >> >> Sorry to step in without a specific solution to your problem, but I >> wanted to share my feeling regarding this proposal. AFAIK, it's >> generally considered bad practice to pop-up a prompt from a library. >> The main reason is that in general use, you can't guarantee that >> someone is actually present behind the console. Imagine a print server >> in a machine room, connected to a park of printers. In that case, when >> one printer fails, the logical behaviour would be to use an other one. >> If you change RxTx the way you propose, the printer queue will simply be >> stuck with a useless "Try again to send data ?" prompt until an >> administrator opens a remote connection to the print server's console >> and clicks "no". >> Second, it would create a dependency upon the existence of a >> graphical console (if you go the graphical "dialogBox" way). On many >> applications (typically server or embedded ones), the JVM is "headless" >> and if you try to pop-up a dialog, your app would throw an exception (at >> best) or just wouldn't display the prompt anywhere... Going the "text >> console" way is not more reliable, because on graphical environments, >> the text console is hidden unless explicitly requested. >> >> My advice would be to think again and find another solution. Ideas are : >> - make the number of retries a parameter so that you can tune it to what >> you think is reasonable >> - throw a more specific exception when the number of retries has been >> reached, so that a specific prompt can be shown at a higher level >> >> Anyway, if you feel that the prompt is the way to go in your case, I >> would at least make that prompt conditional. The least intrusive way >> would probably be using a system property, like >> >> if("true".equals(System.getProperty("org.rxtx.usePrompt")) >> && displayDialogBox("Retry sending data ?")){ >> errorCount = 0; >> } >> else{ >> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >> break; >> } >> >> >> By default, the behaviour would remain as it is now, but you could >> force the prompts by defining the property at VM launch if desired. (for >> example : java.exe -Dorg.rxtx.usePrompt=true myApp) >> >> >> Also, you seemed to say you wanted the printer to start again >> exactly where is stopped. It would indeed be the best way when the >> printer is put offline for a few seconds. On the other hand, if the >> printer is turned off (or the printer runs out of paper, or someone >> steps on the mains cable), then the only way to go back to a "stable" >> situation would be by printing the item (page, label, etc.) again from >> scratch... >> >> >> Just my two cents. >> >> >> Vicne >> >> PS : By the way, the dialog box thing is very platform dependant on the >> C-side, and I think the simplest way would probably be to bridge it to a >> Java call where you can implement it like you proposed : >> >> public boolean displayDialogBox(prompt) { >> return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", >> JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); >> } >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 19:18:51 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 21:18:51 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> Message-ID: <4668AE7B.3060409@gatworks.com> The UNIX version of writeArray is not too great either. It is possible that the write will only process some of the bytes. #else if( write( fd, bytes, count ) < 0 ) throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); #endif -------------------------------- Maybe it might be better to have the native function inform the caller of the # of characters written, then the commapi/output-buffer can be modified to reflect the #of chars written. If an exception is to be thrown, for too many loops of chars written == 0, then exception wont affect the state of the output buffer. Then a ParallelPort.restart() can be called to resume printing whats in the buffer. Trent Jarvi wrote: > An event is possible. I'm amazed this is the largest problem encountered > while using the parallel code. > > How would the write ever exit if we throw events? Isn't this going to > lead to hung applications? Sure. If you dont time out, then there is nothing that will force an EXIT from the write(). Issue is what has the OS done with the write. > > On Thu, 7 Jun 2007, Uncle George wrote: > >> My feeling is that the code that was suggested was for his environs ( >> his shop ). From yvespielusenet at free.fr Fri Jun 8 01:09:01 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Fri, 08 Jun 2007 09:09:01 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4668AE7B.3060409@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> Message-ID: <1181286541.3674.10.camel@localhost.localdomain> It is not possible that the rxtx java method write(byte[], int offset, int length) return anint which contains the number of byte really send to the printer instead of an exception ? So this is the programm which will see if all bytes have been sent. If not it can retry to send the unsended bytes. -------------------------------------------------------- int sended = 0; while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ sended += countWritten; /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } return sended; /*throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break;*/ } ... ... return countWritten; ------------------------------------------------ Le jeudi 07 juin 2007 ? 21:18 -0400, Uncle George a ?crit : > The UNIX version of writeArray is not too great either. It is possible > that the write will only process some of the bytes. > > #else > if( write( fd, bytes, count ) < 0 ) > throw_java_exception_system_msg( env, IO_EXCEPTION, > "writeArray" ); > #endif > -------------------------------- > > Maybe it might be better to have the native function inform the caller > of the # of characters written, then the commapi/output-buffer can be > modified to reflect the #of chars written. If an exception is to be > thrown, for too many loops of chars written == 0, then exception wont > affect the state of the output buffer. Then a ParallelPort.restart() can > be called to resume printing whats in the buffer. > > > Trent Jarvi wrote: > > An event is possible. I'm amazed this is the largest problem encountered > > while using the parallel code. > > > > How would the write ever exit if we throw events? Isn't this going to > > lead to hung applications? > Sure. If you dont time out, then there is nothing that will force an > EXIT from the write(). Issue is what has the OS done with the write. > > > > On Thu, 7 Jun 2007, Uncle George wrote: > > > >> My feeling is that the code that was suggested was for his environs ( > >> his shop ). > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Fri Jun 8 03:45:00 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 11:45:00 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181286541.3674.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> Message-ID: <20070608094500.GC21069@elberon.bln.de.ingenico.com> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > It is not possible that the rxtx java method write(byte[], int offset, > int length) return anint which contains the number of byte really send > to the printer instead of an exception ? > So this is the programm which will see if all bytes have been sent. If > not it can retry to send the unsended bytes. I think write() is void because in Java people love to do this since OutputStream :-) Of course on such interfaces you cannot implement something nice. If you would have a int write, you would not implement the interface and no applications expecting this interface would link/work/compile. oki, Steffen P.S.: (OT) If you propose not to implement the Java interfaces (especially not on JNI level), maybe optionally offering a wrapper that removes e.g. the write return value and so on to downgrade the powerful classic old POSIX read/write style to the modern limited Java style, then I agree :-) Same for read. Instead of things like "int avialable()" it is more powerful to have an approach as select(2) offers (to guarante the caller that read/write will not block [nothing else make sense anyway IMHO] but may read/write less bytes then requested). The caller gets full control and the higher level protocols can care about timeouts, invoking read in some loops and/or implement retransmission. On top of such an implementation, where everything is controlled, defined, guaranteed and reliable, someone could use an InputStream or OutputStream style interface. Or even better: don't use them at all :) just BTW :-) St. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From yvespielusenet at free.fr Fri Jun 8 05:52:45 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Fri, 08 Jun 2007 13:52:45 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <20070608094500.GC21069@elberon.bln.de.ingenico.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> Message-ID: <1181303565.11203.3.camel@localhost.localdomain> So maybe a better way should be to create a new Exception class which has a method "int getWrittenByte()". So the Exception should be use to send again bytes which are not printed yet. yves Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : > * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > > It is not possible that the rxtx java method write(byte[], int offset, > > int length) return anint which contains the number of byte really send > > to the printer instead of an exception ? > > So this is the programm which will see if all bytes have been sent. If > > not it can retry to send the unsended bytes. > > I think write() is void because in Java people love to do this > since OutputStream :-) Of course on such interfaces you cannot > implement something nice. If you would have a int write, you > would not implement the interface and no applications expecting > this interface would link/work/compile. > > oki, > > Steffen > > P.S.: (OT) > If you propose not to implement the Java interfaces (especially > not on JNI level), maybe optionally offering a wrapper that > removes e.g. the write return value and so on to downgrade the > powerful classic old POSIX read/write style to the modern limited > Java style, then I agree :-) Same for read. Instead of things > like "int avialable()" it is more powerful to have an approach as > select(2) offers (to guarante the caller that read/write will not > block [nothing else make sense anyway IMHO] but may read/write > less bytes then requested). The caller gets full control and the > higher level protocols can care about timeouts, invoking read in > some loops and/or implement retransmission. On top of such an > implementation, where everything is controlled, defined, > guaranteed and reliable, someone could use an InputStream or > OutputStream style interface. Or even better: don't use them at > all :) just BTW :-) > St. > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > 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. > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > 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. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Fri Jun 8 06:46:21 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 08:46:21 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181303565.11203.3.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> Message-ID: <46694F9D.5080501@gatworks.com> It seems that with outputstream.write(b[]), you become terribly uncoordinated as soon as an exception is thrown. Docs do not say what happens to the data. Yet from a practicable point of view, one would like to know if the write was accepted in-full, or rejected before any writes. There are no in betweens, as partial writes are not reportable. So for an outputstream.write(), in order for it to return, the full write request has to be taken, and stored in an internal output buffer. If there is no room, the write() is suspended, till there is room. Or throw's an IOException( "no room in buffer") ; As the select() loop for write reports buffer room avail, then more of the internal buffer is sent to the printer. yves pielusenet wrote: > So maybe a better way should be to create a new Exception class which > has a method "int getWrittenByte()". So the Exception should be use to > send again bytes which are not printed yet. > > yves > > Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : >> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: >>> It is not possible that the rxtx java method write(byte[], int offset, >>> int length) return anint which contains the number of byte really send >>> to the printer instead of an exception ? >>> So this is the programm which will see if all bytes have been sent. If >>> not it can retry to send the unsended bytes. >> I think write() is void because in Java people love to do this >> since OutputStream :-) Of course on such interfaces you cannot >> implement something nice. If you would have a int write, you >> would not implement the interface and no applications expecting >> this interface would link/work/compile. >> >> oki, >> >> Steffen >> >> P.S.: (OT) >> If you propose not to implement the Java interfaces (especially >> not on JNI level), maybe optionally offering a wrapper that >> removes e.g. the write return value and so on to downgrade the >> powerful classic old POSIX read/write style to the modern limited >> Java style, then I agree :-) Same for read. Instead of things >> like "int avialable()" it is more powerful to have an approach as >> select(2) offers (to guarante the caller that read/write will not >> block [nothing else make sense anyway IMHO] but may read/write >> less bytes then requested). The caller gets full control and the >> higher level protocols can care about timeouts, invoking read in >> some loops and/or implement retransmission. On top of such an >> implementation, where everything is controlled, defined, >> guaranteed and reliable, someone could use an InputStream or >> OutputStream style interface. Or even better: don't use them at >> all :) just BTW :-) >> St. >> >> About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. >> 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. >> >> About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. >> 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. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From Steffen.DETTMER at ingenico.com Fri Jun 8 08:12:18 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 16:12:18 +0200 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <46694F9D.5080501@gatworks.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: <20070608141218.GE21069@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 08:46 -0400: > It seems that with outputstream.write(b[]), you become terribly > uncoordinated as soon as an exception is thrown. Docs do not say what > happens to the data. (yes, so avoiding it seems to be good :)) > Yet from a practicable point of view, one would like to know if the > write was accepted in-full, or rejected before any writes. There are no > in betweens, as partial writes are not reportable. (which is an artificial API limitation. I never understood how this happend when they invented JDK because the well-known BSD socket API and thus [probably] WinSock does this correct, but anyway) > So for an outputstream.write(), in order for it to return, the full > write request has to be taken, and stored in an internal output buffer. > If there is no room, the write() is suspended, till there is room. Or > throw's an IOException( "no room in buffer") ; As the select() loop for > write reports buffer room avail, then more of the internal buffer is > sent to the printer. yes, might be good in case of a printer. May be horrible in case of PPP/TCP or some other transmission control protocol which may e.g. repeat data or even omit parts of it (e.g. internet realtime radio station broadcasting)... So I think the idea of "int write" (e.g. BSD sockets, linux files and so on) still is the best. A clean API / implementation should guarantee and allow implementations (users) to rely on that; assumptions and automatic background-sending and so on may look pragmatic and may even work on the first look, but may fail in other situations. BTW, if e.g. BSD socket API is known, why not simply copy it (until something better is invented :)) instead of fiddling around with JDK APIs? anyway, have a nice weekend everyone :-) oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Fri Jun 8 08:55:56 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 10:55:56 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070608141218.GE21069@elberon.bln.de.ingenico.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> Message-ID: <46696DFC.7000801@gatworks.com> >> write reports buffer room avail, then more of the internal buffer is >> sent to the printer. > > yes, might be good in case of a printer. May be horrible in case > of PPP/TCP or some other transmission control protocol which > may e.g. repeat data or even omit parts of it (e.g. internet > realtime radio station broadcasting)... So I think the idea of > "int write" (e.g. BSD sockets, linux files and so on) still is > the best. A clean API / implementation should guarantee and allow > implementations (users) to rely on that; assumptions and > automatic background-sending and so on may look pragmatic and may > even work on the first look, but may fail in other situations. > BTW, if e.g. BSD socket API is known, why not simply copy it > (until something better is invented :)) instead of fiddling > around with JDK APIs? But we were talking about the Parallel Port, and the transmission of data over the commapi/parallel-port schema. There isn't much in bi-directional software communication. Its a simple write one byte at a time interface. I'm not looking to change the comm-api. I'm just looking to alter the interaction between the Native ParallelPort functions, and the java ParallelPort functions that call them. This might be more readily doable than to get a committee to re-specify java-API specs. BTW: Whats is off-topic? ( help: not looking for def of off-topic ) From j.kenneth.gentle at acm.org Fri Jun 8 08:58:59 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Fri, 08 Jun 2007 10:58:59 -0400 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <20070608141218.GE21069@elberon.bln.de.ingenico.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> Message-ID: <200706081459.l58Ex5rA019991@qbang.org> Perhaps it is a bit late to jump in on this one, but here goes anyway. If the solutions all seem to "break" the contract with "java.io.outputstream", then, as noted, that may not be the appropriate contract. At the risk of being heretical, JDK1.4 introduced the "nio" package to address some of the compatibility issues with C apis mentioned in previous posts. The interface "java.nio.channels.WriteableByteChannel" defines the following single method: int write(ByteBuffer source); int, strangely enough, is the actual number of bytes written. So, if RXTX as written, against the JavaCOMM api and OutputStream, doesn't do what we want, how about writing a different set of bindings using the java.nio classes and as much of the underlying native code as possible. Note that just because the java.nio.channels.WriteableByteChannel sends back a result, OutputStream.write doesn't have to - and they could both call the same underlying native code. My 2 cents - maybe not worth even that... Ken From netbeans at gatworks.com Fri Jun 8 10:37:28 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 12:37:28 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <200706081459.l58Ex5rA019991@qbang.org> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> Message-ID: <466985C8.8000505@gatworks.com> Ken Gentle wrote: > Perhaps it is a bit late to jump in on this one, but here goes anyway. Common in, the waters fine. > > If the solutions all seem to "break" the contract with > "java.io.outputstream", then, as noted, that may not be the > appropriate contract. > How would the contract be broken? The machinery underneath is handling the contract. From j.kenneth.gentle at acm.org Fri Jun 8 10:48:01 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Fri, 08 Jun 2007 12:48:01 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466985C8.8000505@gatworks.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> Message-ID: <200706081648.l58Gm7YA022904@qbang.org> At 12:37 2007-06-08, you wrote: >Ken Gentle wrote: > > > > If the solutions all seem to "break" the contract with > > "java.io.outputstream", then, as noted, that may not be the > > appropriate contract. > > >How would the contract be broken? The machinery underneath is handling >the contract. It seems that a lot of the discussion has been about not only the timeout and being able to adjust it in the "machinery layer", but also about knowing in the Java layer, in the event of a timeout or exception, how many characters have been written to the device. An OutputStream won't ever do this with out an extension and including a return value "breaks" the contract, right? So, go with a Java IO api that *does* return the number of bytes written, out of the NIO package. I know it doesn't allow for a strict implementation of the JavaCOMM API - however, using NIO classes in place of the IO classes isn't that big a break and would allow those applications that need such information a way to get it. Maybe I'm misunderstanding the problem... Ken From netbeans at gatworks.com Fri Jun 8 11:24:14 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 13:24:14 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <200706081648.l58Gm7YA022904@qbang.org> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> Message-ID: <466990BE.7040100@gatworks.com> Ken Gentle wrote: An > OutputStream won't ever do this with out an extension and including a > return value "breaks" the contract, right? > i was not thinking of change the API to OutputSream. Are there specs for how output stream should work internally? for instance: String data = "Hello this is a line of data"; Outputstream.write( data.getbytes() ); ParallelPort.suspend(); int free = ParallelPort.getoutputbufferfree(); There is a symbiotic relationship between outputstream and the functionality of ParallelPort. From Steffen.DETTMER at ingenico.com Fri Jun 8 11:15:39 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 19:15:39 +0200 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <200706081459.l58Ex5rA019991@qbang.org> References: <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> Message-ID: <20070608171539.GK21069@elberon.bln.de.ingenico.com> * Ken Gentle wrote on Fri, Jun 08, 2007 at 10:58 -0400: > If the solutions all seem to "break" the contract with > "java.io.outputstream", then, as noted, that may not be the > appropriate contract. > > At the risk of being heretical, JDK1.4 introduced the "nio" package > to address some of the compatibility issues with C apis mentioned in > previous posts. The interface > "java.nio.channels.WriteableByteChannel" defines the following single method: > > int write(ByteBuffer source); > > int, strangely enough, is the actual number of bytes written. Yes, AFAIK one of the motivations for the NIO interface was, that the JDK-1.3 APIs (InputStream, e.g.) were not powerfull enough, especially for multi-connection-TCP servers or so. I don't know much about it but I've heard of a project where NIO usage was removed because of stability issues in multi-threaded environments and performance limitations under some circumstances. IIRC the "nio.ByteBuffer" is something very special (namely something you cannot implement in Java, it is "magic" or part of the language itself). Not sure if this is such a great idea (but for performance in the end sometimes heavy prices must be paid) :) > So, if RXTX as written, against the JavaCOMM api and OutputStream, > doesn't do what we want, how about writing a different set of > bindings using the java.nio classes and as much of the underlying > native code as possible. Yes, this would be an idea: use a full-featured interface on JNI, and, if wanted, deliver some wrappers converting this to a less-featured Java-compliant interface. However, powerful things as e.g. "select" are difficult to "emulate" if you are e.g. on some (older?) windows. But if you expose the full-featured APIs, you need to emulate them full-featured, theoretically. In the end it depends what you do on the serial line. If you just want to talk to a modem, then you may not need precise timeouts. But if you need to implement complexer protocols which define response times and timeouts, you may quickly get into difficulties. For instance, AFAIK, rxtx 1.7.2 (?) for windows is very messy with timeouts (there is a maximum, higher values are truncated; resolution is 100ms only; the function may take up to twice the timeout because internally it may be called twice). Probably for most people this is OK, but probably not for all. But having precise timeouts should be OK for all :-) Well, in the end it is nice to wish but somewhat hard to implement (many platforms, connections, USB, BlueTooth, whatever). oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Steffen.DETTMER at ingenico.com Fri Jun 8 11:04:22 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 19:04:22 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <46696DFC.7000801@gatworks.com> References: <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <46696DFC.7000801@gatworks.com> Message-ID: <20070608170422.GJ21069@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 10:55 -0400: > > BTW, if e.g. BSD socket API is known, why not simply copy it > > (until something better is invented :)) instead of fiddling > > around with JDK APIs? > > But we were talking about the Parallel Port, and the > transmission of data over the commapi/parallel-port schema. > There isn't much in bi-directional software communication. Its > a simple write one byte at a time interface. First, there are things like PLIP (http://en.wikipedia.org/wiki/Plip) - well, probably not widely used, sure ;) Second, I think if there is a good simple API known to support all that (with known "best practices") or so and there is no forcing need to invent a new one, why not simply using it? > I'm not looking to change the comm-api. I'm just looking to > alter the interaction between the Native ParallelPort > functions, and the java ParallelPort functions that call them. Ahh, yes. I think this is what I tried to ask. Having an usable JNI interface and on top (in pure java) some wrapper to InputStream or whatever could be done (e.g. by ignoring the return value of write or throwing if != length). Developers could then use the full-featured (non-JAVA-standard) API or select among various wrappers (as InputStream). > This might be more readily doable than to get a committee to > re-specify java-API specs. Yes, of course. I'm afraid that the Java APIs change regularily, but still yet with limited success it seems, so maybe they get it in one of the next iterations; who knows, maybe Java-9 has a BSD-like socket API :) SCNR. > BTW: Whats is off-topic? ( help: not looking for def of > off-topic ) I think I started some "re-specify java-API specs" which was OT probably. oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From lists at iDIAcomputing.com Fri Jun 8 18:48:54 2007 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Fri, 08 Jun 2007 20:48:54 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46684B62.7080802@gmail.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> Message-ID: <4669F8F6.3040101@iDIAcomputing.com> Vicne wrote: > Sorry to step in without a specific solution to your problem, but I > wanted to share my feeling regarding this proposal. AFAIK, it's > generally considered bad practice to pop-up a prompt from a library. ... > > My advice would be to think again and find another solution. Ideas are : > - make the number of retries a parameter so that you can tune it to what > you think is reasonable > - throw a more specific exception when the number of retries has been > reached, so that a specific prompt can be shown at a higher level You could also allow the client code to register a callback class which returns a boolean indicating whether to retry or cancel. This callback class could pop up a dialog, if appropriate, or follow some preset policy, or.... - George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From joachim at buechse.ch Sat Jun 9 09:43:16 2007 From: joachim at buechse.ch (Joachim Buechse) Date: Sat, 9 Jun 2007 17:43:16 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46694F9D.5080501@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: You should not forget, that in the case of an exception it may not even be known what happened to the data. You have a kernel buffer, outgoing chip buffer, incoming chip buffer, etc. So of course, it would be nice to know up to which point data was correctly processed, but this feedback does not exist on the hardware or protocol level and hence can in general not be magicly created on the software level... Regards, Joachim On 08.06.2007, at 14:46, Uncle George wrote: > It seems that with outputstream.write(b[]), you become terribly > uncoordinated as soon as an exception is thrown. Docs do not say what > happens to the data. > > Yet from a practicable point of view, one would like to know if the > write was accepted in-full, or rejected before any writes. There > are no > in betweens, as partial writes are not reportable. > > So for an outputstream.write(), in order for it to return, the full > write request has to be taken, and stored in an internal output > buffer. > If there is no room, the write() is suspended, till there is room. Or > throw's an IOException( "no room in buffer") ; As the select() loop > for > write reports buffer room avail, then more of the internal buffer is > sent to the printer. > > > > yves pielusenet wrote: >> So maybe a better way should be to create a new Exception class which >> has a method "int getWrittenByte()". So the Exception should be >> use to >> send again bytes which are not printed yet. >> >> yves >> >> Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : >>> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: >>>> It is not possible that the rxtx java method write(byte[], int >>>> offset, >>>> int length) return anint which contains the number of byte >>>> really send >>>> to the printer instead of an exception ? >>>> So this is the programm which will see if all bytes have been >>>> sent. If >>>> not it can retry to send the unsended bytes. >>> I think write() is void because in Java people love to do this >>> since OutputStream :-) Of course on such interfaces you cannot >>> implement something nice. If you would have a int write, you >>> would not implement the interface and no applications expecting >>> this interface would link/work/compile. >>> >>> oki, >>> >>> Steffen >>> >>> P.S.: (OT) >>> If you propose not to implement the Java interfaces (especially >>> not on JNI level), maybe optionally offering a wrapper that >>> removes e.g. the write return value and so on to downgrade the >>> powerful classic old POSIX read/write style to the modern limited >>> Java style, then I agree :-) Same for read. Instead of things >>> like "int avialable()" it is more powerful to have an approach as >>> select(2) offers (to guarante the caller that read/write will not >>> block [nothing else make sense anyway IMHO] but may read/write >>> less bytes then requested). The caller gets full control and the >>> higher level protocols can care about timeouts, invoking read in >>> some loops and/or implement retransmission. On top of such an >>> implementation, where everything is controlled, defined, >>> guaranteed and reliable, someone could use an InputStream or >>> OutputStream style interface. Or even better: don't use them at >>> all :) just BTW :-) >>> St. >>> >>> About Ingenico Throughout the world businesses rely on Ingenico >>> for secure and expedient electronic transaction acceptance. >>> Ingenico products leverage proven technology, established >>> standards and unparalleled ergonomics to provide optimal >>> reliability, versatility and usability. This comprehensive range >>> of products is complemented by a global array of services and >>> partnerships, enabling businesses in a number of vertical sectors >>> to accept transactions anywhere their business takes them. >>> 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. >>> >>> About Ingenico Throughout the world businesses rely on Ingenico >>> for secure and expedient electronic transaction acceptance. >>> Ingenico products leverage proven technology, established >>> standards and unparalleled ergonomics to provide optimal >>> reliability, versatility and usability. This comprehensive range >>> of products is complemented by a global array of services and >>> partnerships, enabling businesses in a number of vertical sectors >>> to accept transactions anywhere their business takes them. >>> 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. >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx 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 yvespielusenet at free.fr Mon Jun 11 03:15:12 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Mon, 11 Jun 2007 11:15:12 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: <1181553312.8335.14.camel@localhost.localdomain> So can someone tell a solution for my problem :( Must I say to the user to not put the printer off-line ? I can't since he has to do some pauses, verify print, paper conditioning etc... How do other people ? Before I use the parport librarry to read port status : http://www.geocities.com/Juanga69/parport/ (which doesn't work on windows XP) And I send data into the file LPT1 I use to have no problem when printer was disabled. thanks -- yves piel Le samedi 09 juin 2007 ? 17:43 +0200, Joachim Buechse a ?crit : > You should not forget, that in the case of an exception it may not > even be known what happened to the data. > > You have a kernel buffer, outgoing chip buffer, incoming chip buffer, > etc. So of course, it would be nice to know up to which point data > was correctly processed, but this feedback does not exist on the > hardware or protocol level and hence can in general not be magicly > created on the software level... > > Regards, > Joachim > > On 08.06.2007, at 14:46, Uncle George wrote: > > > It seems that with outputstream.write(b[]), you become terribly > > uncoordinated as soon as an exception is thrown. Docs do not say what > > happens to the data. > > > > Yet from a practicable point of view, one would like to know if the > > write was accepted in-full, or rejected before any writes. There > > are no > > in betweens, as partial writes are not reportable. > > > > So for an outputstream.write(), in order for it to return, the full > > write request has to be taken, and stored in an internal output > > buffer. > > If there is no room, the write() is suspended, till there is room. Or > > throw's an IOException( "no room in buffer") ; As the select() loop > > for > > write reports buffer room avail, then more of the internal buffer is > > sent to the printer. > > > > > > > > yves pielusenet wrote: > >> So maybe a better way should be to create a new Exception class which > >> has a method "int getWrittenByte()". So the Exception should be > >> use to > >> send again bytes which are not printed yet. > >> > >> yves > >> > >> Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : > >>> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > >>>> It is not possible that the rxtx java method write(byte[], int > >>>> offset, > >>>> int length) return anint which contains the number of byte > >>>> really send > >>>> to the printer instead of an exception ? > >>>> So this is the programm which will see if all bytes have been > >>>> sent. If > >>>> not it can retry to send the unsended bytes. > >>> I think write() is void because in Java people love to do this > >>> since OutputStream :-) Of course on such interfaces you cannot > >>> implement something nice. If you would have a int write, you > >>> would not implement the interface and no applications expecting > >>> this interface would link/work/compile. > >>> > >>> oki, > >>> > >>> Steffen > >>> > >>> P.S.: (OT) > >>> If you propose not to implement the Java interfaces (especially > >>> not on JNI level), maybe optionally offering a wrapper that > >>> removes e.g. the write return value and so on to downgrade the > >>> powerful classic old POSIX read/write style to the modern limited > >>> Java style, then I agree :-) Same for read. Instead of things > >>> like "int avialable()" it is more powerful to have an approach as > >>> select(2) offers (to guarante the caller that read/write will not > >>> block [nothing else make sense anyway IMHO] but may read/write > >>> less bytes then requested). The caller gets full control and the > >>> higher level protocols can care about timeouts, invoking read in > >>> some loops and/or implement retransmission. On top of such an > >>> implementation, where everything is controlled, defined, > >>> guaranteed and reliable, someone could use an InputStream or > >>> OutputStream style interface. Or even better: don't use them at > >>> all :) just BTW :-) > >>> St. > >>> > >>> About Ingenico Throughout the world businesses rely on Ingenico > >>> for secure and expedient electronic transaction acceptance. > >>> Ingenico products leverage proven technology, established > >>> standards and unparalleled ergonomics to provide optimal > >>> reliability, versatility and usability. This comprehensive range > >>> of products is complemented by a global array of services and > >>> partnerships, enabling businesses in a number of vertical sectors > >>> to accept transactions anywhere their business takes them. > >>> 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. > >>> > >>> About Ingenico Throughout the world businesses rely on Ingenico > >>> for secure and expedient electronic transaction acceptance. > >>> Ingenico products leverage proven technology, established > >>> standards and unparalleled ergonomics to provide optimal > >>> reliability, versatility and usability. This comprehensive range > >>> of products is complemented by a global array of services and > >>> partnerships, enabling businesses in a number of vertical sectors > >>> to accept transactions anywhere their business takes them. > >>> 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. > >>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx 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 > From Steffen.DETTMER at ingenico.com Mon Jun 11 03:56:18 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 11:56:18 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466990BE.7040100@gatworks.com> References: <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> Message-ID: <20070611095618.GA10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 13:24 -0400: > i was not thinking of change the API to OutputSream. Then I think either someone uses OutputStream (and has no reliable information about incomplete writes) or someone uses somethink else. > Are there specs for how output stream should work internally? > > for instance: > String data = "Hello this is a line of data"; > Outputstream.write( data.getbytes() ); > ParallelPort.suspend(); > int free = ParallelPort.getoutputbufferfree(); > > There is a symbiotic relationship between outputstream and the > functionality of ParallelPort. If you need OutputStream "plus something else", in short you're needing "something else". Personally I dislike the code above a lot. The stream "looks" like if it would be an OutputStream, but in fact it isn't. You need to call getoutputbufferfree later to check if write succeeded (but OutputStream promises that write succeedes synchronous, blocking, or throws an exception). So it is not an OutputStream. No application written for OutputStreams would work without change (because it won't know getoutputbufferfree at all). It is not abstracted from ParallelPort. I think this would be wrong. Then I think an alternative interface instead is better. Let's assume we had some "connection" (to distinguish between OutputStreams and Channels). Then why not working as on a file handle in POSIX: do { // ... select maybe using timer ... readyForWrite = ... if (readyForWrite) { int writtenBytes = connection.write(toWrite); toWrite.remove(0, writtenBytes); } while(readyForWrite && toWrite.length > 0); I think, having such a write isn't the big problem. I think, the difficult thing is around "select" - however this would look like. It should be OO, typesafe, performant, supporting multiple connections/channels/streams in various modes and should be orthogonal to other functionalities. Of course, this heavily depends on what the application is doing; for a simple situation (like reading a small, mandatory file from a local disk) this would be to uncomfortable (and offering unneeded features only). just BTW :) oki, Steffen -- // Modeline for VIM. Please don't remove. // (Help: autoindent, expandtab, shiftwidth=4, tabstop=4, textwidth=75) // vi: set ai et sw=4 ts=4 tw=75 ft=java: About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Mon Jun 11 05:38:33 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 07:38:33 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611095618.GA10821@elberon.bln.de.ingenico.com> References: <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> Message-ID: <466D3439.4020805@gatworks.com> Steffen DETTMER wrote: > (but OutputStream promises that write > succeedes synchronous, blocking, or throws an exception). Where is it so written? From Steffen.DETTMER at ingenico.com Mon Jun 11 06:36:50 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 14:36:50 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466D3439.4020805@gatworks.com> References: <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> <466D3439.4020805@gatworks.com> Message-ID: <20070611123650.GI10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Mon, Jun 11, 2007 at 07:38 -0400: > Steffen DETTMER wrote: > > > (but OutputStream promises that write > > succeedes synchronous, blocking, or throws an exception). > > Where is it so written? Now, as you ask, I think it is not written that clearly but follows from specification. mmm... Am I wrong? I understand the API doc in this way: * http://java.sun.com/j2se/1.4.2/docs/api/java/io/OutputStream.html#write(byte[]) > public void write(byte[] b) > throws IOException > > Writes b.length bytes from the specified byte array to this > output stream. The general contract for write(b) is that > it should have exactly the same effect as the call write(b, > 0, b.length). > > Parameters: > b - the data. > Throws: > IOException - if an I/O error occurs. > See Also: > write(byte[], int, int) and there is: > public void write(byte[] b, > int off, > int len) > throws IOException > > Writes len bytes from the specified byte array starting at > offset off to this output stream. The general contract for > write(b, off, len) is that some of the bytes in the array b > are written to the output stream in order; element b[off] > is the first byte written and b[off+len-1] is the last byte > written by this operation. > > The write method of OutputStream calls the write method of > one argument on each of the bytes to be written out. > Subclasses are encouraged to override this method and > provide a more efficient implementation. > > If b is null, a NullPointerException is thrown. > > If off is negative, or len is negative, or off+len is > greater than the length of the array b, then an > IndexOutOfBoundsException is thrown. > > Parameters: > b - the data. > off - the start offset in the data. > len - the number of bytes to write. > Throws: > IOException - if an I/O error occurs. In particular, an > IOException is thrown if the output stream is closed. In general, any specialisation (derived child class) must comform to this. So write in the end is specified (!) as "The write method ... calls the write method ... on each of the bytes to be written out". This is what must be implemented by ANY OutputStream. Of course, there is: "Subclasses are encouraged to override this method and provide a more efficient implementation." which IMHO does not contradict - the more efficient must behave in exactly the same way of course (just wasting less resources than a simple byte-by-byte write). So it does not matter here I think. The write that finally defines the behavior tells basically: > "Writes the specified byte to this output stream. The general > contract for write is that one byte is written to the output > stream. " > > Throws: > IOException - if an I/O error occurs. which IMHO is another way of saying "write writes the byte immediately and returns on success (only), otherwise an exception is thrown". Especially it cannot happen that zero bytes are written (i.e. the specified byte is NOT written) without an exception. So by this write must be synchronous and blocking, because otherwise it could not reliably know if an asynchronous operation will succeede or not (some getAsyncResult or so would be needed). Since write(byte[]) does this for each byte (or with a behavior beeing exactly the same as if it would do), I think this means that the write(byte[]) succeedes synchronous/blocking or throws an exception. Did I an error in reasoning or confused something or so? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From j.kenneth.gentle at acm.org Mon Jun 11 06:51:25 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 11 Jun 2007 08:51:25 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611123650.GI10821@elberon.bln.de.ingenico.com> References: <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> <466D3439.4020805@gatworks.com> <20070611123650.GI10821@elberon.bln.de.ingenico.com> Message-ID: <200706111251.l5BCpS9T017831@qbang.org> It is as Steffen describes. "InputStream" and "OutputStream" are inherently synchronous (which is why so many java programs resort to threads to use them). Anything outside of this "contract" is *not* an InputStream or OutputStream. That is why there is a new package for things that don't behave like the old *Stream classes - the NIO package. If you look carefully at the IO package, you'll note that almost all the classes are _Decorator_ pattern implementations of the *Stream classes - and the interface presents the _same_ behavior to the calling code in all cases - a synchronous operation that completes successfully or throws an exception (with the one exception of "read" that returns a "-1" on end-of-stream. I know I've read this numerous times - I'd suggest checking the Language Spec or one of the books by Bloch or Gosling. Ken At 08:36 2007-06-11, you wrote: >* Uncle George wrote on Mon, Jun 11, 2007 at 07:38 -0400: > > Steffen DETTMER wrote: > > > > > (but OutputStream promises that write > > > succeedes synchronous, blocking, or throws an exception). > > > > Where is it so written? > >Now, as you ask, I think it is not written that clearly but >follows from specification. mmm... > >Am I wrong? > >I understand the API doc in this way: > >* >http://java.sun.com/j2se/1.4.2/docs/api/java/io/OutputStream.html#write(byte[]) > > public void write(byte[] b) > > throws IOException > > > > Writes b.length bytes from the specified byte array to this > > output stream. The general contract for write(b) is that > > it should have exactly the same effect as the call write(b, > > 0, b.length). > > > > Parameters: > > b - the data. > > Throws: > > IOException - if an I/O error occurs. > > See Also: > > write(byte[], int, int) > > >and there is: > > > > public void write(byte[] b, > > int off, > > int len) > > throws IOException > > > > Writes len bytes from the specified byte array starting at > > offset off to this output stream. The general contract for > > write(b, off, len) is that some of the bytes in the array b > > are written to the output stream in order; element b[off] > > is the first byte written and b[off+len-1] is the last byte > > written by this operation. > > > > The write method of OutputStream calls the write method of > > one argument on each of the bytes to be written out. > > Subclasses are encouraged to override this method and > > provide a more efficient implementation. > > > > If b is null, a NullPointerException is thrown. > > > > If off is negative, or len is negative, or off+len is > > greater than the length of the array b, then an > > IndexOutOfBoundsException is thrown. > > > > Parameters: > > b - the data. > > off - the start offset in the data. > > len - the number of bytes to write. > > Throws: > > IOException - if an I/O error occurs. In particular, an > > IOException is thrown if the output stream is closed. > > >In general, any specialisation (derived child class) must comform >to this. So write in the end is specified (!) as "The write >method ... calls the write method ... on each of the bytes to be >written out". This is what must be implemented by ANY >OutputStream. > >Of course, there is: "Subclasses are encouraged to override this >method and provide a more efficient implementation." which IMHO >does not contradict - the more efficient must behave in exactly >the same way of course (just wasting less resources than a simple >byte-by-byte write). So it does not matter here I think. > > > >The write that finally defines the behavior tells basically: > > > "Writes the specified byte to this output stream. The general > > contract for write is that one byte is written to the output > > stream. " > > > > Throws: > > IOException - if an I/O error occurs. > > >which IMHO is another way of saying "write writes the byte >immediately and returns on success (only), otherwise an exception >is thrown". Especially it cannot happen that zero bytes are >written (i.e. the specified byte is NOT written) without an >exception. So by this write must be synchronous and blocking, >because otherwise it could not reliably know if an asynchronous >operation will succeede or not (some getAsyncResult or so would >be needed). > >Since write(byte[]) does this for each byte (or with a behavior >beeing exactly the same as if it would do), I think this means >that the write(byte[]) succeedes synchronous/blocking or throws >an exception. > >Did I an error in reasoning or confused something or so? > >oki, > >Steffen > >About Ingenico Throughout the world businesses rely on Ingenico for >secure and expedient electronic transaction acceptance. Ingenico >products leverage proven technology, established standards and >unparalleled ergonomics to provide optimal reliability, versatility >and usability. This comprehensive range of products is complemented >by a global array of services and partnerships, enabling businesses >in a number of vertical sectors to accept transactions anywhere >their business takes them. >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. > >About Ingenico Throughout the world businesses rely on Ingenico for >secure and expedient electronic transaction acceptance. Ingenico >products leverage proven technology, established standards and >unparalleled ergonomics to provide optimal reliability, versatility >and usability. This comprehensive range of products is complemented >by a global array of services and partnerships, enabling businesses >in a number of vertical sectors to accept transactions anywhere >their business takes them. >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. > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From alesinskyy at googlemail.com Mon Jun 11 07:25:33 2007 From: alesinskyy at googlemail.com (Oleksandr Alesinskyy) Date: Mon, 11 Jun 2007 15:25:33 +0200 Subject: [Rxtx] [OT] select :-) Message-ID: Sorry, but I have to disagree with following statement: "So write in the end is specified (!) as "The write method ... calls the write method ... on each of the bytes to be written out". This is what must be implemented by ANY OutputStream.". This is not part of the specification or contract, it is just revealed implementation detail of the OutputStream. It is not stated anywhere that behavoiur of derived classes shall conform with this one. Statement concerning "synchronous" nature of the output stream is invalid as well. Really synchronous stream does not require flush() but OutputStream has it. From Steffen.DETTMER at ingenico.com Mon Jun 11 08:21:16 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 16:21:16 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: Message-ID: <20070611142116.GN10821@elberon.bln.de.ingenico.com> * Oleksandr Alesinskyy wrote on Mon, Jun 11, 2007 at 15:25 +0200: > Sorry, but I have to disagree with following statement: > "So write in the end is specified (!) as "The write > method ... calls the write method ... on each of the bytes to be > written out". This is what must be implemented by ANY > OutputStream.". > > This is not part of the specification or contract, it is just > revealed implementation detail of the OutputStream. It is not > stated anywhere that behavoiur of derived classes shall conform > with this one. (I didn't meant that the implementation must really write byte by byte, but that it must "look as if it would do" - because all implementations of OutputStream must "look" in the same way [which is another way of saying "do abstract" I think]) I think the API doc is not "revealing implementation details" but it is the *specification* of that interface and derivations must (should) conform to this specification. Isn't this the idea of interfaces? A function that expects an OutputStream should work on ANY OutputStream, shouldn't it? just kidding: I mean, what would be the point in implementing a checksum function as OutputStream.write which throws its result as IOException? Or which requires to call close() as very first operation to tell that the application is about to transmit confidential data? :-) > Statement concerning "synchronous" nature of the output stream > is invalid as well. Really synchronous stream does not require > flush() but OutputStream has it. ahh, interesting point! I think this is another bug in the API. flush() is wrong. Because write specifies "The general contract for write is that one byte is written to the output stream." but not "a byte may be written or buffered". Actually, an application would need to call flush() after each write (or bunch of write calls) to ensure that write really did something otherwise I think. I didn't found in the spec of OutputStream that it would be required to call flush(). This should mean that calling flush is not required which in turn leads to the conclusion that write must be synchrous (private threads are forbidden because not specified :)) which in turn leads to the conclusion that flush() is not needed at all... I mean, what if someone would only store in write and do the "real write" in flush() and never else? An application could write in one stream and read on another one (e.g. in bidirectional communication) and would never get anything back, because nothing was actually written because no flush was called? Then someone could even think that on error in some write the data could remain buffered AND throw an exception, retrying to send the data in the next write. Ohh, and if there would be some message number inside, and underlaying write (e.g. a protocol offering InputStream/OutputStream) would check this and throw "DuplicatedMessageNumber" the stream would only throw it again and again beeing unusable... In short: I have no clue how someone could be able to implement an asynchrounos write (which is realiable and correct) without beeing specific to anything which is not specified by OutputStream. Well, I think in the end OutputStream was not intended for such communication or protocol implementations - but to read a local disk file or so. In case of I/O errors usually you can abort your application and change the hard disk :-) oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Bob_Jacobsen at lbl.gov Mon Jun 11 09:32:23 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Mon, 11 Jun 2007 08:32:23 -0700 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611142116.GN10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> Message-ID: At 4:21 PM +0200 6/11/07, Steffen DETTMER wrote: > > Statement concerning "synchronous" nature of the output stream >> is invalid as well. Really synchronous stream does not require >> flush() but OutputStream has it. > >ahh, interesting point! > >I think this is another bug in the API. flush() is wrong. Because >write specifies "The general contract for write is that one byte >is written to the output stream." but not "a byte may be written >or buffered". > >Actually, an application would need to call flush() after each >write (or bunch of write calls) to ensure that write really did >something otherwise I think. OutputStreams don't _have_ to be synchronous or asynchronous, but the OutputStream API was be arranged so that subclasses _can_ be synchronous or asynchronous. Such generality is the hardest part of getting an API right. Hence, if at some point a program using an OutputStream wants to be sure that the data has been pushed all the way out, flush() is available. For some subclasses, e.g. the buffered ones, this has important behavior. Others write the data from each call, and flush() doesn't do anything. You _can_ omit it in programs that are known to use this second type, but there's no requirement that you do so; the interface is general in that way. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From Steffen.DETTMER at ingenico.com Mon Jun 11 12:32:39 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 20:32:39 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> Message-ID: <20070611183239.GT10821@elberon.bln.de.ingenico.com> * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: > >Actually, an application would need to call flush() after each > >write (or bunch of write calls) to ensure that write really did > >something otherwise I think. > OutputStreams don't _have_ to be synchronous or asynchronous, > but the OutputStream API was be arranged so that subclasses > _can_ be synchronous or asynchronous. Ahh, oki. Thanks for the clarificaion. So in short, flush() MUST be called on OutputStream, this is just not documented correctly or so clearly (right?). So the overall usage semantics would be: 1. call write (multiple times if desired) 2. call flush only if both succeeded, write was successful. If flush fails it remains unknown if a part of the data was written and/or will be repeated. So the spec (API doc) is wrong. Correct would be to tell that write behaves as told as long as it is followed by a call to flush, otherwise data may or may not get lost (depending wheter close() is called and calls flush(), which seems not to be guaranteed/required). BTW, I think it is a little bit... erm... interesting to find the specification (java API doc reference) wrong, having a need to conclude it from the presence of some methods with "it would make no sense if they behave exactly as specified, so specification must be wrong (incomplete)". > Such generality is the hardest part of getting an API right. Yes, seems to be proven ;) > Hence, if at some point a program using an OutputStream wants > to be sure that the data has been pushed all the way out, > flush() is available. For some subclasses, e.g. the buffered > ones, this has important behavior. Others write the data from > each call, and flush() doesn't do anything. > You _can_ omit it in programs that are known to use this second > type, but there's no requirement that you do so; the interface > is general in that way. I think, it still it must be called always, otherwise the application could break if passing a different runtime type as OutputStream. I think, if the application/method needs a special "type of OutputStream" then the parameter type must be a subclass but not OutputStream, maybe a PrintStream or so - otherwise the compiler could not detect this error (passing wrong type). Is this correct? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Bob_Jacobsen at lbl.gov Mon Jun 11 13:00:52 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Mon, 11 Jun 2007 12:00:52 -0700 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611183239.GT10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> Message-ID: At 8:32 PM +0200 6/11/07, Steffen DETTMER wrote: >So the spec (API doc) is wrong. Correct would be to tell that >write behaves as told as long as it is followed by a call to >flush, otherwise data may or may not get lost (depending wheter >close() is called and calls flush(), which seems not to be >guaranteed/required). I'm not entirely sure that the spec is wrong, but reasonable people can differ on this. In the 1.5 JavaDocs, all that the docs say for the write methods is that they write to the _output_ _stream_; there is no guarantee of anything beyond that. Only the flush method has any guarantee about the data, which is >Flushes this output stream and forces any buffered output bytes to >be written out. The general contract of flush is that calling it is >an indication that, if any bytes previously written have been >buffered by the implementation of the output stream, such bytes >should immediately be written to their intended destination. People commonly use various OutputStreams without using flush(), and it often works, but it's a bad practice and will eventually bite them. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From netbeans at gatworks.com Mon Jun 11 13:31:57 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 15:31:57 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611183239.GT10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> Message-ID: <466DA32D.1010602@gatworks.com> Steffen DETTMER wrote: > * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: >>> Actually, an application would need to call flush() after each >>> write (or bunch of write calls) to ensure that write really did >>> something otherwise I think. > >> OutputStreams don't _have_ to be synchronous or asynchronous, >> but the OutputStream API was be arranged so that subclasses >> _can_ be synchronous or asynchronous. > > Ahh, oki. Thanks for the clarificaion. > > So in short, flush() MUST be called on OutputStream, this is just > not documented correctly or so clearly (right?). No. Flush can be called to force all current data in java buffer's to be written to the kernel - NOW. A flush() can also *imply* that, besides writing out the buffer's that java employs, may also imply/ask the kernel to write all data thusfar written to the kernel, to be physically placed on the destination device - NOW. For some OS's there is no need to do a kernel flush(), as the I/O is synchronized already. Since this is java, you never know what OS your on. From tjarvi at qbang.org Mon Jun 11 19:28:27 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Jun 2007 19:28:27 -0600 (MDT) Subject: [Rxtx] [OT] select :-) In-Reply-To: <466DA32D.1010602@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: On Mon, 11 Jun 2007, Uncle George wrote: > Steffen DETTMER wrote: >> * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: >>>> Actually, an application would need to call flush() after each >>>> write (or bunch of write calls) to ensure that write really did >>>> something otherwise I think. >> >>> OutputStreams don't _have_ to be synchronous or asynchronous, >>> but the OutputStream API was be arranged so that subclasses >>> _can_ be synchronous or asynchronous. >> >> Ahh, oki. Thanks for the clarificaion. >> >> So in short, flush() MUST be called on OutputStream, this is just >> not documented correctly or so clearly (right?). > No. > Flush can be called to force all current data in java buffer's to be > written to the kernel - NOW. > > A flush() can also *imply* that, besides writing out the buffer's that > java employs, may also imply/ask the kernel to write all data thusfar > written to the kernel, to be physically placed on the destination device > - NOW. > For some OS's there is no need to do a kernel flush(), as the I/O is > synchronized already. Since this is java, you never know what OS your on. To add to the confusion, flush on the C side throws away data. drain makes sure it is written. Looking at the ParallelImp.c we can probably do better. /* we set a timeout because all calls are sequentiell (also with asynchron) this means that the default timeout of unlimited blocks all calls (also close and status request) if the device is down */ GetCommTimeouts( (HANDLE)fd, &timeouts ); timeouts.WriteTotalTimeoutMultiplier = 0; timeouts.WriteTotalTimeoutConstant = 2000; /* 2000 is the min value for the default Windows NT and Windows 2000 driver */ SetCommTimeouts( (HANDLE)fd, &timeouts ); while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } errorCount = 0; bytes += countWritten; count -= countWritten; } LPRPort has some timeout code that appears to be doing nothing but flipping bits back and forth right now. The commapi rxtx follows allows for timeout control from javax.comm.CommPort. The above is a solution that worked in one specific use case. With timeouts in place, the original 'old printer going offline' problem could be solved. That printer code isn't written in stone. In fact it was ajusted from being able to print 'asdf' to a daisy wheel printer to working for one person. BTW, I've finished teaching after hours tonight and will be moving forward with a new rxtx release in my free time. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Jun 11 21:28:04 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 23:28:04 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: <466E12C4.1010305@gatworks.com> > Looking at the ParallelImp.c we can probably do better. > The problem stemmed from the possibility that the writev routine could have written some of the buffer, in chunks, printer pauses, refuses any more chunks, and a timeout occurs. Do you or do you not cause an exception to be thrown? Is there a way to set timeout for a ParallelPort data output stream? I cant find it. From tjarvi at qbang.org Mon Jun 11 22:17:23 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Jun 2007 22:17:23 -0600 (MDT) Subject: [Rxtx] [OT] select :-) In-Reply-To: <466E12C4.1010305@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> <466E12C4.1010305@gatworks.com> Message-ID: On Mon, 11 Jun 2007, Uncle George wrote: >> Looking at the ParallelImp.c we can probably do better. >> > The problem stemmed from the possibility that the writev routine could > have written some of the buffer, in chunks, printer pauses, refuses any > more chunks, and a timeout occurs. Do you or do you not cause an > exception to be thrown? > > Is there a way to set timeout for a ParallelPort data output stream? I > cant find it. hmm I looked again after you asked. The timeouts are only controllable on the receive side. This comes from CommPort; the parent. So what we are talking about is some bytes in memory that rxtx has and is supposed to write. A buffer perhaps? The approach with rxtx in the past has been to ignore output buffer sizes. The assumption is that the library does not know how to best handle buffers. There are buffered output streams that can do buffering on top of rxtx for instance. There is also a question regarding what was actually ment when the API was put together. My suspicion is that it was put together while looking at one OS API and was never ment to be anything more than a hook into that API. The comments are fairly telling combined with reading the w32 API. So looking at the problem again.. The current timeout behavior appears fairly arbitrary. Presumably this is to prevent a program from hanging instead of using a helper thread to write - heavy handed for new programmers. Even so, I don't think the write should timeout at all if it is not configurable. >From the API perspective, "What Timeout?" -- Trent Jarvi tjarvi at qbang.org From Steffen.DETTMER at ingenico.com Tue Jun 12 02:14:48 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 12 Jun 2007 10:14:48 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466DA32D.1010602@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: <20070612081447.GU10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Mon, Jun 11, 2007 at 15:31 -0400: > Steffen DETTMER wrote: > > Ahh, oki. Thanks for the clarificaion. > > > > So in short, flush() MUST be called on OutputStream, this is just > > not documented correctly or so clearly (right?). > No. hum (though now I got it, but...). > Flush can be called to force all current data in java buffer's to be > written to the kernel - NOW. > > A flush() can also *imply* that, besides writing out the > buffer's that java employs, may also imply/ask the kernel to > write all data thusfar written to the kernel, to be physically > placed on the destination device - NOW. > > For some OS's there is no need to do a kernel flush(), as the I/O is > synchronized already. Since this is java, you never know what OS your on. (well, but if you're going to kernel level, even flush cannot guarantee that data will "be physically placed". Maybe you're flushing to a file via NFS (and the client "thinks" that it was written, but maybe it was just buffered by the NFS server) or so... but of course such exceptions of the rules are constructable always.) Well, you tell that depending on the OS it can be that flush is needed or it can be that flush is not needed (beacuse the I/O is synchronized already), right? Also, applications should work on any OS, which includes the OSes that do need flush. Since the application cannot know whether flush is needed or not because it doesn't know what the OS is doing, it has to call flush, hasn't it? I mean, if it would not call flush then it would not work on such OSes (except the written data would not be needed at all, but in this would be an artificial example :)). Since applications are supposed to work this would be wrong, wouldn't it? So would it be correct to say: "Applications, that should work under all OSes (including the OSes where the I/O is not synchronised already), have to call flush on OutputStream to ensure the data is transfered to the kernel." or is this wrong? If so, then I'm afraid I missed the point again :( oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Tue Jun 12 04:46:52 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 12 Jun 2007 06:46:52 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070612081447.GU10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> <20070612081447.GU10821@elberon.bln.de.ingenico.com> Message-ID: <466E799C.7060700@gatworks.com> S > (well, but if you're going to kernel level, even flush cannot > guarantee that data will "be physically placed". Thats true now-a-days because ( from "man 2 sync" ) : > According to the standard specification (e.g., SVID), sync() schedules > the writes, but may return before the actual writing is done. However, > since version 1.3.20 Linux does actually wait. (This still does not > guarantee data integrity: modern disks have large caches.) My disk drive has 8mb cache. Maybe you're > flushing to a file via NFS (and the client "thinks" that it was > written, but maybe it was just buffered by the NFS server) or > so... but of course such exceptions of the rules are > constructable always.) > > Well, you tell that depending on the OS it can be that flush is > needed or it can be that flush is not needed (beacuse the I/O is > synchronized already), right? Also, applications should work on > any OS, which includes the OSes that do need flush. Its not OS's that need flush, its applications that want to have some assurance that data is written to the device that really needs to use flush. If your program ( or thread ) dies then it is in your best interest to write out the critical data as soon as possible, as economical as possible. These are trade-off's that the application programmer makes. A big buffer may mean big loss of data, a small buffer may mean spending too much time writing out data. > > > So would it be correct to say: > > "Applications, that should work under all OSes (including the > OSes where the I/O is not synchronised already), have to call > flush on OutputStream to ensure the data is transfered to the > kernel." > > or is this wrong? If so, then I'm afraid I missed the point again > :( > No that is not wrong. Ensuring that data is transfered to the OS is just about what any application can do. From tjarvi at qbang.org Thu Jun 14 08:16:47 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 14 Jun 2007 08:16:47 -0600 (MDT) Subject: [Rxtx] rxtx and usb-serial solution In-Reply-To: References: Message-ID: On Thu, 14 Jun 2007, Vladimir Kirtchev wrote: > Hi Trent, > > I develop a Java application which communicates with devices which have > USB-to-Serial bridge in them. The target OS is Linux. So for this purpose I > use RXTX. > > But I encountered a strange problem - when reading from the InputStream, I > receive series of zeros. I have this problem under Linux only. Under Windows > it is fine. > Actually this problem is the same as the one described here: > http://marc.info/?l=rxtx&m=109703190731748&w=2. > > > So I searched for the problem in the native code. And found that the root of > the problem is in SerialImp.c, > int configure_port( int fd ) > { > ... > ttyset.c_iflag = INPCK; > ... > } > > This line enables input parity checking, and the data sent from the device > is processed by the OS driver before being read with read(). > In this case the driver detects some problem and sets the received bytes to > zero. > > On the other hand in the Java part a set the serial port parameters with > SerialPort.PARITY_NONE. According to me, except all other things, this > should also disable INPCK in c_iflag. > > So I refactored the method translate_parity(...) to the following: > > int translate_parity( JNIEnv *env, struct termios *ttyset, jint parity ) > { > ENTER( "translate_parity" ); > #ifdef CMSPAR > ttyset->c_cflag &= ~(PARENB | PARODD | CMSPAR ); > #endif /* CMSPAR */ > switch( parity ) { > case JPARITY_NONE: > ttyset->c_iflag &= ~INPCK; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_EVEN: > ttyset->c_cflag |= PARENB; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_ODD: > ttyset->c_cflag |= PARENB | PARODD; > LEAVE( "translate_parity" ); > return 0; > #ifdef CMSPAR > case JPARITY_MARK: > ttyset->c_cflag |= PARENB | PARODD | CMSPAR; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_SPACE: > ttyset->c_cflag |= PARENB | CMSPAR; > LEAVE( "translate_parity" ); > return 0; > #endif /* CMSPAR */ > default: > printf("Parity missed %i\n", (int) parity ); > } > > LEAVE( "translate_parity" ); > /* > For some reason the native exceptions are not being caught. Moving this > to the Java side fixed the issue. taj. > throw_java_exception( env, UNSUPPORTED_COMM_OPERATION, > "", "parity value not supported" ); > */ > return 1; > } > > This modification solved the problem and now it works correctly under Linux. > > I think I will be a nice if this is idea is included in a future release of > RXTX. > > Thanks Vadim, I'll try that out. Forwarding to the rxtx mail-list too. This is probably not going to help USB drivers on windows which I'm sure some are looking for. As far as I can tell, windows USB bluetooth and serial dongles are limited by driver functionality. Some are good and others lack key features. -- Trent Jarvi tjarvi at qbang.org From dan.sandberg.lists at gmail.com Mon Jun 18 14:43:39 2007 From: dan.sandberg.lists at gmail.com (Dan Sandberg) Date: Mon, 18 Jun 2007 13:43:39 -0700 Subject: [Rxtx] Fix for JNI Get/Set Field Errors Message-ID: <4676EE7B.7060800@gmail.com> Hi, I've fixed the problems that cause the following JNI error when extra JNI checking ( -Xjni:check ) is turned on. FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) The problem was basically that GetLong was being used to get ints, and SetInt was used for longs. The patch below fixes this. Please let me know if there are any questions / problems. Cheers, -Dan diff -aur old/SerialImp.c src/SerialImp.c --- old/SerialImp.c 2007-06-18 13:24:33.000000000 -0700 +++ src/SerialImp.c 2007-06-18 06:26:26.000000000 -0700 @@ -1337,7 +1337,7 @@ report("init_threads: get eis\n"); jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); report("init_threads: set eis\n"); - (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); + (*eis->env)->SetLongField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); report("init_threads: stop\n"); report_time_end( ); return( 1 ); @@ -1530,7 +1530,7 @@ jobject jobj, jboolean interrupted ) { int fd = get_java_var( env, jobj,"fd","I" ); - struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var( env, jobj, "eis", "J" ); + struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var_long( env, jobj, "eis", "J" ); int result, count=0; char message[80]; @@ -2939,7 +2939,7 @@ /* TRENT */ int flag, count = 0; struct event_info_struct *eis = ( struct event_info_struct * ) - get_java_var( env, *jobj,"eis","J" ); + get_java_var_long( env, *jobj,"eis","J" ); report_time_start(); flag = eis->eventflags[SPE_DATA_AVAILABLE]; @@ -4873,9 +4873,9 @@ exceptions: none comments: ----------------------------------------------------------*/ -size_t get_java_var( JNIEnv *env, jobject jobj, char *id, char *type ) +long get_java_var_long( JNIEnv *env, jobject jobj, char *id, char *type ) { - int result = 0; + long result = 0; jclass jclazz = (*env)->GetObjectClass( env, jobj ); jfieldID jfd = (*env)->GetFieldID( env, jclazz, id, type ); @@ -4889,7 +4889,11 @@ LEAVE( "get_java_var" ); return result; } - result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); + if ( !strcmp( type, "J" ) ) { + result = (long)( (*env)->GetLongField( env, jobj, jfd ) ); + } else { + result = (int) ( (*env)->GetIntField( env, jobj, jfd ) ); + } /* ct7 & gel * Added DeleteLocalRef */ (*env)->DeleteLocalRef( env, jclazz ); if(!strncmp( "fd",id,2) && result == 0) @@ -4900,6 +4904,10 @@ return result; } +int get_java_var( JNIEnv *env, jobject jobj, char *id, char *type ) { + return (int) get_java_var_long( env, jobj, id, type ); +} + /*---------------------------------------------------------- throw_java_exception diff -aur old/SerialImp.h src/SerialImp.h --- old/SerialImp.h 2007-06-18 13:24:39.000000000 -0700 +++ src/SerialImp.h 2007-06-18 06:23:43.000000000 -0700 @@ -413,7 +413,8 @@ void system_wait(); void finalize_event_info_struct( struct event_info_struct * ); int read_byte_array( JNIEnv *, jobject *, int, unsigned char *, int, int ); -size_t get_java_var( JNIEnv *, jobject, char *, char * ); +int get_java_var( JNIEnv *, jobject, char *, char * ); +long get_java_var_long( JNIEnv *, jobject, char *, char * ); jboolean is_interrupted( struct event_info_struct * ); int send_event(struct event_info_struct *, jint, int ); void dump_termios(char *,struct termios *); From yvespielusenet at free.fr Tue Jun 26 03:41:58 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 11:41:58 +0200 Subject: [Rxtx] [PARALLEL] resource in use Message-ID: <1182850918.3483.10.camel@localhost.localdomain> Hello, So now I want to modify the timeout of the library for parallel port. I have downloaded source code. There is a makefile for migw. SO I have installed mingw on ubuntu and modified the makefile.mingw32 to set it for my system. I have no error but some warnings. The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But When I want to use it the jvm crash :( How can I know what is wrong ? How rxtx windows release has been done ? thanks -- yves piel From yvespielusenet at free.fr Tue Jun 26 07:17:02 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 15:17:02 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182850918.3483.10.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> Message-ID: <1182863822.3483.17.camel@localhost.localdomain> Here is the Makefile I use, the output of the 'make' and the log of the jvm when it crashed : - The Makefile : http://yvespiel.free.fr/rxtx/Makefile - The make output : http://yvespiel.free.fr/rxtx/compile.txt - The crash log : http://yvespiel.free.fr/rxtx/hs_err_pid2100.log I have compiled rxtx under Debian testing with mingw : narma at linimi:/tmp/err$ dpkg -l | grep mingw ii mingw32 3.4.5.20060117.1.dfsg-3 ii mingw32-binutils 2.17.50-20070129.1-1 ii mingw32-runtime 3.12-1 thanks fort help :) Le mardi 26 juin 2007 ? 11:41 +0200, yves pielusenet a ?crit : > Hello, > So now I want to modify the timeout of the library for parallel port. I > have downloaded source code. There is a makefile for migw. SO I have > installed mingw on ubuntu and modified the makefile.mingw32 to set it > for my system. > I have no error but some warnings. > The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But > When I want to use it the jvm crash :( > > How can I know what is wrong ? > > How rxtx windows release has been done ? > > thanks > From yvespielusenet at free.fr Tue Jun 26 07:40:11 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 15:40:11 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182863822.3483.17.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> <1182863822.3483.17.camel@localhost.localdomain> Message-ID: <1182865211.3483.21.camel@localhost.localdomain> I have add the options '--enable-stdcall-fixup' to the 'i586-mingw32msvc-ld' commande. Now I have no warning. But the JVM always crashes :( The output seems more detailled, but I don't understand anything... Here is files : http://yvespiel.free.fr/rxtx/2/ -- yves piel Le mardi 26 juin 2007 ? 15:17 +0200, yves pielusenet a ?crit : > Here is the Makefile I use, the output of the 'make' and the log of the > jvm when it crashed : > > - The Makefile : http://yvespiel.free.fr/rxtx/Makefile > - The make output : http://yvespiel.free.fr/rxtx/compile.txt > - The crash log : http://yvespiel.free.fr/rxtx/hs_err_pid2100.log > > I have compiled rxtx under Debian testing with mingw : > narma at linimi:/tmp/err$ dpkg -l | grep mingw > ii mingw32 3.4.5.20060117.1.dfsg-3 > ii mingw32-binutils 2.17.50-20070129.1-1 > ii mingw32-runtime 3.12-1 > > thanks fort help :) > > > Le mardi 26 juin 2007 ? 11:41 +0200, yves pielusenet a ?crit : > > Hello, > > So now I want to modify the timeout of the library for parallel port. I > > have downloaded source code. There is a makefile for migw. SO I have > > installed mingw on ubuntu and modified the makefile.mingw32 to set it > > for my system. > > I have no error but some warnings. > > The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But > > When I want to use it the jvm crash :( > > > > How can I know what is wrong ? > > > > How rxtx windows release has been done ? > > > > thanks > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From yvespielusenet at free.fr Tue Jun 26 08:27:42 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 16:27:42 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182865211.3483.21.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> <1182863822.3483.17.camel@localhost.localdomain> <1182865211.3483.21.camel@localhost.localdomain> Message-ID: <1182868062.3483.24.camel@localhost.localdomain> I think thant the include files of jdk were not for windows but for linux. So I have copied include/ folder from windows to linux and I modified the Makefile to use those file. It compile fine but the JVM always crash :( http://yvespiel.free.fr/rxtx/3/ Le mardi 26 juin 2007 ? 15:40 +0200, yves pielusenet a ?crit : > I have add the options '--enable-stdcall-fixup' to the > 'i586-mingw32msvc-ld' commande. Now I have no warning. But the JVM > always crashes :( The output seems more detailled, but I don't > understand anything... > Here is files : > http://yvespiel.free.fr/rxtx/2/ > From netbeans at gatworks.com Fri Jun 1 05:38:50 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 07:38:50 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <465F7ADD.1010501@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> Message-ID: <4660054A.2040202@gatworks.com> Manuel Naranjo wrote: In the case of my module, you can > unplug the device but it will not delete the symlink until those apps > that had opened the port has closed it. This is done this way to avoid > kernel panics. What does this mean to user code ? I have tried the alternate route ( other than closing ) which is sleep inbetween the I/O errors ( an unplugged USB device). When the device is plugged back in, The writes to the device still get an I/O error. This would seem to be a lost cause for the application. From netbeans at gatworks.com Fri Jun 1 06:35:48 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 08:35:48 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <465F7ADD.1010501@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> Message-ID: <466012A4.90608@gatworks.com> Manuel Naranjo wrote: In the case of my module, you can > unplug the device but it will not delete the symlink until those apps > that had opened the port has closed it. T Did u also mean for this to happen? USB0 was not closed by application. Apparently USB1 got created when USB device was plugged back in. There is only one USB device on a 4 port USB hub. This also seems to suggest that application recovery to be impossible. > Jun 1 07:10:08 mylaptop kernel: garmin_gps 1-1.4:1.0: Garmin GPS usb/tty converter detected > Jun 1 07:10:08 mylaptop kernel: usb 1-1.4: Garmin GPS usb/tty converter now attached to ttyUSB0 > Jun 1 07:15:17 mylaptop kernel: usb 1-1: USB disconnect, address 4 > Jun 1 07:15:17 mylaptop kernel: usb 1-1.4: USB disconnect, address 5 > Jun 1 07:15:17 mylaptop kernel: garmin_gps 1-1.4:1.0: device disconnected > Jun 1 07:15:26 mylaptop kernel: usb 1-1: new full speed USB device using uhci_hcd and address 6 > Jun 1 07:15:26 mylaptop kernel: hub 1-1:1.0: USB hub found > Jun 1 07:15:26 mylaptop kernel: hub 1-1:1.0: 4 ports detected > Jun 1 07:15:27 mylaptop kernel: usb 1-1.4: new full speed USB device using uhci_hcd and address 7 > Jun 1 07:15:27 mylaptop kernel: garmin_gps 1-1.4:1.0: Garmin GPS usb/tty converter detected > Jun 1 07:15:27 mylaptop kernel: usb 1-1.4: Garmin GPS usb/tty converter now attached to ttyUSB1 From naranjo.manuel at gmail.com Fri Jun 1 09:17:22 2007 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Fri, 01 Jun 2007 12:17:22 -0300 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <466012A4.90608@gatworks.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> <466012A4.90608@gatworks.com> Message-ID: <46603882.5050701@gmail.com> Uncle George escribi?: > Manuel Naranjo wrote: > In the case of my module, you can > >> unplug the device but it will not delete the symlink until those apps >> that had opened the port has closed it. T >> > > Did u also mean for this to happen? USB0 was not closed by application. > > Apparently USB1 got created when USB device was plugged back in. There > is only one USB device on a 4 port USB hub. > > This also seems to suggest that application recovery to be impossible. > Exactly there's a dead symlink (you can read and write to it and nothing will happen) and a new port will be created when a new device is connencted. From netbeans at gatworks.com Fri Jun 1 10:20:46 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 12:20:46 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <46603882.5050701@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> <466012A4.90608@gatworks.com> <46603882.5050701@gmail.com> Message-ID: <4660475E.5090202@gatworks.com> Not sure what u mean by "symlink". U cant read/write to it anymore. U get I/O error. In this scenario the device effectively went dead, and only solution is to close the channel. reconnecting the USB device, although dead, but not closed, will create a second device. This does not seem to be a desirable side-effect. The user will now have ttyUSB1, wondering where did ttyUSB0 go to. The application will also be in a confused state, as well as RXTX, because RXTX wont know about ttyUSB1. Manuel Naranjo wrote: > Uncle George escribi?: >> Manuel Naranjo wrote: >> In the case of my module, you can >> >>> unplug the device but it will not delete the symlink until those apps >>> that had opened the port has closed it. T >>> >> Did u also mean for this to happen? USB0 was not closed by application. >> >> Apparently USB1 got created when USB device was plugged back in. There >> is only one USB device on a 4 port USB hub. >> >> This also seems to suggest that application recovery to be impossible. >> > Exactly there's a dead symlink (you can read and write to it and nothing > will happen) and a new port will be created when a new device is connencted. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From arnab.bhaumik at gmail.com Mon Jun 4 01:40:16 2007 From: arnab.bhaumik at gmail.com (arnab bhaumik) Date: Mon, 4 Jun 2007 13:10:16 +0530 Subject: [Rxtx] full duplex com port with rxtx Message-ID: hi , till now i did half duplex communication with rxtx package on com package. my question is : is it possible to use com port with full duplex mode with rxtx package . ther is example of SimpleRead class and SimpleWrite class. it is clear that if i can use both the class simultaneously then full duplex is possible......... arnab/vu2bpw -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070604/6edb0453/attachment-0004.html From lists at iDIAcomputing.com Mon Jun 4 07:53:17 2007 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Mon, 04 Jun 2007 09:53:17 -0400 Subject: [Rxtx] full duplex com port with rxtx In-Reply-To: References: Message-ID: <4664194D.90301@iDIAcomputing.com> arnab bhaumik wrote: > hi , > > till now i did half duplex communication with rxtx package on com > package. > > my question is : is it possible to use com port with full duplex mode > with rxtx package . > > > ther is example of SimpleRead class and SimpleWrite class. it is > clear that if i can use both the class simultaneously then full duplex > is possible......... I haven't looked at the SimpleRead and SimpleWrite classes (I originally wrote my code for the javax.comm api), but full duplex is certainly possible. My CommReader class requires an object analogous to a OutputStream or Writer. When started, it spawns a thread that reads the comm port and writes to that output device. In this way the input is asynchronous and dependent on the actual input data. For full duplex, I extend that class with CommReaderWriter, which adds synchronous output methods. Hope that helps, George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From supsoop at hotmail.com Mon Jun 4 15:21:06 2007 From: supsoop at hotmail.com (soop soop) Date: Mon, 04 Jun 2007 21:21:06 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- Message-ID: Hi Guys, Looked through the archives but still cannot figure this out. I have a Motorola G24 GPRS/GSM modem that I am connecting to my server running Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not detecting the port, CommPortIdentifier.getPortIdentifiers(). I have added the line to RXTXCommDriver: "ttyACM" // for USB Modems Rxtx still does not seem to find the port. Is there something I am missing to make this port visable? [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control Model driver for USB modems and ISDN adapters I really need your help as I have moved my server from windows to Linux and have been down for a few days because of this .. Thanks so much! _________________________________________________________________ PC Magazine’s 2007 editors’ choice for best Web mail—award-winning Windows Live Hotmail. http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 From tjarvi at qbang.org Mon Jun 4 16:17:35 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Jun 2007 16:17:35 -0600 (MDT) Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: On Mon, 4 Jun 2007, soop soop wrote: > Hi Guys, > > Looked through the archives but still cannot figure this out. I have a > Motorola G24 GPRS/GSM modem that I am connecting to my server running Ubuntu. > I can see my modem as is shows up as ttyACM0, but RXTX is not detecting the > port, CommPortIdentifier.getPortIdentifiers(). > > I have added the line to RXTXCommDriver: > > "ttyACM" // for USB Modems > > Rxtx still does not seem to find the port. Is there something I am missing to > make this port visable? > > [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver > [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device > [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control Model > driver for USB modems and ISDN adapters > > I really need your help as I have moved my server from windows to Linux and > have been down for a few days because of this .. Thanks so much! > You could try the INSTALL documentation that comes with the source for possible solutions. Those usually involve lockfile creation, permissions on the device file or the device is in use by another application (even another session of your application). The usual commands: ls -l /dev/ttyACM0 fuser /dev/ttyACM0 touch /var/lock/LCK.testfile && rm -f /var/lock/LCK.testfile whoami To disable lockfiles: ../configure --disable-lockfiles && make install -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Jun 4 16:22:52 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 04 Jun 2007 18:22:52 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <466490BC.3090801@gatworks.com> soop soop wrote: > I really need your help as I have moved my server from windows to Linux > and have been down for a few days because of this .. Thanks so much! can u open the device ? ie is the file protection/permissions keeping you out? From supsoop at hotmail.com Mon Jun 4 16:44:40 2007 From: supsoop at hotmail.com (soop soop) Date: Mon, 04 Jun 2007 22:44:40 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <466490BC.3090801@gatworks.com> Message-ID: Thanks for the reply, I see no exceptions being thrown, just no detection of the port whats so ever. I will run rxtx in debug mode and log. If this were a permissions issue would I not see some exceptions being thrown? >From: Uncle George >Reply-To: RXTX Developers and Users >To: RXTX Developers and Users >Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >Date: Mon, 04 Jun 2007 18:22:52 -0400 > >soop soop wrote: > > > I really need your help as I have moved my server from windows to Linux > > and have been down for a few days because of this .. Thanks so much! > >can u open the device ? ie is the file protection/permissions keeping >you out? >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ Get a preview of Live Earth, the hottest event this summer - only on MSN http://liveearth.msn.com?source=msntaglineliveearthhm From netbeans at gatworks.com Mon Jun 4 17:06:15 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 04 Jun 2007 19:06:15 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <46649AE7.10405@gatworks.com> Exceptions on what? On startup it wants to lookup all devices in /dev that it is capable of opening ( within the list of specific 'comm' devices ). If it cannot open, then does not get onto list. Part of this process, if configured, will also test if the "LOCK" schema can also be opened for the device. then it gets on the list of avail comm port. soop soop wrote: > Thanks for the reply, > > I see no exceptions being thrown, just no detection of the port whats so > ever. I will run rxtx in debug mode and log. If this were a permissions > issue would I not see some exceptions being thrown? > > >> From: Uncle George >> Reply-To: RXTX Developers and Users >> To: RXTX Developers and Users >> Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >> Date: Mon, 04 Jun 2007 18:22:52 -0400 >> >> soop soop wrote: >> >>> I really need your help as I have moved my server from windows to Linux >>> and have been down for a few days because of this .. Thanks so much! >> can u open the device ? ie is the file protection/permissions keeping >> you out? >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _________________________________________________________________ > Get a preview of Live Earth, the hottest event this summer - only on MSN > http://liveearth.msn.com?source=msntaglineliveearthhm > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From alex.flint at gmail.com Mon Jun 4 21:31:49 2007 From: alex.flint at gmail.com (Alex Flint) Date: Tue, 5 Jun 2007 13:01:49 +0930 Subject: [Rxtx] random EXCEPTION_ACCESS_VIOLATION errors Message-ID: Hi All, I'm running winXP and RXTX 2.1-7r2 (the latest from the webpage as of June 2007). I'm sending sequences of 64 lines (each line has about 15 chars) at various intervals. The strings are sent fine, until I get the following error (from hs_err_pid3316.log, at the end of this email). What can I do to avoid the error? Obviously this is a low-level memory exception, but is there any way I can keep the JVM running after such an error? I noticed the exact same problem here: http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20070129/1180520.html Cheers, Alex # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x100034fb, pid=3316, tid=2400 # # Java VM: Java HotSpot(TM) Client VM (1.6.0_01-b06 mixed mode, sharing) # Problematic frame: # C [rxtxSerial.dll+0x34fb] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # --------------- T H R E A D --------------- Current thread (0x00386400): JavaThread "main" [_thread_in_native, id=2400] siginfo: ExceptionCode=0xc0000005, reading address 0x20726f78 Registers: EAX=0x20726f20, EBX=0x6d8922c0, ECX=0x00000005, EDX=0x20726f20 ESP=0x003efa30, EBP=0x003efb68, ESI=0x269728a0, EDI=0x00386400 EIP=0x100034fb, EFLAGS=0x00010212 Top of Stack: (sp=0x003efa30) 0x003efa30: 003efa3c 003efa64 0000000f ffffffff 0x003efa40: 003efa40 2a97f808 003efa6c 2b190ca8 0x003efa50: 00000000 2b190ec0 003efa90 008e2dd7 0x003efa60: 003efa90 008e2dd7 26977f88 6d815e72 0x003efa70: 00000004 2696eae0 0000008a 003efb0c 0x003efa80: 6d852b4a 2696eae0 00000003 26970930 0x003efa90: 000000cb 2696eae0 6d86b264 00385d40 0x003efaa0: 0000003f 003efb0c 26977f90 2ace65d8 Instructions: (pc=0x100034fb) 0x100034eb: ff ff 8d 76 00 eb 02 89 f6 90 8b 45 f8 8b 55 f8 0x100034fb: 8b 4a 58 83 c9 04 89 48 58 83 c4 f8 8b 45 f8 8b Stack: [0x003a0000,0x003f0000), sp=0x003efa30, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x34fb] Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j gnu.io.RXTXPort.writeArray([BIIZ)V+0 j gnu.io.RXTXPort$SerialOutputStream.write([B)V+76 j com.bjt.media.server.CommLink.send(Ljava/lang/String;)V+48 j com.bjt.media.server.DigitoolConnection.select(I)V+73 j com.bjt.media.server.DigitoolConnection.main([Ljava/lang/String;)V+74 v ~StubRoutines::call_stub --------------- P R O C E S S --------------- Java Threads: ( => current thread ) 0x02a69400 JavaThread "Thread-0" [_thread_in_native, id=3052] 0x02a4d000 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=3920] 0x02a48400 JavaThread "CompilerThread0" daemon [_thread_blocked, id=1968] 0x02a47400 JavaThread "Attach Listener" daemon [_thread_blocked, id=2984] 0x02a46400 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=2660] 0x02a41c00 JavaThread "Finalizer" daemon [_thread_blocked, id=3924] 0x02a3d800 JavaThread "Reference Handler" daemon [_thread_blocked, id=4008] =>0x00386400 JavaThread "main" [_thread_in_native, id=2400] Other Threads: 0x02a34400 VMThread [id=3708] 0x02a4e800 WatcherThread [id=3964] VM state:not at safepoint (normal execution) VM Mutex/Monitor currently owned by a thread: None Heap def new generation total 960K, used 131K [0x22960000, 0x22a60000, 0x22e40000) eden space 896K, 7% used [0x22960000, 0x22970ea8, 0x22a40000) from space 64K, 99% used [0x22a50000, 0x22a5fff8, 0x22a60000) to space 64K, 0% used [0x22a40000, 0x22a40000, 0x22a50000) tenured generation total 4096K, used 76K [0x22e40000, 0x23240000, 0x26960000) the space 4096K, 1% used [0x22e40000, 0x22e53060, 0x22e53200, 0x23240000) compacting perm gen total 12288K, used 137K [0x26960000, 0x27560000, 0x2a960000) the space 12288K, 1% used [0x26960000, 0x26982518, 0x26982600, 0x27560000) ro space 8192K, 62% used [0x2a960000, 0x2ae5e4e8, 0x2ae5e600, 0x2b160000) rw space 12288K, 52% used [0x2b160000, 0x2b7a0e78, 0x2b7a1000, 0x2bd60000) Dynamic libraries: 0x00400000 - 0x00423000 C:\Program Files\Java\jre1.6.0_01\bin\javaw.exe 0x7c900000 - 0x7c9b0000 C:\WINDOWS\system32\ntdll.dll 0x7c800000 - 0x7c8f4000 C:\WINDOWS\system32\kernel32.dll 0x77dd0000 - 0x77e6b000 C:\WINDOWS\system32\ADVAPI32.dll 0x77e70000 - 0x77f01000 C:\WINDOWS\system32\RPCRT4.dll 0x7e410000 - 0x7e4a0000 C:\WINDOWS\system32\USER32.dll 0x77f10000 - 0x77f57000 C:\WINDOWS\system32\GDI32.dll 0x76390000 - 0x763ad000 C:\WINDOWS\system32\IMM32.DLL 0x7c340000 - 0x7c396000 C:\Program Files\Java\jre1.6.0_01\bin\msvcr71.dll 0x6d7c0000 - 0x6da07000 C:\Program Files\Java\jre1.6.0_01\bin\client\jvm.dll 0x76b40000 - 0x76b6d000 C:\WINDOWS\system32\WINMM.dll 0x5cd70000 - 0x5cd77000 C:\WINDOWS\system32\serwvdrv.dll 0x5b0a0000 - 0x5b0a7000 C:\WINDOWS\system32\umdmxfrm.dll 0x6d310000 - 0x6d318000 C:\Program Files\Java\jre1.6.0_01\bin\hpi.dll 0x76bf0000 - 0x76bfb000 C:\WINDOWS\system32\PSAPI.DLL 0x6d770000 - 0x6d77c000 C:\Program Files\Java\jre1.6.0_01\bin\verify.dll 0x6d3b0000 - 0x6d3cf000 C:\Program Files\Java\jre1.6.0_01\bin\java.dll 0x6d7b0000 - 0x6d7bf000 C:\Program Files\Java\jre1.6.0_01\bin\zip.dll 0x10000000 - 0x10012000 C:\Documents and Settings\Alex\workspace\MediaServer\rxtxSerial.dll 0x73d90000 - 0x73db7000 C:\WINDOWS\system32\crtdll.dll VM Arguments: jvm_args: -Djava.library.path=C:\Documents and Settings\Alex\workspace\MediaServer java_command: com.bjt.media.server.DigitoolConnection Launcher Type: SUN_STANDARD Environment Variables: CLASSPATH=.;C:\Program Files\Java\j2re1.4.2_07\lib\ext\QTJava.zip PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\wbem;c:\applications\php;C:\Program Files\MATLAB\R2006a\bin\win32;C:\Roger\Projects\UAV\Bin\Debug;C:\Program Files\Microsoft SQL Server\80\Tools\Binn\;c:\Program Files\Microsoft SQL Server\90\Tools\binn\;C:\Program Files\QuickTime\QTSystem\;C:\Pfps\system;C:\Program Files\Java\jdk1.6.0_01\bin;C:\Program Files\Java\jdk1.6.0_01\jre\bin USERNAME=Alex OS=Windows_NT PROCESSOR_IDENTIFIER=x86 Family 15 Model 4 Stepping 1, GenuineIntel --------------- S Y S T E M --------------- OS: Windows XP Build 2600 Service Pack 2 CPU:total 1 family 15, cmov, cx8, fxsr, mmx, sse, sse2 Memory: 4k page, physical 1046508k(275288k free), swap 2522816k(1909176k free) vm_info: Java HotSpot(TM) Client VM (1.6.0_01-b06) for windows-x86, built on Mar 14 2007 00:24:02 by "java_re" with unknown MS VC++:1310 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070604/c87ae1f0/attachment-0004.html From alwyn.schoeman at gmail.com Tue Jun 5 00:10:19 2007 From: alwyn.schoeman at gmail.com (Alwyn Schoeman) Date: Tue, 5 Jun 2007 08:10:19 +0200 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Hi, I'm using a similar modem. By default rxtx doesn't look for devices that start with ACM, so you need to modify the source code and recompile. Look in RXTXCommDriver and add values for ACM in the registerScannedPorts method in the Linux specific parts. Look for osName.equals("Linux")... On 6/4/07, soop soop wrote: > > Hi Guys, > > Looked through the archives but still cannot figure this out. I have a > Motorola G24 GPRS/GSM modem that I am connecting to my server running > Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not > detecting the port, CommPortIdentifier.getPortIdentifiers(). > > I have added the line to RXTXCommDriver: > > "ttyACM" // for USB Modems > > Rxtx still does not seem to find the port. Is there something I am missing > to make this port visable? > > [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver > [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device > [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control > Model > driver for USB modems and ISDN adapters > > I really need your help as I have moved my server from windows to Linux > and > have been down for a few days because of this .. Thanks so much! > > _________________________________________________________________ > PC Magazine's 2007 editors' choice for best Web mail?award-winning Windows > Live Hotmail. > > http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -- Alwyn Schoeman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/b6cb3053/attachment-0004.html From naranjo.manuel at gmail.com Tue Jun 5 06:48:45 2007 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Tue, 05 Jun 2007 09:48:45 -0300 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> References: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Message-ID: <46655BAD.7010501@gmail.com> That's right, an easier solution is creating symlinks to acm. For example make ttyS70 to 79 point to ACM0 to 9 and that will help you a lot, and doesn't even require compile. > Hi, > > I'm using a similar modem. By default rxtx doesn't look for devices > that start with ACM, so you need to modify the > source code and recompile. > > Look in RXTXCommDriver and add values for ACM in the > registerScannedPorts method in the Linux specific parts. Look for > osName.equals("Linux")... > From juanemc2 at gmail.com Tue Jun 5 07:02:43 2007 From: juanemc2 at gmail.com (Juan) Date: Tue, 5 Jun 2007 10:02:43 -0300 Subject: [Rxtx] Problems with Epson TMU220B POSPrinter using XON/XOFF Flow Control and rxtx jar and dll's with the serial port. Message-ID: Hi!, I?m having trouble printing to the serial port using the latest version of rxtx jar and dll's with an Epson POSPrinter. I`ve switched the printer to work with XON/XOFF Flow Control and have watched the serial port to be sure the printer is sending the XON XOFF stop and go characters. I`ve setted the port like this: CommPortIdentifier commPortIdentifier = CommPortIdentifier.* getPortIdentifier*(_portName); SerialPort serialPort = (SerialPort)commPortIdentifier.open(*this*.getClass().getName(), 2000); serialPort.setSerialPortParams(_baudRate, _dataBits, _stopBits, _parity); serialPort.setFlowControlMode( SerialPort.*FLOWCONTROL_XONXOFF_IN* | SerialPort.*FLOWCONTROL_XONXOFF_OUT*); where the baudRate is 9600 the dataBits is 8 the stopBits is 1 and the parity is 0 It seems as the library isn`t taking into account the XON XOFF setting. I would like to know if I`m setting correctly the Flow Control and if you had had any experiences using XON XOFF flow control and could give me some help to solve my problem. I`m very thankful in advance, Yours, Juan Polero -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/b080995a/attachment-0004.html From ehdez.correo at gmail.com Tue Jun 5 07:12:53 2007 From: ehdez.correo at gmail.com (=?ISO-8859-1?Q?Enrique_Hern=E1ndez?=) Date: Tue, 5 Jun 2007 09:12:53 -0400 Subject: [Rxtx] problem with rxtx Message-ID: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Hello: I doing a simple test to show the serial ports. This is the code: import java.util.Enumeration; import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; public class Show { private Enumeration portList; private CommPortIdentifier portId; private SerialPort port; /** Creates a new instance of Show */ public Show() { } public static void main(String args[]){ Show show = new Show(); show.portList = CommPortIdentifier.getPortIdentifiers(); String tPort = ""; System.out.println("========================================="); while(show.portList.hasMoreElements()){ show.portId = (CommPortIdentifier)show.portList.nextElement(); if(show.portId.getPortType() == CommPortIdentifier.PORT_SERIAL) tPort = "Serial"; else tPort = "Parallel"; System.out.println(show.portId.getName() + " " + tPort); } } } whit The problem is that this code not show the serial ports, this show the no use serial ports. I want to connect whit the modem but when windows open and connect the modem my application don't see the port(COMM3) when it is connect. what I can do? Is that the correct way to know the ports? thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/eedd744b/attachment-0004.html From ehdez.correo at gmail.com Tue Jun 5 07:42:13 2007 From: ehdez.correo at gmail.com (=?ISO-8859-1?Q?Enrique_Hern=E1ndez?=) Date: Tue, 5 Jun 2007 09:42:13 -0400 Subject: [Rxtx] serial port Message-ID: <4a814e1f0706050642p4ce9ac7bka80f9479c524c5ea@mail.gmail.com> Hello: How I can ask to the port what device is connect and information about this device. thanks. bye. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/4d10d26a/attachment-0004.html From supsoop at hotmail.com Tue Jun 5 09:29:00 2007 From: supsoop at hotmail.com (soop soop) Date: Tue, 05 Jun 2007 15:29:00 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Message-ID: Hi Guys, Thanks for all your help. I found the problem. I created a user, Tomcat55, for my tomcat but it did not belong to any group. I then added this user to dialout group to have access to the device ttyACM0. Works perfectly! Again permissions was the issue. This also seems to be persistent as a server reboot does not effect the access. Cheers! >From: "Alwyn Schoeman" >Reply-To: RXTX Developers and Users >To: "RXTX Developers and Users" >Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >Date: Tue, 5 Jun 2007 08:10:19 +0200 > >Hi, > >I'm using a similar modem. By default rxtx doesn't look for devices that >start with ACM, so you need to modify the >source code and recompile. > >Look in RXTXCommDriver and add values for ACM in the registerScannedPorts >method in the Linux specific parts. Look for osName.equals("Linux")... > >On 6/4/07, soop soop wrote: >> >>Hi Guys, >> >>Looked through the archives but still cannot figure this out. I have a >>Motorola G24 GPRS/GSM modem that I am connecting to my server running >>Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not >>detecting the port, CommPortIdentifier.getPortIdentifiers(). >> >>I have added the line to RXTXCommDriver: >> >>"ttyACM" // for USB Modems >> >>Rxtx still does not seem to find the port. Is there something I am missing >>to make this port visable? >> >>[ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver >>[ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device >>[ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control >>Model >>driver for USB modems and ISDN adapters >> >>I really need your help as I have moved my server from windows to Linux >>and >>have been down for a few days because of this .. Thanks so much! >> >>_________________________________________________________________ >>PC Magazine's 2007 editors' choice for best Web mail—award-winning Windows >>Live Hotmail. >> >>http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 >> >> >>_______________________________________________ >>Rxtx mailing list >>Rxtx at qbang.org >>http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > >-- >Alwyn Schoeman >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ Need a break? Find your escape route with Live Search Maps. http://maps.live.com/default.aspx?ss=Restaurants~Hotels~Amusement%20Park&cp=33.832922~-117.915659&style=r&lvl=13&tilt=-90&dir=0&alt=-1000&scene=1118863&encType=1&FORM=MGAC01 From netbeans at gatworks.com Tue Jun 5 09:42:31 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 11:42:31 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <46658467.20101@gatworks.com> soop soop wrote: > > Hi Guys, > > Thanks for all your help. I found the problem. I created a user, > Tomcat55, for my tomcat but it did not belong to any group. I then added Look at man pages for the program udev. From tjarvi at qbang.org Tue Jun 5 18:18:17 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Jun 2007 18:18:17 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Message-ID: On Tue, 5 Jun 2007, Enrique Hern?ndez wrote: > The problem is that this code not show the serial ports, this show the no > use serial ports. I want to connect whit the modem but when windows open and > connect the modem my application don't see the port(COMM3) when it is > connect. > what I can do? > Is that the correct way to know the ports? > Hello, We may have problems understanding each other. On windows, the port will not be an available serial port if another application has the port open. That is just how the library behaves. If you can not see the port in the enumerated list, you could not open it. Also note that enumeration only happens once. If you add a port such as a new USB dongle, the port will not be visible until the next time your application runs. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Tue Jun 5 18:45:01 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 20:45:01 -0400 Subject: [Rxtx] problem with rxtx In-Reply-To: References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Message-ID: <4666038D.8090700@gatworks.com> Trent Jarvi wrote: > > > Also note that enumeration only happens once. If you add a port such as > a new USB dongle, the port will not be visible until the next time your > application runs. Is this written in stone ? somewhere? From tjarvi at qbang.org Tue Jun 5 18:54:36 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Jun 2007 18:54:36 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <4666038D.8090700@gatworks.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> Message-ID: On Tue, 5 Jun 2007, Uncle George wrote: > Trent Jarvi wrote: >> >> >> Also note that enumeration only happens once. If you add a port such as >> a new USB dongle, the port will not be visible until the next time your >> application runs. > > Is this written in stone ? somewhere? It is just the current behavior. There is nothing preventing a fix that allows reenumeration. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Tue Jun 5 19:55:19 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 21:55:19 -0400 Subject: [Rxtx] problem with rxtx In-Reply-To: References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> Message-ID: <46661407.4020308@gatworks.com> >> Is this written in stone ? somewhere? > > It is just the current behavior. There is nothing preventing a fix that > allows reenumeration. With usb, ..... , things come and go. Seems a shame that you have to kill application to get at the device u just plugged in. From joachim at buechse.ch Wed Jun 6 01:50:06 2007 From: joachim at buechse.ch (Joachim Buechse) Date: Wed, 6 Jun 2007 09:50:06 +0200 Subject: [Rxtx] problem with rxtx In-Reply-To: <46661407.4020308@gatworks.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> <46661407.4020308@gatworks.com> Message-ID: <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> On MacOS RXTX's enumeration handling is more flexible. It will find new ports that are added during the lifetime of the application. But this is inherently incompatible with suns javax.comm implementation... Regards, Joachim On 06.06.2007, at 03:55, Uncle George wrote: > >>> Is this written in stone ? somewhere? >> >> It is just the current behavior. There is nothing preventing a >> fix that >> allows reenumeration. > > With usb, ..... , things come and go. Seems a shame that you have to > kill application to get at the device u just plugged in. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Jun 6 06:06:48 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Jun 2007 06:06:48 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> <46661407.4020308@gatworks.com> <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> Message-ID: Sun's javax.comm is not a major concern going forward. As long as we do not break old applications using rxtx, I see no reason to limit rxtx to that convention. We have already rejected version 3 from Sun as a dead end and limited our compatability to version 2. That does not mean we will not try to work with Sun and others but the current javax.comm convention (v3) is not a well conceived path. There has been discussion about doing a JSR which is one valid option. On Wed, 6 Jun 2007, Joachim Buechse wrote: > On MacOS RXTX's enumeration handling is more flexible. It will find > new ports that are added during the lifetime of the application. But > this is inherently incompatible with suns javax.comm implementation... > > Regards, > Joachim > > On 06.06.2007, at 03:55, Uncle George wrote: > >> >>>> Is this written in stone ? somewhere? >>> >>> It is just the current behavior. There is nothing preventing a >>> fix that >>> allows reenumeration. >> >> With usb, ..... , things come and go. Seems a shame that you have to >> kill application to get at the device u just plugged in. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From yvespielusenet at free.fr Wed Jun 6 08:46:35 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 16:46:35 +0200 Subject: [Rxtx] [PARALLEL] resource in use Message-ID: <1181141195.3407.20.camel@localhost.localdomain> Hello, I want to use rxtx in my application. I haveto send data to a very old printer (which have a drum and hammers http://perso.orange.fr/tiie/page00010017.html) This is printer is connecter with centronics. It works well but, while it's writting and I putthe printer off-line, after about 45 seconds, I have this error : ------------------------------------- java.io.IOException: La ressource demand?e est en cours d'utilisation. in writeArray at gnu.io.LPRPort.writeArray(Native Method) at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:292) at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:161) at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:156) at mce.buffer.bufferManager.BufferManager$PrintBuffer.run(BufferManager.java:141) The IOexception means "The wanted resource is in use" ------------------------------------- Here is the line 141 of BufferManager : ------------------------------------- while(send){ try{ fos.write(bb); <=== line 141 send = false; } catch(Exception e){ javax.swing.JOptionPane.showMessageDialog(null, "Erreur d'envoie. Veuillez cliquer sur OK pour relancer l'impression de la vignette.\nV?rifiez votre impression !", "Erreur d'envoie", javax.swing.JOptionPane.WARNING_MESSAGE); e.printStackTrace(System.err); System.err.flush(); System.out.println(e); send = true; } } -------------------------------- 'fos' is an outputstream which contains the rxtx stream (this.os is the rxtx outputstream) : -------------------------------- public void write(byte[] bb) throws IOException{ this.write(bb, 0, bb.length); } public void write(byte[] bb, int off, int len) throws IOException{ while(!imp1.isPrinterSelected() || !imp2.isPrinterSelected()){ } this.os.write(bb, off, len); } -------------------------------- Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( can you help me ? thank you :) -- yves piel From yvespielusenet at free.fr Wed Jun 6 09:11:15 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 17:11:15 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181141195.3407.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> Message-ID: <1181142675.3407.23.camel@localhost.localdomain> I forgot to tell that It's under windows XP and java 1.5. Le mercredi 06 juin 2007 ? 16:46 +0200, yves pielusenet a ?crit : > Hello, > I want to use rxtx in my application. I haveto send data to a very old > printer (which have a drum and hammers > http://perso.orange.fr/tiie/page00010017.html) > This is printer is connecter with centronics. It works well but, while > it's writting and I putthe printer off-line, after about 45 seconds, I > have this error : > ------------------------------------- > java.io.IOException: La ressource demand?e est en cours d'utilisation. > in writeArray > at gnu.io.LPRPort.writeArray(Native Method) > at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:292) > at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:161) > at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:156) > at mce.buffer.bufferManager.BufferManager$PrintBuffer.run(BufferManager.java:141) > > The IOexception means "The wanted resource is in use" > ------------------------------------- > > Here is the line 141 of BufferManager : > > ------------------------------------- > while(send){ > try{ > fos.write(bb); <=== line 141 > send = false; > } > catch(Exception e){ > javax.swing.JOptionPane.showMessageDialog(null, "Erreur d'envoie. Veuillez cliquer sur OK pour relancer l'impression de la vignette.\nV?rifiez votre impression !", "Erreur d'envoie", javax.swing.JOptionPane.WARNING_MESSAGE); > e.printStackTrace(System.err); > System.err.flush(); > System.out.println(e); > send = true; > } > } > -------------------------------- > 'fos' is an outputstream which contains the rxtx stream (this.os is the rxtx outputstream) : > > -------------------------------- > public void write(byte[] bb) throws IOException{ > this.write(bb, 0, bb.length); > } > public void write(byte[] bb, int off, int len) throws IOException{ > while(!imp1.isPrinterSelected() || !imp2.isPrinterSelected()){ > } > this.os.write(bb, off, len); > } > -------------------------------- > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > can you help me ? > > thank you :) > From netbeans at gatworks.com Wed Jun 6 09:21:46 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 11:21:46 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181141195.3407.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> Message-ID: <4666D10A.8000507@gatworks.com> } > -------------------------------- > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > can you help me ? > > thank you :) > windoz or linux? ( I guess windoz ) for windoz, there appears to be a timeout ( as Comments suggest ) of about 40seconds. > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } for linux, there is no implied timeout. > if( write( fd, bytes, count ) < 0 ) > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); From netbeans at gatworks.com Wed Jun 6 09:39:41 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 11:39:41 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666D10A.8000507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> Message-ID: <4666D53D.90000@gatworks.com> Uncle George wrote: > } >> -------------------------------- >> >> Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( >> >> can you help me ? From reading the code, I can see your concern. And it appears you are correct, because some of the data will be sent to the OS printer buffers, and then it will refuse to accept anymore. Unfortunately, writeArray does not return the num of characters written :{ So application has no idea to how many characters were accepted by the OS. I dont do windoz, so I cant say with absolute certainty what windoz will do with an off-line condition. If you have the source, and can compile, then maybe u can increase the loop count to hit 4hours? From yvespielusenet at free.fr Wed Jun 6 09:53:25 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 17:53:25 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666D10A.8000507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> Message-ID: <1181145205.3407.35.camel@localhost.localdomain> Thank you for your explanation :) This timeout comes when no data has been send to the printer after 40seconds if I well understand. But why there is such a timeout ? If I setthe printer offline while it's printing I mustn't have an exception. I don't understand why the "printer should solv all problems like buffer full" in 40 seconds. If I pause the printer the buffer will not be emptied, isn't it ? I not very familiar with C/C++, but it seem that the exception is thrown only when countWritten == 0, that means no data at all has been sent. So Is my code is good since when I intercept this exception I send all my buffer again. There is no way that the printer receive two times same bytes ? thanks ps: yes the application is running on windows XP since I developpe under Debian Le mercredi 06 juin 2007 ? 11:21 -0400, Uncle George a ?crit : > } > > -------------------------------- > > > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > > > can you help me ? > > > > thank you :) > > > > windoz or linux? ( I guess windoz ) > > for windoz, there appears to be a timeout ( as Comments suggest ) of > about 40seconds. > > while( count > 0 ){ > > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > > /* > > this are 20 * 2 seconds, in this time a printer (or other parallel device) > > should solv all problems like buffer full, etc > > */ > > if(errorCount++ < 20){ > > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > > continue; > > } > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > for linux, there is no implied timeout. > > if( write( fd, bytes, count ) < 0 ) > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Wed Jun 6 10:34:24 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 12:34:24 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181145205.3407.35.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> Message-ID: <4666E210.30507@gatworks.com> yves pielusenet wrote: > Thank you for your explanation :) > This timeout comes when no data has been send to the printer after > 40seconds if I well understand. But why there is such a timeout ? If I > setthe printer offline while it's printing I mustn't have an exception. > I don't understand why the "printer should solv all problems like buffer > full" in 40 seconds. If I pause the printer the buffer will not be > emptied, isn't it ? > > I not very familiar with C/C++, but it seem that the exception is thrown > only when countWritten == 0, that means no data at all has been sent. So > Is my code is good since when I intercept this exception I send all my > buffer again. There is no way that the printer receive two times same > bytes ? More technically, the function call returns and reports that 0 characters was written in this call. when 0 characters are written, it will check how many times 0 characters was written. If it has tried LESS than 20 times(errorCount), it will sleep() and try to write again. After 20 times, it wont sleep, but throw you the exception. Now suppose you are writing a 120 character line. you off-lined/paused your printer. The OS has room for 80 more characters in it's printer buffer. The WriteFile() will have a char count of 120, but on return the countWritten = 80. You still have 40 more characters to print. Since countWritten != 0, the counters: bytes += countWritten; count -= countWritten; get updated, and the Writefile now has a count of 40 characters. Since the printer is off-line, the countwritten is 0. And so the loop continues, till 40 seconds is up. As to why it is this way, i dont know ( not a windoz maven ); Also the sleep(20) in the loop is not so intuitive to suggest 2 seconds of sleep. I would have guessed 20seconds, or 20milliseconds. But go figure. BTW: Since your computer sends you error messages in French, does it curse in English? :)))) From yvespielusenet at free.fr Thu Jun 7 02:27:44 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Thu, 07 Jun 2007 10:27:44 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666E210.30507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> Message-ID: <1181204864.3501.10.camel@localhost.localdomain> Maybe in my case I should re-compile rxtx and change the code. Instead of send an exception I should display a dialog box to ask if it's printer problem or if it should trie to send bytes. Something like : while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } if(displayDialogBox("Try again to send datas ??")){ errorCount = 0; } else{ throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } } Le mercredi 06 juin 2007 ? 12:34 -0400, Uncle George a ?crit : > yves pielusenet wrote: > > Thank you for your explanation :) > > This timeout comes when no data has been send to the printer after > > 40seconds if I well understand. But why there is such a timeout ? If I > > setthe printer offline while it's printing I mustn't have an exception. > > I don't understand why the "printer should solv all problems like buffer > > full" in 40 seconds. If I pause the printer the buffer will not be > > emptied, isn't it ? > > > > I not very familiar with C/C++, but it seem that the exception is thrown > > only when countWritten == 0, that means no data at all has been sent. So > > Is my code is good since when I intercept this exception I send all my > > buffer again. There is no way that the printer receive two times same > > bytes ? > More technically, the function call returns and reports that 0 > characters was written in this call. > when 0 characters are written, it will check how many times 0 characters > was written. If it has tried LESS than 20 times(errorCount), it will > sleep() and try to write again. > After 20 times, it wont sleep, but throw you the exception. > > Now suppose you are writing a 120 character line. you off-lined/paused > your printer. The OS has room for 80 more characters in it's printer > buffer. The WriteFile() will have a char count of 120, but on return the > countWritten = 80. You still have 40 more characters to print. > Since countWritten != 0, the counters: > bytes += countWritten; > count -= countWritten; > get updated, and the Writefile now has a count of 40 characters. Since > the printer is off-line, the countwritten is 0. And so the loop > continues, till 40 seconds is up. > > As to why it is this way, i dont know ( not a windoz maven ); > Also the sleep(20) in the loop is not so intuitive to suggest 2 seconds > of sleep. I would have guessed 20seconds, or 20milliseconds. But go figure. > > BTW: Since your computer sends you error messages in French, does it > curse in English? :)))) > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 06:11:43 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 08:11:43 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181204864.3501.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> Message-ID: <4667F5FF.8070903@gatworks.com> your suggestion appears good. I dont know what displayDialogBox exactly will do, so all I can say it that it looks good. But I'd like to wait 10min before first dialog box And a 5 min wait for every dialog box there after. And since these are custom solution/choices, maybe a more exact explanation of what the issue is. if(errorCount++ < 300){ // wait 10min ( 10min * 60sec / 2 ) Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } if(displayDialogBox("Printer has Paused. Retry sending data?")){ errorCount = 150; // Wait for 5 min thereafter continue; } > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } yves pielusenet wrote: > Maybe in my case I should re-compile rxtx and change the code. Instead > of send an exception I should display a dialog box to ask if it's > printer problem or if it should trie to send bytes. Something like : > > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > > if(displayDialogBox("Try again to send datas ??")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > } > From yvespielusenet at free.fr Thu Jun 7 07:17:21 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Thu, 07 Jun 2007 15:17:21 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4667F5FF.8070903@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <4667F5FF.8070903@gatworks.com> Message-ID: <1181222241.3501.20.camel@localhost.localdomain> thank you :) 'displayDialogBox()' I think doesn't exist. It was just for the example :) But I think It should not be so complicated to display a dialog box under windows with YES/NO buttons. When yes is clicked it return 0 other it returns 1. Le jeudi 07 juin 2007 ? 08:11 -0400, Uncle George a ?crit : > your suggestion appears good. I dont know what displayDialogBox exactly > will do, so all I can say it that it looks good. > > But I'd like to wait 10min before first dialog box And a 5 min wait for > every dialog box there after. And since these are custom > solution/choices, maybe a more exact explanation of what the issue is. > > if(errorCount++ < 300){ // wait 10min ( 10min * 60sec / 2 ) > Sleep( 20 ); /* make a small pause to execute all other requests > in all other threads */ > continue; > } > > if(displayDialogBox("Printer has Paused. Retry sending data?")){ > errorCount = 150; // Wait for 5 min thereafter > continue; > } > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > > yves pielusenet wrote: > > Maybe in my case I should re-compile rxtx and change the code. Instead > > of send an exception I should display a dialog box to ask if it's > > printer problem or if it should trie to send bytes. Something like : > > > > while( count > 0 ){ > > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > > /* > > this are 20 * 2 seconds, in this time a printer (or other parallel device) > > should solv all problems like buffer full, etc > > */ > > if(errorCount++ < 20){ > > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > > continue; > > } > > > > if(displayDialogBox("Try again to send datas ??")){ > > errorCount = 0; > > } > > else{ > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > } > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 07:41:43 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 09:41:43 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181222241.3501.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <4667F5FF.8070903@gatworks.com> <1181222241.3501.20.camel@localhost.localdomain> Message-ID: <46680B17.8050109@gatworks.com> yves pielusenet wrote: > thank you :) > 'displayDialogBox()' I think doesn't exist. It was just for the > example :) too bad. Good luck. From rtrout at webbresearch.com Thu Jun 7 11:23:04 2007 From: rtrout at webbresearch.com (Robert Trout) Date: Thu, 07 Jun 2007 13:23:04 -0400 Subject: [Rxtx] Disconnected PortServer TS causes Java to hang Message-ID: <1181236984.14186.33.camel@sisyphus.DinkumSoftware.com> I'm running Linux with sun's Java 1.4.2, Java comm API 2.0, RXTX 2.0-7pre1, and the RealPort digi driver. "/dev/ttyrp00" is a RealPort device. My Java application never returns from a ComPortIdentifier.getPortIdentifier("/dev/ttyrp00") call while the Digi PortServer TS 4 is disconnected from the network. If I later re-connect the PortServer, the call returns about 30 seconds later (it's like a serial port read or write is blocking until the PortServer is re- connected). With the PortServer disconnected, minicom immediately responds with "cannot open /dev/ttyrp00: No such file or directory". I would like my Java application to behave similarly. That is, respond with an error condition instead of hanging when the PortServer is not connected. Since minicom and Java behave differently, I think this "hanging" behavior may be due to RXTX or Java? Has anyone had a similar issue? Solutions? Suggestions? Thanks, Robert From vicnevicne at gmail.com Thu Jun 7 12:16:02 2007 From: vicnevicne at gmail.com (Vicne) Date: Thu, 07 Jun 2007 20:16:02 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181204864.3501.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> Message-ID: <46684B62.7080802@gmail.com> yves pielusenet wrote: > Maybe in my case I should re-compile rxtx and change the code. Instead > of send an exception I should display a dialog box to ask if it's > printer problem or if it should trie to send bytes. Something like : > > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > > if(displayDialogBox("Try again to send datas ??")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > } > Sorry to step in without a specific solution to your problem, but I wanted to share my feeling regarding this proposal. AFAIK, it's generally considered bad practice to pop-up a prompt from a library. The main reason is that in general use, you can't guarantee that someone is actually present behind the console. Imagine a print server in a machine room, connected to a park of printers. In that case, when one printer fails, the logical behaviour would be to use an other one. If you change RxTx the way you propose, the printer queue will simply be stuck with a useless "Try again to send data ?" prompt until an administrator opens a remote connection to the print server's console and clicks "no". Second, it would create a dependency upon the existence of a graphical console (if you go the graphical "dialogBox" way). On many applications (typically server or embedded ones), the JVM is "headless" and if you try to pop-up a dialog, your app would throw an exception (at best) or just wouldn't display the prompt anywhere... Going the "text console" way is not more reliable, because on graphical environments, the text console is hidden unless explicitly requested. My advice would be to think again and find another solution. Ideas are : - make the number of retries a parameter so that you can tune it to what you think is reasonable - throw a more specific exception when the number of retries has been reached, so that a specific prompt can be shown at a higher level Anyway, if you feel that the prompt is the way to go in your case, I would at least make that prompt conditional. The least intrusive way would probably be using a system property, like if("true".equals(System.getProperty("org.rxtx.usePrompt")) && displayDialogBox("Retry sending data ?")){ errorCount = 0; } else{ throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } By default, the behaviour would remain as it is now, but you could force the prompts by defining the property at VM launch if desired. (for example : java.exe -Dorg.rxtx.usePrompt=true myApp) Also, you seemed to say you wanted the printer to start again exactly where is stopped. It would indeed be the best way when the printer is put offline for a few seconds. On the other hand, if the printer is turned off (or the printer runs out of paper, or someone steps on the mains cable), then the only way to go back to a "stable" situation would be by printing the item (page, label, etc.) again from scratch... Just my two cents. Vicne PS : By the way, the dialog box thing is very platform dependant on the C-side, and I think the simplest way would probably be to bridge it to a Java call where you can implement it like you proposed : public boolean displayDialogBox(prompt) { return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); } From netbeans at gatworks.com Thu Jun 7 14:08:24 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 16:08:24 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46684B62.7080802@gmail.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> Message-ID: <466865B8.4060004@gatworks.com> My feeling is that the code that was suggested was for his environs ( his shop ). The issue here is that after a 40+ second wait, an exception will be thrown. But you really dont have a way of 'cancelling' all the WriteFiles() that have already occured before the exception so that your writeArray and the Commapi can backtrack to a position in which they are in sync. The main ( really mine ) concern is not to lose data, or replicate data. After 40seconds, 300 seconds, 55min, no matter how long, data should not be lost or duplicated. But as soon as the exception is thrown, that possibility exists. Maybe an event should be thrown instead? Vicne wrote: > yves pielusenet wrote: >> Maybe in my case I should re-compile rxtx and change the code. Instead >> of send an exception I should display a dialog box to ask if it's >> printer problem or if it should trie to send bytes. Something like : >> >> while( count > 0 ){ >> if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ >> /* >> this are 20 * 2 seconds, in this time a printer (or other parallel device) >> should solv all problems like buffer full, etc >> */ >> if(errorCount++ < 20){ >> Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ >> continue; >> } >> >> if(displayDialogBox("Try again to send datas ??")){ >> errorCount = 0; >> } >> else{ >> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >> break; >> } >> } >> > > Sorry to step in without a specific solution to your problem, but I > wanted to share my feeling regarding this proposal. AFAIK, it's > generally considered bad practice to pop-up a prompt from a library. > The main reason is that in general use, you can't guarantee that > someone is actually present behind the console. Imagine a print server > in a machine room, connected to a park of printers. In that case, when > one printer fails, the logical behaviour would be to use an other one. > If you change RxTx the way you propose, the printer queue will simply be > stuck with a useless "Try again to send data ?" prompt until an > administrator opens a remote connection to the print server's console > and clicks "no". > Second, it would create a dependency upon the existence of a > graphical console (if you go the graphical "dialogBox" way). On many > applications (typically server or embedded ones), the JVM is "headless" > and if you try to pop-up a dialog, your app would throw an exception (at > best) or just wouldn't display the prompt anywhere... Going the "text > console" way is not more reliable, because on graphical environments, > the text console is hidden unless explicitly requested. > > My advice would be to think again and find another solution. Ideas are : > - make the number of retries a parameter so that you can tune it to what > you think is reasonable > - throw a more specific exception when the number of retries has been > reached, so that a specific prompt can be shown at a higher level > > Anyway, if you feel that the prompt is the way to go in your case, I > would at least make that prompt conditional. The least intrusive way > would probably be using a system property, like > > if("true".equals(System.getProperty("org.rxtx.usePrompt")) > && displayDialogBox("Retry sending data ?")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > > > By default, the behaviour would remain as it is now, but you could > force the prompts by defining the property at VM launch if desired. (for > example : java.exe -Dorg.rxtx.usePrompt=true myApp) > > > Also, you seemed to say you wanted the printer to start again > exactly where is stopped. It would indeed be the best way when the > printer is put offline for a few seconds. On the other hand, if the > printer is turned off (or the printer runs out of paper, or someone > steps on the mains cable), then the only way to go back to a "stable" > situation would be by printing the item (page, label, etc.) again from > scratch... > > > Just my two cents. > > > Vicne > > PS : By the way, the dialog box thing is very platform dependant on the > C-side, and I think the simplest way would probably be to bridge it to a > Java call where you can implement it like you proposed : > > public boolean displayDialogBox(prompt) { > return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", > JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); > } > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Thu Jun 7 17:48:11 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 Jun 2007 17:48:11 -0600 (MDT) Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <466865B8.4060004@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> Message-ID: An event is possible. I'm amazed this is the largest problem encountered while using the parallel code. How would the write ever exit if we throw events? Isn't this going to lead to hung applications? On Thu, 7 Jun 2007, Uncle George wrote: > My feeling is that the code that was suggested was for his environs ( > his shop ). > > The issue here is that after a 40+ second wait, an exception will be > thrown. But you really dont have a way of 'cancelling' all the > WriteFiles() that have already occured before the exception so that your > writeArray and the Commapi can backtrack to a position in which they are > in sync. > > The main ( really mine ) concern is not to lose data, or replicate data. > After 40seconds, 300 seconds, 55min, no matter how long, data should > not be lost or duplicated. But as soon as the exception is thrown, that > possibility exists. > > Maybe an event should be thrown instead? > > Vicne wrote: >> yves pielusenet wrote: >>> Maybe in my case I should re-compile rxtx and change the code. Instead >>> of send an exception I should display a dialog box to ask if it's >>> printer problem or if it should trie to send bytes. Something like : >>> >>> while( count > 0 ){ >>> if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ >>> /* >>> this are 20 * 2 seconds, in this time a printer (or other parallel device) >>> should solv all problems like buffer full, etc >>> */ >>> if(errorCount++ < 20){ >>> Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ >>> continue; >>> } >>> >>> if(displayDialogBox("Try again to send datas ??")){ >>> errorCount = 0; >>> } >>> else{ >>> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >>> break; >>> } >>> } >>> >> >> Sorry to step in without a specific solution to your problem, but I >> wanted to share my feeling regarding this proposal. AFAIK, it's >> generally considered bad practice to pop-up a prompt from a library. >> The main reason is that in general use, you can't guarantee that >> someone is actually present behind the console. Imagine a print server >> in a machine room, connected to a park of printers. In that case, when >> one printer fails, the logical behaviour would be to use an other one. >> If you change RxTx the way you propose, the printer queue will simply be >> stuck with a useless "Try again to send data ?" prompt until an >> administrator opens a remote connection to the print server's console >> and clicks "no". >> Second, it would create a dependency upon the existence of a >> graphical console (if you go the graphical "dialogBox" way). On many >> applications (typically server or embedded ones), the JVM is "headless" >> and if you try to pop-up a dialog, your app would throw an exception (at >> best) or just wouldn't display the prompt anywhere... Going the "text >> console" way is not more reliable, because on graphical environments, >> the text console is hidden unless explicitly requested. >> >> My advice would be to think again and find another solution. Ideas are : >> - make the number of retries a parameter so that you can tune it to what >> you think is reasonable >> - throw a more specific exception when the number of retries has been >> reached, so that a specific prompt can be shown at a higher level >> >> Anyway, if you feel that the prompt is the way to go in your case, I >> would at least make that prompt conditional. The least intrusive way >> would probably be using a system property, like >> >> if("true".equals(System.getProperty("org.rxtx.usePrompt")) >> && displayDialogBox("Retry sending data ?")){ >> errorCount = 0; >> } >> else{ >> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >> break; >> } >> >> >> By default, the behaviour would remain as it is now, but you could >> force the prompts by defining the property at VM launch if desired. (for >> example : java.exe -Dorg.rxtx.usePrompt=true myApp) >> >> >> Also, you seemed to say you wanted the printer to start again >> exactly where is stopped. It would indeed be the best way when the >> printer is put offline for a few seconds. On the other hand, if the >> printer is turned off (or the printer runs out of paper, or someone >> steps on the mains cable), then the only way to go back to a "stable" >> situation would be by printing the item (page, label, etc.) again from >> scratch... >> >> >> Just my two cents. >> >> >> Vicne >> >> PS : By the way, the dialog box thing is very platform dependant on the >> C-side, and I think the simplest way would probably be to bridge it to a >> Java call where you can implement it like you proposed : >> >> public boolean displayDialogBox(prompt) { >> return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", >> JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); >> } >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 19:18:51 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 21:18:51 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> Message-ID: <4668AE7B.3060409@gatworks.com> The UNIX version of writeArray is not too great either. It is possible that the write will only process some of the bytes. #else if( write( fd, bytes, count ) < 0 ) throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); #endif -------------------------------- Maybe it might be better to have the native function inform the caller of the # of characters written, then the commapi/output-buffer can be modified to reflect the #of chars written. If an exception is to be thrown, for too many loops of chars written == 0, then exception wont affect the state of the output buffer. Then a ParallelPort.restart() can be called to resume printing whats in the buffer. Trent Jarvi wrote: > An event is possible. I'm amazed this is the largest problem encountered > while using the parallel code. > > How would the write ever exit if we throw events? Isn't this going to > lead to hung applications? Sure. If you dont time out, then there is nothing that will force an EXIT from the write(). Issue is what has the OS done with the write. > > On Thu, 7 Jun 2007, Uncle George wrote: > >> My feeling is that the code that was suggested was for his environs ( >> his shop ). From yvespielusenet at free.fr Fri Jun 8 01:09:01 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Fri, 08 Jun 2007 09:09:01 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4668AE7B.3060409@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> Message-ID: <1181286541.3674.10.camel@localhost.localdomain> It is not possible that the rxtx java method write(byte[], int offset, int length) return anint which contains the number of byte really send to the printer instead of an exception ? So this is the programm which will see if all bytes have been sent. If not it can retry to send the unsended bytes. -------------------------------------------------------- int sended = 0; while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ sended += countWritten; /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } return sended; /*throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break;*/ } ... ... return countWritten; ------------------------------------------------ Le jeudi 07 juin 2007 ? 21:18 -0400, Uncle George a ?crit : > The UNIX version of writeArray is not too great either. It is possible > that the write will only process some of the bytes. > > #else > if( write( fd, bytes, count ) < 0 ) > throw_java_exception_system_msg( env, IO_EXCEPTION, > "writeArray" ); > #endif > -------------------------------- > > Maybe it might be better to have the native function inform the caller > of the # of characters written, then the commapi/output-buffer can be > modified to reflect the #of chars written. If an exception is to be > thrown, for too many loops of chars written == 0, then exception wont > affect the state of the output buffer. Then a ParallelPort.restart() can > be called to resume printing whats in the buffer. > > > Trent Jarvi wrote: > > An event is possible. I'm amazed this is the largest problem encountered > > while using the parallel code. > > > > How would the write ever exit if we throw events? Isn't this going to > > lead to hung applications? > Sure. If you dont time out, then there is nothing that will force an > EXIT from the write(). Issue is what has the OS done with the write. > > > > On Thu, 7 Jun 2007, Uncle George wrote: > > > >> My feeling is that the code that was suggested was for his environs ( > >> his shop ). > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Fri Jun 8 03:45:00 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 11:45:00 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181286541.3674.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> Message-ID: <20070608094500.GC21069@elberon.bln.de.ingenico.com> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > It is not possible that the rxtx java method write(byte[], int offset, > int length) return anint which contains the number of byte really send > to the printer instead of an exception ? > So this is the programm which will see if all bytes have been sent. If > not it can retry to send the unsended bytes. I think write() is void because in Java people love to do this since OutputStream :-) Of course on such interfaces you cannot implement something nice. If you would have a int write, you would not implement the interface and no applications expecting this interface would link/work/compile. oki, Steffen P.S.: (OT) If you propose not to implement the Java interfaces (especially not on JNI level), maybe optionally offering a wrapper that removes e.g. the write return value and so on to downgrade the powerful classic old POSIX read/write style to the modern limited Java style, then I agree :-) Same for read. Instead of things like "int avialable()" it is more powerful to have an approach as select(2) offers (to guarante the caller that read/write will not block [nothing else make sense anyway IMHO] but may read/write less bytes then requested). The caller gets full control and the higher level protocols can care about timeouts, invoking read in some loops and/or implement retransmission. On top of such an implementation, where everything is controlled, defined, guaranteed and reliable, someone could use an InputStream or OutputStream style interface. Or even better: don't use them at all :) just BTW :-) St. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From yvespielusenet at free.fr Fri Jun 8 05:52:45 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Fri, 08 Jun 2007 13:52:45 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <20070608094500.GC21069@elberon.bln.de.ingenico.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> Message-ID: <1181303565.11203.3.camel@localhost.localdomain> So maybe a better way should be to create a new Exception class which has a method "int getWrittenByte()". So the Exception should be use to send again bytes which are not printed yet. yves Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : > * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > > It is not possible that the rxtx java method write(byte[], int offset, > > int length) return anint which contains the number of byte really send > > to the printer instead of an exception ? > > So this is the programm which will see if all bytes have been sent. If > > not it can retry to send the unsended bytes. > > I think write() is void because in Java people love to do this > since OutputStream :-) Of course on such interfaces you cannot > implement something nice. If you would have a int write, you > would not implement the interface and no applications expecting > this interface would link/work/compile. > > oki, > > Steffen > > P.S.: (OT) > If you propose not to implement the Java interfaces (especially > not on JNI level), maybe optionally offering a wrapper that > removes e.g. the write return value and so on to downgrade the > powerful classic old POSIX read/write style to the modern limited > Java style, then I agree :-) Same for read. Instead of things > like "int avialable()" it is more powerful to have an approach as > select(2) offers (to guarante the caller that read/write will not > block [nothing else make sense anyway IMHO] but may read/write > less bytes then requested). The caller gets full control and the > higher level protocols can care about timeouts, invoking read in > some loops and/or implement retransmission. On top of such an > implementation, where everything is controlled, defined, > guaranteed and reliable, someone could use an InputStream or > OutputStream style interface. Or even better: don't use them at > all :) just BTW :-) > St. > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > 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. > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > 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. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Fri Jun 8 06:46:21 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 08:46:21 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181303565.11203.3.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> Message-ID: <46694F9D.5080501@gatworks.com> It seems that with outputstream.write(b[]), you become terribly uncoordinated as soon as an exception is thrown. Docs do not say what happens to the data. Yet from a practicable point of view, one would like to know if the write was accepted in-full, or rejected before any writes. There are no in betweens, as partial writes are not reportable. So for an outputstream.write(), in order for it to return, the full write request has to be taken, and stored in an internal output buffer. If there is no room, the write() is suspended, till there is room. Or throw's an IOException( "no room in buffer") ; As the select() loop for write reports buffer room avail, then more of the internal buffer is sent to the printer. yves pielusenet wrote: > So maybe a better way should be to create a new Exception class which > has a method "int getWrittenByte()". So the Exception should be use to > send again bytes which are not printed yet. > > yves > > Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : >> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: >>> It is not possible that the rxtx java method write(byte[], int offset, >>> int length) return anint which contains the number of byte really send >>> to the printer instead of an exception ? >>> So this is the programm which will see if all bytes have been sent. If >>> not it can retry to send the unsended bytes. >> I think write() is void because in Java people love to do this >> since OutputStream :-) Of course on such interfaces you cannot >> implement something nice. If you would have a int write, you >> would not implement the interface and no applications expecting >> this interface would link/work/compile. >> >> oki, >> >> Steffen >> >> P.S.: (OT) >> If you propose not to implement the Java interfaces (especially >> not on JNI level), maybe optionally offering a wrapper that >> removes e.g. the write return value and so on to downgrade the >> powerful classic old POSIX read/write style to the modern limited >> Java style, then I agree :-) Same for read. Instead of things >> like "int avialable()" it is more powerful to have an approach as >> select(2) offers (to guarante the caller that read/write will not >> block [nothing else make sense anyway IMHO] but may read/write >> less bytes then requested). The caller gets full control and the >> higher level protocols can care about timeouts, invoking read in >> some loops and/or implement retransmission. On top of such an >> implementation, where everything is controlled, defined, >> guaranteed and reliable, someone could use an InputStream or >> OutputStream style interface. Or even better: don't use them at >> all :) just BTW :-) >> St. >> >> About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. >> 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. >> >> About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. >> 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. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From Steffen.DETTMER at ingenico.com Fri Jun 8 08:12:18 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 16:12:18 +0200 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <46694F9D.5080501@gatworks.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: <20070608141218.GE21069@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 08:46 -0400: > It seems that with outputstream.write(b[]), you become terribly > uncoordinated as soon as an exception is thrown. Docs do not say what > happens to the data. (yes, so avoiding it seems to be good :)) > Yet from a practicable point of view, one would like to know if the > write was accepted in-full, or rejected before any writes. There are no > in betweens, as partial writes are not reportable. (which is an artificial API limitation. I never understood how this happend when they invented JDK because the well-known BSD socket API and thus [probably] WinSock does this correct, but anyway) > So for an outputstream.write(), in order for it to return, the full > write request has to be taken, and stored in an internal output buffer. > If there is no room, the write() is suspended, till there is room. Or > throw's an IOException( "no room in buffer") ; As the select() loop for > write reports buffer room avail, then more of the internal buffer is > sent to the printer. yes, might be good in case of a printer. May be horrible in case of PPP/TCP or some other transmission control protocol which may e.g. repeat data or even omit parts of it (e.g. internet realtime radio station broadcasting)... So I think the idea of "int write" (e.g. BSD sockets, linux files and so on) still is the best. A clean API / implementation should guarantee and allow implementations (users) to rely on that; assumptions and automatic background-sending and so on may look pragmatic and may even work on the first look, but may fail in other situations. BTW, if e.g. BSD socket API is known, why not simply copy it (until something better is invented :)) instead of fiddling around with JDK APIs? anyway, have a nice weekend everyone :-) oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Fri Jun 8 08:55:56 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 10:55:56 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070608141218.GE21069@elberon.bln.de.ingenico.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> Message-ID: <46696DFC.7000801@gatworks.com> >> write reports buffer room avail, then more of the internal buffer is >> sent to the printer. > > yes, might be good in case of a printer. May be horrible in case > of PPP/TCP or some other transmission control protocol which > may e.g. repeat data or even omit parts of it (e.g. internet > realtime radio station broadcasting)... So I think the idea of > "int write" (e.g. BSD sockets, linux files and so on) still is > the best. A clean API / implementation should guarantee and allow > implementations (users) to rely on that; assumptions and > automatic background-sending and so on may look pragmatic and may > even work on the first look, but may fail in other situations. > BTW, if e.g. BSD socket API is known, why not simply copy it > (until something better is invented :)) instead of fiddling > around with JDK APIs? But we were talking about the Parallel Port, and the transmission of data over the commapi/parallel-port schema. There isn't much in bi-directional software communication. Its a simple write one byte at a time interface. I'm not looking to change the comm-api. I'm just looking to alter the interaction between the Native ParallelPort functions, and the java ParallelPort functions that call them. This might be more readily doable than to get a committee to re-specify java-API specs. BTW: Whats is off-topic? ( help: not looking for def of off-topic ) From j.kenneth.gentle at acm.org Fri Jun 8 08:58:59 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Fri, 08 Jun 2007 10:58:59 -0400 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <20070608141218.GE21069@elberon.bln.de.ingenico.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> Message-ID: <200706081459.l58Ex5rA019991@qbang.org> Perhaps it is a bit late to jump in on this one, but here goes anyway. If the solutions all seem to "break" the contract with "java.io.outputstream", then, as noted, that may not be the appropriate contract. At the risk of being heretical, JDK1.4 introduced the "nio" package to address some of the compatibility issues with C apis mentioned in previous posts. The interface "java.nio.channels.WriteableByteChannel" defines the following single method: int write(ByteBuffer source); int, strangely enough, is the actual number of bytes written. So, if RXTX as written, against the JavaCOMM api and OutputStream, doesn't do what we want, how about writing a different set of bindings using the java.nio classes and as much of the underlying native code as possible. Note that just because the java.nio.channels.WriteableByteChannel sends back a result, OutputStream.write doesn't have to - and they could both call the same underlying native code. My 2 cents - maybe not worth even that... Ken From netbeans at gatworks.com Fri Jun 8 10:37:28 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 12:37:28 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <200706081459.l58Ex5rA019991@qbang.org> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> Message-ID: <466985C8.8000505@gatworks.com> Ken Gentle wrote: > Perhaps it is a bit late to jump in on this one, but here goes anyway. Common in, the waters fine. > > If the solutions all seem to "break" the contract with > "java.io.outputstream", then, as noted, that may not be the > appropriate contract. > How would the contract be broken? The machinery underneath is handling the contract. From j.kenneth.gentle at acm.org Fri Jun 8 10:48:01 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Fri, 08 Jun 2007 12:48:01 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466985C8.8000505@gatworks.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> Message-ID: <200706081648.l58Gm7YA022904@qbang.org> At 12:37 2007-06-08, you wrote: >Ken Gentle wrote: > > > > If the solutions all seem to "break" the contract with > > "java.io.outputstream", then, as noted, that may not be the > > appropriate contract. > > >How would the contract be broken? The machinery underneath is handling >the contract. It seems that a lot of the discussion has been about not only the timeout and being able to adjust it in the "machinery layer", but also about knowing in the Java layer, in the event of a timeout or exception, how many characters have been written to the device. An OutputStream won't ever do this with out an extension and including a return value "breaks" the contract, right? So, go with a Java IO api that *does* return the number of bytes written, out of the NIO package. I know it doesn't allow for a strict implementation of the JavaCOMM API - however, using NIO classes in place of the IO classes isn't that big a break and would allow those applications that need such information a way to get it. Maybe I'm misunderstanding the problem... Ken From netbeans at gatworks.com Fri Jun 8 11:24:14 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 13:24:14 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <200706081648.l58Gm7YA022904@qbang.org> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> Message-ID: <466990BE.7040100@gatworks.com> Ken Gentle wrote: An > OutputStream won't ever do this with out an extension and including a > return value "breaks" the contract, right? > i was not thinking of change the API to OutputSream. Are there specs for how output stream should work internally? for instance: String data = "Hello this is a line of data"; Outputstream.write( data.getbytes() ); ParallelPort.suspend(); int free = ParallelPort.getoutputbufferfree(); There is a symbiotic relationship between outputstream and the functionality of ParallelPort. From Steffen.DETTMER at ingenico.com Fri Jun 8 11:15:39 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 19:15:39 +0200 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <200706081459.l58Ex5rA019991@qbang.org> References: <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> Message-ID: <20070608171539.GK21069@elberon.bln.de.ingenico.com> * Ken Gentle wrote on Fri, Jun 08, 2007 at 10:58 -0400: > If the solutions all seem to "break" the contract with > "java.io.outputstream", then, as noted, that may not be the > appropriate contract. > > At the risk of being heretical, JDK1.4 introduced the "nio" package > to address some of the compatibility issues with C apis mentioned in > previous posts. The interface > "java.nio.channels.WriteableByteChannel" defines the following single method: > > int write(ByteBuffer source); > > int, strangely enough, is the actual number of bytes written. Yes, AFAIK one of the motivations for the NIO interface was, that the JDK-1.3 APIs (InputStream, e.g.) were not powerfull enough, especially for multi-connection-TCP servers or so. I don't know much about it but I've heard of a project where NIO usage was removed because of stability issues in multi-threaded environments and performance limitations under some circumstances. IIRC the "nio.ByteBuffer" is something very special (namely something you cannot implement in Java, it is "magic" or part of the language itself). Not sure if this is such a great idea (but for performance in the end sometimes heavy prices must be paid) :) > So, if RXTX as written, against the JavaCOMM api and OutputStream, > doesn't do what we want, how about writing a different set of > bindings using the java.nio classes and as much of the underlying > native code as possible. Yes, this would be an idea: use a full-featured interface on JNI, and, if wanted, deliver some wrappers converting this to a less-featured Java-compliant interface. However, powerful things as e.g. "select" are difficult to "emulate" if you are e.g. on some (older?) windows. But if you expose the full-featured APIs, you need to emulate them full-featured, theoretically. In the end it depends what you do on the serial line. If you just want to talk to a modem, then you may not need precise timeouts. But if you need to implement complexer protocols which define response times and timeouts, you may quickly get into difficulties. For instance, AFAIK, rxtx 1.7.2 (?) for windows is very messy with timeouts (there is a maximum, higher values are truncated; resolution is 100ms only; the function may take up to twice the timeout because internally it may be called twice). Probably for most people this is OK, but probably not for all. But having precise timeouts should be OK for all :-) Well, in the end it is nice to wish but somewhat hard to implement (many platforms, connections, USB, BlueTooth, whatever). oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Steffen.DETTMER at ingenico.com Fri Jun 8 11:04:22 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 19:04:22 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <46696DFC.7000801@gatworks.com> References: <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <46696DFC.7000801@gatworks.com> Message-ID: <20070608170422.GJ21069@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 10:55 -0400: > > BTW, if e.g. BSD socket API is known, why not simply copy it > > (until something better is invented :)) instead of fiddling > > around with JDK APIs? > > But we were talking about the Parallel Port, and the > transmission of data over the commapi/parallel-port schema. > There isn't much in bi-directional software communication. Its > a simple write one byte at a time interface. First, there are things like PLIP (http://en.wikipedia.org/wiki/Plip) - well, probably not widely used, sure ;) Second, I think if there is a good simple API known to support all that (with known "best practices") or so and there is no forcing need to invent a new one, why not simply using it? > I'm not looking to change the comm-api. I'm just looking to > alter the interaction between the Native ParallelPort > functions, and the java ParallelPort functions that call them. Ahh, yes. I think this is what I tried to ask. Having an usable JNI interface and on top (in pure java) some wrapper to InputStream or whatever could be done (e.g. by ignoring the return value of write or throwing if != length). Developers could then use the full-featured (non-JAVA-standard) API or select among various wrappers (as InputStream). > This might be more readily doable than to get a committee to > re-specify java-API specs. Yes, of course. I'm afraid that the Java APIs change regularily, but still yet with limited success it seems, so maybe they get it in one of the next iterations; who knows, maybe Java-9 has a BSD-like socket API :) SCNR. > BTW: Whats is off-topic? ( help: not looking for def of > off-topic ) I think I started some "re-specify java-API specs" which was OT probably. oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From lists at iDIAcomputing.com Fri Jun 8 18:48:54 2007 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Fri, 08 Jun 2007 20:48:54 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46684B62.7080802@gmail.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> Message-ID: <4669F8F6.3040101@iDIAcomputing.com> Vicne wrote: > Sorry to step in without a specific solution to your problem, but I > wanted to share my feeling regarding this proposal. AFAIK, it's > generally considered bad practice to pop-up a prompt from a library. ... > > My advice would be to think again and find another solution. Ideas are : > - make the number of retries a parameter so that you can tune it to what > you think is reasonable > - throw a more specific exception when the number of retries has been > reached, so that a specific prompt can be shown at a higher level You could also allow the client code to register a callback class which returns a boolean indicating whether to retry or cancel. This callback class could pop up a dialog, if appropriate, or follow some preset policy, or.... - George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From joachim at buechse.ch Sat Jun 9 09:43:16 2007 From: joachim at buechse.ch (Joachim Buechse) Date: Sat, 9 Jun 2007 17:43:16 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46694F9D.5080501@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: You should not forget, that in the case of an exception it may not even be known what happened to the data. You have a kernel buffer, outgoing chip buffer, incoming chip buffer, etc. So of course, it would be nice to know up to which point data was correctly processed, but this feedback does not exist on the hardware or protocol level and hence can in general not be magicly created on the software level... Regards, Joachim On 08.06.2007, at 14:46, Uncle George wrote: > It seems that with outputstream.write(b[]), you become terribly > uncoordinated as soon as an exception is thrown. Docs do not say what > happens to the data. > > Yet from a practicable point of view, one would like to know if the > write was accepted in-full, or rejected before any writes. There > are no > in betweens, as partial writes are not reportable. > > So for an outputstream.write(), in order for it to return, the full > write request has to be taken, and stored in an internal output > buffer. > If there is no room, the write() is suspended, till there is room. Or > throw's an IOException( "no room in buffer") ; As the select() loop > for > write reports buffer room avail, then more of the internal buffer is > sent to the printer. > > > > yves pielusenet wrote: >> So maybe a better way should be to create a new Exception class which >> has a method "int getWrittenByte()". So the Exception should be >> use to >> send again bytes which are not printed yet. >> >> yves >> >> Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : >>> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: >>>> It is not possible that the rxtx java method write(byte[], int >>>> offset, >>>> int length) return anint which contains the number of byte >>>> really send >>>> to the printer instead of an exception ? >>>> So this is the programm which will see if all bytes have been >>>> sent. If >>>> not it can retry to send the unsended bytes. >>> I think write() is void because in Java people love to do this >>> since OutputStream :-) Of course on such interfaces you cannot >>> implement something nice. If you would have a int write, you >>> would not implement the interface and no applications expecting >>> this interface would link/work/compile. >>> >>> oki, >>> >>> Steffen >>> >>> P.S.: (OT) >>> If you propose not to implement the Java interfaces (especially >>> not on JNI level), maybe optionally offering a wrapper that >>> removes e.g. the write return value and so on to downgrade the >>> powerful classic old POSIX read/write style to the modern limited >>> Java style, then I agree :-) Same for read. Instead of things >>> like "int avialable()" it is more powerful to have an approach as >>> select(2) offers (to guarante the caller that read/write will not >>> block [nothing else make sense anyway IMHO] but may read/write >>> less bytes then requested). The caller gets full control and the >>> higher level protocols can care about timeouts, invoking read in >>> some loops and/or implement retransmission. On top of such an >>> implementation, where everything is controlled, defined, >>> guaranteed and reliable, someone could use an InputStream or >>> OutputStream style interface. Or even better: don't use them at >>> all :) just BTW :-) >>> St. >>> >>> About Ingenico Throughout the world businesses rely on Ingenico >>> for secure and expedient electronic transaction acceptance. >>> Ingenico products leverage proven technology, established >>> standards and unparalleled ergonomics to provide optimal >>> reliability, versatility and usability. This comprehensive range >>> of products is complemented by a global array of services and >>> partnerships, enabling businesses in a number of vertical sectors >>> to accept transactions anywhere their business takes them. >>> 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. >>> >>> About Ingenico Throughout the world businesses rely on Ingenico >>> for secure and expedient electronic transaction acceptance. >>> Ingenico products leverage proven technology, established >>> standards and unparalleled ergonomics to provide optimal >>> reliability, versatility and usability. This comprehensive range >>> of products is complemented by a global array of services and >>> partnerships, enabling businesses in a number of vertical sectors >>> to accept transactions anywhere their business takes them. >>> 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. >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx 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 yvespielusenet at free.fr Mon Jun 11 03:15:12 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Mon, 11 Jun 2007 11:15:12 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: <1181553312.8335.14.camel@localhost.localdomain> So can someone tell a solution for my problem :( Must I say to the user to not put the printer off-line ? I can't since he has to do some pauses, verify print, paper conditioning etc... How do other people ? Before I use the parport librarry to read port status : http://www.geocities.com/Juanga69/parport/ (which doesn't work on windows XP) And I send data into the file LPT1 I use to have no problem when printer was disabled. thanks -- yves piel Le samedi 09 juin 2007 ? 17:43 +0200, Joachim Buechse a ?crit : > You should not forget, that in the case of an exception it may not > even be known what happened to the data. > > You have a kernel buffer, outgoing chip buffer, incoming chip buffer, > etc. So of course, it would be nice to know up to which point data > was correctly processed, but this feedback does not exist on the > hardware or protocol level and hence can in general not be magicly > created on the software level... > > Regards, > Joachim > > On 08.06.2007, at 14:46, Uncle George wrote: > > > It seems that with outputstream.write(b[]), you become terribly > > uncoordinated as soon as an exception is thrown. Docs do not say what > > happens to the data. > > > > Yet from a practicable point of view, one would like to know if the > > write was accepted in-full, or rejected before any writes. There > > are no > > in betweens, as partial writes are not reportable. > > > > So for an outputstream.write(), in order for it to return, the full > > write request has to be taken, and stored in an internal output > > buffer. > > If there is no room, the write() is suspended, till there is room. Or > > throw's an IOException( "no room in buffer") ; As the select() loop > > for > > write reports buffer room avail, then more of the internal buffer is > > sent to the printer. > > > > > > > > yves pielusenet wrote: > >> So maybe a better way should be to create a new Exception class which > >> has a method "int getWrittenByte()". So the Exception should be > >> use to > >> send again bytes which are not printed yet. > >> > >> yves > >> > >> Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : > >>> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > >>>> It is not possible that the rxtx java method write(byte[], int > >>>> offset, > >>>> int length) return anint which contains the number of byte > >>>> really send > >>>> to the printer instead of an exception ? > >>>> So this is the programm which will see if all bytes have been > >>>> sent. If > >>>> not it can retry to send the unsended bytes. > >>> I think write() is void because in Java people love to do this > >>> since OutputStream :-) Of course on such interfaces you cannot > >>> implement something nice. If you would have a int write, you > >>> would not implement the interface and no applications expecting > >>> this interface would link/work/compile. > >>> > >>> oki, > >>> > >>> Steffen > >>> > >>> P.S.: (OT) > >>> If you propose not to implement the Java interfaces (especially > >>> not on JNI level), maybe optionally offering a wrapper that > >>> removes e.g. the write return value and so on to downgrade the > >>> powerful classic old POSIX read/write style to the modern limited > >>> Java style, then I agree :-) Same for read. Instead of things > >>> like "int avialable()" it is more powerful to have an approach as > >>> select(2) offers (to guarante the caller that read/write will not > >>> block [nothing else make sense anyway IMHO] but may read/write > >>> less bytes then requested). The caller gets full control and the > >>> higher level protocols can care about timeouts, invoking read in > >>> some loops and/or implement retransmission. On top of such an > >>> implementation, where everything is controlled, defined, > >>> guaranteed and reliable, someone could use an InputStream or > >>> OutputStream style interface. Or even better: don't use them at > >>> all :) just BTW :-) > >>> St. > >>> > >>> About Ingenico Throughout the world businesses rely on Ingenico > >>> for secure and expedient electronic transaction acceptance. > >>> Ingenico products leverage proven technology, established > >>> standards and unparalleled ergonomics to provide optimal > >>> reliability, versatility and usability. This comprehensive range > >>> of products is complemented by a global array of services and > >>> partnerships, enabling businesses in a number of vertical sectors > >>> to accept transactions anywhere their business takes them. > >>> 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. > >>> > >>> About Ingenico Throughout the world businesses rely on Ingenico > >>> for secure and expedient electronic transaction acceptance. > >>> Ingenico products leverage proven technology, established > >>> standards and unparalleled ergonomics to provide optimal > >>> reliability, versatility and usability. This comprehensive range > >>> of products is complemented by a global array of services and > >>> partnerships, enabling businesses in a number of vertical sectors > >>> to accept transactions anywhere their business takes them. > >>> 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. > >>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx 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 > From Steffen.DETTMER at ingenico.com Mon Jun 11 03:56:18 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 11:56:18 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466990BE.7040100@gatworks.com> References: <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> Message-ID: <20070611095618.GA10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 13:24 -0400: > i was not thinking of change the API to OutputSream. Then I think either someone uses OutputStream (and has no reliable information about incomplete writes) or someone uses somethink else. > Are there specs for how output stream should work internally? > > for instance: > String data = "Hello this is a line of data"; > Outputstream.write( data.getbytes() ); > ParallelPort.suspend(); > int free = ParallelPort.getoutputbufferfree(); > > There is a symbiotic relationship between outputstream and the > functionality of ParallelPort. If you need OutputStream "plus something else", in short you're needing "something else". Personally I dislike the code above a lot. The stream "looks" like if it would be an OutputStream, but in fact it isn't. You need to call getoutputbufferfree later to check if write succeeded (but OutputStream promises that write succeedes synchronous, blocking, or throws an exception). So it is not an OutputStream. No application written for OutputStreams would work without change (because it won't know getoutputbufferfree at all). It is not abstracted from ParallelPort. I think this would be wrong. Then I think an alternative interface instead is better. Let's assume we had some "connection" (to distinguish between OutputStreams and Channels). Then why not working as on a file handle in POSIX: do { // ... select maybe using timer ... readyForWrite = ... if (readyForWrite) { int writtenBytes = connection.write(toWrite); toWrite.remove(0, writtenBytes); } while(readyForWrite && toWrite.length > 0); I think, having such a write isn't the big problem. I think, the difficult thing is around "select" - however this would look like. It should be OO, typesafe, performant, supporting multiple connections/channels/streams in various modes and should be orthogonal to other functionalities. Of course, this heavily depends on what the application is doing; for a simple situation (like reading a small, mandatory file from a local disk) this would be to uncomfortable (and offering unneeded features only). just BTW :) oki, Steffen -- // Modeline for VIM. Please don't remove. // (Help: autoindent, expandtab, shiftwidth=4, tabstop=4, textwidth=75) // vi: set ai et sw=4 ts=4 tw=75 ft=java: About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Mon Jun 11 05:38:33 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 07:38:33 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611095618.GA10821@elberon.bln.de.ingenico.com> References: <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> Message-ID: <466D3439.4020805@gatworks.com> Steffen DETTMER wrote: > (but OutputStream promises that write > succeedes synchronous, blocking, or throws an exception). Where is it so written? From Steffen.DETTMER at ingenico.com Mon Jun 11 06:36:50 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 14:36:50 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466D3439.4020805@gatworks.com> References: <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> <466D3439.4020805@gatworks.com> Message-ID: <20070611123650.GI10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Mon, Jun 11, 2007 at 07:38 -0400: > Steffen DETTMER wrote: > > > (but OutputStream promises that write > > succeedes synchronous, blocking, or throws an exception). > > Where is it so written? Now, as you ask, I think it is not written that clearly but follows from specification. mmm... Am I wrong? I understand the API doc in this way: * http://java.sun.com/j2se/1.4.2/docs/api/java/io/OutputStream.html#write(byte[]) > public void write(byte[] b) > throws IOException > > Writes b.length bytes from the specified byte array to this > output stream. The general contract for write(b) is that > it should have exactly the same effect as the call write(b, > 0, b.length). > > Parameters: > b - the data. > Throws: > IOException - if an I/O error occurs. > See Also: > write(byte[], int, int) and there is: > public void write(byte[] b, > int off, > int len) > throws IOException > > Writes len bytes from the specified byte array starting at > offset off to this output stream. The general contract for > write(b, off, len) is that some of the bytes in the array b > are written to the output stream in order; element b[off] > is the first byte written and b[off+len-1] is the last byte > written by this operation. > > The write method of OutputStream calls the write method of > one argument on each of the bytes to be written out. > Subclasses are encouraged to override this method and > provide a more efficient implementation. > > If b is null, a NullPointerException is thrown. > > If off is negative, or len is negative, or off+len is > greater than the length of the array b, then an > IndexOutOfBoundsException is thrown. > > Parameters: > b - the data. > off - the start offset in the data. > len - the number of bytes to write. > Throws: > IOException - if an I/O error occurs. In particular, an > IOException is thrown if the output stream is closed. In general, any specialisation (derived child class) must comform to this. So write in the end is specified (!) as "The write method ... calls the write method ... on each of the bytes to be written out". This is what must be implemented by ANY OutputStream. Of course, there is: "Subclasses are encouraged to override this method and provide a more efficient implementation." which IMHO does not contradict - the more efficient must behave in exactly the same way of course (just wasting less resources than a simple byte-by-byte write). So it does not matter here I think. The write that finally defines the behavior tells basically: > "Writes the specified byte to this output stream. The general > contract for write is that one byte is written to the output > stream. " > > Throws: > IOException - if an I/O error occurs. which IMHO is another way of saying "write writes the byte immediately and returns on success (only), otherwise an exception is thrown". Especially it cannot happen that zero bytes are written (i.e. the specified byte is NOT written) without an exception. So by this write must be synchronous and blocking, because otherwise it could not reliably know if an asynchronous operation will succeede or not (some getAsyncResult or so would be needed). Since write(byte[]) does this for each byte (or with a behavior beeing exactly the same as if it would do), I think this means that the write(byte[]) succeedes synchronous/blocking or throws an exception. Did I an error in reasoning or confused something or so? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From j.kenneth.gentle at acm.org Mon Jun 11 06:51:25 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 11 Jun 2007 08:51:25 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611123650.GI10821@elberon.bln.de.ingenico.com> References: <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> <466D3439.4020805@gatworks.com> <20070611123650.GI10821@elberon.bln.de.ingenico.com> Message-ID: <200706111251.l5BCpS9T017831@qbang.org> It is as Steffen describes. "InputStream" and "OutputStream" are inherently synchronous (which is why so many java programs resort to threads to use them). Anything outside of this "contract" is *not* an InputStream or OutputStream. That is why there is a new package for things that don't behave like the old *Stream classes - the NIO package. If you look carefully at the IO package, you'll note that almost all the classes are _Decorator_ pattern implementations of the *Stream classes - and the interface presents the _same_ behavior to the calling code in all cases - a synchronous operation that completes successfully or throws an exception (with the one exception of "read" that returns a "-1" on end-of-stream. I know I've read this numerous times - I'd suggest checking the Language Spec or one of the books by Bloch or Gosling. Ken At 08:36 2007-06-11, you wrote: >* Uncle George wrote on Mon, Jun 11, 2007 at 07:38 -0400: > > Steffen DETTMER wrote: > > > > > (but OutputStream promises that write > > > succeedes synchronous, blocking, or throws an exception). > > > > Where is it so written? > >Now, as you ask, I think it is not written that clearly but >follows from specification. mmm... > >Am I wrong? > >I understand the API doc in this way: > >* >http://java.sun.com/j2se/1.4.2/docs/api/java/io/OutputStream.html#write(byte[]) > > public void write(byte[] b) > > throws IOException > > > > Writes b.length bytes from the specified byte array to this > > output stream. The general contract for write(b) is that > > it should have exactly the same effect as the call write(b, > > 0, b.length). > > > > Parameters: > > b - the data. > > Throws: > > IOException - if an I/O error occurs. > > See Also: > > write(byte[], int, int) > > >and there is: > > > > public void write(byte[] b, > > int off, > > int len) > > throws IOException > > > > Writes len bytes from the specified byte array starting at > > offset off to this output stream. The general contract for > > write(b, off, len) is that some of the bytes in the array b > > are written to the output stream in order; element b[off] > > is the first byte written and b[off+len-1] is the last byte > > written by this operation. > > > > The write method of OutputStream calls the write method of > > one argument on each of the bytes to be written out. > > Subclasses are encouraged to override this method and > > provide a more efficient implementation. > > > > If b is null, a NullPointerException is thrown. > > > > If off is negative, or len is negative, or off+len is > > greater than the length of the array b, then an > > IndexOutOfBoundsException is thrown. > > > > Parameters: > > b - the data. > > off - the start offset in the data. > > len - the number of bytes to write. > > Throws: > > IOException - if an I/O error occurs. In particular, an > > IOException is thrown if the output stream is closed. > > >In general, any specialisation (derived child class) must comform >to this. So write in the end is specified (!) as "The write >method ... calls the write method ... on each of the bytes to be >written out". This is what must be implemented by ANY >OutputStream. > >Of course, there is: "Subclasses are encouraged to override this >method and provide a more efficient implementation." which IMHO >does not contradict - the more efficient must behave in exactly >the same way of course (just wasting less resources than a simple >byte-by-byte write). So it does not matter here I think. > > > >The write that finally defines the behavior tells basically: > > > "Writes the specified byte to this output stream. The general > > contract for write is that one byte is written to the output > > stream. " > > > > Throws: > > IOException - if an I/O error occurs. > > >which IMHO is another way of saying "write writes the byte >immediately and returns on success (only), otherwise an exception >is thrown". Especially it cannot happen that zero bytes are >written (i.e. the specified byte is NOT written) without an >exception. So by this write must be synchronous and blocking, >because otherwise it could not reliably know if an asynchronous >operation will succeede or not (some getAsyncResult or so would >be needed). > >Since write(byte[]) does this for each byte (or with a behavior >beeing exactly the same as if it would do), I think this means >that the write(byte[]) succeedes synchronous/blocking or throws >an exception. > >Did I an error in reasoning or confused something or so? > >oki, > >Steffen > >About Ingenico Throughout the world businesses rely on Ingenico for >secure and expedient electronic transaction acceptance. Ingenico >products leverage proven technology, established standards and >unparalleled ergonomics to provide optimal reliability, versatility >and usability. This comprehensive range of products is complemented >by a global array of services and partnerships, enabling businesses >in a number of vertical sectors to accept transactions anywhere >their business takes them. >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. > >About Ingenico Throughout the world businesses rely on Ingenico for >secure and expedient electronic transaction acceptance. Ingenico >products leverage proven technology, established standards and >unparalleled ergonomics to provide optimal reliability, versatility >and usability. This comprehensive range of products is complemented >by a global array of services and partnerships, enabling businesses >in a number of vertical sectors to accept transactions anywhere >their business takes them. >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. > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From alesinskyy at googlemail.com Mon Jun 11 07:25:33 2007 From: alesinskyy at googlemail.com (Oleksandr Alesinskyy) Date: Mon, 11 Jun 2007 15:25:33 +0200 Subject: [Rxtx] [OT] select :-) Message-ID: Sorry, but I have to disagree with following statement: "So write in the end is specified (!) as "The write method ... calls the write method ... on each of the bytes to be written out". This is what must be implemented by ANY OutputStream.". This is not part of the specification or contract, it is just revealed implementation detail of the OutputStream. It is not stated anywhere that behavoiur of derived classes shall conform with this one. Statement concerning "synchronous" nature of the output stream is invalid as well. Really synchronous stream does not require flush() but OutputStream has it. From Steffen.DETTMER at ingenico.com Mon Jun 11 08:21:16 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 16:21:16 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: Message-ID: <20070611142116.GN10821@elberon.bln.de.ingenico.com> * Oleksandr Alesinskyy wrote on Mon, Jun 11, 2007 at 15:25 +0200: > Sorry, but I have to disagree with following statement: > "So write in the end is specified (!) as "The write > method ... calls the write method ... on each of the bytes to be > written out". This is what must be implemented by ANY > OutputStream.". > > This is not part of the specification or contract, it is just > revealed implementation detail of the OutputStream. It is not > stated anywhere that behavoiur of derived classes shall conform > with this one. (I didn't meant that the implementation must really write byte by byte, but that it must "look as if it would do" - because all implementations of OutputStream must "look" in the same way [which is another way of saying "do abstract" I think]) I think the API doc is not "revealing implementation details" but it is the *specification* of that interface and derivations must (should) conform to this specification. Isn't this the idea of interfaces? A function that expects an OutputStream should work on ANY OutputStream, shouldn't it? just kidding: I mean, what would be the point in implementing a checksum function as OutputStream.write which throws its result as IOException? Or which requires to call close() as very first operation to tell that the application is about to transmit confidential data? :-) > Statement concerning "synchronous" nature of the output stream > is invalid as well. Really synchronous stream does not require > flush() but OutputStream has it. ahh, interesting point! I think this is another bug in the API. flush() is wrong. Because write specifies "The general contract for write is that one byte is written to the output stream." but not "a byte may be written or buffered". Actually, an application would need to call flush() after each write (or bunch of write calls) to ensure that write really did something otherwise I think. I didn't found in the spec of OutputStream that it would be required to call flush(). This should mean that calling flush is not required which in turn leads to the conclusion that write must be synchrous (private threads are forbidden because not specified :)) which in turn leads to the conclusion that flush() is not needed at all... I mean, what if someone would only store in write and do the "real write" in flush() and never else? An application could write in one stream and read on another one (e.g. in bidirectional communication) and would never get anything back, because nothing was actually written because no flush was called? Then someone could even think that on error in some write the data could remain buffered AND throw an exception, retrying to send the data in the next write. Ohh, and if there would be some message number inside, and underlaying write (e.g. a protocol offering InputStream/OutputStream) would check this and throw "DuplicatedMessageNumber" the stream would only throw it again and again beeing unusable... In short: I have no clue how someone could be able to implement an asynchrounos write (which is realiable and correct) without beeing specific to anything which is not specified by OutputStream. Well, I think in the end OutputStream was not intended for such communication or protocol implementations - but to read a local disk file or so. In case of I/O errors usually you can abort your application and change the hard disk :-) oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Bob_Jacobsen at lbl.gov Mon Jun 11 09:32:23 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Mon, 11 Jun 2007 08:32:23 -0700 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611142116.GN10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> Message-ID: At 4:21 PM +0200 6/11/07, Steffen DETTMER wrote: > > Statement concerning "synchronous" nature of the output stream >> is invalid as well. Really synchronous stream does not require >> flush() but OutputStream has it. > >ahh, interesting point! > >I think this is another bug in the API. flush() is wrong. Because >write specifies "The general contract for write is that one byte >is written to the output stream." but not "a byte may be written >or buffered". > >Actually, an application would need to call flush() after each >write (or bunch of write calls) to ensure that write really did >something otherwise I think. OutputStreams don't _have_ to be synchronous or asynchronous, but the OutputStream API was be arranged so that subclasses _can_ be synchronous or asynchronous. Such generality is the hardest part of getting an API right. Hence, if at some point a program using an OutputStream wants to be sure that the data has been pushed all the way out, flush() is available. For some subclasses, e.g. the buffered ones, this has important behavior. Others write the data from each call, and flush() doesn't do anything. You _can_ omit it in programs that are known to use this second type, but there's no requirement that you do so; the interface is general in that way. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From Steffen.DETTMER at ingenico.com Mon Jun 11 12:32:39 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 20:32:39 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> Message-ID: <20070611183239.GT10821@elberon.bln.de.ingenico.com> * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: > >Actually, an application would need to call flush() after each > >write (or bunch of write calls) to ensure that write really did > >something otherwise I think. > OutputStreams don't _have_ to be synchronous or asynchronous, > but the OutputStream API was be arranged so that subclasses > _can_ be synchronous or asynchronous. Ahh, oki. Thanks for the clarificaion. So in short, flush() MUST be called on OutputStream, this is just not documented correctly or so clearly (right?). So the overall usage semantics would be: 1. call write (multiple times if desired) 2. call flush only if both succeeded, write was successful. If flush fails it remains unknown if a part of the data was written and/or will be repeated. So the spec (API doc) is wrong. Correct would be to tell that write behaves as told as long as it is followed by a call to flush, otherwise data may or may not get lost (depending wheter close() is called and calls flush(), which seems not to be guaranteed/required). BTW, I think it is a little bit... erm... interesting to find the specification (java API doc reference) wrong, having a need to conclude it from the presence of some methods with "it would make no sense if they behave exactly as specified, so specification must be wrong (incomplete)". > Such generality is the hardest part of getting an API right. Yes, seems to be proven ;) > Hence, if at some point a program using an OutputStream wants > to be sure that the data has been pushed all the way out, > flush() is available. For some subclasses, e.g. the buffered > ones, this has important behavior. Others write the data from > each call, and flush() doesn't do anything. > You _can_ omit it in programs that are known to use this second > type, but there's no requirement that you do so; the interface > is general in that way. I think, it still it must be called always, otherwise the application could break if passing a different runtime type as OutputStream. I think, if the application/method needs a special "type of OutputStream" then the parameter type must be a subclass but not OutputStream, maybe a PrintStream or so - otherwise the compiler could not detect this error (passing wrong type). Is this correct? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Bob_Jacobsen at lbl.gov Mon Jun 11 13:00:52 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Mon, 11 Jun 2007 12:00:52 -0700 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611183239.GT10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> Message-ID: At 8:32 PM +0200 6/11/07, Steffen DETTMER wrote: >So the spec (API doc) is wrong. Correct would be to tell that >write behaves as told as long as it is followed by a call to >flush, otherwise data may or may not get lost (depending wheter >close() is called and calls flush(), which seems not to be >guaranteed/required). I'm not entirely sure that the spec is wrong, but reasonable people can differ on this. In the 1.5 JavaDocs, all that the docs say for the write methods is that they write to the _output_ _stream_; there is no guarantee of anything beyond that. Only the flush method has any guarantee about the data, which is >Flushes this output stream and forces any buffered output bytes to >be written out. The general contract of flush is that calling it is >an indication that, if any bytes previously written have been >buffered by the implementation of the output stream, such bytes >should immediately be written to their intended destination. People commonly use various OutputStreams without using flush(), and it often works, but it's a bad practice and will eventually bite them. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From netbeans at gatworks.com Mon Jun 11 13:31:57 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 15:31:57 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611183239.GT10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> Message-ID: <466DA32D.1010602@gatworks.com> Steffen DETTMER wrote: > * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: >>> Actually, an application would need to call flush() after each >>> write (or bunch of write calls) to ensure that write really did >>> something otherwise I think. > >> OutputStreams don't _have_ to be synchronous or asynchronous, >> but the OutputStream API was be arranged so that subclasses >> _can_ be synchronous or asynchronous. > > Ahh, oki. Thanks for the clarificaion. > > So in short, flush() MUST be called on OutputStream, this is just > not documented correctly or so clearly (right?). No. Flush can be called to force all current data in java buffer's to be written to the kernel - NOW. A flush() can also *imply* that, besides writing out the buffer's that java employs, may also imply/ask the kernel to write all data thusfar written to the kernel, to be physically placed on the destination device - NOW. For some OS's there is no need to do a kernel flush(), as the I/O is synchronized already. Since this is java, you never know what OS your on. From tjarvi at qbang.org Mon Jun 11 19:28:27 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Jun 2007 19:28:27 -0600 (MDT) Subject: [Rxtx] [OT] select :-) In-Reply-To: <466DA32D.1010602@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: On Mon, 11 Jun 2007, Uncle George wrote: > Steffen DETTMER wrote: >> * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: >>>> Actually, an application would need to call flush() after each >>>> write (or bunch of write calls) to ensure that write really did >>>> something otherwise I think. >> >>> OutputStreams don't _have_ to be synchronous or asynchronous, >>> but the OutputStream API was be arranged so that subclasses >>> _can_ be synchronous or asynchronous. >> >> Ahh, oki. Thanks for the clarificaion. >> >> So in short, flush() MUST be called on OutputStream, this is just >> not documented correctly or so clearly (right?). > No. > Flush can be called to force all current data in java buffer's to be > written to the kernel - NOW. > > A flush() can also *imply* that, besides writing out the buffer's that > java employs, may also imply/ask the kernel to write all data thusfar > written to the kernel, to be physically placed on the destination device > - NOW. > For some OS's there is no need to do a kernel flush(), as the I/O is > synchronized already. Since this is java, you never know what OS your on. To add to the confusion, flush on the C side throws away data. drain makes sure it is written. Looking at the ParallelImp.c we can probably do better. /* we set a timeout because all calls are sequentiell (also with asynchron) this means that the default timeout of unlimited blocks all calls (also close and status request) if the device is down */ GetCommTimeouts( (HANDLE)fd, &timeouts ); timeouts.WriteTotalTimeoutMultiplier = 0; timeouts.WriteTotalTimeoutConstant = 2000; /* 2000 is the min value for the default Windows NT and Windows 2000 driver */ SetCommTimeouts( (HANDLE)fd, &timeouts ); while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } errorCount = 0; bytes += countWritten; count -= countWritten; } LPRPort has some timeout code that appears to be doing nothing but flipping bits back and forth right now. The commapi rxtx follows allows for timeout control from javax.comm.CommPort. The above is a solution that worked in one specific use case. With timeouts in place, the original 'old printer going offline' problem could be solved. That printer code isn't written in stone. In fact it was ajusted from being able to print 'asdf' to a daisy wheel printer to working for one person. BTW, I've finished teaching after hours tonight and will be moving forward with a new rxtx release in my free time. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Jun 11 21:28:04 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 23:28:04 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: <466E12C4.1010305@gatworks.com> > Looking at the ParallelImp.c we can probably do better. > The problem stemmed from the possibility that the writev routine could have written some of the buffer, in chunks, printer pauses, refuses any more chunks, and a timeout occurs. Do you or do you not cause an exception to be thrown? Is there a way to set timeout for a ParallelPort data output stream? I cant find it. From tjarvi at qbang.org Mon Jun 11 22:17:23 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Jun 2007 22:17:23 -0600 (MDT) Subject: [Rxtx] [OT] select :-) In-Reply-To: <466E12C4.1010305@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> <466E12C4.1010305@gatworks.com> Message-ID: On Mon, 11 Jun 2007, Uncle George wrote: >> Looking at the ParallelImp.c we can probably do better. >> > The problem stemmed from the possibility that the writev routine could > have written some of the buffer, in chunks, printer pauses, refuses any > more chunks, and a timeout occurs. Do you or do you not cause an > exception to be thrown? > > Is there a way to set timeout for a ParallelPort data output stream? I > cant find it. hmm I looked again after you asked. The timeouts are only controllable on the receive side. This comes from CommPort; the parent. So what we are talking about is some bytes in memory that rxtx has and is supposed to write. A buffer perhaps? The approach with rxtx in the past has been to ignore output buffer sizes. The assumption is that the library does not know how to best handle buffers. There are buffered output streams that can do buffering on top of rxtx for instance. There is also a question regarding what was actually ment when the API was put together. My suspicion is that it was put together while looking at one OS API and was never ment to be anything more than a hook into that API. The comments are fairly telling combined with reading the w32 API. So looking at the problem again.. The current timeout behavior appears fairly arbitrary. Presumably this is to prevent a program from hanging instead of using a helper thread to write - heavy handed for new programmers. Even so, I don't think the write should timeout at all if it is not configurable. >From the API perspective, "What Timeout?" -- Trent Jarvi tjarvi at qbang.org From Steffen.DETTMER at ingenico.com Tue Jun 12 02:14:48 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 12 Jun 2007 10:14:48 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466DA32D.1010602@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: <20070612081447.GU10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Mon, Jun 11, 2007 at 15:31 -0400: > Steffen DETTMER wrote: > > Ahh, oki. Thanks for the clarificaion. > > > > So in short, flush() MUST be called on OutputStream, this is just > > not documented correctly or so clearly (right?). > No. hum (though now I got it, but...). > Flush can be called to force all current data in java buffer's to be > written to the kernel - NOW. > > A flush() can also *imply* that, besides writing out the > buffer's that java employs, may also imply/ask the kernel to > write all data thusfar written to the kernel, to be physically > placed on the destination device - NOW. > > For some OS's there is no need to do a kernel flush(), as the I/O is > synchronized already. Since this is java, you never know what OS your on. (well, but if you're going to kernel level, even flush cannot guarantee that data will "be physically placed". Maybe you're flushing to a file via NFS (and the client "thinks" that it was written, but maybe it was just buffered by the NFS server) or so... but of course such exceptions of the rules are constructable always.) Well, you tell that depending on the OS it can be that flush is needed or it can be that flush is not needed (beacuse the I/O is synchronized already), right? Also, applications should work on any OS, which includes the OSes that do need flush. Since the application cannot know whether flush is needed or not because it doesn't know what the OS is doing, it has to call flush, hasn't it? I mean, if it would not call flush then it would not work on such OSes (except the written data would not be needed at all, but in this would be an artificial example :)). Since applications are supposed to work this would be wrong, wouldn't it? So would it be correct to say: "Applications, that should work under all OSes (including the OSes where the I/O is not synchronised already), have to call flush on OutputStream to ensure the data is transfered to the kernel." or is this wrong? If so, then I'm afraid I missed the point again :( oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Tue Jun 12 04:46:52 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 12 Jun 2007 06:46:52 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070612081447.GU10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> <20070612081447.GU10821@elberon.bln.de.ingenico.com> Message-ID: <466E799C.7060700@gatworks.com> S > (well, but if you're going to kernel level, even flush cannot > guarantee that data will "be physically placed". Thats true now-a-days because ( from "man 2 sync" ) : > According to the standard specification (e.g., SVID), sync() schedules > the writes, but may return before the actual writing is done. However, > since version 1.3.20 Linux does actually wait. (This still does not > guarantee data integrity: modern disks have large caches.) My disk drive has 8mb cache. Maybe you're > flushing to a file via NFS (and the client "thinks" that it was > written, but maybe it was just buffered by the NFS server) or > so... but of course such exceptions of the rules are > constructable always.) > > Well, you tell that depending on the OS it can be that flush is > needed or it can be that flush is not needed (beacuse the I/O is > synchronized already), right? Also, applications should work on > any OS, which includes the OSes that do need flush. Its not OS's that need flush, its applications that want to have some assurance that data is written to the device that really needs to use flush. If your program ( or thread ) dies then it is in your best interest to write out the critical data as soon as possible, as economical as possible. These are trade-off's that the application programmer makes. A big buffer may mean big loss of data, a small buffer may mean spending too much time writing out data. > > > So would it be correct to say: > > "Applications, that should work under all OSes (including the > OSes where the I/O is not synchronised already), have to call > flush on OutputStream to ensure the data is transfered to the > kernel." > > or is this wrong? If so, then I'm afraid I missed the point again > :( > No that is not wrong. Ensuring that data is transfered to the OS is just about what any application can do. From tjarvi at qbang.org Thu Jun 14 08:16:47 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 14 Jun 2007 08:16:47 -0600 (MDT) Subject: [Rxtx] rxtx and usb-serial solution In-Reply-To: References: Message-ID: On Thu, 14 Jun 2007, Vladimir Kirtchev wrote: > Hi Trent, > > I develop a Java application which communicates with devices which have > USB-to-Serial bridge in them. The target OS is Linux. So for this purpose I > use RXTX. > > But I encountered a strange problem - when reading from the InputStream, I > receive series of zeros. I have this problem under Linux only. Under Windows > it is fine. > Actually this problem is the same as the one described here: > http://marc.info/?l=rxtx&m=109703190731748&w=2. > > > So I searched for the problem in the native code. And found that the root of > the problem is in SerialImp.c, > int configure_port( int fd ) > { > ... > ttyset.c_iflag = INPCK; > ... > } > > This line enables input parity checking, and the data sent from the device > is processed by the OS driver before being read with read(). > In this case the driver detects some problem and sets the received bytes to > zero. > > On the other hand in the Java part a set the serial port parameters with > SerialPort.PARITY_NONE. According to me, except all other things, this > should also disable INPCK in c_iflag. > > So I refactored the method translate_parity(...) to the following: > > int translate_parity( JNIEnv *env, struct termios *ttyset, jint parity ) > { > ENTER( "translate_parity" ); > #ifdef CMSPAR > ttyset->c_cflag &= ~(PARENB | PARODD | CMSPAR ); > #endif /* CMSPAR */ > switch( parity ) { > case JPARITY_NONE: > ttyset->c_iflag &= ~INPCK; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_EVEN: > ttyset->c_cflag |= PARENB; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_ODD: > ttyset->c_cflag |= PARENB | PARODD; > LEAVE( "translate_parity" ); > return 0; > #ifdef CMSPAR > case JPARITY_MARK: > ttyset->c_cflag |= PARENB | PARODD | CMSPAR; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_SPACE: > ttyset->c_cflag |= PARENB | CMSPAR; > LEAVE( "translate_parity" ); > return 0; > #endif /* CMSPAR */ > default: > printf("Parity missed %i\n", (int) parity ); > } > > LEAVE( "translate_parity" ); > /* > For some reason the native exceptions are not being caught. Moving this > to the Java side fixed the issue. taj. > throw_java_exception( env, UNSUPPORTED_COMM_OPERATION, > "", "parity value not supported" ); > */ > return 1; > } > > This modification solved the problem and now it works correctly under Linux. > > I think I will be a nice if this is idea is included in a future release of > RXTX. > > Thanks Vadim, I'll try that out. Forwarding to the rxtx mail-list too. This is probably not going to help USB drivers on windows which I'm sure some are looking for. As far as I can tell, windows USB bluetooth and serial dongles are limited by driver functionality. Some are good and others lack key features. -- Trent Jarvi tjarvi at qbang.org From dan.sandberg.lists at gmail.com Mon Jun 18 14:43:39 2007 From: dan.sandberg.lists at gmail.com (Dan Sandberg) Date: Mon, 18 Jun 2007 13:43:39 -0700 Subject: [Rxtx] Fix for JNI Get/Set Field Errors Message-ID: <4676EE7B.7060800@gmail.com> Hi, I've fixed the problems that cause the following JNI error when extra JNI checking ( -Xjni:check ) is turned on. FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) The problem was basically that GetLong was being used to get ints, and SetInt was used for longs. The patch below fixes this. Please let me know if there are any questions / problems. Cheers, -Dan diff -aur old/SerialImp.c src/SerialImp.c --- old/SerialImp.c 2007-06-18 13:24:33.000000000 -0700 +++ src/SerialImp.c 2007-06-18 06:26:26.000000000 -0700 @@ -1337,7 +1337,7 @@ report("init_threads: get eis\n"); jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); report("init_threads: set eis\n"); - (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); + (*eis->env)->SetLongField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); report("init_threads: stop\n"); report_time_end( ); return( 1 ); @@ -1530,7 +1530,7 @@ jobject jobj, jboolean interrupted ) { int fd = get_java_var( env, jobj,"fd","I" ); - struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var( env, jobj, "eis", "J" ); + struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var_long( env, jobj, "eis", "J" ); int result, count=0; char message[80]; @@ -2939,7 +2939,7 @@ /* TRENT */ int flag, count = 0; struct event_info_struct *eis = ( struct event_info_struct * ) - get_java_var( env, *jobj,"eis","J" ); + get_java_var_long( env, *jobj,"eis","J" ); report_time_start(); flag = eis->eventflags[SPE_DATA_AVAILABLE]; @@ -4873,9 +4873,9 @@ exceptions: none comments: ----------------------------------------------------------*/ -size_t get_java_var( JNIEnv *env, jobject jobj, char *id, char *type ) +long get_java_var_long( JNIEnv *env, jobject jobj, char *id, char *type ) { - int result = 0; + long result = 0; jclass jclazz = (*env)->GetObjectClass( env, jobj ); jfieldID jfd = (*env)->GetFieldID( env, jclazz, id, type ); @@ -4889,7 +4889,11 @@ LEAVE( "get_java_var" ); return result; } - result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); + if ( !strcmp( type, "J" ) ) { + result = (long)( (*env)->GetLongField( env, jobj, jfd ) ); + } else { + result = (int) ( (*env)->GetIntField( env, jobj, jfd ) ); + } /* ct7 & gel * Added DeleteLocalRef */ (*env)->DeleteLocalRef( env, jclazz ); if(!strncmp( "fd",id,2) && result == 0) @@ -4900,6 +4904,10 @@ return result; } +int get_java_var( JNIEnv *env, jobject jobj, char *id, char *type ) { + return (int) get_java_var_long( env, jobj, id, type ); +} + /*---------------------------------------------------------- throw_java_exception diff -aur old/SerialImp.h src/SerialImp.h --- old/SerialImp.h 2007-06-18 13:24:39.000000000 -0700 +++ src/SerialImp.h 2007-06-18 06:23:43.000000000 -0700 @@ -413,7 +413,8 @@ void system_wait(); void finalize_event_info_struct( struct event_info_struct * ); int read_byte_array( JNIEnv *, jobject *, int, unsigned char *, int, int ); -size_t get_java_var( JNIEnv *, jobject, char *, char * ); +int get_java_var( JNIEnv *, jobject, char *, char * ); +long get_java_var_long( JNIEnv *, jobject, char *, char * ); jboolean is_interrupted( struct event_info_struct * ); int send_event(struct event_info_struct *, jint, int ); void dump_termios(char *,struct termios *); From yvespielusenet at free.fr Tue Jun 26 03:41:58 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 11:41:58 +0200 Subject: [Rxtx] [PARALLEL] resource in use Message-ID: <1182850918.3483.10.camel@localhost.localdomain> Hello, So now I want to modify the timeout of the library for parallel port. I have downloaded source code. There is a makefile for migw. SO I have installed mingw on ubuntu and modified the makefile.mingw32 to set it for my system. I have no error but some warnings. The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But When I want to use it the jvm crash :( How can I know what is wrong ? How rxtx windows release has been done ? thanks -- yves piel From yvespielusenet at free.fr Tue Jun 26 07:17:02 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 15:17:02 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182850918.3483.10.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> Message-ID: <1182863822.3483.17.camel@localhost.localdomain> Here is the Makefile I use, the output of the 'make' and the log of the jvm when it crashed : - The Makefile : http://yvespiel.free.fr/rxtx/Makefile - The make output : http://yvespiel.free.fr/rxtx/compile.txt - The crash log : http://yvespiel.free.fr/rxtx/hs_err_pid2100.log I have compiled rxtx under Debian testing with mingw : narma at linimi:/tmp/err$ dpkg -l | grep mingw ii mingw32 3.4.5.20060117.1.dfsg-3 ii mingw32-binutils 2.17.50-20070129.1-1 ii mingw32-runtime 3.12-1 thanks fort help :) Le mardi 26 juin 2007 ? 11:41 +0200, yves pielusenet a ?crit : > Hello, > So now I want to modify the timeout of the library for parallel port. I > have downloaded source code. There is a makefile for migw. SO I have > installed mingw on ubuntu and modified the makefile.mingw32 to set it > for my system. > I have no error but some warnings. > The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But > When I want to use it the jvm crash :( > > How can I know what is wrong ? > > How rxtx windows release has been done ? > > thanks > From yvespielusenet at free.fr Tue Jun 26 07:40:11 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 15:40:11 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182863822.3483.17.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> <1182863822.3483.17.camel@localhost.localdomain> Message-ID: <1182865211.3483.21.camel@localhost.localdomain> I have add the options '--enable-stdcall-fixup' to the 'i586-mingw32msvc-ld' commande. Now I have no warning. But the JVM always crashes :( The output seems more detailled, but I don't understand anything... Here is files : http://yvespiel.free.fr/rxtx/2/ -- yves piel Le mardi 26 juin 2007 ? 15:17 +0200, yves pielusenet a ?crit : > Here is the Makefile I use, the output of the 'make' and the log of the > jvm when it crashed : > > - The Makefile : http://yvespiel.free.fr/rxtx/Makefile > - The make output : http://yvespiel.free.fr/rxtx/compile.txt > - The crash log : http://yvespiel.free.fr/rxtx/hs_err_pid2100.log > > I have compiled rxtx under Debian testing with mingw : > narma at linimi:/tmp/err$ dpkg -l | grep mingw > ii mingw32 3.4.5.20060117.1.dfsg-3 > ii mingw32-binutils 2.17.50-20070129.1-1 > ii mingw32-runtime 3.12-1 > > thanks fort help :) > > > Le mardi 26 juin 2007 ? 11:41 +0200, yves pielusenet a ?crit : > > Hello, > > So now I want to modify the timeout of the library for parallel port. I > > have downloaded source code. There is a makefile for migw. SO I have > > installed mingw on ubuntu and modified the makefile.mingw32 to set it > > for my system. > > I have no error but some warnings. > > The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But > > When I want to use it the jvm crash :( > > > > How can I know what is wrong ? > > > > How rxtx windows release has been done ? > > > > thanks > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From yvespielusenet at free.fr Tue Jun 26 08:27:42 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 16:27:42 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182865211.3483.21.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> <1182863822.3483.17.camel@localhost.localdomain> <1182865211.3483.21.camel@localhost.localdomain> Message-ID: <1182868062.3483.24.camel@localhost.localdomain> I think thant the include files of jdk were not for windows but for linux. So I have copied include/ folder from windows to linux and I modified the Makefile to use those file. It compile fine but the JVM always crash :( http://yvespiel.free.fr/rxtx/3/ Le mardi 26 juin 2007 ? 15:40 +0200, yves pielusenet a ?crit : > I have add the options '--enable-stdcall-fixup' to the > 'i586-mingw32msvc-ld' commande. Now I have no warning. But the JVM > always crashes :( The output seems more detailled, but I don't > understand anything... > Here is files : > http://yvespiel.free.fr/rxtx/2/ > From netbeans at gatworks.com Fri Jun 1 05:38:50 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 07:38:50 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <465F7ADD.1010501@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> Message-ID: <4660054A.2040202@gatworks.com> Manuel Naranjo wrote: In the case of my module, you can > unplug the device but it will not delete the symlink until those apps > that had opened the port has closed it. This is done this way to avoid > kernel panics. What does this mean to user code ? I have tried the alternate route ( other than closing ) which is sleep inbetween the I/O errors ( an unplugged USB device). When the device is plugged back in, The writes to the device still get an I/O error. This would seem to be a lost cause for the application. From netbeans at gatworks.com Fri Jun 1 06:35:48 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 08:35:48 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <465F7ADD.1010501@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> Message-ID: <466012A4.90608@gatworks.com> Manuel Naranjo wrote: In the case of my module, you can > unplug the device but it will not delete the symlink until those apps > that had opened the port has closed it. T Did u also mean for this to happen? USB0 was not closed by application. Apparently USB1 got created when USB device was plugged back in. There is only one USB device on a 4 port USB hub. This also seems to suggest that application recovery to be impossible. > Jun 1 07:10:08 mylaptop kernel: garmin_gps 1-1.4:1.0: Garmin GPS usb/tty converter detected > Jun 1 07:10:08 mylaptop kernel: usb 1-1.4: Garmin GPS usb/tty converter now attached to ttyUSB0 > Jun 1 07:15:17 mylaptop kernel: usb 1-1: USB disconnect, address 4 > Jun 1 07:15:17 mylaptop kernel: usb 1-1.4: USB disconnect, address 5 > Jun 1 07:15:17 mylaptop kernel: garmin_gps 1-1.4:1.0: device disconnected > Jun 1 07:15:26 mylaptop kernel: usb 1-1: new full speed USB device using uhci_hcd and address 6 > Jun 1 07:15:26 mylaptop kernel: hub 1-1:1.0: USB hub found > Jun 1 07:15:26 mylaptop kernel: hub 1-1:1.0: 4 ports detected > Jun 1 07:15:27 mylaptop kernel: usb 1-1.4: new full speed USB device using uhci_hcd and address 7 > Jun 1 07:15:27 mylaptop kernel: garmin_gps 1-1.4:1.0: Garmin GPS usb/tty converter detected > Jun 1 07:15:27 mylaptop kernel: usb 1-1.4: Garmin GPS usb/tty converter now attached to ttyUSB1 From naranjo.manuel at gmail.com Fri Jun 1 09:17:22 2007 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Fri, 01 Jun 2007 12:17:22 -0300 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <466012A4.90608@gatworks.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> <466012A4.90608@gatworks.com> Message-ID: <46603882.5050701@gmail.com> Uncle George escribi?: > Manuel Naranjo wrote: > In the case of my module, you can > >> unplug the device but it will not delete the symlink until those apps >> that had opened the port has closed it. T >> > > Did u also mean for this to happen? USB0 was not closed by application. > > Apparently USB1 got created when USB device was plugged back in. There > is only one USB device on a 4 port USB hub. > > This also seems to suggest that application recovery to be impossible. > Exactly there's a dead symlink (you can read and write to it and nothing will happen) and a new port will be created when a new device is connencted. From netbeans at gatworks.com Fri Jun 1 10:20:46 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 12:20:46 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <46603882.5050701@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> <466012A4.90608@gatworks.com> <46603882.5050701@gmail.com> Message-ID: <4660475E.5090202@gatworks.com> Not sure what u mean by "symlink". U cant read/write to it anymore. U get I/O error. In this scenario the device effectively went dead, and only solution is to close the channel. reconnecting the USB device, although dead, but not closed, will create a second device. This does not seem to be a desirable side-effect. The user will now have ttyUSB1, wondering where did ttyUSB0 go to. The application will also be in a confused state, as well as RXTX, because RXTX wont know about ttyUSB1. Manuel Naranjo wrote: > Uncle George escribi?: >> Manuel Naranjo wrote: >> In the case of my module, you can >> >>> unplug the device but it will not delete the symlink until those apps >>> that had opened the port has closed it. T >>> >> Did u also mean for this to happen? USB0 was not closed by application. >> >> Apparently USB1 got created when USB device was plugged back in. There >> is only one USB device on a 4 port USB hub. >> >> This also seems to suggest that application recovery to be impossible. >> > Exactly there's a dead symlink (you can read and write to it and nothing > will happen) and a new port will be created when a new device is connencted. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From arnab.bhaumik at gmail.com Mon Jun 4 01:40:16 2007 From: arnab.bhaumik at gmail.com (arnab bhaumik) Date: Mon, 4 Jun 2007 13:10:16 +0530 Subject: [Rxtx] full duplex com port with rxtx Message-ID: hi , till now i did half duplex communication with rxtx package on com package. my question is : is it possible to use com port with full duplex mode with rxtx package . ther is example of SimpleRead class and SimpleWrite class. it is clear that if i can use both the class simultaneously then full duplex is possible......... arnab/vu2bpw -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070604/6edb0453/attachment-0005.html From lists at iDIAcomputing.com Mon Jun 4 07:53:17 2007 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Mon, 04 Jun 2007 09:53:17 -0400 Subject: [Rxtx] full duplex com port with rxtx In-Reply-To: References: Message-ID: <4664194D.90301@iDIAcomputing.com> arnab bhaumik wrote: > hi , > > till now i did half duplex communication with rxtx package on com > package. > > my question is : is it possible to use com port with full duplex mode > with rxtx package . > > > ther is example of SimpleRead class and SimpleWrite class. it is > clear that if i can use both the class simultaneously then full duplex > is possible......... I haven't looked at the SimpleRead and SimpleWrite classes (I originally wrote my code for the javax.comm api), but full duplex is certainly possible. My CommReader class requires an object analogous to a OutputStream or Writer. When started, it spawns a thread that reads the comm port and writes to that output device. In this way the input is asynchronous and dependent on the actual input data. For full duplex, I extend that class with CommReaderWriter, which adds synchronous output methods. Hope that helps, George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From supsoop at hotmail.com Mon Jun 4 15:21:06 2007 From: supsoop at hotmail.com (soop soop) Date: Mon, 04 Jun 2007 21:21:06 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- Message-ID: Hi Guys, Looked through the archives but still cannot figure this out. I have a Motorola G24 GPRS/GSM modem that I am connecting to my server running Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not detecting the port, CommPortIdentifier.getPortIdentifiers(). I have added the line to RXTXCommDriver: "ttyACM" // for USB Modems Rxtx still does not seem to find the port. Is there something I am missing to make this port visable? [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control Model driver for USB modems and ISDN adapters I really need your help as I have moved my server from windows to Linux and have been down for a few days because of this .. Thanks so much! _________________________________________________________________ PC Magazine’s 2007 editors’ choice for best Web mail—award-winning Windows Live Hotmail. http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 From tjarvi at qbang.org Mon Jun 4 16:17:35 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Jun 2007 16:17:35 -0600 (MDT) Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: On Mon, 4 Jun 2007, soop soop wrote: > Hi Guys, > > Looked through the archives but still cannot figure this out. I have a > Motorola G24 GPRS/GSM modem that I am connecting to my server running Ubuntu. > I can see my modem as is shows up as ttyACM0, but RXTX is not detecting the > port, CommPortIdentifier.getPortIdentifiers(). > > I have added the line to RXTXCommDriver: > > "ttyACM" // for USB Modems > > Rxtx still does not seem to find the port. Is there something I am missing to > make this port visable? > > [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver > [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device > [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control Model > driver for USB modems and ISDN adapters > > I really need your help as I have moved my server from windows to Linux and > have been down for a few days because of this .. Thanks so much! > You could try the INSTALL documentation that comes with the source for possible solutions. Those usually involve lockfile creation, permissions on the device file or the device is in use by another application (even another session of your application). The usual commands: ls -l /dev/ttyACM0 fuser /dev/ttyACM0 touch /var/lock/LCK.testfile && rm -f /var/lock/LCK.testfile whoami To disable lockfiles: ../configure --disable-lockfiles && make install -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Jun 4 16:22:52 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 04 Jun 2007 18:22:52 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <466490BC.3090801@gatworks.com> soop soop wrote: > I really need your help as I have moved my server from windows to Linux > and have been down for a few days because of this .. Thanks so much! can u open the device ? ie is the file protection/permissions keeping you out? From supsoop at hotmail.com Mon Jun 4 16:44:40 2007 From: supsoop at hotmail.com (soop soop) Date: Mon, 04 Jun 2007 22:44:40 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <466490BC.3090801@gatworks.com> Message-ID: Thanks for the reply, I see no exceptions being thrown, just no detection of the port whats so ever. I will run rxtx in debug mode and log. If this were a permissions issue would I not see some exceptions being thrown? >From: Uncle George >Reply-To: RXTX Developers and Users >To: RXTX Developers and Users >Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >Date: Mon, 04 Jun 2007 18:22:52 -0400 > >soop soop wrote: > > > I really need your help as I have moved my server from windows to Linux > > and have been down for a few days because of this .. Thanks so much! > >can u open the device ? ie is the file protection/permissions keeping >you out? >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ Get a preview of Live Earth, the hottest event this summer - only on MSN http://liveearth.msn.com?source=msntaglineliveearthhm From netbeans at gatworks.com Mon Jun 4 17:06:15 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 04 Jun 2007 19:06:15 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <46649AE7.10405@gatworks.com> Exceptions on what? On startup it wants to lookup all devices in /dev that it is capable of opening ( within the list of specific 'comm' devices ). If it cannot open, then does not get onto list. Part of this process, if configured, will also test if the "LOCK" schema can also be opened for the device. then it gets on the list of avail comm port. soop soop wrote: > Thanks for the reply, > > I see no exceptions being thrown, just no detection of the port whats so > ever. I will run rxtx in debug mode and log. If this were a permissions > issue would I not see some exceptions being thrown? > > >> From: Uncle George >> Reply-To: RXTX Developers and Users >> To: RXTX Developers and Users >> Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >> Date: Mon, 04 Jun 2007 18:22:52 -0400 >> >> soop soop wrote: >> >>> I really need your help as I have moved my server from windows to Linux >>> and have been down for a few days because of this .. Thanks so much! >> can u open the device ? ie is the file protection/permissions keeping >> you out? >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _________________________________________________________________ > Get a preview of Live Earth, the hottest event this summer - only on MSN > http://liveearth.msn.com?source=msntaglineliveearthhm > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From alex.flint at gmail.com Mon Jun 4 21:31:49 2007 From: alex.flint at gmail.com (Alex Flint) Date: Tue, 5 Jun 2007 13:01:49 +0930 Subject: [Rxtx] random EXCEPTION_ACCESS_VIOLATION errors Message-ID: Hi All, I'm running winXP and RXTX 2.1-7r2 (the latest from the webpage as of June 2007). I'm sending sequences of 64 lines (each line has about 15 chars) at various intervals. The strings are sent fine, until I get the following error (from hs_err_pid3316.log, at the end of this email). What can I do to avoid the error? Obviously this is a low-level memory exception, but is there any way I can keep the JVM running after such an error? I noticed the exact same problem here: http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20070129/1180520.html Cheers, Alex # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x100034fb, pid=3316, tid=2400 # # Java VM: Java HotSpot(TM) Client VM (1.6.0_01-b06 mixed mode, sharing) # Problematic frame: # C [rxtxSerial.dll+0x34fb] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # --------------- T H R E A D --------------- Current thread (0x00386400): JavaThread "main" [_thread_in_native, id=2400] siginfo: ExceptionCode=0xc0000005, reading address 0x20726f78 Registers: EAX=0x20726f20, EBX=0x6d8922c0, ECX=0x00000005, EDX=0x20726f20 ESP=0x003efa30, EBP=0x003efb68, ESI=0x269728a0, EDI=0x00386400 EIP=0x100034fb, EFLAGS=0x00010212 Top of Stack: (sp=0x003efa30) 0x003efa30: 003efa3c 003efa64 0000000f ffffffff 0x003efa40: 003efa40 2a97f808 003efa6c 2b190ca8 0x003efa50: 00000000 2b190ec0 003efa90 008e2dd7 0x003efa60: 003efa90 008e2dd7 26977f88 6d815e72 0x003efa70: 00000004 2696eae0 0000008a 003efb0c 0x003efa80: 6d852b4a 2696eae0 00000003 26970930 0x003efa90: 000000cb 2696eae0 6d86b264 00385d40 0x003efaa0: 0000003f 003efb0c 26977f90 2ace65d8 Instructions: (pc=0x100034fb) 0x100034eb: ff ff 8d 76 00 eb 02 89 f6 90 8b 45 f8 8b 55 f8 0x100034fb: 8b 4a 58 83 c9 04 89 48 58 83 c4 f8 8b 45 f8 8b Stack: [0x003a0000,0x003f0000), sp=0x003efa30, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x34fb] Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j gnu.io.RXTXPort.writeArray([BIIZ)V+0 j gnu.io.RXTXPort$SerialOutputStream.write([B)V+76 j com.bjt.media.server.CommLink.send(Ljava/lang/String;)V+48 j com.bjt.media.server.DigitoolConnection.select(I)V+73 j com.bjt.media.server.DigitoolConnection.main([Ljava/lang/String;)V+74 v ~StubRoutines::call_stub --------------- P R O C E S S --------------- Java Threads: ( => current thread ) 0x02a69400 JavaThread "Thread-0" [_thread_in_native, id=3052] 0x02a4d000 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=3920] 0x02a48400 JavaThread "CompilerThread0" daemon [_thread_blocked, id=1968] 0x02a47400 JavaThread "Attach Listener" daemon [_thread_blocked, id=2984] 0x02a46400 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=2660] 0x02a41c00 JavaThread "Finalizer" daemon [_thread_blocked, id=3924] 0x02a3d800 JavaThread "Reference Handler" daemon [_thread_blocked, id=4008] =>0x00386400 JavaThread "main" [_thread_in_native, id=2400] Other Threads: 0x02a34400 VMThread [id=3708] 0x02a4e800 WatcherThread [id=3964] VM state:not at safepoint (normal execution) VM Mutex/Monitor currently owned by a thread: None Heap def new generation total 960K, used 131K [0x22960000, 0x22a60000, 0x22e40000) eden space 896K, 7% used [0x22960000, 0x22970ea8, 0x22a40000) from space 64K, 99% used [0x22a50000, 0x22a5fff8, 0x22a60000) to space 64K, 0% used [0x22a40000, 0x22a40000, 0x22a50000) tenured generation total 4096K, used 76K [0x22e40000, 0x23240000, 0x26960000) the space 4096K, 1% used [0x22e40000, 0x22e53060, 0x22e53200, 0x23240000) compacting perm gen total 12288K, used 137K [0x26960000, 0x27560000, 0x2a960000) the space 12288K, 1% used [0x26960000, 0x26982518, 0x26982600, 0x27560000) ro space 8192K, 62% used [0x2a960000, 0x2ae5e4e8, 0x2ae5e600, 0x2b160000) rw space 12288K, 52% used [0x2b160000, 0x2b7a0e78, 0x2b7a1000, 0x2bd60000) Dynamic libraries: 0x00400000 - 0x00423000 C:\Program Files\Java\jre1.6.0_01\bin\javaw.exe 0x7c900000 - 0x7c9b0000 C:\WINDOWS\system32\ntdll.dll 0x7c800000 - 0x7c8f4000 C:\WINDOWS\system32\kernel32.dll 0x77dd0000 - 0x77e6b000 C:\WINDOWS\system32\ADVAPI32.dll 0x77e70000 - 0x77f01000 C:\WINDOWS\system32\RPCRT4.dll 0x7e410000 - 0x7e4a0000 C:\WINDOWS\system32\USER32.dll 0x77f10000 - 0x77f57000 C:\WINDOWS\system32\GDI32.dll 0x76390000 - 0x763ad000 C:\WINDOWS\system32\IMM32.DLL 0x7c340000 - 0x7c396000 C:\Program Files\Java\jre1.6.0_01\bin\msvcr71.dll 0x6d7c0000 - 0x6da07000 C:\Program Files\Java\jre1.6.0_01\bin\client\jvm.dll 0x76b40000 - 0x76b6d000 C:\WINDOWS\system32\WINMM.dll 0x5cd70000 - 0x5cd77000 C:\WINDOWS\system32\serwvdrv.dll 0x5b0a0000 - 0x5b0a7000 C:\WINDOWS\system32\umdmxfrm.dll 0x6d310000 - 0x6d318000 C:\Program Files\Java\jre1.6.0_01\bin\hpi.dll 0x76bf0000 - 0x76bfb000 C:\WINDOWS\system32\PSAPI.DLL 0x6d770000 - 0x6d77c000 C:\Program Files\Java\jre1.6.0_01\bin\verify.dll 0x6d3b0000 - 0x6d3cf000 C:\Program Files\Java\jre1.6.0_01\bin\java.dll 0x6d7b0000 - 0x6d7bf000 C:\Program Files\Java\jre1.6.0_01\bin\zip.dll 0x10000000 - 0x10012000 C:\Documents and Settings\Alex\workspace\MediaServer\rxtxSerial.dll 0x73d90000 - 0x73db7000 C:\WINDOWS\system32\crtdll.dll VM Arguments: jvm_args: -Djava.library.path=C:\Documents and Settings\Alex\workspace\MediaServer java_command: com.bjt.media.server.DigitoolConnection Launcher Type: SUN_STANDARD Environment Variables: CLASSPATH=.;C:\Program Files\Java\j2re1.4.2_07\lib\ext\QTJava.zip PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\wbem;c:\applications\php;C:\Program Files\MATLAB\R2006a\bin\win32;C:\Roger\Projects\UAV\Bin\Debug;C:\Program Files\Microsoft SQL Server\80\Tools\Binn\;c:\Program Files\Microsoft SQL Server\90\Tools\binn\;C:\Program Files\QuickTime\QTSystem\;C:\Pfps\system;C:\Program Files\Java\jdk1.6.0_01\bin;C:\Program Files\Java\jdk1.6.0_01\jre\bin USERNAME=Alex OS=Windows_NT PROCESSOR_IDENTIFIER=x86 Family 15 Model 4 Stepping 1, GenuineIntel --------------- S Y S T E M --------------- OS: Windows XP Build 2600 Service Pack 2 CPU:total 1 family 15, cmov, cx8, fxsr, mmx, sse, sse2 Memory: 4k page, physical 1046508k(275288k free), swap 2522816k(1909176k free) vm_info: Java HotSpot(TM) Client VM (1.6.0_01-b06) for windows-x86, built on Mar 14 2007 00:24:02 by "java_re" with unknown MS VC++:1310 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070604/c87ae1f0/attachment-0005.html From alwyn.schoeman at gmail.com Tue Jun 5 00:10:19 2007 From: alwyn.schoeman at gmail.com (Alwyn Schoeman) Date: Tue, 5 Jun 2007 08:10:19 +0200 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Hi, I'm using a similar modem. By default rxtx doesn't look for devices that start with ACM, so you need to modify the source code and recompile. Look in RXTXCommDriver and add values for ACM in the registerScannedPorts method in the Linux specific parts. Look for osName.equals("Linux")... On 6/4/07, soop soop wrote: > > Hi Guys, > > Looked through the archives but still cannot figure this out. I have a > Motorola G24 GPRS/GSM modem that I am connecting to my server running > Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not > detecting the port, CommPortIdentifier.getPortIdentifiers(). > > I have added the line to RXTXCommDriver: > > "ttyACM" // for USB Modems > > Rxtx still does not seem to find the port. Is there something I am missing > to make this port visable? > > [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver > [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device > [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control > Model > driver for USB modems and ISDN adapters > > I really need your help as I have moved my server from windows to Linux > and > have been down for a few days because of this .. Thanks so much! > > _________________________________________________________________ > PC Magazine's 2007 editors' choice for best Web mail?award-winning Windows > Live Hotmail. > > http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -- Alwyn Schoeman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/b6cb3053/attachment-0005.html From naranjo.manuel at gmail.com Tue Jun 5 06:48:45 2007 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Tue, 05 Jun 2007 09:48:45 -0300 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> References: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Message-ID: <46655BAD.7010501@gmail.com> That's right, an easier solution is creating symlinks to acm. For example make ttyS70 to 79 point to ACM0 to 9 and that will help you a lot, and doesn't even require compile. > Hi, > > I'm using a similar modem. By default rxtx doesn't look for devices > that start with ACM, so you need to modify the > source code and recompile. > > Look in RXTXCommDriver and add values for ACM in the > registerScannedPorts method in the Linux specific parts. Look for > osName.equals("Linux")... > From juanemc2 at gmail.com Tue Jun 5 07:02:43 2007 From: juanemc2 at gmail.com (Juan) Date: Tue, 5 Jun 2007 10:02:43 -0300 Subject: [Rxtx] Problems with Epson TMU220B POSPrinter using XON/XOFF Flow Control and rxtx jar and dll's with the serial port. Message-ID: Hi!, I?m having trouble printing to the serial port using the latest version of rxtx jar and dll's with an Epson POSPrinter. I`ve switched the printer to work with XON/XOFF Flow Control and have watched the serial port to be sure the printer is sending the XON XOFF stop and go characters. I`ve setted the port like this: CommPortIdentifier commPortIdentifier = CommPortIdentifier.* getPortIdentifier*(_portName); SerialPort serialPort = (SerialPort)commPortIdentifier.open(*this*.getClass().getName(), 2000); serialPort.setSerialPortParams(_baudRate, _dataBits, _stopBits, _parity); serialPort.setFlowControlMode( SerialPort.*FLOWCONTROL_XONXOFF_IN* | SerialPort.*FLOWCONTROL_XONXOFF_OUT*); where the baudRate is 9600 the dataBits is 8 the stopBits is 1 and the parity is 0 It seems as the library isn`t taking into account the XON XOFF setting. I would like to know if I`m setting correctly the Flow Control and if you had had any experiences using XON XOFF flow control and could give me some help to solve my problem. I`m very thankful in advance, Yours, Juan Polero -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/b080995a/attachment-0005.html From ehdez.correo at gmail.com Tue Jun 5 07:12:53 2007 From: ehdez.correo at gmail.com (=?ISO-8859-1?Q?Enrique_Hern=E1ndez?=) Date: Tue, 5 Jun 2007 09:12:53 -0400 Subject: [Rxtx] problem with rxtx Message-ID: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Hello: I doing a simple test to show the serial ports. This is the code: import java.util.Enumeration; import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; public class Show { private Enumeration portList; private CommPortIdentifier portId; private SerialPort port; /** Creates a new instance of Show */ public Show() { } public static void main(String args[]){ Show show = new Show(); show.portList = CommPortIdentifier.getPortIdentifiers(); String tPort = ""; System.out.println("========================================="); while(show.portList.hasMoreElements()){ show.portId = (CommPortIdentifier)show.portList.nextElement(); if(show.portId.getPortType() == CommPortIdentifier.PORT_SERIAL) tPort = "Serial"; else tPort = "Parallel"; System.out.println(show.portId.getName() + " " + tPort); } } } whit The problem is that this code not show the serial ports, this show the no use serial ports. I want to connect whit the modem but when windows open and connect the modem my application don't see the port(COMM3) when it is connect. what I can do? Is that the correct way to know the ports? thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/eedd744b/attachment-0005.html From ehdez.correo at gmail.com Tue Jun 5 07:42:13 2007 From: ehdez.correo at gmail.com (=?ISO-8859-1?Q?Enrique_Hern=E1ndez?=) Date: Tue, 5 Jun 2007 09:42:13 -0400 Subject: [Rxtx] serial port Message-ID: <4a814e1f0706050642p4ce9ac7bka80f9479c524c5ea@mail.gmail.com> Hello: How I can ask to the port what device is connect and information about this device. thanks. bye. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/4d10d26a/attachment-0005.html From supsoop at hotmail.com Tue Jun 5 09:29:00 2007 From: supsoop at hotmail.com (soop soop) Date: Tue, 05 Jun 2007 15:29:00 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Message-ID: Hi Guys, Thanks for all your help. I found the problem. I created a user, Tomcat55, for my tomcat but it did not belong to any group. I then added this user to dialout group to have access to the device ttyACM0. Works perfectly! Again permissions was the issue. This also seems to be persistent as a server reboot does not effect the access. Cheers! >From: "Alwyn Schoeman" >Reply-To: RXTX Developers and Users >To: "RXTX Developers and Users" >Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >Date: Tue, 5 Jun 2007 08:10:19 +0200 > >Hi, > >I'm using a similar modem. By default rxtx doesn't look for devices that >start with ACM, so you need to modify the >source code and recompile. > >Look in RXTXCommDriver and add values for ACM in the registerScannedPorts >method in the Linux specific parts. Look for osName.equals("Linux")... > >On 6/4/07, soop soop wrote: >> >>Hi Guys, >> >>Looked through the archives but still cannot figure this out. I have a >>Motorola G24 GPRS/GSM modem that I am connecting to my server running >>Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not >>detecting the port, CommPortIdentifier.getPortIdentifiers(). >> >>I have added the line to RXTXCommDriver: >> >>"ttyACM" // for USB Modems >> >>Rxtx still does not seem to find the port. Is there something I am missing >>to make this port visable? >> >>[ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver >>[ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device >>[ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control >>Model >>driver for USB modems and ISDN adapters >> >>I really need your help as I have moved my server from windows to Linux >>and >>have been down for a few days because of this .. Thanks so much! >> >>_________________________________________________________________ >>PC Magazine's 2007 editors' choice for best Web mail—award-winning Windows >>Live Hotmail. >> >>http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 >> >> >>_______________________________________________ >>Rxtx mailing list >>Rxtx at qbang.org >>http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > >-- >Alwyn Schoeman >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ Need a break? Find your escape route with Live Search Maps. http://maps.live.com/default.aspx?ss=Restaurants~Hotels~Amusement%20Park&cp=33.832922~-117.915659&style=r&lvl=13&tilt=-90&dir=0&alt=-1000&scene=1118863&encType=1&FORM=MGAC01 From netbeans at gatworks.com Tue Jun 5 09:42:31 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 11:42:31 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <46658467.20101@gatworks.com> soop soop wrote: > > Hi Guys, > > Thanks for all your help. I found the problem. I created a user, > Tomcat55, for my tomcat but it did not belong to any group. I then added Look at man pages for the program udev. From tjarvi at qbang.org Tue Jun 5 18:18:17 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Jun 2007 18:18:17 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Message-ID: On Tue, 5 Jun 2007, Enrique Hern?ndez wrote: > The problem is that this code not show the serial ports, this show the no > use serial ports. I want to connect whit the modem but when windows open and > connect the modem my application don't see the port(COMM3) when it is > connect. > what I can do? > Is that the correct way to know the ports? > Hello, We may have problems understanding each other. On windows, the port will not be an available serial port if another application has the port open. That is just how the library behaves. If you can not see the port in the enumerated list, you could not open it. Also note that enumeration only happens once. If you add a port such as a new USB dongle, the port will not be visible until the next time your application runs. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Tue Jun 5 18:45:01 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 20:45:01 -0400 Subject: [Rxtx] problem with rxtx In-Reply-To: References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Message-ID: <4666038D.8090700@gatworks.com> Trent Jarvi wrote: > > > Also note that enumeration only happens once. If you add a port such as > a new USB dongle, the port will not be visible until the next time your > application runs. Is this written in stone ? somewhere? From tjarvi at qbang.org Tue Jun 5 18:54:36 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Jun 2007 18:54:36 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <4666038D.8090700@gatworks.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> Message-ID: On Tue, 5 Jun 2007, Uncle George wrote: > Trent Jarvi wrote: >> >> >> Also note that enumeration only happens once. If you add a port such as >> a new USB dongle, the port will not be visible until the next time your >> application runs. > > Is this written in stone ? somewhere? It is just the current behavior. There is nothing preventing a fix that allows reenumeration. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Tue Jun 5 19:55:19 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 21:55:19 -0400 Subject: [Rxtx] problem with rxtx In-Reply-To: References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> Message-ID: <46661407.4020308@gatworks.com> >> Is this written in stone ? somewhere? > > It is just the current behavior. There is nothing preventing a fix that > allows reenumeration. With usb, ..... , things come and go. Seems a shame that you have to kill application to get at the device u just plugged in. From joachim at buechse.ch Wed Jun 6 01:50:06 2007 From: joachim at buechse.ch (Joachim Buechse) Date: Wed, 6 Jun 2007 09:50:06 +0200 Subject: [Rxtx] problem with rxtx In-Reply-To: <46661407.4020308@gatworks.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> <46661407.4020308@gatworks.com> Message-ID: <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> On MacOS RXTX's enumeration handling is more flexible. It will find new ports that are added during the lifetime of the application. But this is inherently incompatible with suns javax.comm implementation... Regards, Joachim On 06.06.2007, at 03:55, Uncle George wrote: > >>> Is this written in stone ? somewhere? >> >> It is just the current behavior. There is nothing preventing a >> fix that >> allows reenumeration. > > With usb, ..... , things come and go. Seems a shame that you have to > kill application to get at the device u just plugged in. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Jun 6 06:06:48 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Jun 2007 06:06:48 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> <46661407.4020308@gatworks.com> <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> Message-ID: Sun's javax.comm is not a major concern going forward. As long as we do not break old applications using rxtx, I see no reason to limit rxtx to that convention. We have already rejected version 3 from Sun as a dead end and limited our compatability to version 2. That does not mean we will not try to work with Sun and others but the current javax.comm convention (v3) is not a well conceived path. There has been discussion about doing a JSR which is one valid option. On Wed, 6 Jun 2007, Joachim Buechse wrote: > On MacOS RXTX's enumeration handling is more flexible. It will find > new ports that are added during the lifetime of the application. But > this is inherently incompatible with suns javax.comm implementation... > > Regards, > Joachim > > On 06.06.2007, at 03:55, Uncle George wrote: > >> >>>> Is this written in stone ? somewhere? >>> >>> It is just the current behavior. There is nothing preventing a >>> fix that >>> allows reenumeration. >> >> With usb, ..... , things come and go. Seems a shame that you have to >> kill application to get at the device u just plugged in. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From yvespielusenet at free.fr Wed Jun 6 08:46:35 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 16:46:35 +0200 Subject: [Rxtx] [PARALLEL] resource in use Message-ID: <1181141195.3407.20.camel@localhost.localdomain> Hello, I want to use rxtx in my application. I haveto send data to a very old printer (which have a drum and hammers http://perso.orange.fr/tiie/page00010017.html) This is printer is connecter with centronics. It works well but, while it's writting and I putthe printer off-line, after about 45 seconds, I have this error : ------------------------------------- java.io.IOException: La ressource demand?e est en cours d'utilisation. in writeArray at gnu.io.LPRPort.writeArray(Native Method) at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:292) at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:161) at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:156) at mce.buffer.bufferManager.BufferManager$PrintBuffer.run(BufferManager.java:141) The IOexception means "The wanted resource is in use" ------------------------------------- Here is the line 141 of BufferManager : ------------------------------------- while(send){ try{ fos.write(bb); <=== line 141 send = false; } catch(Exception e){ javax.swing.JOptionPane.showMessageDialog(null, "Erreur d'envoie. Veuillez cliquer sur OK pour relancer l'impression de la vignette.\nV?rifiez votre impression !", "Erreur d'envoie", javax.swing.JOptionPane.WARNING_MESSAGE); e.printStackTrace(System.err); System.err.flush(); System.out.println(e); send = true; } } -------------------------------- 'fos' is an outputstream which contains the rxtx stream (this.os is the rxtx outputstream) : -------------------------------- public void write(byte[] bb) throws IOException{ this.write(bb, 0, bb.length); } public void write(byte[] bb, int off, int len) throws IOException{ while(!imp1.isPrinterSelected() || !imp2.isPrinterSelected()){ } this.os.write(bb, off, len); } -------------------------------- Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( can you help me ? thank you :) -- yves piel From yvespielusenet at free.fr Wed Jun 6 09:11:15 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 17:11:15 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181141195.3407.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> Message-ID: <1181142675.3407.23.camel@localhost.localdomain> I forgot to tell that It's under windows XP and java 1.5. Le mercredi 06 juin 2007 ? 16:46 +0200, yves pielusenet a ?crit : > Hello, > I want to use rxtx in my application. I haveto send data to a very old > printer (which have a drum and hammers > http://perso.orange.fr/tiie/page00010017.html) > This is printer is connecter with centronics. It works well but, while > it's writting and I putthe printer off-line, after about 45 seconds, I > have this error : > ------------------------------------- > java.io.IOException: La ressource demand?e est en cours d'utilisation. > in writeArray > at gnu.io.LPRPort.writeArray(Native Method) > at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:292) > at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:161) > at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:156) > at mce.buffer.bufferManager.BufferManager$PrintBuffer.run(BufferManager.java:141) > > The IOexception means "The wanted resource is in use" > ------------------------------------- > > Here is the line 141 of BufferManager : > > ------------------------------------- > while(send){ > try{ > fos.write(bb); <=== line 141 > send = false; > } > catch(Exception e){ > javax.swing.JOptionPane.showMessageDialog(null, "Erreur d'envoie. Veuillez cliquer sur OK pour relancer l'impression de la vignette.\nV?rifiez votre impression !", "Erreur d'envoie", javax.swing.JOptionPane.WARNING_MESSAGE); > e.printStackTrace(System.err); > System.err.flush(); > System.out.println(e); > send = true; > } > } > -------------------------------- > 'fos' is an outputstream which contains the rxtx stream (this.os is the rxtx outputstream) : > > -------------------------------- > public void write(byte[] bb) throws IOException{ > this.write(bb, 0, bb.length); > } > public void write(byte[] bb, int off, int len) throws IOException{ > while(!imp1.isPrinterSelected() || !imp2.isPrinterSelected()){ > } > this.os.write(bb, off, len); > } > -------------------------------- > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > can you help me ? > > thank you :) > From netbeans at gatworks.com Wed Jun 6 09:21:46 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 11:21:46 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181141195.3407.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> Message-ID: <4666D10A.8000507@gatworks.com> } > -------------------------------- > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > can you help me ? > > thank you :) > windoz or linux? ( I guess windoz ) for windoz, there appears to be a timeout ( as Comments suggest ) of about 40seconds. > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } for linux, there is no implied timeout. > if( write( fd, bytes, count ) < 0 ) > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); From netbeans at gatworks.com Wed Jun 6 09:39:41 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 11:39:41 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666D10A.8000507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> Message-ID: <4666D53D.90000@gatworks.com> Uncle George wrote: > } >> -------------------------------- >> >> Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( >> >> can you help me ? From reading the code, I can see your concern. And it appears you are correct, because some of the data will be sent to the OS printer buffers, and then it will refuse to accept anymore. Unfortunately, writeArray does not return the num of characters written :{ So application has no idea to how many characters were accepted by the OS. I dont do windoz, so I cant say with absolute certainty what windoz will do with an off-line condition. If you have the source, and can compile, then maybe u can increase the loop count to hit 4hours? From yvespielusenet at free.fr Wed Jun 6 09:53:25 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 17:53:25 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666D10A.8000507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> Message-ID: <1181145205.3407.35.camel@localhost.localdomain> Thank you for your explanation :) This timeout comes when no data has been send to the printer after 40seconds if I well understand. But why there is such a timeout ? If I setthe printer offline while it's printing I mustn't have an exception. I don't understand why the "printer should solv all problems like buffer full" in 40 seconds. If I pause the printer the buffer will not be emptied, isn't it ? I not very familiar with C/C++, but it seem that the exception is thrown only when countWritten == 0, that means no data at all has been sent. So Is my code is good since when I intercept this exception I send all my buffer again. There is no way that the printer receive two times same bytes ? thanks ps: yes the application is running on windows XP since I developpe under Debian Le mercredi 06 juin 2007 ? 11:21 -0400, Uncle George a ?crit : > } > > -------------------------------- > > > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > > > can you help me ? > > > > thank you :) > > > > windoz or linux? ( I guess windoz ) > > for windoz, there appears to be a timeout ( as Comments suggest ) of > about 40seconds. > > while( count > 0 ){ > > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > > /* > > this are 20 * 2 seconds, in this time a printer (or other parallel device) > > should solv all problems like buffer full, etc > > */ > > if(errorCount++ < 20){ > > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > > continue; > > } > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > for linux, there is no implied timeout. > > if( write( fd, bytes, count ) < 0 ) > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Wed Jun 6 10:34:24 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 12:34:24 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181145205.3407.35.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> Message-ID: <4666E210.30507@gatworks.com> yves pielusenet wrote: > Thank you for your explanation :) > This timeout comes when no data has been send to the printer after > 40seconds if I well understand. But why there is such a timeout ? If I > setthe printer offline while it's printing I mustn't have an exception. > I don't understand why the "printer should solv all problems like buffer > full" in 40 seconds. If I pause the printer the buffer will not be > emptied, isn't it ? > > I not very familiar with C/C++, but it seem that the exception is thrown > only when countWritten == 0, that means no data at all has been sent. So > Is my code is good since when I intercept this exception I send all my > buffer again. There is no way that the printer receive two times same > bytes ? More technically, the function call returns and reports that 0 characters was written in this call. when 0 characters are written, it will check how many times 0 characters was written. If it has tried LESS than 20 times(errorCount), it will sleep() and try to write again. After 20 times, it wont sleep, but throw you the exception. Now suppose you are writing a 120 character line. you off-lined/paused your printer. The OS has room for 80 more characters in it's printer buffer. The WriteFile() will have a char count of 120, but on return the countWritten = 80. You still have 40 more characters to print. Since countWritten != 0, the counters: bytes += countWritten; count -= countWritten; get updated, and the Writefile now has a count of 40 characters. Since the printer is off-line, the countwritten is 0. And so the loop continues, till 40 seconds is up. As to why it is this way, i dont know ( not a windoz maven ); Also the sleep(20) in the loop is not so intuitive to suggest 2 seconds of sleep. I would have guessed 20seconds, or 20milliseconds. But go figure. BTW: Since your computer sends you error messages in French, does it curse in English? :)))) From yvespielusenet at free.fr Thu Jun 7 02:27:44 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Thu, 07 Jun 2007 10:27:44 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666E210.30507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> Message-ID: <1181204864.3501.10.camel@localhost.localdomain> Maybe in my case I should re-compile rxtx and change the code. Instead of send an exception I should display a dialog box to ask if it's printer problem or if it should trie to send bytes. Something like : while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } if(displayDialogBox("Try again to send datas ??")){ errorCount = 0; } else{ throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } } Le mercredi 06 juin 2007 ? 12:34 -0400, Uncle George a ?crit : > yves pielusenet wrote: > > Thank you for your explanation :) > > This timeout comes when no data has been send to the printer after > > 40seconds if I well understand. But why there is such a timeout ? If I > > setthe printer offline while it's printing I mustn't have an exception. > > I don't understand why the "printer should solv all problems like buffer > > full" in 40 seconds. If I pause the printer the buffer will not be > > emptied, isn't it ? > > > > I not very familiar with C/C++, but it seem that the exception is thrown > > only when countWritten == 0, that means no data at all has been sent. So > > Is my code is good since when I intercept this exception I send all my > > buffer again. There is no way that the printer receive two times same > > bytes ? > More technically, the function call returns and reports that 0 > characters was written in this call. > when 0 characters are written, it will check how many times 0 characters > was written. If it has tried LESS than 20 times(errorCount), it will > sleep() and try to write again. > After 20 times, it wont sleep, but throw you the exception. > > Now suppose you are writing a 120 character line. you off-lined/paused > your printer. The OS has room for 80 more characters in it's printer > buffer. The WriteFile() will have a char count of 120, but on return the > countWritten = 80. You still have 40 more characters to print. > Since countWritten != 0, the counters: > bytes += countWritten; > count -= countWritten; > get updated, and the Writefile now has a count of 40 characters. Since > the printer is off-line, the countwritten is 0. And so the loop > continues, till 40 seconds is up. > > As to why it is this way, i dont know ( not a windoz maven ); > Also the sleep(20) in the loop is not so intuitive to suggest 2 seconds > of sleep. I would have guessed 20seconds, or 20milliseconds. But go figure. > > BTW: Since your computer sends you error messages in French, does it > curse in English? :)))) > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 06:11:43 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 08:11:43 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181204864.3501.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> Message-ID: <4667F5FF.8070903@gatworks.com> your suggestion appears good. I dont know what displayDialogBox exactly will do, so all I can say it that it looks good. But I'd like to wait 10min before first dialog box And a 5 min wait for every dialog box there after. And since these are custom solution/choices, maybe a more exact explanation of what the issue is. if(errorCount++ < 300){ // wait 10min ( 10min * 60sec / 2 ) Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } if(displayDialogBox("Printer has Paused. Retry sending data?")){ errorCount = 150; // Wait for 5 min thereafter continue; } > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } yves pielusenet wrote: > Maybe in my case I should re-compile rxtx and change the code. Instead > of send an exception I should display a dialog box to ask if it's > printer problem or if it should trie to send bytes. Something like : > > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > > if(displayDialogBox("Try again to send datas ??")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > } > From yvespielusenet at free.fr Thu Jun 7 07:17:21 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Thu, 07 Jun 2007 15:17:21 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4667F5FF.8070903@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <4667F5FF.8070903@gatworks.com> Message-ID: <1181222241.3501.20.camel@localhost.localdomain> thank you :) 'displayDialogBox()' I think doesn't exist. It was just for the example :) But I think It should not be so complicated to display a dialog box under windows with YES/NO buttons. When yes is clicked it return 0 other it returns 1. Le jeudi 07 juin 2007 ? 08:11 -0400, Uncle George a ?crit : > your suggestion appears good. I dont know what displayDialogBox exactly > will do, so all I can say it that it looks good. > > But I'd like to wait 10min before first dialog box And a 5 min wait for > every dialog box there after. And since these are custom > solution/choices, maybe a more exact explanation of what the issue is. > > if(errorCount++ < 300){ // wait 10min ( 10min * 60sec / 2 ) > Sleep( 20 ); /* make a small pause to execute all other requests > in all other threads */ > continue; > } > > if(displayDialogBox("Printer has Paused. Retry sending data?")){ > errorCount = 150; // Wait for 5 min thereafter > continue; > } > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > > yves pielusenet wrote: > > Maybe in my case I should re-compile rxtx and change the code. Instead > > of send an exception I should display a dialog box to ask if it's > > printer problem or if it should trie to send bytes. Something like : > > > > while( count > 0 ){ > > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > > /* > > this are 20 * 2 seconds, in this time a printer (or other parallel device) > > should solv all problems like buffer full, etc > > */ > > if(errorCount++ < 20){ > > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > > continue; > > } > > > > if(displayDialogBox("Try again to send datas ??")){ > > errorCount = 0; > > } > > else{ > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > } > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 07:41:43 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 09:41:43 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181222241.3501.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <4667F5FF.8070903@gatworks.com> <1181222241.3501.20.camel@localhost.localdomain> Message-ID: <46680B17.8050109@gatworks.com> yves pielusenet wrote: > thank you :) > 'displayDialogBox()' I think doesn't exist. It was just for the > example :) too bad. Good luck. From rtrout at webbresearch.com Thu Jun 7 11:23:04 2007 From: rtrout at webbresearch.com (Robert Trout) Date: Thu, 07 Jun 2007 13:23:04 -0400 Subject: [Rxtx] Disconnected PortServer TS causes Java to hang Message-ID: <1181236984.14186.33.camel@sisyphus.DinkumSoftware.com> I'm running Linux with sun's Java 1.4.2, Java comm API 2.0, RXTX 2.0-7pre1, and the RealPort digi driver. "/dev/ttyrp00" is a RealPort device. My Java application never returns from a ComPortIdentifier.getPortIdentifier("/dev/ttyrp00") call while the Digi PortServer TS 4 is disconnected from the network. If I later re-connect the PortServer, the call returns about 30 seconds later (it's like a serial port read or write is blocking until the PortServer is re- connected). With the PortServer disconnected, minicom immediately responds with "cannot open /dev/ttyrp00: No such file or directory". I would like my Java application to behave similarly. That is, respond with an error condition instead of hanging when the PortServer is not connected. Since minicom and Java behave differently, I think this "hanging" behavior may be due to RXTX or Java? Has anyone had a similar issue? Solutions? Suggestions? Thanks, Robert From vicnevicne at gmail.com Thu Jun 7 12:16:02 2007 From: vicnevicne at gmail.com (Vicne) Date: Thu, 07 Jun 2007 20:16:02 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181204864.3501.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> Message-ID: <46684B62.7080802@gmail.com> yves pielusenet wrote: > Maybe in my case I should re-compile rxtx and change the code. Instead > of send an exception I should display a dialog box to ask if it's > printer problem or if it should trie to send bytes. Something like : > > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > > if(displayDialogBox("Try again to send datas ??")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > } > Sorry to step in without a specific solution to your problem, but I wanted to share my feeling regarding this proposal. AFAIK, it's generally considered bad practice to pop-up a prompt from a library. The main reason is that in general use, you can't guarantee that someone is actually present behind the console. Imagine a print server in a machine room, connected to a park of printers. In that case, when one printer fails, the logical behaviour would be to use an other one. If you change RxTx the way you propose, the printer queue will simply be stuck with a useless "Try again to send data ?" prompt until an administrator opens a remote connection to the print server's console and clicks "no". Second, it would create a dependency upon the existence of a graphical console (if you go the graphical "dialogBox" way). On many applications (typically server or embedded ones), the JVM is "headless" and if you try to pop-up a dialog, your app would throw an exception (at best) or just wouldn't display the prompt anywhere... Going the "text console" way is not more reliable, because on graphical environments, the text console is hidden unless explicitly requested. My advice would be to think again and find another solution. Ideas are : - make the number of retries a parameter so that you can tune it to what you think is reasonable - throw a more specific exception when the number of retries has been reached, so that a specific prompt can be shown at a higher level Anyway, if you feel that the prompt is the way to go in your case, I would at least make that prompt conditional. The least intrusive way would probably be using a system property, like if("true".equals(System.getProperty("org.rxtx.usePrompt")) && displayDialogBox("Retry sending data ?")){ errorCount = 0; } else{ throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } By default, the behaviour would remain as it is now, but you could force the prompts by defining the property at VM launch if desired. (for example : java.exe -Dorg.rxtx.usePrompt=true myApp) Also, you seemed to say you wanted the printer to start again exactly where is stopped. It would indeed be the best way when the printer is put offline for a few seconds. On the other hand, if the printer is turned off (or the printer runs out of paper, or someone steps on the mains cable), then the only way to go back to a "stable" situation would be by printing the item (page, label, etc.) again from scratch... Just my two cents. Vicne PS : By the way, the dialog box thing is very platform dependant on the C-side, and I think the simplest way would probably be to bridge it to a Java call where you can implement it like you proposed : public boolean displayDialogBox(prompt) { return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); } From netbeans at gatworks.com Thu Jun 7 14:08:24 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 16:08:24 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46684B62.7080802@gmail.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> Message-ID: <466865B8.4060004@gatworks.com> My feeling is that the code that was suggested was for his environs ( his shop ). The issue here is that after a 40+ second wait, an exception will be thrown. But you really dont have a way of 'cancelling' all the WriteFiles() that have already occured before the exception so that your writeArray and the Commapi can backtrack to a position in which they are in sync. The main ( really mine ) concern is not to lose data, or replicate data. After 40seconds, 300 seconds, 55min, no matter how long, data should not be lost or duplicated. But as soon as the exception is thrown, that possibility exists. Maybe an event should be thrown instead? Vicne wrote: > yves pielusenet wrote: >> Maybe in my case I should re-compile rxtx and change the code. Instead >> of send an exception I should display a dialog box to ask if it's >> printer problem or if it should trie to send bytes. Something like : >> >> while( count > 0 ){ >> if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ >> /* >> this are 20 * 2 seconds, in this time a printer (or other parallel device) >> should solv all problems like buffer full, etc >> */ >> if(errorCount++ < 20){ >> Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ >> continue; >> } >> >> if(displayDialogBox("Try again to send datas ??")){ >> errorCount = 0; >> } >> else{ >> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >> break; >> } >> } >> > > Sorry to step in without a specific solution to your problem, but I > wanted to share my feeling regarding this proposal. AFAIK, it's > generally considered bad practice to pop-up a prompt from a library. > The main reason is that in general use, you can't guarantee that > someone is actually present behind the console. Imagine a print server > in a machine room, connected to a park of printers. In that case, when > one printer fails, the logical behaviour would be to use an other one. > If you change RxTx the way you propose, the printer queue will simply be > stuck with a useless "Try again to send data ?" prompt until an > administrator opens a remote connection to the print server's console > and clicks "no". > Second, it would create a dependency upon the existence of a > graphical console (if you go the graphical "dialogBox" way). On many > applications (typically server or embedded ones), the JVM is "headless" > and if you try to pop-up a dialog, your app would throw an exception (at > best) or just wouldn't display the prompt anywhere... Going the "text > console" way is not more reliable, because on graphical environments, > the text console is hidden unless explicitly requested. > > My advice would be to think again and find another solution. Ideas are : > - make the number of retries a parameter so that you can tune it to what > you think is reasonable > - throw a more specific exception when the number of retries has been > reached, so that a specific prompt can be shown at a higher level > > Anyway, if you feel that the prompt is the way to go in your case, I > would at least make that prompt conditional. The least intrusive way > would probably be using a system property, like > > if("true".equals(System.getProperty("org.rxtx.usePrompt")) > && displayDialogBox("Retry sending data ?")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > > > By default, the behaviour would remain as it is now, but you could > force the prompts by defining the property at VM launch if desired. (for > example : java.exe -Dorg.rxtx.usePrompt=true myApp) > > > Also, you seemed to say you wanted the printer to start again > exactly where is stopped. It would indeed be the best way when the > printer is put offline for a few seconds. On the other hand, if the > printer is turned off (or the printer runs out of paper, or someone > steps on the mains cable), then the only way to go back to a "stable" > situation would be by printing the item (page, label, etc.) again from > scratch... > > > Just my two cents. > > > Vicne > > PS : By the way, the dialog box thing is very platform dependant on the > C-side, and I think the simplest way would probably be to bridge it to a > Java call where you can implement it like you proposed : > > public boolean displayDialogBox(prompt) { > return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", > JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); > } > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Thu Jun 7 17:48:11 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 Jun 2007 17:48:11 -0600 (MDT) Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <466865B8.4060004@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> Message-ID: An event is possible. I'm amazed this is the largest problem encountered while using the parallel code. How would the write ever exit if we throw events? Isn't this going to lead to hung applications? On Thu, 7 Jun 2007, Uncle George wrote: > My feeling is that the code that was suggested was for his environs ( > his shop ). > > The issue here is that after a 40+ second wait, an exception will be > thrown. But you really dont have a way of 'cancelling' all the > WriteFiles() that have already occured before the exception so that your > writeArray and the Commapi can backtrack to a position in which they are > in sync. > > The main ( really mine ) concern is not to lose data, or replicate data. > After 40seconds, 300 seconds, 55min, no matter how long, data should > not be lost or duplicated. But as soon as the exception is thrown, that > possibility exists. > > Maybe an event should be thrown instead? > > Vicne wrote: >> yves pielusenet wrote: >>> Maybe in my case I should re-compile rxtx and change the code. Instead >>> of send an exception I should display a dialog box to ask if it's >>> printer problem or if it should trie to send bytes. Something like : >>> >>> while( count > 0 ){ >>> if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ >>> /* >>> this are 20 * 2 seconds, in this time a printer (or other parallel device) >>> should solv all problems like buffer full, etc >>> */ >>> if(errorCount++ < 20){ >>> Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ >>> continue; >>> } >>> >>> if(displayDialogBox("Try again to send datas ??")){ >>> errorCount = 0; >>> } >>> else{ >>> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >>> break; >>> } >>> } >>> >> >> Sorry to step in without a specific solution to your problem, but I >> wanted to share my feeling regarding this proposal. AFAIK, it's >> generally considered bad practice to pop-up a prompt from a library. >> The main reason is that in general use, you can't guarantee that >> someone is actually present behind the console. Imagine a print server >> in a machine room, connected to a park of printers. In that case, when >> one printer fails, the logical behaviour would be to use an other one. >> If you change RxTx the way you propose, the printer queue will simply be >> stuck with a useless "Try again to send data ?" prompt until an >> administrator opens a remote connection to the print server's console >> and clicks "no". >> Second, it would create a dependency upon the existence of a >> graphical console (if you go the graphical "dialogBox" way). On many >> applications (typically server or embedded ones), the JVM is "headless" >> and if you try to pop-up a dialog, your app would throw an exception (at >> best) or just wouldn't display the prompt anywhere... Going the "text >> console" way is not more reliable, because on graphical environments, >> the text console is hidden unless explicitly requested. >> >> My advice would be to think again and find another solution. Ideas are : >> - make the number of retries a parameter so that you can tune it to what >> you think is reasonable >> - throw a more specific exception when the number of retries has been >> reached, so that a specific prompt can be shown at a higher level >> >> Anyway, if you feel that the prompt is the way to go in your case, I >> would at least make that prompt conditional. The least intrusive way >> would probably be using a system property, like >> >> if("true".equals(System.getProperty("org.rxtx.usePrompt")) >> && displayDialogBox("Retry sending data ?")){ >> errorCount = 0; >> } >> else{ >> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >> break; >> } >> >> >> By default, the behaviour would remain as it is now, but you could >> force the prompts by defining the property at VM launch if desired. (for >> example : java.exe -Dorg.rxtx.usePrompt=true myApp) >> >> >> Also, you seemed to say you wanted the printer to start again >> exactly where is stopped. It would indeed be the best way when the >> printer is put offline for a few seconds. On the other hand, if the >> printer is turned off (or the printer runs out of paper, or someone >> steps on the mains cable), then the only way to go back to a "stable" >> situation would be by printing the item (page, label, etc.) again from >> scratch... >> >> >> Just my two cents. >> >> >> Vicne >> >> PS : By the way, the dialog box thing is very platform dependant on the >> C-side, and I think the simplest way would probably be to bridge it to a >> Java call where you can implement it like you proposed : >> >> public boolean displayDialogBox(prompt) { >> return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", >> JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); >> } >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 19:18:51 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 21:18:51 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> Message-ID: <4668AE7B.3060409@gatworks.com> The UNIX version of writeArray is not too great either. It is possible that the write will only process some of the bytes. #else if( write( fd, bytes, count ) < 0 ) throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); #endif -------------------------------- Maybe it might be better to have the native function inform the caller of the # of characters written, then the commapi/output-buffer can be modified to reflect the #of chars written. If an exception is to be thrown, for too many loops of chars written == 0, then exception wont affect the state of the output buffer. Then a ParallelPort.restart() can be called to resume printing whats in the buffer. Trent Jarvi wrote: > An event is possible. I'm amazed this is the largest problem encountered > while using the parallel code. > > How would the write ever exit if we throw events? Isn't this going to > lead to hung applications? Sure. If you dont time out, then there is nothing that will force an EXIT from the write(). Issue is what has the OS done with the write. > > On Thu, 7 Jun 2007, Uncle George wrote: > >> My feeling is that the code that was suggested was for his environs ( >> his shop ). From yvespielusenet at free.fr Fri Jun 8 01:09:01 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Fri, 08 Jun 2007 09:09:01 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4668AE7B.3060409@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> Message-ID: <1181286541.3674.10.camel@localhost.localdomain> It is not possible that the rxtx java method write(byte[], int offset, int length) return anint which contains the number of byte really send to the printer instead of an exception ? So this is the programm which will see if all bytes have been sent. If not it can retry to send the unsended bytes. -------------------------------------------------------- int sended = 0; while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ sended += countWritten; /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } return sended; /*throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break;*/ } ... ... return countWritten; ------------------------------------------------ Le jeudi 07 juin 2007 ? 21:18 -0400, Uncle George a ?crit : > The UNIX version of writeArray is not too great either. It is possible > that the write will only process some of the bytes. > > #else > if( write( fd, bytes, count ) < 0 ) > throw_java_exception_system_msg( env, IO_EXCEPTION, > "writeArray" ); > #endif > -------------------------------- > > Maybe it might be better to have the native function inform the caller > of the # of characters written, then the commapi/output-buffer can be > modified to reflect the #of chars written. If an exception is to be > thrown, for too many loops of chars written == 0, then exception wont > affect the state of the output buffer. Then a ParallelPort.restart() can > be called to resume printing whats in the buffer. > > > Trent Jarvi wrote: > > An event is possible. I'm amazed this is the largest problem encountered > > while using the parallel code. > > > > How would the write ever exit if we throw events? Isn't this going to > > lead to hung applications? > Sure. If you dont time out, then there is nothing that will force an > EXIT from the write(). Issue is what has the OS done with the write. > > > > On Thu, 7 Jun 2007, Uncle George wrote: > > > >> My feeling is that the code that was suggested was for his environs ( > >> his shop ). > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Fri Jun 8 03:45:00 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 11:45:00 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181286541.3674.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> Message-ID: <20070608094500.GC21069@elberon.bln.de.ingenico.com> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > It is not possible that the rxtx java method write(byte[], int offset, > int length) return anint which contains the number of byte really send > to the printer instead of an exception ? > So this is the programm which will see if all bytes have been sent. If > not it can retry to send the unsended bytes. I think write() is void because in Java people love to do this since OutputStream :-) Of course on such interfaces you cannot implement something nice. If you would have a int write, you would not implement the interface and no applications expecting this interface would link/work/compile. oki, Steffen P.S.: (OT) If you propose not to implement the Java interfaces (especially not on JNI level), maybe optionally offering a wrapper that removes e.g. the write return value and so on to downgrade the powerful classic old POSIX read/write style to the modern limited Java style, then I agree :-) Same for read. Instead of things like "int avialable()" it is more powerful to have an approach as select(2) offers (to guarante the caller that read/write will not block [nothing else make sense anyway IMHO] but may read/write less bytes then requested). The caller gets full control and the higher level protocols can care about timeouts, invoking read in some loops and/or implement retransmission. On top of such an implementation, where everything is controlled, defined, guaranteed and reliable, someone could use an InputStream or OutputStream style interface. Or even better: don't use them at all :) just BTW :-) St. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From yvespielusenet at free.fr Fri Jun 8 05:52:45 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Fri, 08 Jun 2007 13:52:45 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <20070608094500.GC21069@elberon.bln.de.ingenico.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> Message-ID: <1181303565.11203.3.camel@localhost.localdomain> So maybe a better way should be to create a new Exception class which has a method "int getWrittenByte()". So the Exception should be use to send again bytes which are not printed yet. yves Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : > * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > > It is not possible that the rxtx java method write(byte[], int offset, > > int length) return anint which contains the number of byte really send > > to the printer instead of an exception ? > > So this is the programm which will see if all bytes have been sent. If > > not it can retry to send the unsended bytes. > > I think write() is void because in Java people love to do this > since OutputStream :-) Of course on such interfaces you cannot > implement something nice. If you would have a int write, you > would not implement the interface and no applications expecting > this interface would link/work/compile. > > oki, > > Steffen > > P.S.: (OT) > If you propose not to implement the Java interfaces (especially > not on JNI level), maybe optionally offering a wrapper that > removes e.g. the write return value and so on to downgrade the > powerful classic old POSIX read/write style to the modern limited > Java style, then I agree :-) Same for read. Instead of things > like "int avialable()" it is more powerful to have an approach as > select(2) offers (to guarante the caller that read/write will not > block [nothing else make sense anyway IMHO] but may read/write > less bytes then requested). The caller gets full control and the > higher level protocols can care about timeouts, invoking read in > some loops and/or implement retransmission. On top of such an > implementation, where everything is controlled, defined, > guaranteed and reliable, someone could use an InputStream or > OutputStream style interface. Or even better: don't use them at > all :) just BTW :-) > St. > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > 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. > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > 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. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Fri Jun 8 06:46:21 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 08:46:21 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181303565.11203.3.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> Message-ID: <46694F9D.5080501@gatworks.com> It seems that with outputstream.write(b[]), you become terribly uncoordinated as soon as an exception is thrown. Docs do not say what happens to the data. Yet from a practicable point of view, one would like to know if the write was accepted in-full, or rejected before any writes. There are no in betweens, as partial writes are not reportable. So for an outputstream.write(), in order for it to return, the full write request has to be taken, and stored in an internal output buffer. If there is no room, the write() is suspended, till there is room. Or throw's an IOException( "no room in buffer") ; As the select() loop for write reports buffer room avail, then more of the internal buffer is sent to the printer. yves pielusenet wrote: > So maybe a better way should be to create a new Exception class which > has a method "int getWrittenByte()". So the Exception should be use to > send again bytes which are not printed yet. > > yves > > Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : >> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: >>> It is not possible that the rxtx java method write(byte[], int offset, >>> int length) return anint which contains the number of byte really send >>> to the printer instead of an exception ? >>> So this is the programm which will see if all bytes have been sent. If >>> not it can retry to send the unsended bytes. >> I think write() is void because in Java people love to do this >> since OutputStream :-) Of course on such interfaces you cannot >> implement something nice. If you would have a int write, you >> would not implement the interface and no applications expecting >> this interface would link/work/compile. >> >> oki, >> >> Steffen >> >> P.S.: (OT) >> If you propose not to implement the Java interfaces (especially >> not on JNI level), maybe optionally offering a wrapper that >> removes e.g. the write return value and so on to downgrade the >> powerful classic old POSIX read/write style to the modern limited >> Java style, then I agree :-) Same for read. Instead of things >> like "int avialable()" it is more powerful to have an approach as >> select(2) offers (to guarante the caller that read/write will not >> block [nothing else make sense anyway IMHO] but may read/write >> less bytes then requested). The caller gets full control and the >> higher level protocols can care about timeouts, invoking read in >> some loops and/or implement retransmission. On top of such an >> implementation, where everything is controlled, defined, >> guaranteed and reliable, someone could use an InputStream or >> OutputStream style interface. Or even better: don't use them at >> all :) just BTW :-) >> St. >> >> About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. >> 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. >> >> About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. >> 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. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From Steffen.DETTMER at ingenico.com Fri Jun 8 08:12:18 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 16:12:18 +0200 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <46694F9D.5080501@gatworks.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: <20070608141218.GE21069@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 08:46 -0400: > It seems that with outputstream.write(b[]), you become terribly > uncoordinated as soon as an exception is thrown. Docs do not say what > happens to the data. (yes, so avoiding it seems to be good :)) > Yet from a practicable point of view, one would like to know if the > write was accepted in-full, or rejected before any writes. There are no > in betweens, as partial writes are not reportable. (which is an artificial API limitation. I never understood how this happend when they invented JDK because the well-known BSD socket API and thus [probably] WinSock does this correct, but anyway) > So for an outputstream.write(), in order for it to return, the full > write request has to be taken, and stored in an internal output buffer. > If there is no room, the write() is suspended, till there is room. Or > throw's an IOException( "no room in buffer") ; As the select() loop for > write reports buffer room avail, then more of the internal buffer is > sent to the printer. yes, might be good in case of a printer. May be horrible in case of PPP/TCP or some other transmission control protocol which may e.g. repeat data or even omit parts of it (e.g. internet realtime radio station broadcasting)... So I think the idea of "int write" (e.g. BSD sockets, linux files and so on) still is the best. A clean API / implementation should guarantee and allow implementations (users) to rely on that; assumptions and automatic background-sending and so on may look pragmatic and may even work on the first look, but may fail in other situations. BTW, if e.g. BSD socket API is known, why not simply copy it (until something better is invented :)) instead of fiddling around with JDK APIs? anyway, have a nice weekend everyone :-) oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Fri Jun 8 08:55:56 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 10:55:56 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070608141218.GE21069@elberon.bln.de.ingenico.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> Message-ID: <46696DFC.7000801@gatworks.com> >> write reports buffer room avail, then more of the internal buffer is >> sent to the printer. > > yes, might be good in case of a printer. May be horrible in case > of PPP/TCP or some other transmission control protocol which > may e.g. repeat data or even omit parts of it (e.g. internet > realtime radio station broadcasting)... So I think the idea of > "int write" (e.g. BSD sockets, linux files and so on) still is > the best. A clean API / implementation should guarantee and allow > implementations (users) to rely on that; assumptions and > automatic background-sending and so on may look pragmatic and may > even work on the first look, but may fail in other situations. > BTW, if e.g. BSD socket API is known, why not simply copy it > (until something better is invented :)) instead of fiddling > around with JDK APIs? But we were talking about the Parallel Port, and the transmission of data over the commapi/parallel-port schema. There isn't much in bi-directional software communication. Its a simple write one byte at a time interface. I'm not looking to change the comm-api. I'm just looking to alter the interaction between the Native ParallelPort functions, and the java ParallelPort functions that call them. This might be more readily doable than to get a committee to re-specify java-API specs. BTW: Whats is off-topic? ( help: not looking for def of off-topic ) From j.kenneth.gentle at acm.org Fri Jun 8 08:58:59 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Fri, 08 Jun 2007 10:58:59 -0400 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <20070608141218.GE21069@elberon.bln.de.ingenico.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> Message-ID: <200706081459.l58Ex5rA019991@qbang.org> Perhaps it is a bit late to jump in on this one, but here goes anyway. If the solutions all seem to "break" the contract with "java.io.outputstream", then, as noted, that may not be the appropriate contract. At the risk of being heretical, JDK1.4 introduced the "nio" package to address some of the compatibility issues with C apis mentioned in previous posts. The interface "java.nio.channels.WriteableByteChannel" defines the following single method: int write(ByteBuffer source); int, strangely enough, is the actual number of bytes written. So, if RXTX as written, against the JavaCOMM api and OutputStream, doesn't do what we want, how about writing a different set of bindings using the java.nio classes and as much of the underlying native code as possible. Note that just because the java.nio.channels.WriteableByteChannel sends back a result, OutputStream.write doesn't have to - and they could both call the same underlying native code. My 2 cents - maybe not worth even that... Ken From netbeans at gatworks.com Fri Jun 8 10:37:28 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 12:37:28 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <200706081459.l58Ex5rA019991@qbang.org> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> Message-ID: <466985C8.8000505@gatworks.com> Ken Gentle wrote: > Perhaps it is a bit late to jump in on this one, but here goes anyway. Common in, the waters fine. > > If the solutions all seem to "break" the contract with > "java.io.outputstream", then, as noted, that may not be the > appropriate contract. > How would the contract be broken? The machinery underneath is handling the contract. From j.kenneth.gentle at acm.org Fri Jun 8 10:48:01 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Fri, 08 Jun 2007 12:48:01 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466985C8.8000505@gatworks.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> Message-ID: <200706081648.l58Gm7YA022904@qbang.org> At 12:37 2007-06-08, you wrote: >Ken Gentle wrote: > > > > If the solutions all seem to "break" the contract with > > "java.io.outputstream", then, as noted, that may not be the > > appropriate contract. > > >How would the contract be broken? The machinery underneath is handling >the contract. It seems that a lot of the discussion has been about not only the timeout and being able to adjust it in the "machinery layer", but also about knowing in the Java layer, in the event of a timeout or exception, how many characters have been written to the device. An OutputStream won't ever do this with out an extension and including a return value "breaks" the contract, right? So, go with a Java IO api that *does* return the number of bytes written, out of the NIO package. I know it doesn't allow for a strict implementation of the JavaCOMM API - however, using NIO classes in place of the IO classes isn't that big a break and would allow those applications that need such information a way to get it. Maybe I'm misunderstanding the problem... Ken From netbeans at gatworks.com Fri Jun 8 11:24:14 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 13:24:14 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <200706081648.l58Gm7YA022904@qbang.org> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> Message-ID: <466990BE.7040100@gatworks.com> Ken Gentle wrote: An > OutputStream won't ever do this with out an extension and including a > return value "breaks" the contract, right? > i was not thinking of change the API to OutputSream. Are there specs for how output stream should work internally? for instance: String data = "Hello this is a line of data"; Outputstream.write( data.getbytes() ); ParallelPort.suspend(); int free = ParallelPort.getoutputbufferfree(); There is a symbiotic relationship between outputstream and the functionality of ParallelPort. From Steffen.DETTMER at ingenico.com Fri Jun 8 11:15:39 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 19:15:39 +0200 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <200706081459.l58Ex5rA019991@qbang.org> References: <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> Message-ID: <20070608171539.GK21069@elberon.bln.de.ingenico.com> * Ken Gentle wrote on Fri, Jun 08, 2007 at 10:58 -0400: > If the solutions all seem to "break" the contract with > "java.io.outputstream", then, as noted, that may not be the > appropriate contract. > > At the risk of being heretical, JDK1.4 introduced the "nio" package > to address some of the compatibility issues with C apis mentioned in > previous posts. The interface > "java.nio.channels.WriteableByteChannel" defines the following single method: > > int write(ByteBuffer source); > > int, strangely enough, is the actual number of bytes written. Yes, AFAIK one of the motivations for the NIO interface was, that the JDK-1.3 APIs (InputStream, e.g.) were not powerfull enough, especially for multi-connection-TCP servers or so. I don't know much about it but I've heard of a project where NIO usage was removed because of stability issues in multi-threaded environments and performance limitations under some circumstances. IIRC the "nio.ByteBuffer" is something very special (namely something you cannot implement in Java, it is "magic" or part of the language itself). Not sure if this is such a great idea (but for performance in the end sometimes heavy prices must be paid) :) > So, if RXTX as written, against the JavaCOMM api and OutputStream, > doesn't do what we want, how about writing a different set of > bindings using the java.nio classes and as much of the underlying > native code as possible. Yes, this would be an idea: use a full-featured interface on JNI, and, if wanted, deliver some wrappers converting this to a less-featured Java-compliant interface. However, powerful things as e.g. "select" are difficult to "emulate" if you are e.g. on some (older?) windows. But if you expose the full-featured APIs, you need to emulate them full-featured, theoretically. In the end it depends what you do on the serial line. If you just want to talk to a modem, then you may not need precise timeouts. But if you need to implement complexer protocols which define response times and timeouts, you may quickly get into difficulties. For instance, AFAIK, rxtx 1.7.2 (?) for windows is very messy with timeouts (there is a maximum, higher values are truncated; resolution is 100ms only; the function may take up to twice the timeout because internally it may be called twice). Probably for most people this is OK, but probably not for all. But having precise timeouts should be OK for all :-) Well, in the end it is nice to wish but somewhat hard to implement (many platforms, connections, USB, BlueTooth, whatever). oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Steffen.DETTMER at ingenico.com Fri Jun 8 11:04:22 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 19:04:22 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <46696DFC.7000801@gatworks.com> References: <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <46696DFC.7000801@gatworks.com> Message-ID: <20070608170422.GJ21069@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 10:55 -0400: > > BTW, if e.g. BSD socket API is known, why not simply copy it > > (until something better is invented :)) instead of fiddling > > around with JDK APIs? > > But we were talking about the Parallel Port, and the > transmission of data over the commapi/parallel-port schema. > There isn't much in bi-directional software communication. Its > a simple write one byte at a time interface. First, there are things like PLIP (http://en.wikipedia.org/wiki/Plip) - well, probably not widely used, sure ;) Second, I think if there is a good simple API known to support all that (with known "best practices") or so and there is no forcing need to invent a new one, why not simply using it? > I'm not looking to change the comm-api. I'm just looking to > alter the interaction between the Native ParallelPort > functions, and the java ParallelPort functions that call them. Ahh, yes. I think this is what I tried to ask. Having an usable JNI interface and on top (in pure java) some wrapper to InputStream or whatever could be done (e.g. by ignoring the return value of write or throwing if != length). Developers could then use the full-featured (non-JAVA-standard) API or select among various wrappers (as InputStream). > This might be more readily doable than to get a committee to > re-specify java-API specs. Yes, of course. I'm afraid that the Java APIs change regularily, but still yet with limited success it seems, so maybe they get it in one of the next iterations; who knows, maybe Java-9 has a BSD-like socket API :) SCNR. > BTW: Whats is off-topic? ( help: not looking for def of > off-topic ) I think I started some "re-specify java-API specs" which was OT probably. oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From lists at iDIAcomputing.com Fri Jun 8 18:48:54 2007 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Fri, 08 Jun 2007 20:48:54 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46684B62.7080802@gmail.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> Message-ID: <4669F8F6.3040101@iDIAcomputing.com> Vicne wrote: > Sorry to step in without a specific solution to your problem, but I > wanted to share my feeling regarding this proposal. AFAIK, it's > generally considered bad practice to pop-up a prompt from a library. ... > > My advice would be to think again and find another solution. Ideas are : > - make the number of retries a parameter so that you can tune it to what > you think is reasonable > - throw a more specific exception when the number of retries has been > reached, so that a specific prompt can be shown at a higher level You could also allow the client code to register a callback class which returns a boolean indicating whether to retry or cancel. This callback class could pop up a dialog, if appropriate, or follow some preset policy, or.... - George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From joachim at buechse.ch Sat Jun 9 09:43:16 2007 From: joachim at buechse.ch (Joachim Buechse) Date: Sat, 9 Jun 2007 17:43:16 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46694F9D.5080501@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: You should not forget, that in the case of an exception it may not even be known what happened to the data. You have a kernel buffer, outgoing chip buffer, incoming chip buffer, etc. So of course, it would be nice to know up to which point data was correctly processed, but this feedback does not exist on the hardware or protocol level and hence can in general not be magicly created on the software level... Regards, Joachim On 08.06.2007, at 14:46, Uncle George wrote: > It seems that with outputstream.write(b[]), you become terribly > uncoordinated as soon as an exception is thrown. Docs do not say what > happens to the data. > > Yet from a practicable point of view, one would like to know if the > write was accepted in-full, or rejected before any writes. There > are no > in betweens, as partial writes are not reportable. > > So for an outputstream.write(), in order for it to return, the full > write request has to be taken, and stored in an internal output > buffer. > If there is no room, the write() is suspended, till there is room. Or > throw's an IOException( "no room in buffer") ; As the select() loop > for > write reports buffer room avail, then more of the internal buffer is > sent to the printer. > > > > yves pielusenet wrote: >> So maybe a better way should be to create a new Exception class which >> has a method "int getWrittenByte()". So the Exception should be >> use to >> send again bytes which are not printed yet. >> >> yves >> >> Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : >>> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: >>>> It is not possible that the rxtx java method write(byte[], int >>>> offset, >>>> int length) return anint which contains the number of byte >>>> really send >>>> to the printer instead of an exception ? >>>> So this is the programm which will see if all bytes have been >>>> sent. If >>>> not it can retry to send the unsended bytes. >>> I think write() is void because in Java people love to do this >>> since OutputStream :-) Of course on such interfaces you cannot >>> implement something nice. If you would have a int write, you >>> would not implement the interface and no applications expecting >>> this interface would link/work/compile. >>> >>> oki, >>> >>> Steffen >>> >>> P.S.: (OT) >>> If you propose not to implement the Java interfaces (especially >>> not on JNI level), maybe optionally offering a wrapper that >>> removes e.g. the write return value and so on to downgrade the >>> powerful classic old POSIX read/write style to the modern limited >>> Java style, then I agree :-) Same for read. Instead of things >>> like "int avialable()" it is more powerful to have an approach as >>> select(2) offers (to guarante the caller that read/write will not >>> block [nothing else make sense anyway IMHO] but may read/write >>> less bytes then requested). The caller gets full control and the >>> higher level protocols can care about timeouts, invoking read in >>> some loops and/or implement retransmission. On top of such an >>> implementation, where everything is controlled, defined, >>> guaranteed and reliable, someone could use an InputStream or >>> OutputStream style interface. Or even better: don't use them at >>> all :) just BTW :-) >>> St. >>> >>> About Ingenico Throughout the world businesses rely on Ingenico >>> for secure and expedient electronic transaction acceptance. >>> Ingenico products leverage proven technology, established >>> standards and unparalleled ergonomics to provide optimal >>> reliability, versatility and usability. This comprehensive range >>> of products is complemented by a global array of services and >>> partnerships, enabling businesses in a number of vertical sectors >>> to accept transactions anywhere their business takes them. >>> 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. >>> >>> About Ingenico Throughout the world businesses rely on Ingenico >>> for secure and expedient electronic transaction acceptance. >>> Ingenico products leverage proven technology, established >>> standards and unparalleled ergonomics to provide optimal >>> reliability, versatility and usability. This comprehensive range >>> of products is complemented by a global array of services and >>> partnerships, enabling businesses in a number of vertical sectors >>> to accept transactions anywhere their business takes them. >>> 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. >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx 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 yvespielusenet at free.fr Mon Jun 11 03:15:12 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Mon, 11 Jun 2007 11:15:12 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: <1181553312.8335.14.camel@localhost.localdomain> So can someone tell a solution for my problem :( Must I say to the user to not put the printer off-line ? I can't since he has to do some pauses, verify print, paper conditioning etc... How do other people ? Before I use the parport librarry to read port status : http://www.geocities.com/Juanga69/parport/ (which doesn't work on windows XP) And I send data into the file LPT1 I use to have no problem when printer was disabled. thanks -- yves piel Le samedi 09 juin 2007 ? 17:43 +0200, Joachim Buechse a ?crit : > You should not forget, that in the case of an exception it may not > even be known what happened to the data. > > You have a kernel buffer, outgoing chip buffer, incoming chip buffer, > etc. So of course, it would be nice to know up to which point data > was correctly processed, but this feedback does not exist on the > hardware or protocol level and hence can in general not be magicly > created on the software level... > > Regards, > Joachim > > On 08.06.2007, at 14:46, Uncle George wrote: > > > It seems that with outputstream.write(b[]), you become terribly > > uncoordinated as soon as an exception is thrown. Docs do not say what > > happens to the data. > > > > Yet from a practicable point of view, one would like to know if the > > write was accepted in-full, or rejected before any writes. There > > are no > > in betweens, as partial writes are not reportable. > > > > So for an outputstream.write(), in order for it to return, the full > > write request has to be taken, and stored in an internal output > > buffer. > > If there is no room, the write() is suspended, till there is room. Or > > throw's an IOException( "no room in buffer") ; As the select() loop > > for > > write reports buffer room avail, then more of the internal buffer is > > sent to the printer. > > > > > > > > yves pielusenet wrote: > >> So maybe a better way should be to create a new Exception class which > >> has a method "int getWrittenByte()". So the Exception should be > >> use to > >> send again bytes which are not printed yet. > >> > >> yves > >> > >> Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : > >>> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > >>>> It is not possible that the rxtx java method write(byte[], int > >>>> offset, > >>>> int length) return anint which contains the number of byte > >>>> really send > >>>> to the printer instead of an exception ? > >>>> So this is the programm which will see if all bytes have been > >>>> sent. If > >>>> not it can retry to send the unsended bytes. > >>> I think write() is void because in Java people love to do this > >>> since OutputStream :-) Of course on such interfaces you cannot > >>> implement something nice. If you would have a int write, you > >>> would not implement the interface and no applications expecting > >>> this interface would link/work/compile. > >>> > >>> oki, > >>> > >>> Steffen > >>> > >>> P.S.: (OT) > >>> If you propose not to implement the Java interfaces (especially > >>> not on JNI level), maybe optionally offering a wrapper that > >>> removes e.g. the write return value and so on to downgrade the > >>> powerful classic old POSIX read/write style to the modern limited > >>> Java style, then I agree :-) Same for read. Instead of things > >>> like "int avialable()" it is more powerful to have an approach as > >>> select(2) offers (to guarante the caller that read/write will not > >>> block [nothing else make sense anyway IMHO] but may read/write > >>> less bytes then requested). The caller gets full control and the > >>> higher level protocols can care about timeouts, invoking read in > >>> some loops and/or implement retransmission. On top of such an > >>> implementation, where everything is controlled, defined, > >>> guaranteed and reliable, someone could use an InputStream or > >>> OutputStream style interface. Or even better: don't use them at > >>> all :) just BTW :-) > >>> St. > >>> > >>> About Ingenico Throughout the world businesses rely on Ingenico > >>> for secure and expedient electronic transaction acceptance. > >>> Ingenico products leverage proven technology, established > >>> standards and unparalleled ergonomics to provide optimal > >>> reliability, versatility and usability. This comprehensive range > >>> of products is complemented by a global array of services and > >>> partnerships, enabling businesses in a number of vertical sectors > >>> to accept transactions anywhere their business takes them. > >>> 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. > >>> > >>> About Ingenico Throughout the world businesses rely on Ingenico > >>> for secure and expedient electronic transaction acceptance. > >>> Ingenico products leverage proven technology, established > >>> standards and unparalleled ergonomics to provide optimal > >>> reliability, versatility and usability. This comprehensive range > >>> of products is complemented by a global array of services and > >>> partnerships, enabling businesses in a number of vertical sectors > >>> to accept transactions anywhere their business takes them. > >>> 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. > >>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx 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 > From Steffen.DETTMER at ingenico.com Mon Jun 11 03:56:18 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 11:56:18 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466990BE.7040100@gatworks.com> References: <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> Message-ID: <20070611095618.GA10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 13:24 -0400: > i was not thinking of change the API to OutputSream. Then I think either someone uses OutputStream (and has no reliable information about incomplete writes) or someone uses somethink else. > Are there specs for how output stream should work internally? > > for instance: > String data = "Hello this is a line of data"; > Outputstream.write( data.getbytes() ); > ParallelPort.suspend(); > int free = ParallelPort.getoutputbufferfree(); > > There is a symbiotic relationship between outputstream and the > functionality of ParallelPort. If you need OutputStream "plus something else", in short you're needing "something else". Personally I dislike the code above a lot. The stream "looks" like if it would be an OutputStream, but in fact it isn't. You need to call getoutputbufferfree later to check if write succeeded (but OutputStream promises that write succeedes synchronous, blocking, or throws an exception). So it is not an OutputStream. No application written for OutputStreams would work without change (because it won't know getoutputbufferfree at all). It is not abstracted from ParallelPort. I think this would be wrong. Then I think an alternative interface instead is better. Let's assume we had some "connection" (to distinguish between OutputStreams and Channels). Then why not working as on a file handle in POSIX: do { // ... select maybe using timer ... readyForWrite = ... if (readyForWrite) { int writtenBytes = connection.write(toWrite); toWrite.remove(0, writtenBytes); } while(readyForWrite && toWrite.length > 0); I think, having such a write isn't the big problem. I think, the difficult thing is around "select" - however this would look like. It should be OO, typesafe, performant, supporting multiple connections/channels/streams in various modes and should be orthogonal to other functionalities. Of course, this heavily depends on what the application is doing; for a simple situation (like reading a small, mandatory file from a local disk) this would be to uncomfortable (and offering unneeded features only). just BTW :) oki, Steffen -- // Modeline for VIM. Please don't remove. // (Help: autoindent, expandtab, shiftwidth=4, tabstop=4, textwidth=75) // vi: set ai et sw=4 ts=4 tw=75 ft=java: About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Mon Jun 11 05:38:33 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 07:38:33 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611095618.GA10821@elberon.bln.de.ingenico.com> References: <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> Message-ID: <466D3439.4020805@gatworks.com> Steffen DETTMER wrote: > (but OutputStream promises that write > succeedes synchronous, blocking, or throws an exception). Where is it so written? From Steffen.DETTMER at ingenico.com Mon Jun 11 06:36:50 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 14:36:50 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466D3439.4020805@gatworks.com> References: <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> <466D3439.4020805@gatworks.com> Message-ID: <20070611123650.GI10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Mon, Jun 11, 2007 at 07:38 -0400: > Steffen DETTMER wrote: > > > (but OutputStream promises that write > > succeedes synchronous, blocking, or throws an exception). > > Where is it so written? Now, as you ask, I think it is not written that clearly but follows from specification. mmm... Am I wrong? I understand the API doc in this way: * http://java.sun.com/j2se/1.4.2/docs/api/java/io/OutputStream.html#write(byte[]) > public void write(byte[] b) > throws IOException > > Writes b.length bytes from the specified byte array to this > output stream. The general contract for write(b) is that > it should have exactly the same effect as the call write(b, > 0, b.length). > > Parameters: > b - the data. > Throws: > IOException - if an I/O error occurs. > See Also: > write(byte[], int, int) and there is: > public void write(byte[] b, > int off, > int len) > throws IOException > > Writes len bytes from the specified byte array starting at > offset off to this output stream. The general contract for > write(b, off, len) is that some of the bytes in the array b > are written to the output stream in order; element b[off] > is the first byte written and b[off+len-1] is the last byte > written by this operation. > > The write method of OutputStream calls the write method of > one argument on each of the bytes to be written out. > Subclasses are encouraged to override this method and > provide a more efficient implementation. > > If b is null, a NullPointerException is thrown. > > If off is negative, or len is negative, or off+len is > greater than the length of the array b, then an > IndexOutOfBoundsException is thrown. > > Parameters: > b - the data. > off - the start offset in the data. > len - the number of bytes to write. > Throws: > IOException - if an I/O error occurs. In particular, an > IOException is thrown if the output stream is closed. In general, any specialisation (derived child class) must comform to this. So write in the end is specified (!) as "The write method ... calls the write method ... on each of the bytes to be written out". This is what must be implemented by ANY OutputStream. Of course, there is: "Subclasses are encouraged to override this method and provide a more efficient implementation." which IMHO does not contradict - the more efficient must behave in exactly the same way of course (just wasting less resources than a simple byte-by-byte write). So it does not matter here I think. The write that finally defines the behavior tells basically: > "Writes the specified byte to this output stream. The general > contract for write is that one byte is written to the output > stream. " > > Throws: > IOException - if an I/O error occurs. which IMHO is another way of saying "write writes the byte immediately and returns on success (only), otherwise an exception is thrown". Especially it cannot happen that zero bytes are written (i.e. the specified byte is NOT written) without an exception. So by this write must be synchronous and blocking, because otherwise it could not reliably know if an asynchronous operation will succeede or not (some getAsyncResult or so would be needed). Since write(byte[]) does this for each byte (or with a behavior beeing exactly the same as if it would do), I think this means that the write(byte[]) succeedes synchronous/blocking or throws an exception. Did I an error in reasoning or confused something or so? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From j.kenneth.gentle at acm.org Mon Jun 11 06:51:25 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 11 Jun 2007 08:51:25 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611123650.GI10821@elberon.bln.de.ingenico.com> References: <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> <466D3439.4020805@gatworks.com> <20070611123650.GI10821@elberon.bln.de.ingenico.com> Message-ID: <200706111251.l5BCpS9T017831@qbang.org> It is as Steffen describes. "InputStream" and "OutputStream" are inherently synchronous (which is why so many java programs resort to threads to use them). Anything outside of this "contract" is *not* an InputStream or OutputStream. That is why there is a new package for things that don't behave like the old *Stream classes - the NIO package. If you look carefully at the IO package, you'll note that almost all the classes are _Decorator_ pattern implementations of the *Stream classes - and the interface presents the _same_ behavior to the calling code in all cases - a synchronous operation that completes successfully or throws an exception (with the one exception of "read" that returns a "-1" on end-of-stream. I know I've read this numerous times - I'd suggest checking the Language Spec or one of the books by Bloch or Gosling. Ken At 08:36 2007-06-11, you wrote: >* Uncle George wrote on Mon, Jun 11, 2007 at 07:38 -0400: > > Steffen DETTMER wrote: > > > > > (but OutputStream promises that write > > > succeedes synchronous, blocking, or throws an exception). > > > > Where is it so written? > >Now, as you ask, I think it is not written that clearly but >follows from specification. mmm... > >Am I wrong? > >I understand the API doc in this way: > >* >http://java.sun.com/j2se/1.4.2/docs/api/java/io/OutputStream.html#write(byte[]) > > public void write(byte[] b) > > throws IOException > > > > Writes b.length bytes from the specified byte array to this > > output stream. The general contract for write(b) is that > > it should have exactly the same effect as the call write(b, > > 0, b.length). > > > > Parameters: > > b - the data. > > Throws: > > IOException - if an I/O error occurs. > > See Also: > > write(byte[], int, int) > > >and there is: > > > > public void write(byte[] b, > > int off, > > int len) > > throws IOException > > > > Writes len bytes from the specified byte array starting at > > offset off to this output stream. The general contract for > > write(b, off, len) is that some of the bytes in the array b > > are written to the output stream in order; element b[off] > > is the first byte written and b[off+len-1] is the last byte > > written by this operation. > > > > The write method of OutputStream calls the write method of > > one argument on each of the bytes to be written out. > > Subclasses are encouraged to override this method and > > provide a more efficient implementation. > > > > If b is null, a NullPointerException is thrown. > > > > If off is negative, or len is negative, or off+len is > > greater than the length of the array b, then an > > IndexOutOfBoundsException is thrown. > > > > Parameters: > > b - the data. > > off - the start offset in the data. > > len - the number of bytes to write. > > Throws: > > IOException - if an I/O error occurs. In particular, an > > IOException is thrown if the output stream is closed. > > >In general, any specialisation (derived child class) must comform >to this. So write in the end is specified (!) as "The write >method ... calls the write method ... on each of the bytes to be >written out". This is what must be implemented by ANY >OutputStream. > >Of course, there is: "Subclasses are encouraged to override this >method and provide a more efficient implementation." which IMHO >does not contradict - the more efficient must behave in exactly >the same way of course (just wasting less resources than a simple >byte-by-byte write). So it does not matter here I think. > > > >The write that finally defines the behavior tells basically: > > > "Writes the specified byte to this output stream. The general > > contract for write is that one byte is written to the output > > stream. " > > > > Throws: > > IOException - if an I/O error occurs. > > >which IMHO is another way of saying "write writes the byte >immediately and returns on success (only), otherwise an exception >is thrown". Especially it cannot happen that zero bytes are >written (i.e. the specified byte is NOT written) without an >exception. So by this write must be synchronous and blocking, >because otherwise it could not reliably know if an asynchronous >operation will succeede or not (some getAsyncResult or so would >be needed). > >Since write(byte[]) does this for each byte (or with a behavior >beeing exactly the same as if it would do), I think this means >that the write(byte[]) succeedes synchronous/blocking or throws >an exception. > >Did I an error in reasoning or confused something or so? > >oki, > >Steffen > >About Ingenico Throughout the world businesses rely on Ingenico for >secure and expedient electronic transaction acceptance. Ingenico >products leverage proven technology, established standards and >unparalleled ergonomics to provide optimal reliability, versatility >and usability. This comprehensive range of products is complemented >by a global array of services and partnerships, enabling businesses >in a number of vertical sectors to accept transactions anywhere >their business takes them. >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. > >About Ingenico Throughout the world businesses rely on Ingenico for >secure and expedient electronic transaction acceptance. Ingenico >products leverage proven technology, established standards and >unparalleled ergonomics to provide optimal reliability, versatility >and usability. This comprehensive range of products is complemented >by a global array of services and partnerships, enabling businesses >in a number of vertical sectors to accept transactions anywhere >their business takes them. >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. > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From alesinskyy at googlemail.com Mon Jun 11 07:25:33 2007 From: alesinskyy at googlemail.com (Oleksandr Alesinskyy) Date: Mon, 11 Jun 2007 15:25:33 +0200 Subject: [Rxtx] [OT] select :-) Message-ID: Sorry, but I have to disagree with following statement: "So write in the end is specified (!) as "The write method ... calls the write method ... on each of the bytes to be written out". This is what must be implemented by ANY OutputStream.". This is not part of the specification or contract, it is just revealed implementation detail of the OutputStream. It is not stated anywhere that behavoiur of derived classes shall conform with this one. Statement concerning "synchronous" nature of the output stream is invalid as well. Really synchronous stream does not require flush() but OutputStream has it. From Steffen.DETTMER at ingenico.com Mon Jun 11 08:21:16 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 16:21:16 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: Message-ID: <20070611142116.GN10821@elberon.bln.de.ingenico.com> * Oleksandr Alesinskyy wrote on Mon, Jun 11, 2007 at 15:25 +0200: > Sorry, but I have to disagree with following statement: > "So write in the end is specified (!) as "The write > method ... calls the write method ... on each of the bytes to be > written out". This is what must be implemented by ANY > OutputStream.". > > This is not part of the specification or contract, it is just > revealed implementation detail of the OutputStream. It is not > stated anywhere that behavoiur of derived classes shall conform > with this one. (I didn't meant that the implementation must really write byte by byte, but that it must "look as if it would do" - because all implementations of OutputStream must "look" in the same way [which is another way of saying "do abstract" I think]) I think the API doc is not "revealing implementation details" but it is the *specification* of that interface and derivations must (should) conform to this specification. Isn't this the idea of interfaces? A function that expects an OutputStream should work on ANY OutputStream, shouldn't it? just kidding: I mean, what would be the point in implementing a checksum function as OutputStream.write which throws its result as IOException? Or which requires to call close() as very first operation to tell that the application is about to transmit confidential data? :-) > Statement concerning "synchronous" nature of the output stream > is invalid as well. Really synchronous stream does not require > flush() but OutputStream has it. ahh, interesting point! I think this is another bug in the API. flush() is wrong. Because write specifies "The general contract for write is that one byte is written to the output stream." but not "a byte may be written or buffered". Actually, an application would need to call flush() after each write (or bunch of write calls) to ensure that write really did something otherwise I think. I didn't found in the spec of OutputStream that it would be required to call flush(). This should mean that calling flush is not required which in turn leads to the conclusion that write must be synchrous (private threads are forbidden because not specified :)) which in turn leads to the conclusion that flush() is not needed at all... I mean, what if someone would only store in write and do the "real write" in flush() and never else? An application could write in one stream and read on another one (e.g. in bidirectional communication) and would never get anything back, because nothing was actually written because no flush was called? Then someone could even think that on error in some write the data could remain buffered AND throw an exception, retrying to send the data in the next write. Ohh, and if there would be some message number inside, and underlaying write (e.g. a protocol offering InputStream/OutputStream) would check this and throw "DuplicatedMessageNumber" the stream would only throw it again and again beeing unusable... In short: I have no clue how someone could be able to implement an asynchrounos write (which is realiable and correct) without beeing specific to anything which is not specified by OutputStream. Well, I think in the end OutputStream was not intended for such communication or protocol implementations - but to read a local disk file or so. In case of I/O errors usually you can abort your application and change the hard disk :-) oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Bob_Jacobsen at lbl.gov Mon Jun 11 09:32:23 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Mon, 11 Jun 2007 08:32:23 -0700 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611142116.GN10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> Message-ID: At 4:21 PM +0200 6/11/07, Steffen DETTMER wrote: > > Statement concerning "synchronous" nature of the output stream >> is invalid as well. Really synchronous stream does not require >> flush() but OutputStream has it. > >ahh, interesting point! > >I think this is another bug in the API. flush() is wrong. Because >write specifies "The general contract for write is that one byte >is written to the output stream." but not "a byte may be written >or buffered". > >Actually, an application would need to call flush() after each >write (or bunch of write calls) to ensure that write really did >something otherwise I think. OutputStreams don't _have_ to be synchronous or asynchronous, but the OutputStream API was be arranged so that subclasses _can_ be synchronous or asynchronous. Such generality is the hardest part of getting an API right. Hence, if at some point a program using an OutputStream wants to be sure that the data has been pushed all the way out, flush() is available. For some subclasses, e.g. the buffered ones, this has important behavior. Others write the data from each call, and flush() doesn't do anything. You _can_ omit it in programs that are known to use this second type, but there's no requirement that you do so; the interface is general in that way. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From Steffen.DETTMER at ingenico.com Mon Jun 11 12:32:39 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 20:32:39 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> Message-ID: <20070611183239.GT10821@elberon.bln.de.ingenico.com> * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: > >Actually, an application would need to call flush() after each > >write (or bunch of write calls) to ensure that write really did > >something otherwise I think. > OutputStreams don't _have_ to be synchronous or asynchronous, > but the OutputStream API was be arranged so that subclasses > _can_ be synchronous or asynchronous. Ahh, oki. Thanks for the clarificaion. So in short, flush() MUST be called on OutputStream, this is just not documented correctly or so clearly (right?). So the overall usage semantics would be: 1. call write (multiple times if desired) 2. call flush only if both succeeded, write was successful. If flush fails it remains unknown if a part of the data was written and/or will be repeated. So the spec (API doc) is wrong. Correct would be to tell that write behaves as told as long as it is followed by a call to flush, otherwise data may or may not get lost (depending wheter close() is called and calls flush(), which seems not to be guaranteed/required). BTW, I think it is a little bit... erm... interesting to find the specification (java API doc reference) wrong, having a need to conclude it from the presence of some methods with "it would make no sense if they behave exactly as specified, so specification must be wrong (incomplete)". > Such generality is the hardest part of getting an API right. Yes, seems to be proven ;) > Hence, if at some point a program using an OutputStream wants > to be sure that the data has been pushed all the way out, > flush() is available. For some subclasses, e.g. the buffered > ones, this has important behavior. Others write the data from > each call, and flush() doesn't do anything. > You _can_ omit it in programs that are known to use this second > type, but there's no requirement that you do so; the interface > is general in that way. I think, it still it must be called always, otherwise the application could break if passing a different runtime type as OutputStream. I think, if the application/method needs a special "type of OutputStream" then the parameter type must be a subclass but not OutputStream, maybe a PrintStream or so - otherwise the compiler could not detect this error (passing wrong type). Is this correct? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Bob_Jacobsen at lbl.gov Mon Jun 11 13:00:52 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Mon, 11 Jun 2007 12:00:52 -0700 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611183239.GT10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> Message-ID: At 8:32 PM +0200 6/11/07, Steffen DETTMER wrote: >So the spec (API doc) is wrong. Correct would be to tell that >write behaves as told as long as it is followed by a call to >flush, otherwise data may or may not get lost (depending wheter >close() is called and calls flush(), which seems not to be >guaranteed/required). I'm not entirely sure that the spec is wrong, but reasonable people can differ on this. In the 1.5 JavaDocs, all that the docs say for the write methods is that they write to the _output_ _stream_; there is no guarantee of anything beyond that. Only the flush method has any guarantee about the data, which is >Flushes this output stream and forces any buffered output bytes to >be written out. The general contract of flush is that calling it is >an indication that, if any bytes previously written have been >buffered by the implementation of the output stream, such bytes >should immediately be written to their intended destination. People commonly use various OutputStreams without using flush(), and it often works, but it's a bad practice and will eventually bite them. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From netbeans at gatworks.com Mon Jun 11 13:31:57 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 15:31:57 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611183239.GT10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> Message-ID: <466DA32D.1010602@gatworks.com> Steffen DETTMER wrote: > * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: >>> Actually, an application would need to call flush() after each >>> write (or bunch of write calls) to ensure that write really did >>> something otherwise I think. > >> OutputStreams don't _have_ to be synchronous or asynchronous, >> but the OutputStream API was be arranged so that subclasses >> _can_ be synchronous or asynchronous. > > Ahh, oki. Thanks for the clarificaion. > > So in short, flush() MUST be called on OutputStream, this is just > not documented correctly or so clearly (right?). No. Flush can be called to force all current data in java buffer's to be written to the kernel - NOW. A flush() can also *imply* that, besides writing out the buffer's that java employs, may also imply/ask the kernel to write all data thusfar written to the kernel, to be physically placed on the destination device - NOW. For some OS's there is no need to do a kernel flush(), as the I/O is synchronized already. Since this is java, you never know what OS your on. From tjarvi at qbang.org Mon Jun 11 19:28:27 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Jun 2007 19:28:27 -0600 (MDT) Subject: [Rxtx] [OT] select :-) In-Reply-To: <466DA32D.1010602@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: On Mon, 11 Jun 2007, Uncle George wrote: > Steffen DETTMER wrote: >> * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: >>>> Actually, an application would need to call flush() after each >>>> write (or bunch of write calls) to ensure that write really did >>>> something otherwise I think. >> >>> OutputStreams don't _have_ to be synchronous or asynchronous, >>> but the OutputStream API was be arranged so that subclasses >>> _can_ be synchronous or asynchronous. >> >> Ahh, oki. Thanks for the clarificaion. >> >> So in short, flush() MUST be called on OutputStream, this is just >> not documented correctly or so clearly (right?). > No. > Flush can be called to force all current data in java buffer's to be > written to the kernel - NOW. > > A flush() can also *imply* that, besides writing out the buffer's that > java employs, may also imply/ask the kernel to write all data thusfar > written to the kernel, to be physically placed on the destination device > - NOW. > For some OS's there is no need to do a kernel flush(), as the I/O is > synchronized already. Since this is java, you never know what OS your on. To add to the confusion, flush on the C side throws away data. drain makes sure it is written. Looking at the ParallelImp.c we can probably do better. /* we set a timeout because all calls are sequentiell (also with asynchron) this means that the default timeout of unlimited blocks all calls (also close and status request) if the device is down */ GetCommTimeouts( (HANDLE)fd, &timeouts ); timeouts.WriteTotalTimeoutMultiplier = 0; timeouts.WriteTotalTimeoutConstant = 2000; /* 2000 is the min value for the default Windows NT and Windows 2000 driver */ SetCommTimeouts( (HANDLE)fd, &timeouts ); while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } errorCount = 0; bytes += countWritten; count -= countWritten; } LPRPort has some timeout code that appears to be doing nothing but flipping bits back and forth right now. The commapi rxtx follows allows for timeout control from javax.comm.CommPort. The above is a solution that worked in one specific use case. With timeouts in place, the original 'old printer going offline' problem could be solved. That printer code isn't written in stone. In fact it was ajusted from being able to print 'asdf' to a daisy wheel printer to working for one person. BTW, I've finished teaching after hours tonight and will be moving forward with a new rxtx release in my free time. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Jun 11 21:28:04 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 23:28:04 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: <466E12C4.1010305@gatworks.com> > Looking at the ParallelImp.c we can probably do better. > The problem stemmed from the possibility that the writev routine could have written some of the buffer, in chunks, printer pauses, refuses any more chunks, and a timeout occurs. Do you or do you not cause an exception to be thrown? Is there a way to set timeout for a ParallelPort data output stream? I cant find it. From tjarvi at qbang.org Mon Jun 11 22:17:23 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Jun 2007 22:17:23 -0600 (MDT) Subject: [Rxtx] [OT] select :-) In-Reply-To: <466E12C4.1010305@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> <466E12C4.1010305@gatworks.com> Message-ID: On Mon, 11 Jun 2007, Uncle George wrote: >> Looking at the ParallelImp.c we can probably do better. >> > The problem stemmed from the possibility that the writev routine could > have written some of the buffer, in chunks, printer pauses, refuses any > more chunks, and a timeout occurs. Do you or do you not cause an > exception to be thrown? > > Is there a way to set timeout for a ParallelPort data output stream? I > cant find it. hmm I looked again after you asked. The timeouts are only controllable on the receive side. This comes from CommPort; the parent. So what we are talking about is some bytes in memory that rxtx has and is supposed to write. A buffer perhaps? The approach with rxtx in the past has been to ignore output buffer sizes. The assumption is that the library does not know how to best handle buffers. There are buffered output streams that can do buffering on top of rxtx for instance. There is also a question regarding what was actually ment when the API was put together. My suspicion is that it was put together while looking at one OS API and was never ment to be anything more than a hook into that API. The comments are fairly telling combined with reading the w32 API. So looking at the problem again.. The current timeout behavior appears fairly arbitrary. Presumably this is to prevent a program from hanging instead of using a helper thread to write - heavy handed for new programmers. Even so, I don't think the write should timeout at all if it is not configurable. >From the API perspective, "What Timeout?" -- Trent Jarvi tjarvi at qbang.org From Steffen.DETTMER at ingenico.com Tue Jun 12 02:14:48 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 12 Jun 2007 10:14:48 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466DA32D.1010602@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: <20070612081447.GU10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Mon, Jun 11, 2007 at 15:31 -0400: > Steffen DETTMER wrote: > > Ahh, oki. Thanks for the clarificaion. > > > > So in short, flush() MUST be called on OutputStream, this is just > > not documented correctly or so clearly (right?). > No. hum (though now I got it, but...). > Flush can be called to force all current data in java buffer's to be > written to the kernel - NOW. > > A flush() can also *imply* that, besides writing out the > buffer's that java employs, may also imply/ask the kernel to > write all data thusfar written to the kernel, to be physically > placed on the destination device - NOW. > > For some OS's there is no need to do a kernel flush(), as the I/O is > synchronized already. Since this is java, you never know what OS your on. (well, but if you're going to kernel level, even flush cannot guarantee that data will "be physically placed". Maybe you're flushing to a file via NFS (and the client "thinks" that it was written, but maybe it was just buffered by the NFS server) or so... but of course such exceptions of the rules are constructable always.) Well, you tell that depending on the OS it can be that flush is needed or it can be that flush is not needed (beacuse the I/O is synchronized already), right? Also, applications should work on any OS, which includes the OSes that do need flush. Since the application cannot know whether flush is needed or not because it doesn't know what the OS is doing, it has to call flush, hasn't it? I mean, if it would not call flush then it would not work on such OSes (except the written data would not be needed at all, but in this would be an artificial example :)). Since applications are supposed to work this would be wrong, wouldn't it? So would it be correct to say: "Applications, that should work under all OSes (including the OSes where the I/O is not synchronised already), have to call flush on OutputStream to ensure the data is transfered to the kernel." or is this wrong? If so, then I'm afraid I missed the point again :( oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Tue Jun 12 04:46:52 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 12 Jun 2007 06:46:52 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070612081447.GU10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> <20070612081447.GU10821@elberon.bln.de.ingenico.com> Message-ID: <466E799C.7060700@gatworks.com> S > (well, but if you're going to kernel level, even flush cannot > guarantee that data will "be physically placed". Thats true now-a-days because ( from "man 2 sync" ) : > According to the standard specification (e.g., SVID), sync() schedules > the writes, but may return before the actual writing is done. However, > since version 1.3.20 Linux does actually wait. (This still does not > guarantee data integrity: modern disks have large caches.) My disk drive has 8mb cache. Maybe you're > flushing to a file via NFS (and the client "thinks" that it was > written, but maybe it was just buffered by the NFS server) or > so... but of course such exceptions of the rules are > constructable always.) > > Well, you tell that depending on the OS it can be that flush is > needed or it can be that flush is not needed (beacuse the I/O is > synchronized already), right? Also, applications should work on > any OS, which includes the OSes that do need flush. Its not OS's that need flush, its applications that want to have some assurance that data is written to the device that really needs to use flush. If your program ( or thread ) dies then it is in your best interest to write out the critical data as soon as possible, as economical as possible. These are trade-off's that the application programmer makes. A big buffer may mean big loss of data, a small buffer may mean spending too much time writing out data. > > > So would it be correct to say: > > "Applications, that should work under all OSes (including the > OSes where the I/O is not synchronised already), have to call > flush on OutputStream to ensure the data is transfered to the > kernel." > > or is this wrong? If so, then I'm afraid I missed the point again > :( > No that is not wrong. Ensuring that data is transfered to the OS is just about what any application can do. From tjarvi at qbang.org Thu Jun 14 08:16:47 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 14 Jun 2007 08:16:47 -0600 (MDT) Subject: [Rxtx] rxtx and usb-serial solution In-Reply-To: References: Message-ID: On Thu, 14 Jun 2007, Vladimir Kirtchev wrote: > Hi Trent, > > I develop a Java application which communicates with devices which have > USB-to-Serial bridge in them. The target OS is Linux. So for this purpose I > use RXTX. > > But I encountered a strange problem - when reading from the InputStream, I > receive series of zeros. I have this problem under Linux only. Under Windows > it is fine. > Actually this problem is the same as the one described here: > http://marc.info/?l=rxtx&m=109703190731748&w=2. > > > So I searched for the problem in the native code. And found that the root of > the problem is in SerialImp.c, > int configure_port( int fd ) > { > ... > ttyset.c_iflag = INPCK; > ... > } > > This line enables input parity checking, and the data sent from the device > is processed by the OS driver before being read with read(). > In this case the driver detects some problem and sets the received bytes to > zero. > > On the other hand in the Java part a set the serial port parameters with > SerialPort.PARITY_NONE. According to me, except all other things, this > should also disable INPCK in c_iflag. > > So I refactored the method translate_parity(...) to the following: > > int translate_parity( JNIEnv *env, struct termios *ttyset, jint parity ) > { > ENTER( "translate_parity" ); > #ifdef CMSPAR > ttyset->c_cflag &= ~(PARENB | PARODD | CMSPAR ); > #endif /* CMSPAR */ > switch( parity ) { > case JPARITY_NONE: > ttyset->c_iflag &= ~INPCK; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_EVEN: > ttyset->c_cflag |= PARENB; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_ODD: > ttyset->c_cflag |= PARENB | PARODD; > LEAVE( "translate_parity" ); > return 0; > #ifdef CMSPAR > case JPARITY_MARK: > ttyset->c_cflag |= PARENB | PARODD | CMSPAR; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_SPACE: > ttyset->c_cflag |= PARENB | CMSPAR; > LEAVE( "translate_parity" ); > return 0; > #endif /* CMSPAR */ > default: > printf("Parity missed %i\n", (int) parity ); > } > > LEAVE( "translate_parity" ); > /* > For some reason the native exceptions are not being caught. Moving this > to the Java side fixed the issue. taj. > throw_java_exception( env, UNSUPPORTED_COMM_OPERATION, > "", "parity value not supported" ); > */ > return 1; > } > > This modification solved the problem and now it works correctly under Linux. > > I think I will be a nice if this is idea is included in a future release of > RXTX. > > Thanks Vadim, I'll try that out. Forwarding to the rxtx mail-list too. This is probably not going to help USB drivers on windows which I'm sure some are looking for. As far as I can tell, windows USB bluetooth and serial dongles are limited by driver functionality. Some are good and others lack key features. -- Trent Jarvi tjarvi at qbang.org From dan.sandberg.lists at gmail.com Mon Jun 18 14:43:39 2007 From: dan.sandberg.lists at gmail.com (Dan Sandberg) Date: Mon, 18 Jun 2007 13:43:39 -0700 Subject: [Rxtx] Fix for JNI Get/Set Field Errors Message-ID: <4676EE7B.7060800@gmail.com> Hi, I've fixed the problems that cause the following JNI error when extra JNI checking ( -Xjni:check ) is turned on. FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) The problem was basically that GetLong was being used to get ints, and SetInt was used for longs. The patch below fixes this. Please let me know if there are any questions / problems. Cheers, -Dan diff -aur old/SerialImp.c src/SerialImp.c --- old/SerialImp.c 2007-06-18 13:24:33.000000000 -0700 +++ src/SerialImp.c 2007-06-18 06:26:26.000000000 -0700 @@ -1337,7 +1337,7 @@ report("init_threads: get eis\n"); jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); report("init_threads: set eis\n"); - (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); + (*eis->env)->SetLongField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); report("init_threads: stop\n"); report_time_end( ); return( 1 ); @@ -1530,7 +1530,7 @@ jobject jobj, jboolean interrupted ) { int fd = get_java_var( env, jobj,"fd","I" ); - struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var( env, jobj, "eis", "J" ); + struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var_long( env, jobj, "eis", "J" ); int result, count=0; char message[80]; @@ -2939,7 +2939,7 @@ /* TRENT */ int flag, count = 0; struct event_info_struct *eis = ( struct event_info_struct * ) - get_java_var( env, *jobj,"eis","J" ); + get_java_var_long( env, *jobj,"eis","J" ); report_time_start(); flag = eis->eventflags[SPE_DATA_AVAILABLE]; @@ -4873,9 +4873,9 @@ exceptions: none comments: ----------------------------------------------------------*/ -size_t get_java_var( JNIEnv *env, jobject jobj, char *id, char *type ) +long get_java_var_long( JNIEnv *env, jobject jobj, char *id, char *type ) { - int result = 0; + long result = 0; jclass jclazz = (*env)->GetObjectClass( env, jobj ); jfieldID jfd = (*env)->GetFieldID( env, jclazz, id, type ); @@ -4889,7 +4889,11 @@ LEAVE( "get_java_var" ); return result; } - result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); + if ( !strcmp( type, "J" ) ) { + result = (long)( (*env)->GetLongField( env, jobj, jfd ) ); + } else { + result = (int) ( (*env)->GetIntField( env, jobj, jfd ) ); + } /* ct7 & gel * Added DeleteLocalRef */ (*env)->DeleteLocalRef( env, jclazz ); if(!strncmp( "fd",id,2) && result == 0) @@ -4900,6 +4904,10 @@ return result; } +int get_java_var( JNIEnv *env, jobject jobj, char *id, char *type ) { + return (int) get_java_var_long( env, jobj, id, type ); +} + /*---------------------------------------------------------- throw_java_exception diff -aur old/SerialImp.h src/SerialImp.h --- old/SerialImp.h 2007-06-18 13:24:39.000000000 -0700 +++ src/SerialImp.h 2007-06-18 06:23:43.000000000 -0700 @@ -413,7 +413,8 @@ void system_wait(); void finalize_event_info_struct( struct event_info_struct * ); int read_byte_array( JNIEnv *, jobject *, int, unsigned char *, int, int ); -size_t get_java_var( JNIEnv *, jobject, char *, char * ); +int get_java_var( JNIEnv *, jobject, char *, char * ); +long get_java_var_long( JNIEnv *, jobject, char *, char * ); jboolean is_interrupted( struct event_info_struct * ); int send_event(struct event_info_struct *, jint, int ); void dump_termios(char *,struct termios *); From yvespielusenet at free.fr Tue Jun 26 03:41:58 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 11:41:58 +0200 Subject: [Rxtx] [PARALLEL] resource in use Message-ID: <1182850918.3483.10.camel@localhost.localdomain> Hello, So now I want to modify the timeout of the library for parallel port. I have downloaded source code. There is a makefile for migw. SO I have installed mingw on ubuntu and modified the makefile.mingw32 to set it for my system. I have no error but some warnings. The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But When I want to use it the jvm crash :( How can I know what is wrong ? How rxtx windows release has been done ? thanks -- yves piel From yvespielusenet at free.fr Tue Jun 26 07:17:02 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 15:17:02 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182850918.3483.10.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> Message-ID: <1182863822.3483.17.camel@localhost.localdomain> Here is the Makefile I use, the output of the 'make' and the log of the jvm when it crashed : - The Makefile : http://yvespiel.free.fr/rxtx/Makefile - The make output : http://yvespiel.free.fr/rxtx/compile.txt - The crash log : http://yvespiel.free.fr/rxtx/hs_err_pid2100.log I have compiled rxtx under Debian testing with mingw : narma at linimi:/tmp/err$ dpkg -l | grep mingw ii mingw32 3.4.5.20060117.1.dfsg-3 ii mingw32-binutils 2.17.50-20070129.1-1 ii mingw32-runtime 3.12-1 thanks fort help :) Le mardi 26 juin 2007 ? 11:41 +0200, yves pielusenet a ?crit : > Hello, > So now I want to modify the timeout of the library for parallel port. I > have downloaded source code. There is a makefile for migw. SO I have > installed mingw on ubuntu and modified the makefile.mingw32 to set it > for my system. > I have no error but some warnings. > The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But > When I want to use it the jvm crash :( > > How can I know what is wrong ? > > How rxtx windows release has been done ? > > thanks > From yvespielusenet at free.fr Tue Jun 26 07:40:11 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 15:40:11 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182863822.3483.17.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> <1182863822.3483.17.camel@localhost.localdomain> Message-ID: <1182865211.3483.21.camel@localhost.localdomain> I have add the options '--enable-stdcall-fixup' to the 'i586-mingw32msvc-ld' commande. Now I have no warning. But the JVM always crashes :( The output seems more detailled, but I don't understand anything... Here is files : http://yvespiel.free.fr/rxtx/2/ -- yves piel Le mardi 26 juin 2007 ? 15:17 +0200, yves pielusenet a ?crit : > Here is the Makefile I use, the output of the 'make' and the log of the > jvm when it crashed : > > - The Makefile : http://yvespiel.free.fr/rxtx/Makefile > - The make output : http://yvespiel.free.fr/rxtx/compile.txt > - The crash log : http://yvespiel.free.fr/rxtx/hs_err_pid2100.log > > I have compiled rxtx under Debian testing with mingw : > narma at linimi:/tmp/err$ dpkg -l | grep mingw > ii mingw32 3.4.5.20060117.1.dfsg-3 > ii mingw32-binutils 2.17.50-20070129.1-1 > ii mingw32-runtime 3.12-1 > > thanks fort help :) > > > Le mardi 26 juin 2007 ? 11:41 +0200, yves pielusenet a ?crit : > > Hello, > > So now I want to modify the timeout of the library for parallel port. I > > have downloaded source code. There is a makefile for migw. SO I have > > installed mingw on ubuntu and modified the makefile.mingw32 to set it > > for my system. > > I have no error but some warnings. > > The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But > > When I want to use it the jvm crash :( > > > > How can I know what is wrong ? > > > > How rxtx windows release has been done ? > > > > thanks > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From yvespielusenet at free.fr Tue Jun 26 08:27:42 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 16:27:42 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182865211.3483.21.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> <1182863822.3483.17.camel@localhost.localdomain> <1182865211.3483.21.camel@localhost.localdomain> Message-ID: <1182868062.3483.24.camel@localhost.localdomain> I think thant the include files of jdk were not for windows but for linux. So I have copied include/ folder from windows to linux and I modified the Makefile to use those file. It compile fine but the JVM always crash :( http://yvespiel.free.fr/rxtx/3/ Le mardi 26 juin 2007 ? 15:40 +0200, yves pielusenet a ?crit : > I have add the options '--enable-stdcall-fixup' to the > 'i586-mingw32msvc-ld' commande. Now I have no warning. But the JVM > always crashes :( The output seems more detailled, but I don't > understand anything... > Here is files : > http://yvespiel.free.fr/rxtx/2/ > From netbeans at gatworks.com Fri Jun 1 05:38:50 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 07:38:50 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <465F7ADD.1010501@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> Message-ID: <4660054A.2040202@gatworks.com> Manuel Naranjo wrote: In the case of my module, you can > unplug the device but it will not delete the symlink until those apps > that had opened the port has closed it. This is done this way to avoid > kernel panics. What does this mean to user code ? I have tried the alternate route ( other than closing ) which is sleep inbetween the I/O errors ( an unplugged USB device). When the device is plugged back in, The writes to the device still get an I/O error. This would seem to be a lost cause for the application. From netbeans at gatworks.com Fri Jun 1 06:35:48 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 08:35:48 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <465F7ADD.1010501@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> Message-ID: <466012A4.90608@gatworks.com> Manuel Naranjo wrote: In the case of my module, you can > unplug the device but it will not delete the symlink until those apps > that had opened the port has closed it. T Did u also mean for this to happen? USB0 was not closed by application. Apparently USB1 got created when USB device was plugged back in. There is only one USB device on a 4 port USB hub. This also seems to suggest that application recovery to be impossible. > Jun 1 07:10:08 mylaptop kernel: garmin_gps 1-1.4:1.0: Garmin GPS usb/tty converter detected > Jun 1 07:10:08 mylaptop kernel: usb 1-1.4: Garmin GPS usb/tty converter now attached to ttyUSB0 > Jun 1 07:15:17 mylaptop kernel: usb 1-1: USB disconnect, address 4 > Jun 1 07:15:17 mylaptop kernel: usb 1-1.4: USB disconnect, address 5 > Jun 1 07:15:17 mylaptop kernel: garmin_gps 1-1.4:1.0: device disconnected > Jun 1 07:15:26 mylaptop kernel: usb 1-1: new full speed USB device using uhci_hcd and address 6 > Jun 1 07:15:26 mylaptop kernel: hub 1-1:1.0: USB hub found > Jun 1 07:15:26 mylaptop kernel: hub 1-1:1.0: 4 ports detected > Jun 1 07:15:27 mylaptop kernel: usb 1-1.4: new full speed USB device using uhci_hcd and address 7 > Jun 1 07:15:27 mylaptop kernel: garmin_gps 1-1.4:1.0: Garmin GPS usb/tty converter detected > Jun 1 07:15:27 mylaptop kernel: usb 1-1.4: Garmin GPS usb/tty converter now attached to ttyUSB1 From naranjo.manuel at gmail.com Fri Jun 1 09:17:22 2007 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Fri, 01 Jun 2007 12:17:22 -0300 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <466012A4.90608@gatworks.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> <466012A4.90608@gatworks.com> Message-ID: <46603882.5050701@gmail.com> Uncle George escribi?: > Manuel Naranjo wrote: > In the case of my module, you can > >> unplug the device but it will not delete the symlink until those apps >> that had opened the port has closed it. T >> > > Did u also mean for this to happen? USB0 was not closed by application. > > Apparently USB1 got created when USB device was plugged back in. There > is only one USB device on a 4 port USB hub. > > This also seems to suggest that application recovery to be impossible. > Exactly there's a dead symlink (you can read and write to it and nothing will happen) and a new port will be created when a new device is connencted. From netbeans at gatworks.com Fri Jun 1 10:20:46 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 12:20:46 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <46603882.5050701@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> <466012A4.90608@gatworks.com> <46603882.5050701@gmail.com> Message-ID: <4660475E.5090202@gatworks.com> Not sure what u mean by "symlink". U cant read/write to it anymore. U get I/O error. In this scenario the device effectively went dead, and only solution is to close the channel. reconnecting the USB device, although dead, but not closed, will create a second device. This does not seem to be a desirable side-effect. The user will now have ttyUSB1, wondering where did ttyUSB0 go to. The application will also be in a confused state, as well as RXTX, because RXTX wont know about ttyUSB1. Manuel Naranjo wrote: > Uncle George escribi?: >> Manuel Naranjo wrote: >> In the case of my module, you can >> >>> unplug the device but it will not delete the symlink until those apps >>> that had opened the port has closed it. T >>> >> Did u also mean for this to happen? USB0 was not closed by application. >> >> Apparently USB1 got created when USB device was plugged back in. There >> is only one USB device on a 4 port USB hub. >> >> This also seems to suggest that application recovery to be impossible. >> > Exactly there's a dead symlink (you can read and write to it and nothing > will happen) and a new port will be created when a new device is connencted. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From arnab.bhaumik at gmail.com Mon Jun 4 01:40:16 2007 From: arnab.bhaumik at gmail.com (arnab bhaumik) Date: Mon, 4 Jun 2007 13:10:16 +0530 Subject: [Rxtx] full duplex com port with rxtx Message-ID: hi , till now i did half duplex communication with rxtx package on com package. my question is : is it possible to use com port with full duplex mode with rxtx package . ther is example of SimpleRead class and SimpleWrite class. it is clear that if i can use both the class simultaneously then full duplex is possible......... arnab/vu2bpw -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070604/6edb0453/attachment-0006.html From lists at iDIAcomputing.com Mon Jun 4 07:53:17 2007 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Mon, 04 Jun 2007 09:53:17 -0400 Subject: [Rxtx] full duplex com port with rxtx In-Reply-To: References: Message-ID: <4664194D.90301@iDIAcomputing.com> arnab bhaumik wrote: > hi , > > till now i did half duplex communication with rxtx package on com > package. > > my question is : is it possible to use com port with full duplex mode > with rxtx package . > > > ther is example of SimpleRead class and SimpleWrite class. it is > clear that if i can use both the class simultaneously then full duplex > is possible......... I haven't looked at the SimpleRead and SimpleWrite classes (I originally wrote my code for the javax.comm api), but full duplex is certainly possible. My CommReader class requires an object analogous to a OutputStream or Writer. When started, it spawns a thread that reads the comm port and writes to that output device. In this way the input is asynchronous and dependent on the actual input data. For full duplex, I extend that class with CommReaderWriter, which adds synchronous output methods. Hope that helps, George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From supsoop at hotmail.com Mon Jun 4 15:21:06 2007 From: supsoop at hotmail.com (soop soop) Date: Mon, 04 Jun 2007 21:21:06 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- Message-ID: Hi Guys, Looked through the archives but still cannot figure this out. I have a Motorola G24 GPRS/GSM modem that I am connecting to my server running Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not detecting the port, CommPortIdentifier.getPortIdentifiers(). I have added the line to RXTXCommDriver: "ttyACM" // for USB Modems Rxtx still does not seem to find the port. Is there something I am missing to make this port visable? [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control Model driver for USB modems and ISDN adapters I really need your help as I have moved my server from windows to Linux and have been down for a few days because of this .. Thanks so much! _________________________________________________________________ PC Magazine’s 2007 editors’ choice for best Web mail—award-winning Windows Live Hotmail. http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 From tjarvi at qbang.org Mon Jun 4 16:17:35 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Jun 2007 16:17:35 -0600 (MDT) Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: On Mon, 4 Jun 2007, soop soop wrote: > Hi Guys, > > Looked through the archives but still cannot figure this out. I have a > Motorola G24 GPRS/GSM modem that I am connecting to my server running Ubuntu. > I can see my modem as is shows up as ttyACM0, but RXTX is not detecting the > port, CommPortIdentifier.getPortIdentifiers(). > > I have added the line to RXTXCommDriver: > > "ttyACM" // for USB Modems > > Rxtx still does not seem to find the port. Is there something I am missing to > make this port visable? > > [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver > [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device > [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control Model > driver for USB modems and ISDN adapters > > I really need your help as I have moved my server from windows to Linux and > have been down for a few days because of this .. Thanks so much! > You could try the INSTALL documentation that comes with the source for possible solutions. Those usually involve lockfile creation, permissions on the device file or the device is in use by another application (even another session of your application). The usual commands: ls -l /dev/ttyACM0 fuser /dev/ttyACM0 touch /var/lock/LCK.testfile && rm -f /var/lock/LCK.testfile whoami To disable lockfiles: ../configure --disable-lockfiles && make install -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Jun 4 16:22:52 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 04 Jun 2007 18:22:52 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <466490BC.3090801@gatworks.com> soop soop wrote: > I really need your help as I have moved my server from windows to Linux > and have been down for a few days because of this .. Thanks so much! can u open the device ? ie is the file protection/permissions keeping you out? From supsoop at hotmail.com Mon Jun 4 16:44:40 2007 From: supsoop at hotmail.com (soop soop) Date: Mon, 04 Jun 2007 22:44:40 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <466490BC.3090801@gatworks.com> Message-ID: Thanks for the reply, I see no exceptions being thrown, just no detection of the port whats so ever. I will run rxtx in debug mode and log. If this were a permissions issue would I not see some exceptions being thrown? >From: Uncle George >Reply-To: RXTX Developers and Users >To: RXTX Developers and Users >Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >Date: Mon, 04 Jun 2007 18:22:52 -0400 > >soop soop wrote: > > > I really need your help as I have moved my server from windows to Linux > > and have been down for a few days because of this .. Thanks so much! > >can u open the device ? ie is the file protection/permissions keeping >you out? >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ Get a preview of Live Earth, the hottest event this summer - only on MSN http://liveearth.msn.com?source=msntaglineliveearthhm From netbeans at gatworks.com Mon Jun 4 17:06:15 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 04 Jun 2007 19:06:15 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <46649AE7.10405@gatworks.com> Exceptions on what? On startup it wants to lookup all devices in /dev that it is capable of opening ( within the list of specific 'comm' devices ). If it cannot open, then does not get onto list. Part of this process, if configured, will also test if the "LOCK" schema can also be opened for the device. then it gets on the list of avail comm port. soop soop wrote: > Thanks for the reply, > > I see no exceptions being thrown, just no detection of the port whats so > ever. I will run rxtx in debug mode and log. If this were a permissions > issue would I not see some exceptions being thrown? > > >> From: Uncle George >> Reply-To: RXTX Developers and Users >> To: RXTX Developers and Users >> Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >> Date: Mon, 04 Jun 2007 18:22:52 -0400 >> >> soop soop wrote: >> >>> I really need your help as I have moved my server from windows to Linux >>> and have been down for a few days because of this .. Thanks so much! >> can u open the device ? ie is the file protection/permissions keeping >> you out? >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _________________________________________________________________ > Get a preview of Live Earth, the hottest event this summer - only on MSN > http://liveearth.msn.com?source=msntaglineliveearthhm > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From alex.flint at gmail.com Mon Jun 4 21:31:49 2007 From: alex.flint at gmail.com (Alex Flint) Date: Tue, 5 Jun 2007 13:01:49 +0930 Subject: [Rxtx] random EXCEPTION_ACCESS_VIOLATION errors Message-ID: Hi All, I'm running winXP and RXTX 2.1-7r2 (the latest from the webpage as of June 2007). I'm sending sequences of 64 lines (each line has about 15 chars) at various intervals. The strings are sent fine, until I get the following error (from hs_err_pid3316.log, at the end of this email). What can I do to avoid the error? Obviously this is a low-level memory exception, but is there any way I can keep the JVM running after such an error? I noticed the exact same problem here: http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20070129/1180520.html Cheers, Alex # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x100034fb, pid=3316, tid=2400 # # Java VM: Java HotSpot(TM) Client VM (1.6.0_01-b06 mixed mode, sharing) # Problematic frame: # C [rxtxSerial.dll+0x34fb] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # --------------- T H R E A D --------------- Current thread (0x00386400): JavaThread "main" [_thread_in_native, id=2400] siginfo: ExceptionCode=0xc0000005, reading address 0x20726f78 Registers: EAX=0x20726f20, EBX=0x6d8922c0, ECX=0x00000005, EDX=0x20726f20 ESP=0x003efa30, EBP=0x003efb68, ESI=0x269728a0, EDI=0x00386400 EIP=0x100034fb, EFLAGS=0x00010212 Top of Stack: (sp=0x003efa30) 0x003efa30: 003efa3c 003efa64 0000000f ffffffff 0x003efa40: 003efa40 2a97f808 003efa6c 2b190ca8 0x003efa50: 00000000 2b190ec0 003efa90 008e2dd7 0x003efa60: 003efa90 008e2dd7 26977f88 6d815e72 0x003efa70: 00000004 2696eae0 0000008a 003efb0c 0x003efa80: 6d852b4a 2696eae0 00000003 26970930 0x003efa90: 000000cb 2696eae0 6d86b264 00385d40 0x003efaa0: 0000003f 003efb0c 26977f90 2ace65d8 Instructions: (pc=0x100034fb) 0x100034eb: ff ff 8d 76 00 eb 02 89 f6 90 8b 45 f8 8b 55 f8 0x100034fb: 8b 4a 58 83 c9 04 89 48 58 83 c4 f8 8b 45 f8 8b Stack: [0x003a0000,0x003f0000), sp=0x003efa30, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x34fb] Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j gnu.io.RXTXPort.writeArray([BIIZ)V+0 j gnu.io.RXTXPort$SerialOutputStream.write([B)V+76 j com.bjt.media.server.CommLink.send(Ljava/lang/String;)V+48 j com.bjt.media.server.DigitoolConnection.select(I)V+73 j com.bjt.media.server.DigitoolConnection.main([Ljava/lang/String;)V+74 v ~StubRoutines::call_stub --------------- P R O C E S S --------------- Java Threads: ( => current thread ) 0x02a69400 JavaThread "Thread-0" [_thread_in_native, id=3052] 0x02a4d000 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=3920] 0x02a48400 JavaThread "CompilerThread0" daemon [_thread_blocked, id=1968] 0x02a47400 JavaThread "Attach Listener" daemon [_thread_blocked, id=2984] 0x02a46400 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=2660] 0x02a41c00 JavaThread "Finalizer" daemon [_thread_blocked, id=3924] 0x02a3d800 JavaThread "Reference Handler" daemon [_thread_blocked, id=4008] =>0x00386400 JavaThread "main" [_thread_in_native, id=2400] Other Threads: 0x02a34400 VMThread [id=3708] 0x02a4e800 WatcherThread [id=3964] VM state:not at safepoint (normal execution) VM Mutex/Monitor currently owned by a thread: None Heap def new generation total 960K, used 131K [0x22960000, 0x22a60000, 0x22e40000) eden space 896K, 7% used [0x22960000, 0x22970ea8, 0x22a40000) from space 64K, 99% used [0x22a50000, 0x22a5fff8, 0x22a60000) to space 64K, 0% used [0x22a40000, 0x22a40000, 0x22a50000) tenured generation total 4096K, used 76K [0x22e40000, 0x23240000, 0x26960000) the space 4096K, 1% used [0x22e40000, 0x22e53060, 0x22e53200, 0x23240000) compacting perm gen total 12288K, used 137K [0x26960000, 0x27560000, 0x2a960000) the space 12288K, 1% used [0x26960000, 0x26982518, 0x26982600, 0x27560000) ro space 8192K, 62% used [0x2a960000, 0x2ae5e4e8, 0x2ae5e600, 0x2b160000) rw space 12288K, 52% used [0x2b160000, 0x2b7a0e78, 0x2b7a1000, 0x2bd60000) Dynamic libraries: 0x00400000 - 0x00423000 C:\Program Files\Java\jre1.6.0_01\bin\javaw.exe 0x7c900000 - 0x7c9b0000 C:\WINDOWS\system32\ntdll.dll 0x7c800000 - 0x7c8f4000 C:\WINDOWS\system32\kernel32.dll 0x77dd0000 - 0x77e6b000 C:\WINDOWS\system32\ADVAPI32.dll 0x77e70000 - 0x77f01000 C:\WINDOWS\system32\RPCRT4.dll 0x7e410000 - 0x7e4a0000 C:\WINDOWS\system32\USER32.dll 0x77f10000 - 0x77f57000 C:\WINDOWS\system32\GDI32.dll 0x76390000 - 0x763ad000 C:\WINDOWS\system32\IMM32.DLL 0x7c340000 - 0x7c396000 C:\Program Files\Java\jre1.6.0_01\bin\msvcr71.dll 0x6d7c0000 - 0x6da07000 C:\Program Files\Java\jre1.6.0_01\bin\client\jvm.dll 0x76b40000 - 0x76b6d000 C:\WINDOWS\system32\WINMM.dll 0x5cd70000 - 0x5cd77000 C:\WINDOWS\system32\serwvdrv.dll 0x5b0a0000 - 0x5b0a7000 C:\WINDOWS\system32\umdmxfrm.dll 0x6d310000 - 0x6d318000 C:\Program Files\Java\jre1.6.0_01\bin\hpi.dll 0x76bf0000 - 0x76bfb000 C:\WINDOWS\system32\PSAPI.DLL 0x6d770000 - 0x6d77c000 C:\Program Files\Java\jre1.6.0_01\bin\verify.dll 0x6d3b0000 - 0x6d3cf000 C:\Program Files\Java\jre1.6.0_01\bin\java.dll 0x6d7b0000 - 0x6d7bf000 C:\Program Files\Java\jre1.6.0_01\bin\zip.dll 0x10000000 - 0x10012000 C:\Documents and Settings\Alex\workspace\MediaServer\rxtxSerial.dll 0x73d90000 - 0x73db7000 C:\WINDOWS\system32\crtdll.dll VM Arguments: jvm_args: -Djava.library.path=C:\Documents and Settings\Alex\workspace\MediaServer java_command: com.bjt.media.server.DigitoolConnection Launcher Type: SUN_STANDARD Environment Variables: CLASSPATH=.;C:\Program Files\Java\j2re1.4.2_07\lib\ext\QTJava.zip PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\wbem;c:\applications\php;C:\Program Files\MATLAB\R2006a\bin\win32;C:\Roger\Projects\UAV\Bin\Debug;C:\Program Files\Microsoft SQL Server\80\Tools\Binn\;c:\Program Files\Microsoft SQL Server\90\Tools\binn\;C:\Program Files\QuickTime\QTSystem\;C:\Pfps\system;C:\Program Files\Java\jdk1.6.0_01\bin;C:\Program Files\Java\jdk1.6.0_01\jre\bin USERNAME=Alex OS=Windows_NT PROCESSOR_IDENTIFIER=x86 Family 15 Model 4 Stepping 1, GenuineIntel --------------- S Y S T E M --------------- OS: Windows XP Build 2600 Service Pack 2 CPU:total 1 family 15, cmov, cx8, fxsr, mmx, sse, sse2 Memory: 4k page, physical 1046508k(275288k free), swap 2522816k(1909176k free) vm_info: Java HotSpot(TM) Client VM (1.6.0_01-b06) for windows-x86, built on Mar 14 2007 00:24:02 by "java_re" with unknown MS VC++:1310 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070604/c87ae1f0/attachment-0006.html From alwyn.schoeman at gmail.com Tue Jun 5 00:10:19 2007 From: alwyn.schoeman at gmail.com (Alwyn Schoeman) Date: Tue, 5 Jun 2007 08:10:19 +0200 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Hi, I'm using a similar modem. By default rxtx doesn't look for devices that start with ACM, so you need to modify the source code and recompile. Look in RXTXCommDriver and add values for ACM in the registerScannedPorts method in the Linux specific parts. Look for osName.equals("Linux")... On 6/4/07, soop soop wrote: > > Hi Guys, > > Looked through the archives but still cannot figure this out. I have a > Motorola G24 GPRS/GSM modem that I am connecting to my server running > Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not > detecting the port, CommPortIdentifier.getPortIdentifiers(). > > I have added the line to RXTXCommDriver: > > "ttyACM" // for USB Modems > > Rxtx still does not seem to find the port. Is there something I am missing > to make this port visable? > > [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver > [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device > [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control > Model > driver for USB modems and ISDN adapters > > I really need your help as I have moved my server from windows to Linux > and > have been down for a few days because of this .. Thanks so much! > > _________________________________________________________________ > PC Magazine's 2007 editors' choice for best Web mail?award-winning Windows > Live Hotmail. > > http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -- Alwyn Schoeman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/b6cb3053/attachment-0006.html From naranjo.manuel at gmail.com Tue Jun 5 06:48:45 2007 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Tue, 05 Jun 2007 09:48:45 -0300 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> References: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Message-ID: <46655BAD.7010501@gmail.com> That's right, an easier solution is creating symlinks to acm. For example make ttyS70 to 79 point to ACM0 to 9 and that will help you a lot, and doesn't even require compile. > Hi, > > I'm using a similar modem. By default rxtx doesn't look for devices > that start with ACM, so you need to modify the > source code and recompile. > > Look in RXTXCommDriver and add values for ACM in the > registerScannedPorts method in the Linux specific parts. Look for > osName.equals("Linux")... > From juanemc2 at gmail.com Tue Jun 5 07:02:43 2007 From: juanemc2 at gmail.com (Juan) Date: Tue, 5 Jun 2007 10:02:43 -0300 Subject: [Rxtx] Problems with Epson TMU220B POSPrinter using XON/XOFF Flow Control and rxtx jar and dll's with the serial port. Message-ID: Hi!, I?m having trouble printing to the serial port using the latest version of rxtx jar and dll's with an Epson POSPrinter. I`ve switched the printer to work with XON/XOFF Flow Control and have watched the serial port to be sure the printer is sending the XON XOFF stop and go characters. I`ve setted the port like this: CommPortIdentifier commPortIdentifier = CommPortIdentifier.* getPortIdentifier*(_portName); SerialPort serialPort = (SerialPort)commPortIdentifier.open(*this*.getClass().getName(), 2000); serialPort.setSerialPortParams(_baudRate, _dataBits, _stopBits, _parity); serialPort.setFlowControlMode( SerialPort.*FLOWCONTROL_XONXOFF_IN* | SerialPort.*FLOWCONTROL_XONXOFF_OUT*); where the baudRate is 9600 the dataBits is 8 the stopBits is 1 and the parity is 0 It seems as the library isn`t taking into account the XON XOFF setting. I would like to know if I`m setting correctly the Flow Control and if you had had any experiences using XON XOFF flow control and could give me some help to solve my problem. I`m very thankful in advance, Yours, Juan Polero -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/b080995a/attachment-0006.html From ehdez.correo at gmail.com Tue Jun 5 07:12:53 2007 From: ehdez.correo at gmail.com (=?ISO-8859-1?Q?Enrique_Hern=E1ndez?=) Date: Tue, 5 Jun 2007 09:12:53 -0400 Subject: [Rxtx] problem with rxtx Message-ID: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Hello: I doing a simple test to show the serial ports. This is the code: import java.util.Enumeration; import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; public class Show { private Enumeration portList; private CommPortIdentifier portId; private SerialPort port; /** Creates a new instance of Show */ public Show() { } public static void main(String args[]){ Show show = new Show(); show.portList = CommPortIdentifier.getPortIdentifiers(); String tPort = ""; System.out.println("========================================="); while(show.portList.hasMoreElements()){ show.portId = (CommPortIdentifier)show.portList.nextElement(); if(show.portId.getPortType() == CommPortIdentifier.PORT_SERIAL) tPort = "Serial"; else tPort = "Parallel"; System.out.println(show.portId.getName() + " " + tPort); } } } whit The problem is that this code not show the serial ports, this show the no use serial ports. I want to connect whit the modem but when windows open and connect the modem my application don't see the port(COMM3) when it is connect. what I can do? Is that the correct way to know the ports? thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/eedd744b/attachment-0006.html From ehdez.correo at gmail.com Tue Jun 5 07:42:13 2007 From: ehdez.correo at gmail.com (=?ISO-8859-1?Q?Enrique_Hern=E1ndez?=) Date: Tue, 5 Jun 2007 09:42:13 -0400 Subject: [Rxtx] serial port Message-ID: <4a814e1f0706050642p4ce9ac7bka80f9479c524c5ea@mail.gmail.com> Hello: How I can ask to the port what device is connect and information about this device. thanks. bye. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/4d10d26a/attachment-0006.html From supsoop at hotmail.com Tue Jun 5 09:29:00 2007 From: supsoop at hotmail.com (soop soop) Date: Tue, 05 Jun 2007 15:29:00 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Message-ID: Hi Guys, Thanks for all your help. I found the problem. I created a user, Tomcat55, for my tomcat but it did not belong to any group. I then added this user to dialout group to have access to the device ttyACM0. Works perfectly! Again permissions was the issue. This also seems to be persistent as a server reboot does not effect the access. Cheers! >From: "Alwyn Schoeman" >Reply-To: RXTX Developers and Users >To: "RXTX Developers and Users" >Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >Date: Tue, 5 Jun 2007 08:10:19 +0200 > >Hi, > >I'm using a similar modem. By default rxtx doesn't look for devices that >start with ACM, so you need to modify the >source code and recompile. > >Look in RXTXCommDriver and add values for ACM in the registerScannedPorts >method in the Linux specific parts. Look for osName.equals("Linux")... > >On 6/4/07, soop soop wrote: >> >>Hi Guys, >> >>Looked through the archives but still cannot figure this out. I have a >>Motorola G24 GPRS/GSM modem that I am connecting to my server running >>Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not >>detecting the port, CommPortIdentifier.getPortIdentifiers(). >> >>I have added the line to RXTXCommDriver: >> >>"ttyACM" // for USB Modems >> >>Rxtx still does not seem to find the port. Is there something I am missing >>to make this port visable? >> >>[ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver >>[ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device >>[ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control >>Model >>driver for USB modems and ISDN adapters >> >>I really need your help as I have moved my server from windows to Linux >>and >>have been down for a few days because of this .. Thanks so much! >> >>_________________________________________________________________ >>PC Magazine's 2007 editors' choice for best Web mail—award-winning Windows >>Live Hotmail. >> >>http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 >> >> >>_______________________________________________ >>Rxtx mailing list >>Rxtx at qbang.org >>http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > >-- >Alwyn Schoeman >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ Need a break? Find your escape route with Live Search Maps. http://maps.live.com/default.aspx?ss=Restaurants~Hotels~Amusement%20Park&cp=33.832922~-117.915659&style=r&lvl=13&tilt=-90&dir=0&alt=-1000&scene=1118863&encType=1&FORM=MGAC01 From netbeans at gatworks.com Tue Jun 5 09:42:31 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 11:42:31 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <46658467.20101@gatworks.com> soop soop wrote: > > Hi Guys, > > Thanks for all your help. I found the problem. I created a user, > Tomcat55, for my tomcat but it did not belong to any group. I then added Look at man pages for the program udev. From tjarvi at qbang.org Tue Jun 5 18:18:17 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Jun 2007 18:18:17 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Message-ID: On Tue, 5 Jun 2007, Enrique Hern?ndez wrote: > The problem is that this code not show the serial ports, this show the no > use serial ports. I want to connect whit the modem but when windows open and > connect the modem my application don't see the port(COMM3) when it is > connect. > what I can do? > Is that the correct way to know the ports? > Hello, We may have problems understanding each other. On windows, the port will not be an available serial port if another application has the port open. That is just how the library behaves. If you can not see the port in the enumerated list, you could not open it. Also note that enumeration only happens once. If you add a port such as a new USB dongle, the port will not be visible until the next time your application runs. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Tue Jun 5 18:45:01 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 20:45:01 -0400 Subject: [Rxtx] problem with rxtx In-Reply-To: References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Message-ID: <4666038D.8090700@gatworks.com> Trent Jarvi wrote: > > > Also note that enumeration only happens once. If you add a port such as > a new USB dongle, the port will not be visible until the next time your > application runs. Is this written in stone ? somewhere? From tjarvi at qbang.org Tue Jun 5 18:54:36 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Jun 2007 18:54:36 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <4666038D.8090700@gatworks.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> Message-ID: On Tue, 5 Jun 2007, Uncle George wrote: > Trent Jarvi wrote: >> >> >> Also note that enumeration only happens once. If you add a port such as >> a new USB dongle, the port will not be visible until the next time your >> application runs. > > Is this written in stone ? somewhere? It is just the current behavior. There is nothing preventing a fix that allows reenumeration. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Tue Jun 5 19:55:19 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 21:55:19 -0400 Subject: [Rxtx] problem with rxtx In-Reply-To: References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> Message-ID: <46661407.4020308@gatworks.com> >> Is this written in stone ? somewhere? > > It is just the current behavior. There is nothing preventing a fix that > allows reenumeration. With usb, ..... , things come and go. Seems a shame that you have to kill application to get at the device u just plugged in. From joachim at buechse.ch Wed Jun 6 01:50:06 2007 From: joachim at buechse.ch (Joachim Buechse) Date: Wed, 6 Jun 2007 09:50:06 +0200 Subject: [Rxtx] problem with rxtx In-Reply-To: <46661407.4020308@gatworks.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> <46661407.4020308@gatworks.com> Message-ID: <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> On MacOS RXTX's enumeration handling is more flexible. It will find new ports that are added during the lifetime of the application. But this is inherently incompatible with suns javax.comm implementation... Regards, Joachim On 06.06.2007, at 03:55, Uncle George wrote: > >>> Is this written in stone ? somewhere? >> >> It is just the current behavior. There is nothing preventing a >> fix that >> allows reenumeration. > > With usb, ..... , things come and go. Seems a shame that you have to > kill application to get at the device u just plugged in. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Jun 6 06:06:48 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Jun 2007 06:06:48 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> <46661407.4020308@gatworks.com> <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> Message-ID: Sun's javax.comm is not a major concern going forward. As long as we do not break old applications using rxtx, I see no reason to limit rxtx to that convention. We have already rejected version 3 from Sun as a dead end and limited our compatability to version 2. That does not mean we will not try to work with Sun and others but the current javax.comm convention (v3) is not a well conceived path. There has been discussion about doing a JSR which is one valid option. On Wed, 6 Jun 2007, Joachim Buechse wrote: > On MacOS RXTX's enumeration handling is more flexible. It will find > new ports that are added during the lifetime of the application. But > this is inherently incompatible with suns javax.comm implementation... > > Regards, > Joachim > > On 06.06.2007, at 03:55, Uncle George wrote: > >> >>>> Is this written in stone ? somewhere? >>> >>> It is just the current behavior. There is nothing preventing a >>> fix that >>> allows reenumeration. >> >> With usb, ..... , things come and go. Seems a shame that you have to >> kill application to get at the device u just plugged in. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From yvespielusenet at free.fr Wed Jun 6 08:46:35 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 16:46:35 +0200 Subject: [Rxtx] [PARALLEL] resource in use Message-ID: <1181141195.3407.20.camel@localhost.localdomain> Hello, I want to use rxtx in my application. I haveto send data to a very old printer (which have a drum and hammers http://perso.orange.fr/tiie/page00010017.html) This is printer is connecter with centronics. It works well but, while it's writting and I putthe printer off-line, after about 45 seconds, I have this error : ------------------------------------- java.io.IOException: La ressource demand?e est en cours d'utilisation. in writeArray at gnu.io.LPRPort.writeArray(Native Method) at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:292) at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:161) at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:156) at mce.buffer.bufferManager.BufferManager$PrintBuffer.run(BufferManager.java:141) The IOexception means "The wanted resource is in use" ------------------------------------- Here is the line 141 of BufferManager : ------------------------------------- while(send){ try{ fos.write(bb); <=== line 141 send = false; } catch(Exception e){ javax.swing.JOptionPane.showMessageDialog(null, "Erreur d'envoie. Veuillez cliquer sur OK pour relancer l'impression de la vignette.\nV?rifiez votre impression !", "Erreur d'envoie", javax.swing.JOptionPane.WARNING_MESSAGE); e.printStackTrace(System.err); System.err.flush(); System.out.println(e); send = true; } } -------------------------------- 'fos' is an outputstream which contains the rxtx stream (this.os is the rxtx outputstream) : -------------------------------- public void write(byte[] bb) throws IOException{ this.write(bb, 0, bb.length); } public void write(byte[] bb, int off, int len) throws IOException{ while(!imp1.isPrinterSelected() || !imp2.isPrinterSelected()){ } this.os.write(bb, off, len); } -------------------------------- Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( can you help me ? thank you :) -- yves piel From yvespielusenet at free.fr Wed Jun 6 09:11:15 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 17:11:15 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181141195.3407.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> Message-ID: <1181142675.3407.23.camel@localhost.localdomain> I forgot to tell that It's under windows XP and java 1.5. Le mercredi 06 juin 2007 ? 16:46 +0200, yves pielusenet a ?crit : > Hello, > I want to use rxtx in my application. I haveto send data to a very old > printer (which have a drum and hammers > http://perso.orange.fr/tiie/page00010017.html) > This is printer is connecter with centronics. It works well but, while > it's writting and I putthe printer off-line, after about 45 seconds, I > have this error : > ------------------------------------- > java.io.IOException: La ressource demand?e est en cours d'utilisation. > in writeArray > at gnu.io.LPRPort.writeArray(Native Method) > at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:292) > at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:161) > at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:156) > at mce.buffer.bufferManager.BufferManager$PrintBuffer.run(BufferManager.java:141) > > The IOexception means "The wanted resource is in use" > ------------------------------------- > > Here is the line 141 of BufferManager : > > ------------------------------------- > while(send){ > try{ > fos.write(bb); <=== line 141 > send = false; > } > catch(Exception e){ > javax.swing.JOptionPane.showMessageDialog(null, "Erreur d'envoie. Veuillez cliquer sur OK pour relancer l'impression de la vignette.\nV?rifiez votre impression !", "Erreur d'envoie", javax.swing.JOptionPane.WARNING_MESSAGE); > e.printStackTrace(System.err); > System.err.flush(); > System.out.println(e); > send = true; > } > } > -------------------------------- > 'fos' is an outputstream which contains the rxtx stream (this.os is the rxtx outputstream) : > > -------------------------------- > public void write(byte[] bb) throws IOException{ > this.write(bb, 0, bb.length); > } > public void write(byte[] bb, int off, int len) throws IOException{ > while(!imp1.isPrinterSelected() || !imp2.isPrinterSelected()){ > } > this.os.write(bb, off, len); > } > -------------------------------- > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > can you help me ? > > thank you :) > From netbeans at gatworks.com Wed Jun 6 09:21:46 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 11:21:46 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181141195.3407.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> Message-ID: <4666D10A.8000507@gatworks.com> } > -------------------------------- > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > can you help me ? > > thank you :) > windoz or linux? ( I guess windoz ) for windoz, there appears to be a timeout ( as Comments suggest ) of about 40seconds. > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } for linux, there is no implied timeout. > if( write( fd, bytes, count ) < 0 ) > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); From netbeans at gatworks.com Wed Jun 6 09:39:41 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 11:39:41 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666D10A.8000507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> Message-ID: <4666D53D.90000@gatworks.com> Uncle George wrote: > } >> -------------------------------- >> >> Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( >> >> can you help me ? From reading the code, I can see your concern. And it appears you are correct, because some of the data will be sent to the OS printer buffers, and then it will refuse to accept anymore. Unfortunately, writeArray does not return the num of characters written :{ So application has no idea to how many characters were accepted by the OS. I dont do windoz, so I cant say with absolute certainty what windoz will do with an off-line condition. If you have the source, and can compile, then maybe u can increase the loop count to hit 4hours? From yvespielusenet at free.fr Wed Jun 6 09:53:25 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 17:53:25 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666D10A.8000507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> Message-ID: <1181145205.3407.35.camel@localhost.localdomain> Thank you for your explanation :) This timeout comes when no data has been send to the printer after 40seconds if I well understand. But why there is such a timeout ? If I setthe printer offline while it's printing I mustn't have an exception. I don't understand why the "printer should solv all problems like buffer full" in 40 seconds. If I pause the printer the buffer will not be emptied, isn't it ? I not very familiar with C/C++, but it seem that the exception is thrown only when countWritten == 0, that means no data at all has been sent. So Is my code is good since when I intercept this exception I send all my buffer again. There is no way that the printer receive two times same bytes ? thanks ps: yes the application is running on windows XP since I developpe under Debian Le mercredi 06 juin 2007 ? 11:21 -0400, Uncle George a ?crit : > } > > -------------------------------- > > > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > > > can you help me ? > > > > thank you :) > > > > windoz or linux? ( I guess windoz ) > > for windoz, there appears to be a timeout ( as Comments suggest ) of > about 40seconds. > > while( count > 0 ){ > > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > > /* > > this are 20 * 2 seconds, in this time a printer (or other parallel device) > > should solv all problems like buffer full, etc > > */ > > if(errorCount++ < 20){ > > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > > continue; > > } > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > for linux, there is no implied timeout. > > if( write( fd, bytes, count ) < 0 ) > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Wed Jun 6 10:34:24 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 12:34:24 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181145205.3407.35.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> Message-ID: <4666E210.30507@gatworks.com> yves pielusenet wrote: > Thank you for your explanation :) > This timeout comes when no data has been send to the printer after > 40seconds if I well understand. But why there is such a timeout ? If I > setthe printer offline while it's printing I mustn't have an exception. > I don't understand why the "printer should solv all problems like buffer > full" in 40 seconds. If I pause the printer the buffer will not be > emptied, isn't it ? > > I not very familiar with C/C++, but it seem that the exception is thrown > only when countWritten == 0, that means no data at all has been sent. So > Is my code is good since when I intercept this exception I send all my > buffer again. There is no way that the printer receive two times same > bytes ? More technically, the function call returns and reports that 0 characters was written in this call. when 0 characters are written, it will check how many times 0 characters was written. If it has tried LESS than 20 times(errorCount), it will sleep() and try to write again. After 20 times, it wont sleep, but throw you the exception. Now suppose you are writing a 120 character line. you off-lined/paused your printer. The OS has room for 80 more characters in it's printer buffer. The WriteFile() will have a char count of 120, but on return the countWritten = 80. You still have 40 more characters to print. Since countWritten != 0, the counters: bytes += countWritten; count -= countWritten; get updated, and the Writefile now has a count of 40 characters. Since the printer is off-line, the countwritten is 0. And so the loop continues, till 40 seconds is up. As to why it is this way, i dont know ( not a windoz maven ); Also the sleep(20) in the loop is not so intuitive to suggest 2 seconds of sleep. I would have guessed 20seconds, or 20milliseconds. But go figure. BTW: Since your computer sends you error messages in French, does it curse in English? :)))) From yvespielusenet at free.fr Thu Jun 7 02:27:44 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Thu, 07 Jun 2007 10:27:44 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666E210.30507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> Message-ID: <1181204864.3501.10.camel@localhost.localdomain> Maybe in my case I should re-compile rxtx and change the code. Instead of send an exception I should display a dialog box to ask if it's printer problem or if it should trie to send bytes. Something like : while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } if(displayDialogBox("Try again to send datas ??")){ errorCount = 0; } else{ throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } } Le mercredi 06 juin 2007 ? 12:34 -0400, Uncle George a ?crit : > yves pielusenet wrote: > > Thank you for your explanation :) > > This timeout comes when no data has been send to the printer after > > 40seconds if I well understand. But why there is such a timeout ? If I > > setthe printer offline while it's printing I mustn't have an exception. > > I don't understand why the "printer should solv all problems like buffer > > full" in 40 seconds. If I pause the printer the buffer will not be > > emptied, isn't it ? > > > > I not very familiar with C/C++, but it seem that the exception is thrown > > only when countWritten == 0, that means no data at all has been sent. So > > Is my code is good since when I intercept this exception I send all my > > buffer again. There is no way that the printer receive two times same > > bytes ? > More technically, the function call returns and reports that 0 > characters was written in this call. > when 0 characters are written, it will check how many times 0 characters > was written. If it has tried LESS than 20 times(errorCount), it will > sleep() and try to write again. > After 20 times, it wont sleep, but throw you the exception. > > Now suppose you are writing a 120 character line. you off-lined/paused > your printer. The OS has room for 80 more characters in it's printer > buffer. The WriteFile() will have a char count of 120, but on return the > countWritten = 80. You still have 40 more characters to print. > Since countWritten != 0, the counters: > bytes += countWritten; > count -= countWritten; > get updated, and the Writefile now has a count of 40 characters. Since > the printer is off-line, the countwritten is 0. And so the loop > continues, till 40 seconds is up. > > As to why it is this way, i dont know ( not a windoz maven ); > Also the sleep(20) in the loop is not so intuitive to suggest 2 seconds > of sleep. I would have guessed 20seconds, or 20milliseconds. But go figure. > > BTW: Since your computer sends you error messages in French, does it > curse in English? :)))) > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 06:11:43 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 08:11:43 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181204864.3501.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> Message-ID: <4667F5FF.8070903@gatworks.com> your suggestion appears good. I dont know what displayDialogBox exactly will do, so all I can say it that it looks good. But I'd like to wait 10min before first dialog box And a 5 min wait for every dialog box there after. And since these are custom solution/choices, maybe a more exact explanation of what the issue is. if(errorCount++ < 300){ // wait 10min ( 10min * 60sec / 2 ) Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } if(displayDialogBox("Printer has Paused. Retry sending data?")){ errorCount = 150; // Wait for 5 min thereafter continue; } > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } yves pielusenet wrote: > Maybe in my case I should re-compile rxtx and change the code. Instead > of send an exception I should display a dialog box to ask if it's > printer problem or if it should trie to send bytes. Something like : > > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > > if(displayDialogBox("Try again to send datas ??")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > } > From yvespielusenet at free.fr Thu Jun 7 07:17:21 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Thu, 07 Jun 2007 15:17:21 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4667F5FF.8070903@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <4667F5FF.8070903@gatworks.com> Message-ID: <1181222241.3501.20.camel@localhost.localdomain> thank you :) 'displayDialogBox()' I think doesn't exist. It was just for the example :) But I think It should not be so complicated to display a dialog box under windows with YES/NO buttons. When yes is clicked it return 0 other it returns 1. Le jeudi 07 juin 2007 ? 08:11 -0400, Uncle George a ?crit : > your suggestion appears good. I dont know what displayDialogBox exactly > will do, so all I can say it that it looks good. > > But I'd like to wait 10min before first dialog box And a 5 min wait for > every dialog box there after. And since these are custom > solution/choices, maybe a more exact explanation of what the issue is. > > if(errorCount++ < 300){ // wait 10min ( 10min * 60sec / 2 ) > Sleep( 20 ); /* make a small pause to execute all other requests > in all other threads */ > continue; > } > > if(displayDialogBox("Printer has Paused. Retry sending data?")){ > errorCount = 150; // Wait for 5 min thereafter > continue; > } > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > > yves pielusenet wrote: > > Maybe in my case I should re-compile rxtx and change the code. Instead > > of send an exception I should display a dialog box to ask if it's > > printer problem or if it should trie to send bytes. Something like : > > > > while( count > 0 ){ > > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > > /* > > this are 20 * 2 seconds, in this time a printer (or other parallel device) > > should solv all problems like buffer full, etc > > */ > > if(errorCount++ < 20){ > > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > > continue; > > } > > > > if(displayDialogBox("Try again to send datas ??")){ > > errorCount = 0; > > } > > else{ > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > } > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 07:41:43 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 09:41:43 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181222241.3501.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <4667F5FF.8070903@gatworks.com> <1181222241.3501.20.camel@localhost.localdomain> Message-ID: <46680B17.8050109@gatworks.com> yves pielusenet wrote: > thank you :) > 'displayDialogBox()' I think doesn't exist. It was just for the > example :) too bad. Good luck. From rtrout at webbresearch.com Thu Jun 7 11:23:04 2007 From: rtrout at webbresearch.com (Robert Trout) Date: Thu, 07 Jun 2007 13:23:04 -0400 Subject: [Rxtx] Disconnected PortServer TS causes Java to hang Message-ID: <1181236984.14186.33.camel@sisyphus.DinkumSoftware.com> I'm running Linux with sun's Java 1.4.2, Java comm API 2.0, RXTX 2.0-7pre1, and the RealPort digi driver. "/dev/ttyrp00" is a RealPort device. My Java application never returns from a ComPortIdentifier.getPortIdentifier("/dev/ttyrp00") call while the Digi PortServer TS 4 is disconnected from the network. If I later re-connect the PortServer, the call returns about 30 seconds later (it's like a serial port read or write is blocking until the PortServer is re- connected). With the PortServer disconnected, minicom immediately responds with "cannot open /dev/ttyrp00: No such file or directory". I would like my Java application to behave similarly. That is, respond with an error condition instead of hanging when the PortServer is not connected. Since minicom and Java behave differently, I think this "hanging" behavior may be due to RXTX or Java? Has anyone had a similar issue? Solutions? Suggestions? Thanks, Robert From vicnevicne at gmail.com Thu Jun 7 12:16:02 2007 From: vicnevicne at gmail.com (Vicne) Date: Thu, 07 Jun 2007 20:16:02 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181204864.3501.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> Message-ID: <46684B62.7080802@gmail.com> yves pielusenet wrote: > Maybe in my case I should re-compile rxtx and change the code. Instead > of send an exception I should display a dialog box to ask if it's > printer problem or if it should trie to send bytes. Something like : > > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > > if(displayDialogBox("Try again to send datas ??")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > } > Sorry to step in without a specific solution to your problem, but I wanted to share my feeling regarding this proposal. AFAIK, it's generally considered bad practice to pop-up a prompt from a library. The main reason is that in general use, you can't guarantee that someone is actually present behind the console. Imagine a print server in a machine room, connected to a park of printers. In that case, when one printer fails, the logical behaviour would be to use an other one. If you change RxTx the way you propose, the printer queue will simply be stuck with a useless "Try again to send data ?" prompt until an administrator opens a remote connection to the print server's console and clicks "no". Second, it would create a dependency upon the existence of a graphical console (if you go the graphical "dialogBox" way). On many applications (typically server or embedded ones), the JVM is "headless" and if you try to pop-up a dialog, your app would throw an exception (at best) or just wouldn't display the prompt anywhere... Going the "text console" way is not more reliable, because on graphical environments, the text console is hidden unless explicitly requested. My advice would be to think again and find another solution. Ideas are : - make the number of retries a parameter so that you can tune it to what you think is reasonable - throw a more specific exception when the number of retries has been reached, so that a specific prompt can be shown at a higher level Anyway, if you feel that the prompt is the way to go in your case, I would at least make that prompt conditional. The least intrusive way would probably be using a system property, like if("true".equals(System.getProperty("org.rxtx.usePrompt")) && displayDialogBox("Retry sending data ?")){ errorCount = 0; } else{ throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } By default, the behaviour would remain as it is now, but you could force the prompts by defining the property at VM launch if desired. (for example : java.exe -Dorg.rxtx.usePrompt=true myApp) Also, you seemed to say you wanted the printer to start again exactly where is stopped. It would indeed be the best way when the printer is put offline for a few seconds. On the other hand, if the printer is turned off (or the printer runs out of paper, or someone steps on the mains cable), then the only way to go back to a "stable" situation would be by printing the item (page, label, etc.) again from scratch... Just my two cents. Vicne PS : By the way, the dialog box thing is very platform dependant on the C-side, and I think the simplest way would probably be to bridge it to a Java call where you can implement it like you proposed : public boolean displayDialogBox(prompt) { return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); } From netbeans at gatworks.com Thu Jun 7 14:08:24 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 16:08:24 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46684B62.7080802@gmail.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> Message-ID: <466865B8.4060004@gatworks.com> My feeling is that the code that was suggested was for his environs ( his shop ). The issue here is that after a 40+ second wait, an exception will be thrown. But you really dont have a way of 'cancelling' all the WriteFiles() that have already occured before the exception so that your writeArray and the Commapi can backtrack to a position in which they are in sync. The main ( really mine ) concern is not to lose data, or replicate data. After 40seconds, 300 seconds, 55min, no matter how long, data should not be lost or duplicated. But as soon as the exception is thrown, that possibility exists. Maybe an event should be thrown instead? Vicne wrote: > yves pielusenet wrote: >> Maybe in my case I should re-compile rxtx and change the code. Instead >> of send an exception I should display a dialog box to ask if it's >> printer problem or if it should trie to send bytes. Something like : >> >> while( count > 0 ){ >> if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ >> /* >> this are 20 * 2 seconds, in this time a printer (or other parallel device) >> should solv all problems like buffer full, etc >> */ >> if(errorCount++ < 20){ >> Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ >> continue; >> } >> >> if(displayDialogBox("Try again to send datas ??")){ >> errorCount = 0; >> } >> else{ >> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >> break; >> } >> } >> > > Sorry to step in without a specific solution to your problem, but I > wanted to share my feeling regarding this proposal. AFAIK, it's > generally considered bad practice to pop-up a prompt from a library. > The main reason is that in general use, you can't guarantee that > someone is actually present behind the console. Imagine a print server > in a machine room, connected to a park of printers. In that case, when > one printer fails, the logical behaviour would be to use an other one. > If you change RxTx the way you propose, the printer queue will simply be > stuck with a useless "Try again to send data ?" prompt until an > administrator opens a remote connection to the print server's console > and clicks "no". > Second, it would create a dependency upon the existence of a > graphical console (if you go the graphical "dialogBox" way). On many > applications (typically server or embedded ones), the JVM is "headless" > and if you try to pop-up a dialog, your app would throw an exception (at > best) or just wouldn't display the prompt anywhere... Going the "text > console" way is not more reliable, because on graphical environments, > the text console is hidden unless explicitly requested. > > My advice would be to think again and find another solution. Ideas are : > - make the number of retries a parameter so that you can tune it to what > you think is reasonable > - throw a more specific exception when the number of retries has been > reached, so that a specific prompt can be shown at a higher level > > Anyway, if you feel that the prompt is the way to go in your case, I > would at least make that prompt conditional. The least intrusive way > would probably be using a system property, like > > if("true".equals(System.getProperty("org.rxtx.usePrompt")) > && displayDialogBox("Retry sending data ?")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > > > By default, the behaviour would remain as it is now, but you could > force the prompts by defining the property at VM launch if desired. (for > example : java.exe -Dorg.rxtx.usePrompt=true myApp) > > > Also, you seemed to say you wanted the printer to start again > exactly where is stopped. It would indeed be the best way when the > printer is put offline for a few seconds. On the other hand, if the > printer is turned off (or the printer runs out of paper, or someone > steps on the mains cable), then the only way to go back to a "stable" > situation would be by printing the item (page, label, etc.) again from > scratch... > > > Just my two cents. > > > Vicne > > PS : By the way, the dialog box thing is very platform dependant on the > C-side, and I think the simplest way would probably be to bridge it to a > Java call where you can implement it like you proposed : > > public boolean displayDialogBox(prompt) { > return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", > JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); > } > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Thu Jun 7 17:48:11 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 Jun 2007 17:48:11 -0600 (MDT) Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <466865B8.4060004@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> Message-ID: An event is possible. I'm amazed this is the largest problem encountered while using the parallel code. How would the write ever exit if we throw events? Isn't this going to lead to hung applications? On Thu, 7 Jun 2007, Uncle George wrote: > My feeling is that the code that was suggested was for his environs ( > his shop ). > > The issue here is that after a 40+ second wait, an exception will be > thrown. But you really dont have a way of 'cancelling' all the > WriteFiles() that have already occured before the exception so that your > writeArray and the Commapi can backtrack to a position in which they are > in sync. > > The main ( really mine ) concern is not to lose data, or replicate data. > After 40seconds, 300 seconds, 55min, no matter how long, data should > not be lost or duplicated. But as soon as the exception is thrown, that > possibility exists. > > Maybe an event should be thrown instead? > > Vicne wrote: >> yves pielusenet wrote: >>> Maybe in my case I should re-compile rxtx and change the code. Instead >>> of send an exception I should display a dialog box to ask if it's >>> printer problem or if it should trie to send bytes. Something like : >>> >>> while( count > 0 ){ >>> if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ >>> /* >>> this are 20 * 2 seconds, in this time a printer (or other parallel device) >>> should solv all problems like buffer full, etc >>> */ >>> if(errorCount++ < 20){ >>> Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ >>> continue; >>> } >>> >>> if(displayDialogBox("Try again to send datas ??")){ >>> errorCount = 0; >>> } >>> else{ >>> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >>> break; >>> } >>> } >>> >> >> Sorry to step in without a specific solution to your problem, but I >> wanted to share my feeling regarding this proposal. AFAIK, it's >> generally considered bad practice to pop-up a prompt from a library. >> The main reason is that in general use, you can't guarantee that >> someone is actually present behind the console. Imagine a print server >> in a machine room, connected to a park of printers. In that case, when >> one printer fails, the logical behaviour would be to use an other one. >> If you change RxTx the way you propose, the printer queue will simply be >> stuck with a useless "Try again to send data ?" prompt until an >> administrator opens a remote connection to the print server's console >> and clicks "no". >> Second, it would create a dependency upon the existence of a >> graphical console (if you go the graphical "dialogBox" way). On many >> applications (typically server or embedded ones), the JVM is "headless" >> and if you try to pop-up a dialog, your app would throw an exception (at >> best) or just wouldn't display the prompt anywhere... Going the "text >> console" way is not more reliable, because on graphical environments, >> the text console is hidden unless explicitly requested. >> >> My advice would be to think again and find another solution. Ideas are : >> - make the number of retries a parameter so that you can tune it to what >> you think is reasonable >> - throw a more specific exception when the number of retries has been >> reached, so that a specific prompt can be shown at a higher level >> >> Anyway, if you feel that the prompt is the way to go in your case, I >> would at least make that prompt conditional. The least intrusive way >> would probably be using a system property, like >> >> if("true".equals(System.getProperty("org.rxtx.usePrompt")) >> && displayDialogBox("Retry sending data ?")){ >> errorCount = 0; >> } >> else{ >> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >> break; >> } >> >> >> By default, the behaviour would remain as it is now, but you could >> force the prompts by defining the property at VM launch if desired. (for >> example : java.exe -Dorg.rxtx.usePrompt=true myApp) >> >> >> Also, you seemed to say you wanted the printer to start again >> exactly where is stopped. It would indeed be the best way when the >> printer is put offline for a few seconds. On the other hand, if the >> printer is turned off (or the printer runs out of paper, or someone >> steps on the mains cable), then the only way to go back to a "stable" >> situation would be by printing the item (page, label, etc.) again from >> scratch... >> >> >> Just my two cents. >> >> >> Vicne >> >> PS : By the way, the dialog box thing is very platform dependant on the >> C-side, and I think the simplest way would probably be to bridge it to a >> Java call where you can implement it like you proposed : >> >> public boolean displayDialogBox(prompt) { >> return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", >> JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); >> } >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 19:18:51 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 21:18:51 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> Message-ID: <4668AE7B.3060409@gatworks.com> The UNIX version of writeArray is not too great either. It is possible that the write will only process some of the bytes. #else if( write( fd, bytes, count ) < 0 ) throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); #endif -------------------------------- Maybe it might be better to have the native function inform the caller of the # of characters written, then the commapi/output-buffer can be modified to reflect the #of chars written. If an exception is to be thrown, for too many loops of chars written == 0, then exception wont affect the state of the output buffer. Then a ParallelPort.restart() can be called to resume printing whats in the buffer. Trent Jarvi wrote: > An event is possible. I'm amazed this is the largest problem encountered > while using the parallel code. > > How would the write ever exit if we throw events? Isn't this going to > lead to hung applications? Sure. If you dont time out, then there is nothing that will force an EXIT from the write(). Issue is what has the OS done with the write. > > On Thu, 7 Jun 2007, Uncle George wrote: > >> My feeling is that the code that was suggested was for his environs ( >> his shop ). From yvespielusenet at free.fr Fri Jun 8 01:09:01 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Fri, 08 Jun 2007 09:09:01 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4668AE7B.3060409@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> Message-ID: <1181286541.3674.10.camel@localhost.localdomain> It is not possible that the rxtx java method write(byte[], int offset, int length) return anint which contains the number of byte really send to the printer instead of an exception ? So this is the programm which will see if all bytes have been sent. If not it can retry to send the unsended bytes. -------------------------------------------------------- int sended = 0; while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ sended += countWritten; /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } return sended; /*throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break;*/ } ... ... return countWritten; ------------------------------------------------ Le jeudi 07 juin 2007 ? 21:18 -0400, Uncle George a ?crit : > The UNIX version of writeArray is not too great either. It is possible > that the write will only process some of the bytes. > > #else > if( write( fd, bytes, count ) < 0 ) > throw_java_exception_system_msg( env, IO_EXCEPTION, > "writeArray" ); > #endif > -------------------------------- > > Maybe it might be better to have the native function inform the caller > of the # of characters written, then the commapi/output-buffer can be > modified to reflect the #of chars written. If an exception is to be > thrown, for too many loops of chars written == 0, then exception wont > affect the state of the output buffer. Then a ParallelPort.restart() can > be called to resume printing whats in the buffer. > > > Trent Jarvi wrote: > > An event is possible. I'm amazed this is the largest problem encountered > > while using the parallel code. > > > > How would the write ever exit if we throw events? Isn't this going to > > lead to hung applications? > Sure. If you dont time out, then there is nothing that will force an > EXIT from the write(). Issue is what has the OS done with the write. > > > > On Thu, 7 Jun 2007, Uncle George wrote: > > > >> My feeling is that the code that was suggested was for his environs ( > >> his shop ). > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Fri Jun 8 03:45:00 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 11:45:00 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181286541.3674.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> Message-ID: <20070608094500.GC21069@elberon.bln.de.ingenico.com> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > It is not possible that the rxtx java method write(byte[], int offset, > int length) return anint which contains the number of byte really send > to the printer instead of an exception ? > So this is the programm which will see if all bytes have been sent. If > not it can retry to send the unsended bytes. I think write() is void because in Java people love to do this since OutputStream :-) Of course on such interfaces you cannot implement something nice. If you would have a int write, you would not implement the interface and no applications expecting this interface would link/work/compile. oki, Steffen P.S.: (OT) If you propose not to implement the Java interfaces (especially not on JNI level), maybe optionally offering a wrapper that removes e.g. the write return value and so on to downgrade the powerful classic old POSIX read/write style to the modern limited Java style, then I agree :-) Same for read. Instead of things like "int avialable()" it is more powerful to have an approach as select(2) offers (to guarante the caller that read/write will not block [nothing else make sense anyway IMHO] but may read/write less bytes then requested). The caller gets full control and the higher level protocols can care about timeouts, invoking read in some loops and/or implement retransmission. On top of such an implementation, where everything is controlled, defined, guaranteed and reliable, someone could use an InputStream or OutputStream style interface. Or even better: don't use them at all :) just BTW :-) St. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From yvespielusenet at free.fr Fri Jun 8 05:52:45 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Fri, 08 Jun 2007 13:52:45 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <20070608094500.GC21069@elberon.bln.de.ingenico.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> Message-ID: <1181303565.11203.3.camel@localhost.localdomain> So maybe a better way should be to create a new Exception class which has a method "int getWrittenByte()". So the Exception should be use to send again bytes which are not printed yet. yves Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : > * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > > It is not possible that the rxtx java method write(byte[], int offset, > > int length) return anint which contains the number of byte really send > > to the printer instead of an exception ? > > So this is the programm which will see if all bytes have been sent. If > > not it can retry to send the unsended bytes. > > I think write() is void because in Java people love to do this > since OutputStream :-) Of course on such interfaces you cannot > implement something nice. If you would have a int write, you > would not implement the interface and no applications expecting > this interface would link/work/compile. > > oki, > > Steffen > > P.S.: (OT) > If you propose not to implement the Java interfaces (especially > not on JNI level), maybe optionally offering a wrapper that > removes e.g. the write return value and so on to downgrade the > powerful classic old POSIX read/write style to the modern limited > Java style, then I agree :-) Same for read. Instead of things > like "int avialable()" it is more powerful to have an approach as > select(2) offers (to guarante the caller that read/write will not > block [nothing else make sense anyway IMHO] but may read/write > less bytes then requested). The caller gets full control and the > higher level protocols can care about timeouts, invoking read in > some loops and/or implement retransmission. On top of such an > implementation, where everything is controlled, defined, > guaranteed and reliable, someone could use an InputStream or > OutputStream style interface. Or even better: don't use them at > all :) just BTW :-) > St. > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > 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. > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > 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. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Fri Jun 8 06:46:21 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 08:46:21 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181303565.11203.3.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> Message-ID: <46694F9D.5080501@gatworks.com> It seems that with outputstream.write(b[]), you become terribly uncoordinated as soon as an exception is thrown. Docs do not say what happens to the data. Yet from a practicable point of view, one would like to know if the write was accepted in-full, or rejected before any writes. There are no in betweens, as partial writes are not reportable. So for an outputstream.write(), in order for it to return, the full write request has to be taken, and stored in an internal output buffer. If there is no room, the write() is suspended, till there is room. Or throw's an IOException( "no room in buffer") ; As the select() loop for write reports buffer room avail, then more of the internal buffer is sent to the printer. yves pielusenet wrote: > So maybe a better way should be to create a new Exception class which > has a method "int getWrittenByte()". So the Exception should be use to > send again bytes which are not printed yet. > > yves > > Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : >> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: >>> It is not possible that the rxtx java method write(byte[], int offset, >>> int length) return anint which contains the number of byte really send >>> to the printer instead of an exception ? >>> So this is the programm which will see if all bytes have been sent. If >>> not it can retry to send the unsended bytes. >> I think write() is void because in Java people love to do this >> since OutputStream :-) Of course on such interfaces you cannot >> implement something nice. If you would have a int write, you >> would not implement the interface and no applications expecting >> this interface would link/work/compile. >> >> oki, >> >> Steffen >> >> P.S.: (OT) >> If you propose not to implement the Java interfaces (especially >> not on JNI level), maybe optionally offering a wrapper that >> removes e.g. the write return value and so on to downgrade the >> powerful classic old POSIX read/write style to the modern limited >> Java style, then I agree :-) Same for read. Instead of things >> like "int avialable()" it is more powerful to have an approach as >> select(2) offers (to guarante the caller that read/write will not >> block [nothing else make sense anyway IMHO] but may read/write >> less bytes then requested). The caller gets full control and the >> higher level protocols can care about timeouts, invoking read in >> some loops and/or implement retransmission. On top of such an >> implementation, where everything is controlled, defined, >> guaranteed and reliable, someone could use an InputStream or >> OutputStream style interface. Or even better: don't use them at >> all :) just BTW :-) >> St. >> >> About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. >> 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. >> >> About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. >> 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. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From Steffen.DETTMER at ingenico.com Fri Jun 8 08:12:18 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 16:12:18 +0200 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <46694F9D.5080501@gatworks.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: <20070608141218.GE21069@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 08:46 -0400: > It seems that with outputstream.write(b[]), you become terribly > uncoordinated as soon as an exception is thrown. Docs do not say what > happens to the data. (yes, so avoiding it seems to be good :)) > Yet from a practicable point of view, one would like to know if the > write was accepted in-full, or rejected before any writes. There are no > in betweens, as partial writes are not reportable. (which is an artificial API limitation. I never understood how this happend when they invented JDK because the well-known BSD socket API and thus [probably] WinSock does this correct, but anyway) > So for an outputstream.write(), in order for it to return, the full > write request has to be taken, and stored in an internal output buffer. > If there is no room, the write() is suspended, till there is room. Or > throw's an IOException( "no room in buffer") ; As the select() loop for > write reports buffer room avail, then more of the internal buffer is > sent to the printer. yes, might be good in case of a printer. May be horrible in case of PPP/TCP or some other transmission control protocol which may e.g. repeat data or even omit parts of it (e.g. internet realtime radio station broadcasting)... So I think the idea of "int write" (e.g. BSD sockets, linux files and so on) still is the best. A clean API / implementation should guarantee and allow implementations (users) to rely on that; assumptions and automatic background-sending and so on may look pragmatic and may even work on the first look, but may fail in other situations. BTW, if e.g. BSD socket API is known, why not simply copy it (until something better is invented :)) instead of fiddling around with JDK APIs? anyway, have a nice weekend everyone :-) oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Fri Jun 8 08:55:56 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 10:55:56 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070608141218.GE21069@elberon.bln.de.ingenico.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> Message-ID: <46696DFC.7000801@gatworks.com> >> write reports buffer room avail, then more of the internal buffer is >> sent to the printer. > > yes, might be good in case of a printer. May be horrible in case > of PPP/TCP or some other transmission control protocol which > may e.g. repeat data or even omit parts of it (e.g. internet > realtime radio station broadcasting)... So I think the idea of > "int write" (e.g. BSD sockets, linux files and so on) still is > the best. A clean API / implementation should guarantee and allow > implementations (users) to rely on that; assumptions and > automatic background-sending and so on may look pragmatic and may > even work on the first look, but may fail in other situations. > BTW, if e.g. BSD socket API is known, why not simply copy it > (until something better is invented :)) instead of fiddling > around with JDK APIs? But we were talking about the Parallel Port, and the transmission of data over the commapi/parallel-port schema. There isn't much in bi-directional software communication. Its a simple write one byte at a time interface. I'm not looking to change the comm-api. I'm just looking to alter the interaction between the Native ParallelPort functions, and the java ParallelPort functions that call them. This might be more readily doable than to get a committee to re-specify java-API specs. BTW: Whats is off-topic? ( help: not looking for def of off-topic ) From j.kenneth.gentle at acm.org Fri Jun 8 08:58:59 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Fri, 08 Jun 2007 10:58:59 -0400 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <20070608141218.GE21069@elberon.bln.de.ingenico.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> Message-ID: <200706081459.l58Ex5rA019991@qbang.org> Perhaps it is a bit late to jump in on this one, but here goes anyway. If the solutions all seem to "break" the contract with "java.io.outputstream", then, as noted, that may not be the appropriate contract. At the risk of being heretical, JDK1.4 introduced the "nio" package to address some of the compatibility issues with C apis mentioned in previous posts. The interface "java.nio.channels.WriteableByteChannel" defines the following single method: int write(ByteBuffer source); int, strangely enough, is the actual number of bytes written. So, if RXTX as written, against the JavaCOMM api and OutputStream, doesn't do what we want, how about writing a different set of bindings using the java.nio classes and as much of the underlying native code as possible. Note that just because the java.nio.channels.WriteableByteChannel sends back a result, OutputStream.write doesn't have to - and they could both call the same underlying native code. My 2 cents - maybe not worth even that... Ken From netbeans at gatworks.com Fri Jun 8 10:37:28 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 12:37:28 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <200706081459.l58Ex5rA019991@qbang.org> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> Message-ID: <466985C8.8000505@gatworks.com> Ken Gentle wrote: > Perhaps it is a bit late to jump in on this one, but here goes anyway. Common in, the waters fine. > > If the solutions all seem to "break" the contract with > "java.io.outputstream", then, as noted, that may not be the > appropriate contract. > How would the contract be broken? The machinery underneath is handling the contract. From j.kenneth.gentle at acm.org Fri Jun 8 10:48:01 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Fri, 08 Jun 2007 12:48:01 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466985C8.8000505@gatworks.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> Message-ID: <200706081648.l58Gm7YA022904@qbang.org> At 12:37 2007-06-08, you wrote: >Ken Gentle wrote: > > > > If the solutions all seem to "break" the contract with > > "java.io.outputstream", then, as noted, that may not be the > > appropriate contract. > > >How would the contract be broken? The machinery underneath is handling >the contract. It seems that a lot of the discussion has been about not only the timeout and being able to adjust it in the "machinery layer", but also about knowing in the Java layer, in the event of a timeout or exception, how many characters have been written to the device. An OutputStream won't ever do this with out an extension and including a return value "breaks" the contract, right? So, go with a Java IO api that *does* return the number of bytes written, out of the NIO package. I know it doesn't allow for a strict implementation of the JavaCOMM API - however, using NIO classes in place of the IO classes isn't that big a break and would allow those applications that need such information a way to get it. Maybe I'm misunderstanding the problem... Ken From netbeans at gatworks.com Fri Jun 8 11:24:14 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 13:24:14 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <200706081648.l58Gm7YA022904@qbang.org> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> Message-ID: <466990BE.7040100@gatworks.com> Ken Gentle wrote: An > OutputStream won't ever do this with out an extension and including a > return value "breaks" the contract, right? > i was not thinking of change the API to OutputSream. Are there specs for how output stream should work internally? for instance: String data = "Hello this is a line of data"; Outputstream.write( data.getbytes() ); ParallelPort.suspend(); int free = ParallelPort.getoutputbufferfree(); There is a symbiotic relationship between outputstream and the functionality of ParallelPort. From Steffen.DETTMER at ingenico.com Fri Jun 8 11:15:39 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 19:15:39 +0200 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <200706081459.l58Ex5rA019991@qbang.org> References: <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> Message-ID: <20070608171539.GK21069@elberon.bln.de.ingenico.com> * Ken Gentle wrote on Fri, Jun 08, 2007 at 10:58 -0400: > If the solutions all seem to "break" the contract with > "java.io.outputstream", then, as noted, that may not be the > appropriate contract. > > At the risk of being heretical, JDK1.4 introduced the "nio" package > to address some of the compatibility issues with C apis mentioned in > previous posts. The interface > "java.nio.channels.WriteableByteChannel" defines the following single method: > > int write(ByteBuffer source); > > int, strangely enough, is the actual number of bytes written. Yes, AFAIK one of the motivations for the NIO interface was, that the JDK-1.3 APIs (InputStream, e.g.) were not powerfull enough, especially for multi-connection-TCP servers or so. I don't know much about it but I've heard of a project where NIO usage was removed because of stability issues in multi-threaded environments and performance limitations under some circumstances. IIRC the "nio.ByteBuffer" is something very special (namely something you cannot implement in Java, it is "magic" or part of the language itself). Not sure if this is such a great idea (but for performance in the end sometimes heavy prices must be paid) :) > So, if RXTX as written, against the JavaCOMM api and OutputStream, > doesn't do what we want, how about writing a different set of > bindings using the java.nio classes and as much of the underlying > native code as possible. Yes, this would be an idea: use a full-featured interface on JNI, and, if wanted, deliver some wrappers converting this to a less-featured Java-compliant interface. However, powerful things as e.g. "select" are difficult to "emulate" if you are e.g. on some (older?) windows. But if you expose the full-featured APIs, you need to emulate them full-featured, theoretically. In the end it depends what you do on the serial line. If you just want to talk to a modem, then you may not need precise timeouts. But if you need to implement complexer protocols which define response times and timeouts, you may quickly get into difficulties. For instance, AFAIK, rxtx 1.7.2 (?) for windows is very messy with timeouts (there is a maximum, higher values are truncated; resolution is 100ms only; the function may take up to twice the timeout because internally it may be called twice). Probably for most people this is OK, but probably not for all. But having precise timeouts should be OK for all :-) Well, in the end it is nice to wish but somewhat hard to implement (many platforms, connections, USB, BlueTooth, whatever). oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Steffen.DETTMER at ingenico.com Fri Jun 8 11:04:22 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 19:04:22 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <46696DFC.7000801@gatworks.com> References: <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <46696DFC.7000801@gatworks.com> Message-ID: <20070608170422.GJ21069@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 10:55 -0400: > > BTW, if e.g. BSD socket API is known, why not simply copy it > > (until something better is invented :)) instead of fiddling > > around with JDK APIs? > > But we were talking about the Parallel Port, and the > transmission of data over the commapi/parallel-port schema. > There isn't much in bi-directional software communication. Its > a simple write one byte at a time interface. First, there are things like PLIP (http://en.wikipedia.org/wiki/Plip) - well, probably not widely used, sure ;) Second, I think if there is a good simple API known to support all that (with known "best practices") or so and there is no forcing need to invent a new one, why not simply using it? > I'm not looking to change the comm-api. I'm just looking to > alter the interaction between the Native ParallelPort > functions, and the java ParallelPort functions that call them. Ahh, yes. I think this is what I tried to ask. Having an usable JNI interface and on top (in pure java) some wrapper to InputStream or whatever could be done (e.g. by ignoring the return value of write or throwing if != length). Developers could then use the full-featured (non-JAVA-standard) API or select among various wrappers (as InputStream). > This might be more readily doable than to get a committee to > re-specify java-API specs. Yes, of course. I'm afraid that the Java APIs change regularily, but still yet with limited success it seems, so maybe they get it in one of the next iterations; who knows, maybe Java-9 has a BSD-like socket API :) SCNR. > BTW: Whats is off-topic? ( help: not looking for def of > off-topic ) I think I started some "re-specify java-API specs" which was OT probably. oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From lists at iDIAcomputing.com Fri Jun 8 18:48:54 2007 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Fri, 08 Jun 2007 20:48:54 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46684B62.7080802@gmail.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> Message-ID: <4669F8F6.3040101@iDIAcomputing.com> Vicne wrote: > Sorry to step in without a specific solution to your problem, but I > wanted to share my feeling regarding this proposal. AFAIK, it's > generally considered bad practice to pop-up a prompt from a library. ... > > My advice would be to think again and find another solution. Ideas are : > - make the number of retries a parameter so that you can tune it to what > you think is reasonable > - throw a more specific exception when the number of retries has been > reached, so that a specific prompt can be shown at a higher level You could also allow the client code to register a callback class which returns a boolean indicating whether to retry or cancel. This callback class could pop up a dialog, if appropriate, or follow some preset policy, or.... - George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From joachim at buechse.ch Sat Jun 9 09:43:16 2007 From: joachim at buechse.ch (Joachim Buechse) Date: Sat, 9 Jun 2007 17:43:16 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46694F9D.5080501@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: You should not forget, that in the case of an exception it may not even be known what happened to the data. You have a kernel buffer, outgoing chip buffer, incoming chip buffer, etc. So of course, it would be nice to know up to which point data was correctly processed, but this feedback does not exist on the hardware or protocol level and hence can in general not be magicly created on the software level... Regards, Joachim On 08.06.2007, at 14:46, Uncle George wrote: > It seems that with outputstream.write(b[]), you become terribly > uncoordinated as soon as an exception is thrown. Docs do not say what > happens to the data. > > Yet from a practicable point of view, one would like to know if the > write was accepted in-full, or rejected before any writes. There > are no > in betweens, as partial writes are not reportable. > > So for an outputstream.write(), in order for it to return, the full > write request has to be taken, and stored in an internal output > buffer. > If there is no room, the write() is suspended, till there is room. Or > throw's an IOException( "no room in buffer") ; As the select() loop > for > write reports buffer room avail, then more of the internal buffer is > sent to the printer. > > > > yves pielusenet wrote: >> So maybe a better way should be to create a new Exception class which >> has a method "int getWrittenByte()". So the Exception should be >> use to >> send again bytes which are not printed yet. >> >> yves >> >> Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : >>> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: >>>> It is not possible that the rxtx java method write(byte[], int >>>> offset, >>>> int length) return anint which contains the number of byte >>>> really send >>>> to the printer instead of an exception ? >>>> So this is the programm which will see if all bytes have been >>>> sent. If >>>> not it can retry to send the unsended bytes. >>> I think write() is void because in Java people love to do this >>> since OutputStream :-) Of course on such interfaces you cannot >>> implement something nice. If you would have a int write, you >>> would not implement the interface and no applications expecting >>> this interface would link/work/compile. >>> >>> oki, >>> >>> Steffen >>> >>> P.S.: (OT) >>> If you propose not to implement the Java interfaces (especially >>> not on JNI level), maybe optionally offering a wrapper that >>> removes e.g. the write return value and so on to downgrade the >>> powerful classic old POSIX read/write style to the modern limited >>> Java style, then I agree :-) Same for read. Instead of things >>> like "int avialable()" it is more powerful to have an approach as >>> select(2) offers (to guarante the caller that read/write will not >>> block [nothing else make sense anyway IMHO] but may read/write >>> less bytes then requested). The caller gets full control and the >>> higher level protocols can care about timeouts, invoking read in >>> some loops and/or implement retransmission. On top of such an >>> implementation, where everything is controlled, defined, >>> guaranteed and reliable, someone could use an InputStream or >>> OutputStream style interface. Or even better: don't use them at >>> all :) just BTW :-) >>> St. >>> >>> About Ingenico Throughout the world businesses rely on Ingenico >>> for secure and expedient electronic transaction acceptance. >>> Ingenico products leverage proven technology, established >>> standards and unparalleled ergonomics to provide optimal >>> reliability, versatility and usability. This comprehensive range >>> of products is complemented by a global array of services and >>> partnerships, enabling businesses in a number of vertical sectors >>> to accept transactions anywhere their business takes them. >>> 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. >>> >>> About Ingenico Throughout the world businesses rely on Ingenico >>> for secure and expedient electronic transaction acceptance. >>> Ingenico products leverage proven technology, established >>> standards and unparalleled ergonomics to provide optimal >>> reliability, versatility and usability. This comprehensive range >>> of products is complemented by a global array of services and >>> partnerships, enabling businesses in a number of vertical sectors >>> to accept transactions anywhere their business takes them. >>> 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. >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx 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 yvespielusenet at free.fr Mon Jun 11 03:15:12 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Mon, 11 Jun 2007 11:15:12 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: <1181553312.8335.14.camel@localhost.localdomain> So can someone tell a solution for my problem :( Must I say to the user to not put the printer off-line ? I can't since he has to do some pauses, verify print, paper conditioning etc... How do other people ? Before I use the parport librarry to read port status : http://www.geocities.com/Juanga69/parport/ (which doesn't work on windows XP) And I send data into the file LPT1 I use to have no problem when printer was disabled. thanks -- yves piel Le samedi 09 juin 2007 ? 17:43 +0200, Joachim Buechse a ?crit : > You should not forget, that in the case of an exception it may not > even be known what happened to the data. > > You have a kernel buffer, outgoing chip buffer, incoming chip buffer, > etc. So of course, it would be nice to know up to which point data > was correctly processed, but this feedback does not exist on the > hardware or protocol level and hence can in general not be magicly > created on the software level... > > Regards, > Joachim > > On 08.06.2007, at 14:46, Uncle George wrote: > > > It seems that with outputstream.write(b[]), you become terribly > > uncoordinated as soon as an exception is thrown. Docs do not say what > > happens to the data. > > > > Yet from a practicable point of view, one would like to know if the > > write was accepted in-full, or rejected before any writes. There > > are no > > in betweens, as partial writes are not reportable. > > > > So for an outputstream.write(), in order for it to return, the full > > write request has to be taken, and stored in an internal output > > buffer. > > If there is no room, the write() is suspended, till there is room. Or > > throw's an IOException( "no room in buffer") ; As the select() loop > > for > > write reports buffer room avail, then more of the internal buffer is > > sent to the printer. > > > > > > > > yves pielusenet wrote: > >> So maybe a better way should be to create a new Exception class which > >> has a method "int getWrittenByte()". So the Exception should be > >> use to > >> send again bytes which are not printed yet. > >> > >> yves > >> > >> Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : > >>> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > >>>> It is not possible that the rxtx java method write(byte[], int > >>>> offset, > >>>> int length) return anint which contains the number of byte > >>>> really send > >>>> to the printer instead of an exception ? > >>>> So this is the programm which will see if all bytes have been > >>>> sent. If > >>>> not it can retry to send the unsended bytes. > >>> I think write() is void because in Java people love to do this > >>> since OutputStream :-) Of course on such interfaces you cannot > >>> implement something nice. If you would have a int write, you > >>> would not implement the interface and no applications expecting > >>> this interface would link/work/compile. > >>> > >>> oki, > >>> > >>> Steffen > >>> > >>> P.S.: (OT) > >>> If you propose not to implement the Java interfaces (especially > >>> not on JNI level), maybe optionally offering a wrapper that > >>> removes e.g. the write return value and so on to downgrade the > >>> powerful classic old POSIX read/write style to the modern limited > >>> Java style, then I agree :-) Same for read. Instead of things > >>> like "int avialable()" it is more powerful to have an approach as > >>> select(2) offers (to guarante the caller that read/write will not > >>> block [nothing else make sense anyway IMHO] but may read/write > >>> less bytes then requested). The caller gets full control and the > >>> higher level protocols can care about timeouts, invoking read in > >>> some loops and/or implement retransmission. On top of such an > >>> implementation, where everything is controlled, defined, > >>> guaranteed and reliable, someone could use an InputStream or > >>> OutputStream style interface. Or even better: don't use them at > >>> all :) just BTW :-) > >>> St. > >>> > >>> About Ingenico Throughout the world businesses rely on Ingenico > >>> for secure and expedient electronic transaction acceptance. > >>> Ingenico products leverage proven technology, established > >>> standards and unparalleled ergonomics to provide optimal > >>> reliability, versatility and usability. This comprehensive range > >>> of products is complemented by a global array of services and > >>> partnerships, enabling businesses in a number of vertical sectors > >>> to accept transactions anywhere their business takes them. > >>> 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. > >>> > >>> About Ingenico Throughout the world businesses rely on Ingenico > >>> for secure and expedient electronic transaction acceptance. > >>> Ingenico products leverage proven technology, established > >>> standards and unparalleled ergonomics to provide optimal > >>> reliability, versatility and usability. This comprehensive range > >>> of products is complemented by a global array of services and > >>> partnerships, enabling businesses in a number of vertical sectors > >>> to accept transactions anywhere their business takes them. > >>> 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. > >>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx 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 > From Steffen.DETTMER at ingenico.com Mon Jun 11 03:56:18 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 11:56:18 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466990BE.7040100@gatworks.com> References: <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> Message-ID: <20070611095618.GA10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 13:24 -0400: > i was not thinking of change the API to OutputSream. Then I think either someone uses OutputStream (and has no reliable information about incomplete writes) or someone uses somethink else. > Are there specs for how output stream should work internally? > > for instance: > String data = "Hello this is a line of data"; > Outputstream.write( data.getbytes() ); > ParallelPort.suspend(); > int free = ParallelPort.getoutputbufferfree(); > > There is a symbiotic relationship between outputstream and the > functionality of ParallelPort. If you need OutputStream "plus something else", in short you're needing "something else". Personally I dislike the code above a lot. The stream "looks" like if it would be an OutputStream, but in fact it isn't. You need to call getoutputbufferfree later to check if write succeeded (but OutputStream promises that write succeedes synchronous, blocking, or throws an exception). So it is not an OutputStream. No application written for OutputStreams would work without change (because it won't know getoutputbufferfree at all). It is not abstracted from ParallelPort. I think this would be wrong. Then I think an alternative interface instead is better. Let's assume we had some "connection" (to distinguish between OutputStreams and Channels). Then why not working as on a file handle in POSIX: do { // ... select maybe using timer ... readyForWrite = ... if (readyForWrite) { int writtenBytes = connection.write(toWrite); toWrite.remove(0, writtenBytes); } while(readyForWrite && toWrite.length > 0); I think, having such a write isn't the big problem. I think, the difficult thing is around "select" - however this would look like. It should be OO, typesafe, performant, supporting multiple connections/channels/streams in various modes and should be orthogonal to other functionalities. Of course, this heavily depends on what the application is doing; for a simple situation (like reading a small, mandatory file from a local disk) this would be to uncomfortable (and offering unneeded features only). just BTW :) oki, Steffen -- // Modeline for VIM. Please don't remove. // (Help: autoindent, expandtab, shiftwidth=4, tabstop=4, textwidth=75) // vi: set ai et sw=4 ts=4 tw=75 ft=java: About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Mon Jun 11 05:38:33 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 07:38:33 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611095618.GA10821@elberon.bln.de.ingenico.com> References: <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> Message-ID: <466D3439.4020805@gatworks.com> Steffen DETTMER wrote: > (but OutputStream promises that write > succeedes synchronous, blocking, or throws an exception). Where is it so written? From Steffen.DETTMER at ingenico.com Mon Jun 11 06:36:50 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 14:36:50 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466D3439.4020805@gatworks.com> References: <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> <466D3439.4020805@gatworks.com> Message-ID: <20070611123650.GI10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Mon, Jun 11, 2007 at 07:38 -0400: > Steffen DETTMER wrote: > > > (but OutputStream promises that write > > succeedes synchronous, blocking, or throws an exception). > > Where is it so written? Now, as you ask, I think it is not written that clearly but follows from specification. mmm... Am I wrong? I understand the API doc in this way: * http://java.sun.com/j2se/1.4.2/docs/api/java/io/OutputStream.html#write(byte[]) > public void write(byte[] b) > throws IOException > > Writes b.length bytes from the specified byte array to this > output stream. The general contract for write(b) is that > it should have exactly the same effect as the call write(b, > 0, b.length). > > Parameters: > b - the data. > Throws: > IOException - if an I/O error occurs. > See Also: > write(byte[], int, int) and there is: > public void write(byte[] b, > int off, > int len) > throws IOException > > Writes len bytes from the specified byte array starting at > offset off to this output stream. The general contract for > write(b, off, len) is that some of the bytes in the array b > are written to the output stream in order; element b[off] > is the first byte written and b[off+len-1] is the last byte > written by this operation. > > The write method of OutputStream calls the write method of > one argument on each of the bytes to be written out. > Subclasses are encouraged to override this method and > provide a more efficient implementation. > > If b is null, a NullPointerException is thrown. > > If off is negative, or len is negative, or off+len is > greater than the length of the array b, then an > IndexOutOfBoundsException is thrown. > > Parameters: > b - the data. > off - the start offset in the data. > len - the number of bytes to write. > Throws: > IOException - if an I/O error occurs. In particular, an > IOException is thrown if the output stream is closed. In general, any specialisation (derived child class) must comform to this. So write in the end is specified (!) as "The write method ... calls the write method ... on each of the bytes to be written out". This is what must be implemented by ANY OutputStream. Of course, there is: "Subclasses are encouraged to override this method and provide a more efficient implementation." which IMHO does not contradict - the more efficient must behave in exactly the same way of course (just wasting less resources than a simple byte-by-byte write). So it does not matter here I think. The write that finally defines the behavior tells basically: > "Writes the specified byte to this output stream. The general > contract for write is that one byte is written to the output > stream. " > > Throws: > IOException - if an I/O error occurs. which IMHO is another way of saying "write writes the byte immediately and returns on success (only), otherwise an exception is thrown". Especially it cannot happen that zero bytes are written (i.e. the specified byte is NOT written) without an exception. So by this write must be synchronous and blocking, because otherwise it could not reliably know if an asynchronous operation will succeede or not (some getAsyncResult or so would be needed). Since write(byte[]) does this for each byte (or with a behavior beeing exactly the same as if it would do), I think this means that the write(byte[]) succeedes synchronous/blocking or throws an exception. Did I an error in reasoning or confused something or so? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From j.kenneth.gentle at acm.org Mon Jun 11 06:51:25 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 11 Jun 2007 08:51:25 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611123650.GI10821@elberon.bln.de.ingenico.com> References: <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> <466D3439.4020805@gatworks.com> <20070611123650.GI10821@elberon.bln.de.ingenico.com> Message-ID: <200706111251.l5BCpS9T017831@qbang.org> It is as Steffen describes. "InputStream" and "OutputStream" are inherently synchronous (which is why so many java programs resort to threads to use them). Anything outside of this "contract" is *not* an InputStream or OutputStream. That is why there is a new package for things that don't behave like the old *Stream classes - the NIO package. If you look carefully at the IO package, you'll note that almost all the classes are _Decorator_ pattern implementations of the *Stream classes - and the interface presents the _same_ behavior to the calling code in all cases - a synchronous operation that completes successfully or throws an exception (with the one exception of "read" that returns a "-1" on end-of-stream. I know I've read this numerous times - I'd suggest checking the Language Spec or one of the books by Bloch or Gosling. Ken At 08:36 2007-06-11, you wrote: >* Uncle George wrote on Mon, Jun 11, 2007 at 07:38 -0400: > > Steffen DETTMER wrote: > > > > > (but OutputStream promises that write > > > succeedes synchronous, blocking, or throws an exception). > > > > Where is it so written? > >Now, as you ask, I think it is not written that clearly but >follows from specification. mmm... > >Am I wrong? > >I understand the API doc in this way: > >* >http://java.sun.com/j2se/1.4.2/docs/api/java/io/OutputStream.html#write(byte[]) > > public void write(byte[] b) > > throws IOException > > > > Writes b.length bytes from the specified byte array to this > > output stream. The general contract for write(b) is that > > it should have exactly the same effect as the call write(b, > > 0, b.length). > > > > Parameters: > > b - the data. > > Throws: > > IOException - if an I/O error occurs. > > See Also: > > write(byte[], int, int) > > >and there is: > > > > public void write(byte[] b, > > int off, > > int len) > > throws IOException > > > > Writes len bytes from the specified byte array starting at > > offset off to this output stream. The general contract for > > write(b, off, len) is that some of the bytes in the array b > > are written to the output stream in order; element b[off] > > is the first byte written and b[off+len-1] is the last byte > > written by this operation. > > > > The write method of OutputStream calls the write method of > > one argument on each of the bytes to be written out. > > Subclasses are encouraged to override this method and > > provide a more efficient implementation. > > > > If b is null, a NullPointerException is thrown. > > > > If off is negative, or len is negative, or off+len is > > greater than the length of the array b, then an > > IndexOutOfBoundsException is thrown. > > > > Parameters: > > b - the data. > > off - the start offset in the data. > > len - the number of bytes to write. > > Throws: > > IOException - if an I/O error occurs. In particular, an > > IOException is thrown if the output stream is closed. > > >In general, any specialisation (derived child class) must comform >to this. So write in the end is specified (!) as "The write >method ... calls the write method ... on each of the bytes to be >written out". This is what must be implemented by ANY >OutputStream. > >Of course, there is: "Subclasses are encouraged to override this >method and provide a more efficient implementation." which IMHO >does not contradict - the more efficient must behave in exactly >the same way of course (just wasting less resources than a simple >byte-by-byte write). So it does not matter here I think. > > > >The write that finally defines the behavior tells basically: > > > "Writes the specified byte to this output stream. The general > > contract for write is that one byte is written to the output > > stream. " > > > > Throws: > > IOException - if an I/O error occurs. > > >which IMHO is another way of saying "write writes the byte >immediately and returns on success (only), otherwise an exception >is thrown". Especially it cannot happen that zero bytes are >written (i.e. the specified byte is NOT written) without an >exception. So by this write must be synchronous and blocking, >because otherwise it could not reliably know if an asynchronous >operation will succeede or not (some getAsyncResult or so would >be needed). > >Since write(byte[]) does this for each byte (or with a behavior >beeing exactly the same as if it would do), I think this means >that the write(byte[]) succeedes synchronous/blocking or throws >an exception. > >Did I an error in reasoning or confused something or so? > >oki, > >Steffen > >About Ingenico Throughout the world businesses rely on Ingenico for >secure and expedient electronic transaction acceptance. Ingenico >products leverage proven technology, established standards and >unparalleled ergonomics to provide optimal reliability, versatility >and usability. This comprehensive range of products is complemented >by a global array of services and partnerships, enabling businesses >in a number of vertical sectors to accept transactions anywhere >their business takes them. >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. > >About Ingenico Throughout the world businesses rely on Ingenico for >secure and expedient electronic transaction acceptance. Ingenico >products leverage proven technology, established standards and >unparalleled ergonomics to provide optimal reliability, versatility >and usability. This comprehensive range of products is complemented >by a global array of services and partnerships, enabling businesses >in a number of vertical sectors to accept transactions anywhere >their business takes them. >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. > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From alesinskyy at googlemail.com Mon Jun 11 07:25:33 2007 From: alesinskyy at googlemail.com (Oleksandr Alesinskyy) Date: Mon, 11 Jun 2007 15:25:33 +0200 Subject: [Rxtx] [OT] select :-) Message-ID: Sorry, but I have to disagree with following statement: "So write in the end is specified (!) as "The write method ... calls the write method ... on each of the bytes to be written out". This is what must be implemented by ANY OutputStream.". This is not part of the specification or contract, it is just revealed implementation detail of the OutputStream. It is not stated anywhere that behavoiur of derived classes shall conform with this one. Statement concerning "synchronous" nature of the output stream is invalid as well. Really synchronous stream does not require flush() but OutputStream has it. From Steffen.DETTMER at ingenico.com Mon Jun 11 08:21:16 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 16:21:16 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: Message-ID: <20070611142116.GN10821@elberon.bln.de.ingenico.com> * Oleksandr Alesinskyy wrote on Mon, Jun 11, 2007 at 15:25 +0200: > Sorry, but I have to disagree with following statement: > "So write in the end is specified (!) as "The write > method ... calls the write method ... on each of the bytes to be > written out". This is what must be implemented by ANY > OutputStream.". > > This is not part of the specification or contract, it is just > revealed implementation detail of the OutputStream. It is not > stated anywhere that behavoiur of derived classes shall conform > with this one. (I didn't meant that the implementation must really write byte by byte, but that it must "look as if it would do" - because all implementations of OutputStream must "look" in the same way [which is another way of saying "do abstract" I think]) I think the API doc is not "revealing implementation details" but it is the *specification* of that interface and derivations must (should) conform to this specification. Isn't this the idea of interfaces? A function that expects an OutputStream should work on ANY OutputStream, shouldn't it? just kidding: I mean, what would be the point in implementing a checksum function as OutputStream.write which throws its result as IOException? Or which requires to call close() as very first operation to tell that the application is about to transmit confidential data? :-) > Statement concerning "synchronous" nature of the output stream > is invalid as well. Really synchronous stream does not require > flush() but OutputStream has it. ahh, interesting point! I think this is another bug in the API. flush() is wrong. Because write specifies "The general contract for write is that one byte is written to the output stream." but not "a byte may be written or buffered". Actually, an application would need to call flush() after each write (or bunch of write calls) to ensure that write really did something otherwise I think. I didn't found in the spec of OutputStream that it would be required to call flush(). This should mean that calling flush is not required which in turn leads to the conclusion that write must be synchrous (private threads are forbidden because not specified :)) which in turn leads to the conclusion that flush() is not needed at all... I mean, what if someone would only store in write and do the "real write" in flush() and never else? An application could write in one stream and read on another one (e.g. in bidirectional communication) and would never get anything back, because nothing was actually written because no flush was called? Then someone could even think that on error in some write the data could remain buffered AND throw an exception, retrying to send the data in the next write. Ohh, and if there would be some message number inside, and underlaying write (e.g. a protocol offering InputStream/OutputStream) would check this and throw "DuplicatedMessageNumber" the stream would only throw it again and again beeing unusable... In short: I have no clue how someone could be able to implement an asynchrounos write (which is realiable and correct) without beeing specific to anything which is not specified by OutputStream. Well, I think in the end OutputStream was not intended for such communication or protocol implementations - but to read a local disk file or so. In case of I/O errors usually you can abort your application and change the hard disk :-) oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Bob_Jacobsen at lbl.gov Mon Jun 11 09:32:23 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Mon, 11 Jun 2007 08:32:23 -0700 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611142116.GN10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> Message-ID: At 4:21 PM +0200 6/11/07, Steffen DETTMER wrote: > > Statement concerning "synchronous" nature of the output stream >> is invalid as well. Really synchronous stream does not require >> flush() but OutputStream has it. > >ahh, interesting point! > >I think this is another bug in the API. flush() is wrong. Because >write specifies "The general contract for write is that one byte >is written to the output stream." but not "a byte may be written >or buffered". > >Actually, an application would need to call flush() after each >write (or bunch of write calls) to ensure that write really did >something otherwise I think. OutputStreams don't _have_ to be synchronous or asynchronous, but the OutputStream API was be arranged so that subclasses _can_ be synchronous or asynchronous. Such generality is the hardest part of getting an API right. Hence, if at some point a program using an OutputStream wants to be sure that the data has been pushed all the way out, flush() is available. For some subclasses, e.g. the buffered ones, this has important behavior. Others write the data from each call, and flush() doesn't do anything. You _can_ omit it in programs that are known to use this second type, but there's no requirement that you do so; the interface is general in that way. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From Steffen.DETTMER at ingenico.com Mon Jun 11 12:32:39 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 20:32:39 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> Message-ID: <20070611183239.GT10821@elberon.bln.de.ingenico.com> * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: > >Actually, an application would need to call flush() after each > >write (or bunch of write calls) to ensure that write really did > >something otherwise I think. > OutputStreams don't _have_ to be synchronous or asynchronous, > but the OutputStream API was be arranged so that subclasses > _can_ be synchronous or asynchronous. Ahh, oki. Thanks for the clarificaion. So in short, flush() MUST be called on OutputStream, this is just not documented correctly or so clearly (right?). So the overall usage semantics would be: 1. call write (multiple times if desired) 2. call flush only if both succeeded, write was successful. If flush fails it remains unknown if a part of the data was written and/or will be repeated. So the spec (API doc) is wrong. Correct would be to tell that write behaves as told as long as it is followed by a call to flush, otherwise data may or may not get lost (depending wheter close() is called and calls flush(), which seems not to be guaranteed/required). BTW, I think it is a little bit... erm... interesting to find the specification (java API doc reference) wrong, having a need to conclude it from the presence of some methods with "it would make no sense if they behave exactly as specified, so specification must be wrong (incomplete)". > Such generality is the hardest part of getting an API right. Yes, seems to be proven ;) > Hence, if at some point a program using an OutputStream wants > to be sure that the data has been pushed all the way out, > flush() is available. For some subclasses, e.g. the buffered > ones, this has important behavior. Others write the data from > each call, and flush() doesn't do anything. > You _can_ omit it in programs that are known to use this second > type, but there's no requirement that you do so; the interface > is general in that way. I think, it still it must be called always, otherwise the application could break if passing a different runtime type as OutputStream. I think, if the application/method needs a special "type of OutputStream" then the parameter type must be a subclass but not OutputStream, maybe a PrintStream or so - otherwise the compiler could not detect this error (passing wrong type). Is this correct? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Bob_Jacobsen at lbl.gov Mon Jun 11 13:00:52 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Mon, 11 Jun 2007 12:00:52 -0700 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611183239.GT10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> Message-ID: At 8:32 PM +0200 6/11/07, Steffen DETTMER wrote: >So the spec (API doc) is wrong. Correct would be to tell that >write behaves as told as long as it is followed by a call to >flush, otherwise data may or may not get lost (depending wheter >close() is called and calls flush(), which seems not to be >guaranteed/required). I'm not entirely sure that the spec is wrong, but reasonable people can differ on this. In the 1.5 JavaDocs, all that the docs say for the write methods is that they write to the _output_ _stream_; there is no guarantee of anything beyond that. Only the flush method has any guarantee about the data, which is >Flushes this output stream and forces any buffered output bytes to >be written out. The general contract of flush is that calling it is >an indication that, if any bytes previously written have been >buffered by the implementation of the output stream, such bytes >should immediately be written to their intended destination. People commonly use various OutputStreams without using flush(), and it often works, but it's a bad practice and will eventually bite them. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From netbeans at gatworks.com Mon Jun 11 13:31:57 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 15:31:57 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611183239.GT10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> Message-ID: <466DA32D.1010602@gatworks.com> Steffen DETTMER wrote: > * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: >>> Actually, an application would need to call flush() after each >>> write (or bunch of write calls) to ensure that write really did >>> something otherwise I think. > >> OutputStreams don't _have_ to be synchronous or asynchronous, >> but the OutputStream API was be arranged so that subclasses >> _can_ be synchronous or asynchronous. > > Ahh, oki. Thanks for the clarificaion. > > So in short, flush() MUST be called on OutputStream, this is just > not documented correctly or so clearly (right?). No. Flush can be called to force all current data in java buffer's to be written to the kernel - NOW. A flush() can also *imply* that, besides writing out the buffer's that java employs, may also imply/ask the kernel to write all data thusfar written to the kernel, to be physically placed on the destination device - NOW. For some OS's there is no need to do a kernel flush(), as the I/O is synchronized already. Since this is java, you never know what OS your on. From tjarvi at qbang.org Mon Jun 11 19:28:27 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Jun 2007 19:28:27 -0600 (MDT) Subject: [Rxtx] [OT] select :-) In-Reply-To: <466DA32D.1010602@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: On Mon, 11 Jun 2007, Uncle George wrote: > Steffen DETTMER wrote: >> * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: >>>> Actually, an application would need to call flush() after each >>>> write (or bunch of write calls) to ensure that write really did >>>> something otherwise I think. >> >>> OutputStreams don't _have_ to be synchronous or asynchronous, >>> but the OutputStream API was be arranged so that subclasses >>> _can_ be synchronous or asynchronous. >> >> Ahh, oki. Thanks for the clarificaion. >> >> So in short, flush() MUST be called on OutputStream, this is just >> not documented correctly or so clearly (right?). > No. > Flush can be called to force all current data in java buffer's to be > written to the kernel - NOW. > > A flush() can also *imply* that, besides writing out the buffer's that > java employs, may also imply/ask the kernel to write all data thusfar > written to the kernel, to be physically placed on the destination device > - NOW. > For some OS's there is no need to do a kernel flush(), as the I/O is > synchronized already. Since this is java, you never know what OS your on. To add to the confusion, flush on the C side throws away data. drain makes sure it is written. Looking at the ParallelImp.c we can probably do better. /* we set a timeout because all calls are sequentiell (also with asynchron) this means that the default timeout of unlimited blocks all calls (also close and status request) if the device is down */ GetCommTimeouts( (HANDLE)fd, &timeouts ); timeouts.WriteTotalTimeoutMultiplier = 0; timeouts.WriteTotalTimeoutConstant = 2000; /* 2000 is the min value for the default Windows NT and Windows 2000 driver */ SetCommTimeouts( (HANDLE)fd, &timeouts ); while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } errorCount = 0; bytes += countWritten; count -= countWritten; } LPRPort has some timeout code that appears to be doing nothing but flipping bits back and forth right now. The commapi rxtx follows allows for timeout control from javax.comm.CommPort. The above is a solution that worked in one specific use case. With timeouts in place, the original 'old printer going offline' problem could be solved. That printer code isn't written in stone. In fact it was ajusted from being able to print 'asdf' to a daisy wheel printer to working for one person. BTW, I've finished teaching after hours tonight and will be moving forward with a new rxtx release in my free time. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Jun 11 21:28:04 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 23:28:04 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: <466E12C4.1010305@gatworks.com> > Looking at the ParallelImp.c we can probably do better. > The problem stemmed from the possibility that the writev routine could have written some of the buffer, in chunks, printer pauses, refuses any more chunks, and a timeout occurs. Do you or do you not cause an exception to be thrown? Is there a way to set timeout for a ParallelPort data output stream? I cant find it. From tjarvi at qbang.org Mon Jun 11 22:17:23 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Jun 2007 22:17:23 -0600 (MDT) Subject: [Rxtx] [OT] select :-) In-Reply-To: <466E12C4.1010305@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> <466E12C4.1010305@gatworks.com> Message-ID: On Mon, 11 Jun 2007, Uncle George wrote: >> Looking at the ParallelImp.c we can probably do better. >> > The problem stemmed from the possibility that the writev routine could > have written some of the buffer, in chunks, printer pauses, refuses any > more chunks, and a timeout occurs. Do you or do you not cause an > exception to be thrown? > > Is there a way to set timeout for a ParallelPort data output stream? I > cant find it. hmm I looked again after you asked. The timeouts are only controllable on the receive side. This comes from CommPort; the parent. So what we are talking about is some bytes in memory that rxtx has and is supposed to write. A buffer perhaps? The approach with rxtx in the past has been to ignore output buffer sizes. The assumption is that the library does not know how to best handle buffers. There are buffered output streams that can do buffering on top of rxtx for instance. There is also a question regarding what was actually ment when the API was put together. My suspicion is that it was put together while looking at one OS API and was never ment to be anything more than a hook into that API. The comments are fairly telling combined with reading the w32 API. So looking at the problem again.. The current timeout behavior appears fairly arbitrary. Presumably this is to prevent a program from hanging instead of using a helper thread to write - heavy handed for new programmers. Even so, I don't think the write should timeout at all if it is not configurable. >From the API perspective, "What Timeout?" -- Trent Jarvi tjarvi at qbang.org From Steffen.DETTMER at ingenico.com Tue Jun 12 02:14:48 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 12 Jun 2007 10:14:48 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466DA32D.1010602@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: <20070612081447.GU10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Mon, Jun 11, 2007 at 15:31 -0400: > Steffen DETTMER wrote: > > Ahh, oki. Thanks for the clarificaion. > > > > So in short, flush() MUST be called on OutputStream, this is just > > not documented correctly or so clearly (right?). > No. hum (though now I got it, but...). > Flush can be called to force all current data in java buffer's to be > written to the kernel - NOW. > > A flush() can also *imply* that, besides writing out the > buffer's that java employs, may also imply/ask the kernel to > write all data thusfar written to the kernel, to be physically > placed on the destination device - NOW. > > For some OS's there is no need to do a kernel flush(), as the I/O is > synchronized already. Since this is java, you never know what OS your on. (well, but if you're going to kernel level, even flush cannot guarantee that data will "be physically placed". Maybe you're flushing to a file via NFS (and the client "thinks" that it was written, but maybe it was just buffered by the NFS server) or so... but of course such exceptions of the rules are constructable always.) Well, you tell that depending on the OS it can be that flush is needed or it can be that flush is not needed (beacuse the I/O is synchronized already), right? Also, applications should work on any OS, which includes the OSes that do need flush. Since the application cannot know whether flush is needed or not because it doesn't know what the OS is doing, it has to call flush, hasn't it? I mean, if it would not call flush then it would not work on such OSes (except the written data would not be needed at all, but in this would be an artificial example :)). Since applications are supposed to work this would be wrong, wouldn't it? So would it be correct to say: "Applications, that should work under all OSes (including the OSes where the I/O is not synchronised already), have to call flush on OutputStream to ensure the data is transfered to the kernel." or is this wrong? If so, then I'm afraid I missed the point again :( oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Tue Jun 12 04:46:52 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 12 Jun 2007 06:46:52 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070612081447.GU10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> <20070612081447.GU10821@elberon.bln.de.ingenico.com> Message-ID: <466E799C.7060700@gatworks.com> S > (well, but if you're going to kernel level, even flush cannot > guarantee that data will "be physically placed". Thats true now-a-days because ( from "man 2 sync" ) : > According to the standard specification (e.g., SVID), sync() schedules > the writes, but may return before the actual writing is done. However, > since version 1.3.20 Linux does actually wait. (This still does not > guarantee data integrity: modern disks have large caches.) My disk drive has 8mb cache. Maybe you're > flushing to a file via NFS (and the client "thinks" that it was > written, but maybe it was just buffered by the NFS server) or > so... but of course such exceptions of the rules are > constructable always.) > > Well, you tell that depending on the OS it can be that flush is > needed or it can be that flush is not needed (beacuse the I/O is > synchronized already), right? Also, applications should work on > any OS, which includes the OSes that do need flush. Its not OS's that need flush, its applications that want to have some assurance that data is written to the device that really needs to use flush. If your program ( or thread ) dies then it is in your best interest to write out the critical data as soon as possible, as economical as possible. These are trade-off's that the application programmer makes. A big buffer may mean big loss of data, a small buffer may mean spending too much time writing out data. > > > So would it be correct to say: > > "Applications, that should work under all OSes (including the > OSes where the I/O is not synchronised already), have to call > flush on OutputStream to ensure the data is transfered to the > kernel." > > or is this wrong? If so, then I'm afraid I missed the point again > :( > No that is not wrong. Ensuring that data is transfered to the OS is just about what any application can do. From tjarvi at qbang.org Thu Jun 14 08:16:47 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 14 Jun 2007 08:16:47 -0600 (MDT) Subject: [Rxtx] rxtx and usb-serial solution In-Reply-To: References: Message-ID: On Thu, 14 Jun 2007, Vladimir Kirtchev wrote: > Hi Trent, > > I develop a Java application which communicates with devices which have > USB-to-Serial bridge in them. The target OS is Linux. So for this purpose I > use RXTX. > > But I encountered a strange problem - when reading from the InputStream, I > receive series of zeros. I have this problem under Linux only. Under Windows > it is fine. > Actually this problem is the same as the one described here: > http://marc.info/?l=rxtx&m=109703190731748&w=2. > > > So I searched for the problem in the native code. And found that the root of > the problem is in SerialImp.c, > int configure_port( int fd ) > { > ... > ttyset.c_iflag = INPCK; > ... > } > > This line enables input parity checking, and the data sent from the device > is processed by the OS driver before being read with read(). > In this case the driver detects some problem and sets the received bytes to > zero. > > On the other hand in the Java part a set the serial port parameters with > SerialPort.PARITY_NONE. According to me, except all other things, this > should also disable INPCK in c_iflag. > > So I refactored the method translate_parity(...) to the following: > > int translate_parity( JNIEnv *env, struct termios *ttyset, jint parity ) > { > ENTER( "translate_parity" ); > #ifdef CMSPAR > ttyset->c_cflag &= ~(PARENB | PARODD | CMSPAR ); > #endif /* CMSPAR */ > switch( parity ) { > case JPARITY_NONE: > ttyset->c_iflag &= ~INPCK; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_EVEN: > ttyset->c_cflag |= PARENB; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_ODD: > ttyset->c_cflag |= PARENB | PARODD; > LEAVE( "translate_parity" ); > return 0; > #ifdef CMSPAR > case JPARITY_MARK: > ttyset->c_cflag |= PARENB | PARODD | CMSPAR; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_SPACE: > ttyset->c_cflag |= PARENB | CMSPAR; > LEAVE( "translate_parity" ); > return 0; > #endif /* CMSPAR */ > default: > printf("Parity missed %i\n", (int) parity ); > } > > LEAVE( "translate_parity" ); > /* > For some reason the native exceptions are not being caught. Moving this > to the Java side fixed the issue. taj. > throw_java_exception( env, UNSUPPORTED_COMM_OPERATION, > "", "parity value not supported" ); > */ > return 1; > } > > This modification solved the problem and now it works correctly under Linux. > > I think I will be a nice if this is idea is included in a future release of > RXTX. > > Thanks Vadim, I'll try that out. Forwarding to the rxtx mail-list too. This is probably not going to help USB drivers on windows which I'm sure some are looking for. As far as I can tell, windows USB bluetooth and serial dongles are limited by driver functionality. Some are good and others lack key features. -- Trent Jarvi tjarvi at qbang.org From dan.sandberg.lists at gmail.com Mon Jun 18 14:43:39 2007 From: dan.sandberg.lists at gmail.com (Dan Sandberg) Date: Mon, 18 Jun 2007 13:43:39 -0700 Subject: [Rxtx] Fix for JNI Get/Set Field Errors Message-ID: <4676EE7B.7060800@gmail.com> Hi, I've fixed the problems that cause the following JNI error when extra JNI checking ( -Xjni:check ) is turned on. FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) The problem was basically that GetLong was being used to get ints, and SetInt was used for longs. The patch below fixes this. Please let me know if there are any questions / problems. Cheers, -Dan diff -aur old/SerialImp.c src/SerialImp.c --- old/SerialImp.c 2007-06-18 13:24:33.000000000 -0700 +++ src/SerialImp.c 2007-06-18 06:26:26.000000000 -0700 @@ -1337,7 +1337,7 @@ report("init_threads: get eis\n"); jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); report("init_threads: set eis\n"); - (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); + (*eis->env)->SetLongField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); report("init_threads: stop\n"); report_time_end( ); return( 1 ); @@ -1530,7 +1530,7 @@ jobject jobj, jboolean interrupted ) { int fd = get_java_var( env, jobj,"fd","I" ); - struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var( env, jobj, "eis", "J" ); + struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var_long( env, jobj, "eis", "J" ); int result, count=0; char message[80]; @@ -2939,7 +2939,7 @@ /* TRENT */ int flag, count = 0; struct event_info_struct *eis = ( struct event_info_struct * ) - get_java_var( env, *jobj,"eis","J" ); + get_java_var_long( env, *jobj,"eis","J" ); report_time_start(); flag = eis->eventflags[SPE_DATA_AVAILABLE]; @@ -4873,9 +4873,9 @@ exceptions: none comments: ----------------------------------------------------------*/ -size_t get_java_var( JNIEnv *env, jobject jobj, char *id, char *type ) +long get_java_var_long( JNIEnv *env, jobject jobj, char *id, char *type ) { - int result = 0; + long result = 0; jclass jclazz = (*env)->GetObjectClass( env, jobj ); jfieldID jfd = (*env)->GetFieldID( env, jclazz, id, type ); @@ -4889,7 +4889,11 @@ LEAVE( "get_java_var" ); return result; } - result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); + if ( !strcmp( type, "J" ) ) { + result = (long)( (*env)->GetLongField( env, jobj, jfd ) ); + } else { + result = (int) ( (*env)->GetIntField( env, jobj, jfd ) ); + } /* ct7 & gel * Added DeleteLocalRef */ (*env)->DeleteLocalRef( env, jclazz ); if(!strncmp( "fd",id,2) && result == 0) @@ -4900,6 +4904,10 @@ return result; } +int get_java_var( JNIEnv *env, jobject jobj, char *id, char *type ) { + return (int) get_java_var_long( env, jobj, id, type ); +} + /*---------------------------------------------------------- throw_java_exception diff -aur old/SerialImp.h src/SerialImp.h --- old/SerialImp.h 2007-06-18 13:24:39.000000000 -0700 +++ src/SerialImp.h 2007-06-18 06:23:43.000000000 -0700 @@ -413,7 +413,8 @@ void system_wait(); void finalize_event_info_struct( struct event_info_struct * ); int read_byte_array( JNIEnv *, jobject *, int, unsigned char *, int, int ); -size_t get_java_var( JNIEnv *, jobject, char *, char * ); +int get_java_var( JNIEnv *, jobject, char *, char * ); +long get_java_var_long( JNIEnv *, jobject, char *, char * ); jboolean is_interrupted( struct event_info_struct * ); int send_event(struct event_info_struct *, jint, int ); void dump_termios(char *,struct termios *); From yvespielusenet at free.fr Tue Jun 26 03:41:58 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 11:41:58 +0200 Subject: [Rxtx] [PARALLEL] resource in use Message-ID: <1182850918.3483.10.camel@localhost.localdomain> Hello, So now I want to modify the timeout of the library for parallel port. I have downloaded source code. There is a makefile for migw. SO I have installed mingw on ubuntu and modified the makefile.mingw32 to set it for my system. I have no error but some warnings. The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But When I want to use it the jvm crash :( How can I know what is wrong ? How rxtx windows release has been done ? thanks -- yves piel From yvespielusenet at free.fr Tue Jun 26 07:17:02 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 15:17:02 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182850918.3483.10.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> Message-ID: <1182863822.3483.17.camel@localhost.localdomain> Here is the Makefile I use, the output of the 'make' and the log of the jvm when it crashed : - The Makefile : http://yvespiel.free.fr/rxtx/Makefile - The make output : http://yvespiel.free.fr/rxtx/compile.txt - The crash log : http://yvespiel.free.fr/rxtx/hs_err_pid2100.log I have compiled rxtx under Debian testing with mingw : narma at linimi:/tmp/err$ dpkg -l | grep mingw ii mingw32 3.4.5.20060117.1.dfsg-3 ii mingw32-binutils 2.17.50-20070129.1-1 ii mingw32-runtime 3.12-1 thanks fort help :) Le mardi 26 juin 2007 ? 11:41 +0200, yves pielusenet a ?crit : > Hello, > So now I want to modify the timeout of the library for parallel port. I > have downloaded source code. There is a makefile for migw. SO I have > installed mingw on ubuntu and modified the makefile.mingw32 to set it > for my system. > I have no error but some warnings. > The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But > When I want to use it the jvm crash :( > > How can I know what is wrong ? > > How rxtx windows release has been done ? > > thanks > From yvespielusenet at free.fr Tue Jun 26 07:40:11 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 15:40:11 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182863822.3483.17.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> <1182863822.3483.17.camel@localhost.localdomain> Message-ID: <1182865211.3483.21.camel@localhost.localdomain> I have add the options '--enable-stdcall-fixup' to the 'i586-mingw32msvc-ld' commande. Now I have no warning. But the JVM always crashes :( The output seems more detailled, but I don't understand anything... Here is files : http://yvespiel.free.fr/rxtx/2/ -- yves piel Le mardi 26 juin 2007 ? 15:17 +0200, yves pielusenet a ?crit : > Here is the Makefile I use, the output of the 'make' and the log of the > jvm when it crashed : > > - The Makefile : http://yvespiel.free.fr/rxtx/Makefile > - The make output : http://yvespiel.free.fr/rxtx/compile.txt > - The crash log : http://yvespiel.free.fr/rxtx/hs_err_pid2100.log > > I have compiled rxtx under Debian testing with mingw : > narma at linimi:/tmp/err$ dpkg -l | grep mingw > ii mingw32 3.4.5.20060117.1.dfsg-3 > ii mingw32-binutils 2.17.50-20070129.1-1 > ii mingw32-runtime 3.12-1 > > thanks fort help :) > > > Le mardi 26 juin 2007 ? 11:41 +0200, yves pielusenet a ?crit : > > Hello, > > So now I want to modify the timeout of the library for parallel port. I > > have downloaded source code. There is a makefile for migw. SO I have > > installed mingw on ubuntu and modified the makefile.mingw32 to set it > > for my system. > > I have no error but some warnings. > > The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But > > When I want to use it the jvm crash :( > > > > How can I know what is wrong ? > > > > How rxtx windows release has been done ? > > > > thanks > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From yvespielusenet at free.fr Tue Jun 26 08:27:42 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 16:27:42 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182865211.3483.21.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> <1182863822.3483.17.camel@localhost.localdomain> <1182865211.3483.21.camel@localhost.localdomain> Message-ID: <1182868062.3483.24.camel@localhost.localdomain> I think thant the include files of jdk were not for windows but for linux. So I have copied include/ folder from windows to linux and I modified the Makefile to use those file. It compile fine but the JVM always crash :( http://yvespiel.free.fr/rxtx/3/ Le mardi 26 juin 2007 ? 15:40 +0200, yves pielusenet a ?crit : > I have add the options '--enable-stdcall-fixup' to the > 'i586-mingw32msvc-ld' commande. Now I have no warning. But the JVM > always crashes :( The output seems more detailled, but I don't > understand anything... > Here is files : > http://yvespiel.free.fr/rxtx/2/ > From netbeans at gatworks.com Fri Jun 1 05:38:50 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 07:38:50 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <465F7ADD.1010501@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> Message-ID: <4660054A.2040202@gatworks.com> Manuel Naranjo wrote: In the case of my module, you can > unplug the device but it will not delete the symlink until those apps > that had opened the port has closed it. This is done this way to avoid > kernel panics. What does this mean to user code ? I have tried the alternate route ( other than closing ) which is sleep inbetween the I/O errors ( an unplugged USB device). When the device is plugged back in, The writes to the device still get an I/O error. This would seem to be a lost cause for the application. From netbeans at gatworks.com Fri Jun 1 06:35:48 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 08:35:48 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <465F7ADD.1010501@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> Message-ID: <466012A4.90608@gatworks.com> Manuel Naranjo wrote: In the case of my module, you can > unplug the device but it will not delete the symlink until those apps > that had opened the port has closed it. T Did u also mean for this to happen? USB0 was not closed by application. Apparently USB1 got created when USB device was plugged back in. There is only one USB device on a 4 port USB hub. This also seems to suggest that application recovery to be impossible. > Jun 1 07:10:08 mylaptop kernel: garmin_gps 1-1.4:1.0: Garmin GPS usb/tty converter detected > Jun 1 07:10:08 mylaptop kernel: usb 1-1.4: Garmin GPS usb/tty converter now attached to ttyUSB0 > Jun 1 07:15:17 mylaptop kernel: usb 1-1: USB disconnect, address 4 > Jun 1 07:15:17 mylaptop kernel: usb 1-1.4: USB disconnect, address 5 > Jun 1 07:15:17 mylaptop kernel: garmin_gps 1-1.4:1.0: device disconnected > Jun 1 07:15:26 mylaptop kernel: usb 1-1: new full speed USB device using uhci_hcd and address 6 > Jun 1 07:15:26 mylaptop kernel: hub 1-1:1.0: USB hub found > Jun 1 07:15:26 mylaptop kernel: hub 1-1:1.0: 4 ports detected > Jun 1 07:15:27 mylaptop kernel: usb 1-1.4: new full speed USB device using uhci_hcd and address 7 > Jun 1 07:15:27 mylaptop kernel: garmin_gps 1-1.4:1.0: Garmin GPS usb/tty converter detected > Jun 1 07:15:27 mylaptop kernel: usb 1-1.4: Garmin GPS usb/tty converter now attached to ttyUSB1 From naranjo.manuel at gmail.com Fri Jun 1 09:17:22 2007 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Fri, 01 Jun 2007 12:17:22 -0300 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <466012A4.90608@gatworks.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> <466012A4.90608@gatworks.com> Message-ID: <46603882.5050701@gmail.com> Uncle George escribi?: > Manuel Naranjo wrote: > In the case of my module, you can > >> unplug the device but it will not delete the symlink until those apps >> that had opened the port has closed it. T >> > > Did u also mean for this to happen? USB0 was not closed by application. > > Apparently USB1 got created when USB device was plugged back in. There > is only one USB device on a 4 port USB hub. > > This also seems to suggest that application recovery to be impossible. > Exactly there's a dead symlink (you can read and write to it and nothing will happen) and a new port will be created when a new device is connencted. From netbeans at gatworks.com Fri Jun 1 10:20:46 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 12:20:46 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <46603882.5050701@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> <466012A4.90608@gatworks.com> <46603882.5050701@gmail.com> Message-ID: <4660475E.5090202@gatworks.com> Not sure what u mean by "symlink". U cant read/write to it anymore. U get I/O error. In this scenario the device effectively went dead, and only solution is to close the channel. reconnecting the USB device, although dead, but not closed, will create a second device. This does not seem to be a desirable side-effect. The user will now have ttyUSB1, wondering where did ttyUSB0 go to. The application will also be in a confused state, as well as RXTX, because RXTX wont know about ttyUSB1. Manuel Naranjo wrote: > Uncle George escribi?: >> Manuel Naranjo wrote: >> In the case of my module, you can >> >>> unplug the device but it will not delete the symlink until those apps >>> that had opened the port has closed it. T >>> >> Did u also mean for this to happen? USB0 was not closed by application. >> >> Apparently USB1 got created when USB device was plugged back in. There >> is only one USB device on a 4 port USB hub. >> >> This also seems to suggest that application recovery to be impossible. >> > Exactly there's a dead symlink (you can read and write to it and nothing > will happen) and a new port will be created when a new device is connencted. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From arnab.bhaumik at gmail.com Mon Jun 4 01:40:16 2007 From: arnab.bhaumik at gmail.com (arnab bhaumik) Date: Mon, 4 Jun 2007 13:10:16 +0530 Subject: [Rxtx] full duplex com port with rxtx Message-ID: hi , till now i did half duplex communication with rxtx package on com package. my question is : is it possible to use com port with full duplex mode with rxtx package . ther is example of SimpleRead class and SimpleWrite class. it is clear that if i can use both the class simultaneously then full duplex is possible......... arnab/vu2bpw -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070604/6edb0453/attachment-0007.html From lists at iDIAcomputing.com Mon Jun 4 07:53:17 2007 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Mon, 04 Jun 2007 09:53:17 -0400 Subject: [Rxtx] full duplex com port with rxtx In-Reply-To: References: Message-ID: <4664194D.90301@iDIAcomputing.com> arnab bhaumik wrote: > hi , > > till now i did half duplex communication with rxtx package on com > package. > > my question is : is it possible to use com port with full duplex mode > with rxtx package . > > > ther is example of SimpleRead class and SimpleWrite class. it is > clear that if i can use both the class simultaneously then full duplex > is possible......... I haven't looked at the SimpleRead and SimpleWrite classes (I originally wrote my code for the javax.comm api), but full duplex is certainly possible. My CommReader class requires an object analogous to a OutputStream or Writer. When started, it spawns a thread that reads the comm port and writes to that output device. In this way the input is asynchronous and dependent on the actual input data. For full duplex, I extend that class with CommReaderWriter, which adds synchronous output methods. Hope that helps, George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From supsoop at hotmail.com Mon Jun 4 15:21:06 2007 From: supsoop at hotmail.com (soop soop) Date: Mon, 04 Jun 2007 21:21:06 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- Message-ID: Hi Guys, Looked through the archives but still cannot figure this out. I have a Motorola G24 GPRS/GSM modem that I am connecting to my server running Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not detecting the port, CommPortIdentifier.getPortIdentifiers(). I have added the line to RXTXCommDriver: "ttyACM" // for USB Modems Rxtx still does not seem to find the port. Is there something I am missing to make this port visable? [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control Model driver for USB modems and ISDN adapters I really need your help as I have moved my server from windows to Linux and have been down for a few days because of this .. Thanks so much! _________________________________________________________________ PC Magazine’s 2007 editors’ choice for best Web mail—award-winning Windows Live Hotmail. http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 From tjarvi at qbang.org Mon Jun 4 16:17:35 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Jun 2007 16:17:35 -0600 (MDT) Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: On Mon, 4 Jun 2007, soop soop wrote: > Hi Guys, > > Looked through the archives but still cannot figure this out. I have a > Motorola G24 GPRS/GSM modem that I am connecting to my server running Ubuntu. > I can see my modem as is shows up as ttyACM0, but RXTX is not detecting the > port, CommPortIdentifier.getPortIdentifiers(). > > I have added the line to RXTXCommDriver: > > "ttyACM" // for USB Modems > > Rxtx still does not seem to find the port. Is there something I am missing to > make this port visable? > > [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver > [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device > [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control Model > driver for USB modems and ISDN adapters > > I really need your help as I have moved my server from windows to Linux and > have been down for a few days because of this .. Thanks so much! > You could try the INSTALL documentation that comes with the source for possible solutions. Those usually involve lockfile creation, permissions on the device file or the device is in use by another application (even another session of your application). The usual commands: ls -l /dev/ttyACM0 fuser /dev/ttyACM0 touch /var/lock/LCK.testfile && rm -f /var/lock/LCK.testfile whoami To disable lockfiles: ../configure --disable-lockfiles && make install -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Jun 4 16:22:52 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 04 Jun 2007 18:22:52 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <466490BC.3090801@gatworks.com> soop soop wrote: > I really need your help as I have moved my server from windows to Linux > and have been down for a few days because of this .. Thanks so much! can u open the device ? ie is the file protection/permissions keeping you out? From supsoop at hotmail.com Mon Jun 4 16:44:40 2007 From: supsoop at hotmail.com (soop soop) Date: Mon, 04 Jun 2007 22:44:40 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <466490BC.3090801@gatworks.com> Message-ID: Thanks for the reply, I see no exceptions being thrown, just no detection of the port whats so ever. I will run rxtx in debug mode and log. If this were a permissions issue would I not see some exceptions being thrown? >From: Uncle George >Reply-To: RXTX Developers and Users >To: RXTX Developers and Users >Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >Date: Mon, 04 Jun 2007 18:22:52 -0400 > >soop soop wrote: > > > I really need your help as I have moved my server from windows to Linux > > and have been down for a few days because of this .. Thanks so much! > >can u open the device ? ie is the file protection/permissions keeping >you out? >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ Get a preview of Live Earth, the hottest event this summer - only on MSN http://liveearth.msn.com?source=msntaglineliveearthhm From netbeans at gatworks.com Mon Jun 4 17:06:15 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 04 Jun 2007 19:06:15 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <46649AE7.10405@gatworks.com> Exceptions on what? On startup it wants to lookup all devices in /dev that it is capable of opening ( within the list of specific 'comm' devices ). If it cannot open, then does not get onto list. Part of this process, if configured, will also test if the "LOCK" schema can also be opened for the device. then it gets on the list of avail comm port. soop soop wrote: > Thanks for the reply, > > I see no exceptions being thrown, just no detection of the port whats so > ever. I will run rxtx in debug mode and log. If this were a permissions > issue would I not see some exceptions being thrown? > > >> From: Uncle George >> Reply-To: RXTX Developers and Users >> To: RXTX Developers and Users >> Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >> Date: Mon, 04 Jun 2007 18:22:52 -0400 >> >> soop soop wrote: >> >>> I really need your help as I have moved my server from windows to Linux >>> and have been down for a few days because of this .. Thanks so much! >> can u open the device ? ie is the file protection/permissions keeping >> you out? >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _________________________________________________________________ > Get a preview of Live Earth, the hottest event this summer - only on MSN > http://liveearth.msn.com?source=msntaglineliveearthhm > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From alex.flint at gmail.com Mon Jun 4 21:31:49 2007 From: alex.flint at gmail.com (Alex Flint) Date: Tue, 5 Jun 2007 13:01:49 +0930 Subject: [Rxtx] random EXCEPTION_ACCESS_VIOLATION errors Message-ID: Hi All, I'm running winXP and RXTX 2.1-7r2 (the latest from the webpage as of June 2007). I'm sending sequences of 64 lines (each line has about 15 chars) at various intervals. The strings are sent fine, until I get the following error (from hs_err_pid3316.log, at the end of this email). What can I do to avoid the error? Obviously this is a low-level memory exception, but is there any way I can keep the JVM running after such an error? I noticed the exact same problem here: http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20070129/1180520.html Cheers, Alex # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x100034fb, pid=3316, tid=2400 # # Java VM: Java HotSpot(TM) Client VM (1.6.0_01-b06 mixed mode, sharing) # Problematic frame: # C [rxtxSerial.dll+0x34fb] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # --------------- T H R E A D --------------- Current thread (0x00386400): JavaThread "main" [_thread_in_native, id=2400] siginfo: ExceptionCode=0xc0000005, reading address 0x20726f78 Registers: EAX=0x20726f20, EBX=0x6d8922c0, ECX=0x00000005, EDX=0x20726f20 ESP=0x003efa30, EBP=0x003efb68, ESI=0x269728a0, EDI=0x00386400 EIP=0x100034fb, EFLAGS=0x00010212 Top of Stack: (sp=0x003efa30) 0x003efa30: 003efa3c 003efa64 0000000f ffffffff 0x003efa40: 003efa40 2a97f808 003efa6c 2b190ca8 0x003efa50: 00000000 2b190ec0 003efa90 008e2dd7 0x003efa60: 003efa90 008e2dd7 26977f88 6d815e72 0x003efa70: 00000004 2696eae0 0000008a 003efb0c 0x003efa80: 6d852b4a 2696eae0 00000003 26970930 0x003efa90: 000000cb 2696eae0 6d86b264 00385d40 0x003efaa0: 0000003f 003efb0c 26977f90 2ace65d8 Instructions: (pc=0x100034fb) 0x100034eb: ff ff 8d 76 00 eb 02 89 f6 90 8b 45 f8 8b 55 f8 0x100034fb: 8b 4a 58 83 c9 04 89 48 58 83 c4 f8 8b 45 f8 8b Stack: [0x003a0000,0x003f0000), sp=0x003efa30, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x34fb] Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j gnu.io.RXTXPort.writeArray([BIIZ)V+0 j gnu.io.RXTXPort$SerialOutputStream.write([B)V+76 j com.bjt.media.server.CommLink.send(Ljava/lang/String;)V+48 j com.bjt.media.server.DigitoolConnection.select(I)V+73 j com.bjt.media.server.DigitoolConnection.main([Ljava/lang/String;)V+74 v ~StubRoutines::call_stub --------------- P R O C E S S --------------- Java Threads: ( => current thread ) 0x02a69400 JavaThread "Thread-0" [_thread_in_native, id=3052] 0x02a4d000 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=3920] 0x02a48400 JavaThread "CompilerThread0" daemon [_thread_blocked, id=1968] 0x02a47400 JavaThread "Attach Listener" daemon [_thread_blocked, id=2984] 0x02a46400 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=2660] 0x02a41c00 JavaThread "Finalizer" daemon [_thread_blocked, id=3924] 0x02a3d800 JavaThread "Reference Handler" daemon [_thread_blocked, id=4008] =>0x00386400 JavaThread "main" [_thread_in_native, id=2400] Other Threads: 0x02a34400 VMThread [id=3708] 0x02a4e800 WatcherThread [id=3964] VM state:not at safepoint (normal execution) VM Mutex/Monitor currently owned by a thread: None Heap def new generation total 960K, used 131K [0x22960000, 0x22a60000, 0x22e40000) eden space 896K, 7% used [0x22960000, 0x22970ea8, 0x22a40000) from space 64K, 99% used [0x22a50000, 0x22a5fff8, 0x22a60000) to space 64K, 0% used [0x22a40000, 0x22a40000, 0x22a50000) tenured generation total 4096K, used 76K [0x22e40000, 0x23240000, 0x26960000) the space 4096K, 1% used [0x22e40000, 0x22e53060, 0x22e53200, 0x23240000) compacting perm gen total 12288K, used 137K [0x26960000, 0x27560000, 0x2a960000) the space 12288K, 1% used [0x26960000, 0x26982518, 0x26982600, 0x27560000) ro space 8192K, 62% used [0x2a960000, 0x2ae5e4e8, 0x2ae5e600, 0x2b160000) rw space 12288K, 52% used [0x2b160000, 0x2b7a0e78, 0x2b7a1000, 0x2bd60000) Dynamic libraries: 0x00400000 - 0x00423000 C:\Program Files\Java\jre1.6.0_01\bin\javaw.exe 0x7c900000 - 0x7c9b0000 C:\WINDOWS\system32\ntdll.dll 0x7c800000 - 0x7c8f4000 C:\WINDOWS\system32\kernel32.dll 0x77dd0000 - 0x77e6b000 C:\WINDOWS\system32\ADVAPI32.dll 0x77e70000 - 0x77f01000 C:\WINDOWS\system32\RPCRT4.dll 0x7e410000 - 0x7e4a0000 C:\WINDOWS\system32\USER32.dll 0x77f10000 - 0x77f57000 C:\WINDOWS\system32\GDI32.dll 0x76390000 - 0x763ad000 C:\WINDOWS\system32\IMM32.DLL 0x7c340000 - 0x7c396000 C:\Program Files\Java\jre1.6.0_01\bin\msvcr71.dll 0x6d7c0000 - 0x6da07000 C:\Program Files\Java\jre1.6.0_01\bin\client\jvm.dll 0x76b40000 - 0x76b6d000 C:\WINDOWS\system32\WINMM.dll 0x5cd70000 - 0x5cd77000 C:\WINDOWS\system32\serwvdrv.dll 0x5b0a0000 - 0x5b0a7000 C:\WINDOWS\system32\umdmxfrm.dll 0x6d310000 - 0x6d318000 C:\Program Files\Java\jre1.6.0_01\bin\hpi.dll 0x76bf0000 - 0x76bfb000 C:\WINDOWS\system32\PSAPI.DLL 0x6d770000 - 0x6d77c000 C:\Program Files\Java\jre1.6.0_01\bin\verify.dll 0x6d3b0000 - 0x6d3cf000 C:\Program Files\Java\jre1.6.0_01\bin\java.dll 0x6d7b0000 - 0x6d7bf000 C:\Program Files\Java\jre1.6.0_01\bin\zip.dll 0x10000000 - 0x10012000 C:\Documents and Settings\Alex\workspace\MediaServer\rxtxSerial.dll 0x73d90000 - 0x73db7000 C:\WINDOWS\system32\crtdll.dll VM Arguments: jvm_args: -Djava.library.path=C:\Documents and Settings\Alex\workspace\MediaServer java_command: com.bjt.media.server.DigitoolConnection Launcher Type: SUN_STANDARD Environment Variables: CLASSPATH=.;C:\Program Files\Java\j2re1.4.2_07\lib\ext\QTJava.zip PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\wbem;c:\applications\php;C:\Program Files\MATLAB\R2006a\bin\win32;C:\Roger\Projects\UAV\Bin\Debug;C:\Program Files\Microsoft SQL Server\80\Tools\Binn\;c:\Program Files\Microsoft SQL Server\90\Tools\binn\;C:\Program Files\QuickTime\QTSystem\;C:\Pfps\system;C:\Program Files\Java\jdk1.6.0_01\bin;C:\Program Files\Java\jdk1.6.0_01\jre\bin USERNAME=Alex OS=Windows_NT PROCESSOR_IDENTIFIER=x86 Family 15 Model 4 Stepping 1, GenuineIntel --------------- S Y S T E M --------------- OS: Windows XP Build 2600 Service Pack 2 CPU:total 1 family 15, cmov, cx8, fxsr, mmx, sse, sse2 Memory: 4k page, physical 1046508k(275288k free), swap 2522816k(1909176k free) vm_info: Java HotSpot(TM) Client VM (1.6.0_01-b06) for windows-x86, built on Mar 14 2007 00:24:02 by "java_re" with unknown MS VC++:1310 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070604/c87ae1f0/attachment-0007.html From alwyn.schoeman at gmail.com Tue Jun 5 00:10:19 2007 From: alwyn.schoeman at gmail.com (Alwyn Schoeman) Date: Tue, 5 Jun 2007 08:10:19 +0200 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Hi, I'm using a similar modem. By default rxtx doesn't look for devices that start with ACM, so you need to modify the source code and recompile. Look in RXTXCommDriver and add values for ACM in the registerScannedPorts method in the Linux specific parts. Look for osName.equals("Linux")... On 6/4/07, soop soop wrote: > > Hi Guys, > > Looked through the archives but still cannot figure this out. I have a > Motorola G24 GPRS/GSM modem that I am connecting to my server running > Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not > detecting the port, CommPortIdentifier.getPortIdentifiers(). > > I have added the line to RXTXCommDriver: > > "ttyACM" // for USB Modems > > Rxtx still does not seem to find the port. Is there something I am missing > to make this port visable? > > [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver > [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device > [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control > Model > driver for USB modems and ISDN adapters > > I really need your help as I have moved my server from windows to Linux > and > have been down for a few days because of this .. Thanks so much! > > _________________________________________________________________ > PC Magazine's 2007 editors' choice for best Web mail?award-winning Windows > Live Hotmail. > > http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -- Alwyn Schoeman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/b6cb3053/attachment-0007.html From naranjo.manuel at gmail.com Tue Jun 5 06:48:45 2007 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Tue, 05 Jun 2007 09:48:45 -0300 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> References: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Message-ID: <46655BAD.7010501@gmail.com> That's right, an easier solution is creating symlinks to acm. For example make ttyS70 to 79 point to ACM0 to 9 and that will help you a lot, and doesn't even require compile. > Hi, > > I'm using a similar modem. By default rxtx doesn't look for devices > that start with ACM, so you need to modify the > source code and recompile. > > Look in RXTXCommDriver and add values for ACM in the > registerScannedPorts method in the Linux specific parts. Look for > osName.equals("Linux")... > From juanemc2 at gmail.com Tue Jun 5 07:02:43 2007 From: juanemc2 at gmail.com (Juan) Date: Tue, 5 Jun 2007 10:02:43 -0300 Subject: [Rxtx] Problems with Epson TMU220B POSPrinter using XON/XOFF Flow Control and rxtx jar and dll's with the serial port. Message-ID: Hi!, I?m having trouble printing to the serial port using the latest version of rxtx jar and dll's with an Epson POSPrinter. I`ve switched the printer to work with XON/XOFF Flow Control and have watched the serial port to be sure the printer is sending the XON XOFF stop and go characters. I`ve setted the port like this: CommPortIdentifier commPortIdentifier = CommPortIdentifier.* getPortIdentifier*(_portName); SerialPort serialPort = (SerialPort)commPortIdentifier.open(*this*.getClass().getName(), 2000); serialPort.setSerialPortParams(_baudRate, _dataBits, _stopBits, _parity); serialPort.setFlowControlMode( SerialPort.*FLOWCONTROL_XONXOFF_IN* | SerialPort.*FLOWCONTROL_XONXOFF_OUT*); where the baudRate is 9600 the dataBits is 8 the stopBits is 1 and the parity is 0 It seems as the library isn`t taking into account the XON XOFF setting. I would like to know if I`m setting correctly the Flow Control and if you had had any experiences using XON XOFF flow control and could give me some help to solve my problem. I`m very thankful in advance, Yours, Juan Polero -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/b080995a/attachment-0007.html From ehdez.correo at gmail.com Tue Jun 5 07:12:53 2007 From: ehdez.correo at gmail.com (=?ISO-8859-1?Q?Enrique_Hern=E1ndez?=) Date: Tue, 5 Jun 2007 09:12:53 -0400 Subject: [Rxtx] problem with rxtx Message-ID: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Hello: I doing a simple test to show the serial ports. This is the code: import java.util.Enumeration; import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; public class Show { private Enumeration portList; private CommPortIdentifier portId; private SerialPort port; /** Creates a new instance of Show */ public Show() { } public static void main(String args[]){ Show show = new Show(); show.portList = CommPortIdentifier.getPortIdentifiers(); String tPort = ""; System.out.println("========================================="); while(show.portList.hasMoreElements()){ show.portId = (CommPortIdentifier)show.portList.nextElement(); if(show.portId.getPortType() == CommPortIdentifier.PORT_SERIAL) tPort = "Serial"; else tPort = "Parallel"; System.out.println(show.portId.getName() + " " + tPort); } } } whit The problem is that this code not show the serial ports, this show the no use serial ports. I want to connect whit the modem but when windows open and connect the modem my application don't see the port(COMM3) when it is connect. what I can do? Is that the correct way to know the ports? thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/eedd744b/attachment-0007.html From ehdez.correo at gmail.com Tue Jun 5 07:42:13 2007 From: ehdez.correo at gmail.com (=?ISO-8859-1?Q?Enrique_Hern=E1ndez?=) Date: Tue, 5 Jun 2007 09:42:13 -0400 Subject: [Rxtx] serial port Message-ID: <4a814e1f0706050642p4ce9ac7bka80f9479c524c5ea@mail.gmail.com> Hello: How I can ask to the port what device is connect and information about this device. thanks. bye. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/4d10d26a/attachment-0007.html From supsoop at hotmail.com Tue Jun 5 09:29:00 2007 From: supsoop at hotmail.com (soop soop) Date: Tue, 05 Jun 2007 15:29:00 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Message-ID: Hi Guys, Thanks for all your help. I found the problem. I created a user, Tomcat55, for my tomcat but it did not belong to any group. I then added this user to dialout group to have access to the device ttyACM0. Works perfectly! Again permissions was the issue. This also seems to be persistent as a server reboot does not effect the access. Cheers! >From: "Alwyn Schoeman" >Reply-To: RXTX Developers and Users >To: "RXTX Developers and Users" >Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >Date: Tue, 5 Jun 2007 08:10:19 +0200 > >Hi, > >I'm using a similar modem. By default rxtx doesn't look for devices that >start with ACM, so you need to modify the >source code and recompile. > >Look in RXTXCommDriver and add values for ACM in the registerScannedPorts >method in the Linux specific parts. Look for osName.equals("Linux")... > >On 6/4/07, soop soop wrote: >> >>Hi Guys, >> >>Looked through the archives but still cannot figure this out. I have a >>Motorola G24 GPRS/GSM modem that I am connecting to my server running >>Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not >>detecting the port, CommPortIdentifier.getPortIdentifiers(). >> >>I have added the line to RXTXCommDriver: >> >>"ttyACM" // for USB Modems >> >>Rxtx still does not seem to find the port. Is there something I am missing >>to make this port visable? >> >>[ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver >>[ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device >>[ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control >>Model >>driver for USB modems and ISDN adapters >> >>I really need your help as I have moved my server from windows to Linux >>and >>have been down for a few days because of this .. Thanks so much! >> >>_________________________________________________________________ >>PC Magazine's 2007 editors' choice for best Web mail—award-winning Windows >>Live Hotmail. >> >>http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 >> >> >>_______________________________________________ >>Rxtx mailing list >>Rxtx at qbang.org >>http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > >-- >Alwyn Schoeman >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ Need a break? Find your escape route with Live Search Maps. http://maps.live.com/default.aspx?ss=Restaurants~Hotels~Amusement%20Park&cp=33.832922~-117.915659&style=r&lvl=13&tilt=-90&dir=0&alt=-1000&scene=1118863&encType=1&FORM=MGAC01 From netbeans at gatworks.com Tue Jun 5 09:42:31 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 11:42:31 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <46658467.20101@gatworks.com> soop soop wrote: > > Hi Guys, > > Thanks for all your help. I found the problem. I created a user, > Tomcat55, for my tomcat but it did not belong to any group. I then added Look at man pages for the program udev. From tjarvi at qbang.org Tue Jun 5 18:18:17 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Jun 2007 18:18:17 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Message-ID: On Tue, 5 Jun 2007, Enrique Hern?ndez wrote: > The problem is that this code not show the serial ports, this show the no > use serial ports. I want to connect whit the modem but when windows open and > connect the modem my application don't see the port(COMM3) when it is > connect. > what I can do? > Is that the correct way to know the ports? > Hello, We may have problems understanding each other. On windows, the port will not be an available serial port if another application has the port open. That is just how the library behaves. If you can not see the port in the enumerated list, you could not open it. Also note that enumeration only happens once. If you add a port such as a new USB dongle, the port will not be visible until the next time your application runs. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Tue Jun 5 18:45:01 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 20:45:01 -0400 Subject: [Rxtx] problem with rxtx In-Reply-To: References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Message-ID: <4666038D.8090700@gatworks.com> Trent Jarvi wrote: > > > Also note that enumeration only happens once. If you add a port such as > a new USB dongle, the port will not be visible until the next time your > application runs. Is this written in stone ? somewhere? From tjarvi at qbang.org Tue Jun 5 18:54:36 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Jun 2007 18:54:36 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <4666038D.8090700@gatworks.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> Message-ID: On Tue, 5 Jun 2007, Uncle George wrote: > Trent Jarvi wrote: >> >> >> Also note that enumeration only happens once. If you add a port such as >> a new USB dongle, the port will not be visible until the next time your >> application runs. > > Is this written in stone ? somewhere? It is just the current behavior. There is nothing preventing a fix that allows reenumeration. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Tue Jun 5 19:55:19 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 21:55:19 -0400 Subject: [Rxtx] problem with rxtx In-Reply-To: References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> Message-ID: <46661407.4020308@gatworks.com> >> Is this written in stone ? somewhere? > > It is just the current behavior. There is nothing preventing a fix that > allows reenumeration. With usb, ..... , things come and go. Seems a shame that you have to kill application to get at the device u just plugged in. From joachim at buechse.ch Wed Jun 6 01:50:06 2007 From: joachim at buechse.ch (Joachim Buechse) Date: Wed, 6 Jun 2007 09:50:06 +0200 Subject: [Rxtx] problem with rxtx In-Reply-To: <46661407.4020308@gatworks.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> <46661407.4020308@gatworks.com> Message-ID: <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> On MacOS RXTX's enumeration handling is more flexible. It will find new ports that are added during the lifetime of the application. But this is inherently incompatible with suns javax.comm implementation... Regards, Joachim On 06.06.2007, at 03:55, Uncle George wrote: > >>> Is this written in stone ? somewhere? >> >> It is just the current behavior. There is nothing preventing a >> fix that >> allows reenumeration. > > With usb, ..... , things come and go. Seems a shame that you have to > kill application to get at the device u just plugged in. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Jun 6 06:06:48 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Jun 2007 06:06:48 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> <46661407.4020308@gatworks.com> <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> Message-ID: Sun's javax.comm is not a major concern going forward. As long as we do not break old applications using rxtx, I see no reason to limit rxtx to that convention. We have already rejected version 3 from Sun as a dead end and limited our compatability to version 2. That does not mean we will not try to work with Sun and others but the current javax.comm convention (v3) is not a well conceived path. There has been discussion about doing a JSR which is one valid option. On Wed, 6 Jun 2007, Joachim Buechse wrote: > On MacOS RXTX's enumeration handling is more flexible. It will find > new ports that are added during the lifetime of the application. But > this is inherently incompatible with suns javax.comm implementation... > > Regards, > Joachim > > On 06.06.2007, at 03:55, Uncle George wrote: > >> >>>> Is this written in stone ? somewhere? >>> >>> It is just the current behavior. There is nothing preventing a >>> fix that >>> allows reenumeration. >> >> With usb, ..... , things come and go. Seems a shame that you have to >> kill application to get at the device u just plugged in. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From yvespielusenet at free.fr Wed Jun 6 08:46:35 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 16:46:35 +0200 Subject: [Rxtx] [PARALLEL] resource in use Message-ID: <1181141195.3407.20.camel@localhost.localdomain> Hello, I want to use rxtx in my application. I haveto send data to a very old printer (which have a drum and hammers http://perso.orange.fr/tiie/page00010017.html) This is printer is connecter with centronics. It works well but, while it's writting and I putthe printer off-line, after about 45 seconds, I have this error : ------------------------------------- java.io.IOException: La ressource demand?e est en cours d'utilisation. in writeArray at gnu.io.LPRPort.writeArray(Native Method) at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:292) at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:161) at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:156) at mce.buffer.bufferManager.BufferManager$PrintBuffer.run(BufferManager.java:141) The IOexception means "The wanted resource is in use" ------------------------------------- Here is the line 141 of BufferManager : ------------------------------------- while(send){ try{ fos.write(bb); <=== line 141 send = false; } catch(Exception e){ javax.swing.JOptionPane.showMessageDialog(null, "Erreur d'envoie. Veuillez cliquer sur OK pour relancer l'impression de la vignette.\nV?rifiez votre impression !", "Erreur d'envoie", javax.swing.JOptionPane.WARNING_MESSAGE); e.printStackTrace(System.err); System.err.flush(); System.out.println(e); send = true; } } -------------------------------- 'fos' is an outputstream which contains the rxtx stream (this.os is the rxtx outputstream) : -------------------------------- public void write(byte[] bb) throws IOException{ this.write(bb, 0, bb.length); } public void write(byte[] bb, int off, int len) throws IOException{ while(!imp1.isPrinterSelected() || !imp2.isPrinterSelected()){ } this.os.write(bb, off, len); } -------------------------------- Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( can you help me ? thank you :) -- yves piel From yvespielusenet at free.fr Wed Jun 6 09:11:15 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 17:11:15 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181141195.3407.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> Message-ID: <1181142675.3407.23.camel@localhost.localdomain> I forgot to tell that It's under windows XP and java 1.5. Le mercredi 06 juin 2007 ? 16:46 +0200, yves pielusenet a ?crit : > Hello, > I want to use rxtx in my application. I haveto send data to a very old > printer (which have a drum and hammers > http://perso.orange.fr/tiie/page00010017.html) > This is printer is connecter with centronics. It works well but, while > it's writting and I putthe printer off-line, after about 45 seconds, I > have this error : > ------------------------------------- > java.io.IOException: La ressource demand?e est en cours d'utilisation. > in writeArray > at gnu.io.LPRPort.writeArray(Native Method) > at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:292) > at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:161) > at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:156) > at mce.buffer.bufferManager.BufferManager$PrintBuffer.run(BufferManager.java:141) > > The IOexception means "The wanted resource is in use" > ------------------------------------- > > Here is the line 141 of BufferManager : > > ------------------------------------- > while(send){ > try{ > fos.write(bb); <=== line 141 > send = false; > } > catch(Exception e){ > javax.swing.JOptionPane.showMessageDialog(null, "Erreur d'envoie. Veuillez cliquer sur OK pour relancer l'impression de la vignette.\nV?rifiez votre impression !", "Erreur d'envoie", javax.swing.JOptionPane.WARNING_MESSAGE); > e.printStackTrace(System.err); > System.err.flush(); > System.out.println(e); > send = true; > } > } > -------------------------------- > 'fos' is an outputstream which contains the rxtx stream (this.os is the rxtx outputstream) : > > -------------------------------- > public void write(byte[] bb) throws IOException{ > this.write(bb, 0, bb.length); > } > public void write(byte[] bb, int off, int len) throws IOException{ > while(!imp1.isPrinterSelected() || !imp2.isPrinterSelected()){ > } > this.os.write(bb, off, len); > } > -------------------------------- > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > can you help me ? > > thank you :) > From netbeans at gatworks.com Wed Jun 6 09:21:46 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 11:21:46 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181141195.3407.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> Message-ID: <4666D10A.8000507@gatworks.com> } > -------------------------------- > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > can you help me ? > > thank you :) > windoz or linux? ( I guess windoz ) for windoz, there appears to be a timeout ( as Comments suggest ) of about 40seconds. > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } for linux, there is no implied timeout. > if( write( fd, bytes, count ) < 0 ) > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); From netbeans at gatworks.com Wed Jun 6 09:39:41 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 11:39:41 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666D10A.8000507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> Message-ID: <4666D53D.90000@gatworks.com> Uncle George wrote: > } >> -------------------------------- >> >> Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( >> >> can you help me ? From reading the code, I can see your concern. And it appears you are correct, because some of the data will be sent to the OS printer buffers, and then it will refuse to accept anymore. Unfortunately, writeArray does not return the num of characters written :{ So application has no idea to how many characters were accepted by the OS. I dont do windoz, so I cant say with absolute certainty what windoz will do with an off-line condition. If you have the source, and can compile, then maybe u can increase the loop count to hit 4hours? From yvespielusenet at free.fr Wed Jun 6 09:53:25 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 17:53:25 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666D10A.8000507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> Message-ID: <1181145205.3407.35.camel@localhost.localdomain> Thank you for your explanation :) This timeout comes when no data has been send to the printer after 40seconds if I well understand. But why there is such a timeout ? If I setthe printer offline while it's printing I mustn't have an exception. I don't understand why the "printer should solv all problems like buffer full" in 40 seconds. If I pause the printer the buffer will not be emptied, isn't it ? I not very familiar with C/C++, but it seem that the exception is thrown only when countWritten == 0, that means no data at all has been sent. So Is my code is good since when I intercept this exception I send all my buffer again. There is no way that the printer receive two times same bytes ? thanks ps: yes the application is running on windows XP since I developpe under Debian Le mercredi 06 juin 2007 ? 11:21 -0400, Uncle George a ?crit : > } > > -------------------------------- > > > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > > > can you help me ? > > > > thank you :) > > > > windoz or linux? ( I guess windoz ) > > for windoz, there appears to be a timeout ( as Comments suggest ) of > about 40seconds. > > while( count > 0 ){ > > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > > /* > > this are 20 * 2 seconds, in this time a printer (or other parallel device) > > should solv all problems like buffer full, etc > > */ > > if(errorCount++ < 20){ > > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > > continue; > > } > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > for linux, there is no implied timeout. > > if( write( fd, bytes, count ) < 0 ) > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Wed Jun 6 10:34:24 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 12:34:24 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181145205.3407.35.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> Message-ID: <4666E210.30507@gatworks.com> yves pielusenet wrote: > Thank you for your explanation :) > This timeout comes when no data has been send to the printer after > 40seconds if I well understand. But why there is such a timeout ? If I > setthe printer offline while it's printing I mustn't have an exception. > I don't understand why the "printer should solv all problems like buffer > full" in 40 seconds. If I pause the printer the buffer will not be > emptied, isn't it ? > > I not very familiar with C/C++, but it seem that the exception is thrown > only when countWritten == 0, that means no data at all has been sent. So > Is my code is good since when I intercept this exception I send all my > buffer again. There is no way that the printer receive two times same > bytes ? More technically, the function call returns and reports that 0 characters was written in this call. when 0 characters are written, it will check how many times 0 characters was written. If it has tried LESS than 20 times(errorCount), it will sleep() and try to write again. After 20 times, it wont sleep, but throw you the exception. Now suppose you are writing a 120 character line. you off-lined/paused your printer. The OS has room for 80 more characters in it's printer buffer. The WriteFile() will have a char count of 120, but on return the countWritten = 80. You still have 40 more characters to print. Since countWritten != 0, the counters: bytes += countWritten; count -= countWritten; get updated, and the Writefile now has a count of 40 characters. Since the printer is off-line, the countwritten is 0. And so the loop continues, till 40 seconds is up. As to why it is this way, i dont know ( not a windoz maven ); Also the sleep(20) in the loop is not so intuitive to suggest 2 seconds of sleep. I would have guessed 20seconds, or 20milliseconds. But go figure. BTW: Since your computer sends you error messages in French, does it curse in English? :)))) From yvespielusenet at free.fr Thu Jun 7 02:27:44 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Thu, 07 Jun 2007 10:27:44 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666E210.30507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> Message-ID: <1181204864.3501.10.camel@localhost.localdomain> Maybe in my case I should re-compile rxtx and change the code. Instead of send an exception I should display a dialog box to ask if it's printer problem or if it should trie to send bytes. Something like : while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } if(displayDialogBox("Try again to send datas ??")){ errorCount = 0; } else{ throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } } Le mercredi 06 juin 2007 ? 12:34 -0400, Uncle George a ?crit : > yves pielusenet wrote: > > Thank you for your explanation :) > > This timeout comes when no data has been send to the printer after > > 40seconds if I well understand. But why there is such a timeout ? If I > > setthe printer offline while it's printing I mustn't have an exception. > > I don't understand why the "printer should solv all problems like buffer > > full" in 40 seconds. If I pause the printer the buffer will not be > > emptied, isn't it ? > > > > I not very familiar with C/C++, but it seem that the exception is thrown > > only when countWritten == 0, that means no data at all has been sent. So > > Is my code is good since when I intercept this exception I send all my > > buffer again. There is no way that the printer receive two times same > > bytes ? > More technically, the function call returns and reports that 0 > characters was written in this call. > when 0 characters are written, it will check how many times 0 characters > was written. If it has tried LESS than 20 times(errorCount), it will > sleep() and try to write again. > After 20 times, it wont sleep, but throw you the exception. > > Now suppose you are writing a 120 character line. you off-lined/paused > your printer. The OS has room for 80 more characters in it's printer > buffer. The WriteFile() will have a char count of 120, but on return the > countWritten = 80. You still have 40 more characters to print. > Since countWritten != 0, the counters: > bytes += countWritten; > count -= countWritten; > get updated, and the Writefile now has a count of 40 characters. Since > the printer is off-line, the countwritten is 0. And so the loop > continues, till 40 seconds is up. > > As to why it is this way, i dont know ( not a windoz maven ); > Also the sleep(20) in the loop is not so intuitive to suggest 2 seconds > of sleep. I would have guessed 20seconds, or 20milliseconds. But go figure. > > BTW: Since your computer sends you error messages in French, does it > curse in English? :)))) > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 06:11:43 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 08:11:43 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181204864.3501.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> Message-ID: <4667F5FF.8070903@gatworks.com> your suggestion appears good. I dont know what displayDialogBox exactly will do, so all I can say it that it looks good. But I'd like to wait 10min before first dialog box And a 5 min wait for every dialog box there after. And since these are custom solution/choices, maybe a more exact explanation of what the issue is. if(errorCount++ < 300){ // wait 10min ( 10min * 60sec / 2 ) Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } if(displayDialogBox("Printer has Paused. Retry sending data?")){ errorCount = 150; // Wait for 5 min thereafter continue; } > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } yves pielusenet wrote: > Maybe in my case I should re-compile rxtx and change the code. Instead > of send an exception I should display a dialog box to ask if it's > printer problem or if it should trie to send bytes. Something like : > > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > > if(displayDialogBox("Try again to send datas ??")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > } > From yvespielusenet at free.fr Thu Jun 7 07:17:21 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Thu, 07 Jun 2007 15:17:21 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4667F5FF.8070903@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <4667F5FF.8070903@gatworks.com> Message-ID: <1181222241.3501.20.camel@localhost.localdomain> thank you :) 'displayDialogBox()' I think doesn't exist. It was just for the example :) But I think It should not be so complicated to display a dialog box under windows with YES/NO buttons. When yes is clicked it return 0 other it returns 1. Le jeudi 07 juin 2007 ? 08:11 -0400, Uncle George a ?crit : > your suggestion appears good. I dont know what displayDialogBox exactly > will do, so all I can say it that it looks good. > > But I'd like to wait 10min before first dialog box And a 5 min wait for > every dialog box there after. And since these are custom > solution/choices, maybe a more exact explanation of what the issue is. > > if(errorCount++ < 300){ // wait 10min ( 10min * 60sec / 2 ) > Sleep( 20 ); /* make a small pause to execute all other requests > in all other threads */ > continue; > } > > if(displayDialogBox("Printer has Paused. Retry sending data?")){ > errorCount = 150; // Wait for 5 min thereafter > continue; > } > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > > yves pielusenet wrote: > > Maybe in my case I should re-compile rxtx and change the code. Instead > > of send an exception I should display a dialog box to ask if it's > > printer problem or if it should trie to send bytes. Something like : > > > > while( count > 0 ){ > > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > > /* > > this are 20 * 2 seconds, in this time a printer (or other parallel device) > > should solv all problems like buffer full, etc > > */ > > if(errorCount++ < 20){ > > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > > continue; > > } > > > > if(displayDialogBox("Try again to send datas ??")){ > > errorCount = 0; > > } > > else{ > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > } > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 07:41:43 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 09:41:43 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181222241.3501.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <4667F5FF.8070903@gatworks.com> <1181222241.3501.20.camel@localhost.localdomain> Message-ID: <46680B17.8050109@gatworks.com> yves pielusenet wrote: > thank you :) > 'displayDialogBox()' I think doesn't exist. It was just for the > example :) too bad. Good luck. From rtrout at webbresearch.com Thu Jun 7 11:23:04 2007 From: rtrout at webbresearch.com (Robert Trout) Date: Thu, 07 Jun 2007 13:23:04 -0400 Subject: [Rxtx] Disconnected PortServer TS causes Java to hang Message-ID: <1181236984.14186.33.camel@sisyphus.DinkumSoftware.com> I'm running Linux with sun's Java 1.4.2, Java comm API 2.0, RXTX 2.0-7pre1, and the RealPort digi driver. "/dev/ttyrp00" is a RealPort device. My Java application never returns from a ComPortIdentifier.getPortIdentifier("/dev/ttyrp00") call while the Digi PortServer TS 4 is disconnected from the network. If I later re-connect the PortServer, the call returns about 30 seconds later (it's like a serial port read or write is blocking until the PortServer is re- connected). With the PortServer disconnected, minicom immediately responds with "cannot open /dev/ttyrp00: No such file or directory". I would like my Java application to behave similarly. That is, respond with an error condition instead of hanging when the PortServer is not connected. Since minicom and Java behave differently, I think this "hanging" behavior may be due to RXTX or Java? Has anyone had a similar issue? Solutions? Suggestions? Thanks, Robert From vicnevicne at gmail.com Thu Jun 7 12:16:02 2007 From: vicnevicne at gmail.com (Vicne) Date: Thu, 07 Jun 2007 20:16:02 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181204864.3501.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> Message-ID: <46684B62.7080802@gmail.com> yves pielusenet wrote: > Maybe in my case I should re-compile rxtx and change the code. Instead > of send an exception I should display a dialog box to ask if it's > printer problem or if it should trie to send bytes. Something like : > > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > > if(displayDialogBox("Try again to send datas ??")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > } > Sorry to step in without a specific solution to your problem, but I wanted to share my feeling regarding this proposal. AFAIK, it's generally considered bad practice to pop-up a prompt from a library. The main reason is that in general use, you can't guarantee that someone is actually present behind the console. Imagine a print server in a machine room, connected to a park of printers. In that case, when one printer fails, the logical behaviour would be to use an other one. If you change RxTx the way you propose, the printer queue will simply be stuck with a useless "Try again to send data ?" prompt until an administrator opens a remote connection to the print server's console and clicks "no". Second, it would create a dependency upon the existence of a graphical console (if you go the graphical "dialogBox" way). On many applications (typically server or embedded ones), the JVM is "headless" and if you try to pop-up a dialog, your app would throw an exception (at best) or just wouldn't display the prompt anywhere... Going the "text console" way is not more reliable, because on graphical environments, the text console is hidden unless explicitly requested. My advice would be to think again and find another solution. Ideas are : - make the number of retries a parameter so that you can tune it to what you think is reasonable - throw a more specific exception when the number of retries has been reached, so that a specific prompt can be shown at a higher level Anyway, if you feel that the prompt is the way to go in your case, I would at least make that prompt conditional. The least intrusive way would probably be using a system property, like if("true".equals(System.getProperty("org.rxtx.usePrompt")) && displayDialogBox("Retry sending data ?")){ errorCount = 0; } else{ throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } By default, the behaviour would remain as it is now, but you could force the prompts by defining the property at VM launch if desired. (for example : java.exe -Dorg.rxtx.usePrompt=true myApp) Also, you seemed to say you wanted the printer to start again exactly where is stopped. It would indeed be the best way when the printer is put offline for a few seconds. On the other hand, if the printer is turned off (or the printer runs out of paper, or someone steps on the mains cable), then the only way to go back to a "stable" situation would be by printing the item (page, label, etc.) again from scratch... Just my two cents. Vicne PS : By the way, the dialog box thing is very platform dependant on the C-side, and I think the simplest way would probably be to bridge it to a Java call where you can implement it like you proposed : public boolean displayDialogBox(prompt) { return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); } From netbeans at gatworks.com Thu Jun 7 14:08:24 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 16:08:24 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46684B62.7080802@gmail.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> Message-ID: <466865B8.4060004@gatworks.com> My feeling is that the code that was suggested was for his environs ( his shop ). The issue here is that after a 40+ second wait, an exception will be thrown. But you really dont have a way of 'cancelling' all the WriteFiles() that have already occured before the exception so that your writeArray and the Commapi can backtrack to a position in which they are in sync. The main ( really mine ) concern is not to lose data, or replicate data. After 40seconds, 300 seconds, 55min, no matter how long, data should not be lost or duplicated. But as soon as the exception is thrown, that possibility exists. Maybe an event should be thrown instead? Vicne wrote: > yves pielusenet wrote: >> Maybe in my case I should re-compile rxtx and change the code. Instead >> of send an exception I should display a dialog box to ask if it's >> printer problem or if it should trie to send bytes. Something like : >> >> while( count > 0 ){ >> if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ >> /* >> this are 20 * 2 seconds, in this time a printer (or other parallel device) >> should solv all problems like buffer full, etc >> */ >> if(errorCount++ < 20){ >> Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ >> continue; >> } >> >> if(displayDialogBox("Try again to send datas ??")){ >> errorCount = 0; >> } >> else{ >> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >> break; >> } >> } >> > > Sorry to step in without a specific solution to your problem, but I > wanted to share my feeling regarding this proposal. AFAIK, it's > generally considered bad practice to pop-up a prompt from a library. > The main reason is that in general use, you can't guarantee that > someone is actually present behind the console. Imagine a print server > in a machine room, connected to a park of printers. In that case, when > one printer fails, the logical behaviour would be to use an other one. > If you change RxTx the way you propose, the printer queue will simply be > stuck with a useless "Try again to send data ?" prompt until an > administrator opens a remote connection to the print server's console > and clicks "no". > Second, it would create a dependency upon the existence of a > graphical console (if you go the graphical "dialogBox" way). On many > applications (typically server or embedded ones), the JVM is "headless" > and if you try to pop-up a dialog, your app would throw an exception (at > best) or just wouldn't display the prompt anywhere... Going the "text > console" way is not more reliable, because on graphical environments, > the text console is hidden unless explicitly requested. > > My advice would be to think again and find another solution. Ideas are : > - make the number of retries a parameter so that you can tune it to what > you think is reasonable > - throw a more specific exception when the number of retries has been > reached, so that a specific prompt can be shown at a higher level > > Anyway, if you feel that the prompt is the way to go in your case, I > would at least make that prompt conditional. The least intrusive way > would probably be using a system property, like > > if("true".equals(System.getProperty("org.rxtx.usePrompt")) > && displayDialogBox("Retry sending data ?")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > > > By default, the behaviour would remain as it is now, but you could > force the prompts by defining the property at VM launch if desired. (for > example : java.exe -Dorg.rxtx.usePrompt=true myApp) > > > Also, you seemed to say you wanted the printer to start again > exactly where is stopped. It would indeed be the best way when the > printer is put offline for a few seconds. On the other hand, if the > printer is turned off (or the printer runs out of paper, or someone > steps on the mains cable), then the only way to go back to a "stable" > situation would be by printing the item (page, label, etc.) again from > scratch... > > > Just my two cents. > > > Vicne > > PS : By the way, the dialog box thing is very platform dependant on the > C-side, and I think the simplest way would probably be to bridge it to a > Java call where you can implement it like you proposed : > > public boolean displayDialogBox(prompt) { > return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", > JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); > } > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Thu Jun 7 17:48:11 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 Jun 2007 17:48:11 -0600 (MDT) Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <466865B8.4060004@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> Message-ID: An event is possible. I'm amazed this is the largest problem encountered while using the parallel code. How would the write ever exit if we throw events? Isn't this going to lead to hung applications? On Thu, 7 Jun 2007, Uncle George wrote: > My feeling is that the code that was suggested was for his environs ( > his shop ). > > The issue here is that after a 40+ second wait, an exception will be > thrown. But you really dont have a way of 'cancelling' all the > WriteFiles() that have already occured before the exception so that your > writeArray and the Commapi can backtrack to a position in which they are > in sync. > > The main ( really mine ) concern is not to lose data, or replicate data. > After 40seconds, 300 seconds, 55min, no matter how long, data should > not be lost or duplicated. But as soon as the exception is thrown, that > possibility exists. > > Maybe an event should be thrown instead? > > Vicne wrote: >> yves pielusenet wrote: >>> Maybe in my case I should re-compile rxtx and change the code. Instead >>> of send an exception I should display a dialog box to ask if it's >>> printer problem or if it should trie to send bytes. Something like : >>> >>> while( count > 0 ){ >>> if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ >>> /* >>> this are 20 * 2 seconds, in this time a printer (or other parallel device) >>> should solv all problems like buffer full, etc >>> */ >>> if(errorCount++ < 20){ >>> Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ >>> continue; >>> } >>> >>> if(displayDialogBox("Try again to send datas ??")){ >>> errorCount = 0; >>> } >>> else{ >>> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >>> break; >>> } >>> } >>> >> >> Sorry to step in without a specific solution to your problem, but I >> wanted to share my feeling regarding this proposal. AFAIK, it's >> generally considered bad practice to pop-up a prompt from a library. >> The main reason is that in general use, you can't guarantee that >> someone is actually present behind the console. Imagine a print server >> in a machine room, connected to a park of printers. In that case, when >> one printer fails, the logical behaviour would be to use an other one. >> If you change RxTx the way you propose, the printer queue will simply be >> stuck with a useless "Try again to send data ?" prompt until an >> administrator opens a remote connection to the print server's console >> and clicks "no". >> Second, it would create a dependency upon the existence of a >> graphical console (if you go the graphical "dialogBox" way). On many >> applications (typically server or embedded ones), the JVM is "headless" >> and if you try to pop-up a dialog, your app would throw an exception (at >> best) or just wouldn't display the prompt anywhere... Going the "text >> console" way is not more reliable, because on graphical environments, >> the text console is hidden unless explicitly requested. >> >> My advice would be to think again and find another solution. Ideas are : >> - make the number of retries a parameter so that you can tune it to what >> you think is reasonable >> - throw a more specific exception when the number of retries has been >> reached, so that a specific prompt can be shown at a higher level >> >> Anyway, if you feel that the prompt is the way to go in your case, I >> would at least make that prompt conditional. The least intrusive way >> would probably be using a system property, like >> >> if("true".equals(System.getProperty("org.rxtx.usePrompt")) >> && displayDialogBox("Retry sending data ?")){ >> errorCount = 0; >> } >> else{ >> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >> break; >> } >> >> >> By default, the behaviour would remain as it is now, but you could >> force the prompts by defining the property at VM launch if desired. (for >> example : java.exe -Dorg.rxtx.usePrompt=true myApp) >> >> >> Also, you seemed to say you wanted the printer to start again >> exactly where is stopped. It would indeed be the best way when the >> printer is put offline for a few seconds. On the other hand, if the >> printer is turned off (or the printer runs out of paper, or someone >> steps on the mains cable), then the only way to go back to a "stable" >> situation would be by printing the item (page, label, etc.) again from >> scratch... >> >> >> Just my two cents. >> >> >> Vicne >> >> PS : By the way, the dialog box thing is very platform dependant on the >> C-side, and I think the simplest way would probably be to bridge it to a >> Java call where you can implement it like you proposed : >> >> public boolean displayDialogBox(prompt) { >> return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", >> JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); >> } >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 19:18:51 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 21:18:51 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> Message-ID: <4668AE7B.3060409@gatworks.com> The UNIX version of writeArray is not too great either. It is possible that the write will only process some of the bytes. #else if( write( fd, bytes, count ) < 0 ) throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); #endif -------------------------------- Maybe it might be better to have the native function inform the caller of the # of characters written, then the commapi/output-buffer can be modified to reflect the #of chars written. If an exception is to be thrown, for too many loops of chars written == 0, then exception wont affect the state of the output buffer. Then a ParallelPort.restart() can be called to resume printing whats in the buffer. Trent Jarvi wrote: > An event is possible. I'm amazed this is the largest problem encountered > while using the parallel code. > > How would the write ever exit if we throw events? Isn't this going to > lead to hung applications? Sure. If you dont time out, then there is nothing that will force an EXIT from the write(). Issue is what has the OS done with the write. > > On Thu, 7 Jun 2007, Uncle George wrote: > >> My feeling is that the code that was suggested was for his environs ( >> his shop ). From yvespielusenet at free.fr Fri Jun 8 01:09:01 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Fri, 08 Jun 2007 09:09:01 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4668AE7B.3060409@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> Message-ID: <1181286541.3674.10.camel@localhost.localdomain> It is not possible that the rxtx java method write(byte[], int offset, int length) return anint which contains the number of byte really send to the printer instead of an exception ? So this is the programm which will see if all bytes have been sent. If not it can retry to send the unsended bytes. -------------------------------------------------------- int sended = 0; while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ sended += countWritten; /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } return sended; /*throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break;*/ } ... ... return countWritten; ------------------------------------------------ Le jeudi 07 juin 2007 ? 21:18 -0400, Uncle George a ?crit : > The UNIX version of writeArray is not too great either. It is possible > that the write will only process some of the bytes. > > #else > if( write( fd, bytes, count ) < 0 ) > throw_java_exception_system_msg( env, IO_EXCEPTION, > "writeArray" ); > #endif > -------------------------------- > > Maybe it might be better to have the native function inform the caller > of the # of characters written, then the commapi/output-buffer can be > modified to reflect the #of chars written. If an exception is to be > thrown, for too many loops of chars written == 0, then exception wont > affect the state of the output buffer. Then a ParallelPort.restart() can > be called to resume printing whats in the buffer. > > > Trent Jarvi wrote: > > An event is possible. I'm amazed this is the largest problem encountered > > while using the parallel code. > > > > How would the write ever exit if we throw events? Isn't this going to > > lead to hung applications? > Sure. If you dont time out, then there is nothing that will force an > EXIT from the write(). Issue is what has the OS done with the write. > > > > On Thu, 7 Jun 2007, Uncle George wrote: > > > >> My feeling is that the code that was suggested was for his environs ( > >> his shop ). > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Fri Jun 8 03:45:00 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 11:45:00 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181286541.3674.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> Message-ID: <20070608094500.GC21069@elberon.bln.de.ingenico.com> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > It is not possible that the rxtx java method write(byte[], int offset, > int length) return anint which contains the number of byte really send > to the printer instead of an exception ? > So this is the programm which will see if all bytes have been sent. If > not it can retry to send the unsended bytes. I think write() is void because in Java people love to do this since OutputStream :-) Of course on such interfaces you cannot implement something nice. If you would have a int write, you would not implement the interface and no applications expecting this interface would link/work/compile. oki, Steffen P.S.: (OT) If you propose not to implement the Java interfaces (especially not on JNI level), maybe optionally offering a wrapper that removes e.g. the write return value and so on to downgrade the powerful classic old POSIX read/write style to the modern limited Java style, then I agree :-) Same for read. Instead of things like "int avialable()" it is more powerful to have an approach as select(2) offers (to guarante the caller that read/write will not block [nothing else make sense anyway IMHO] but may read/write less bytes then requested). The caller gets full control and the higher level protocols can care about timeouts, invoking read in some loops and/or implement retransmission. On top of such an implementation, where everything is controlled, defined, guaranteed and reliable, someone could use an InputStream or OutputStream style interface. Or even better: don't use them at all :) just BTW :-) St. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From yvespielusenet at free.fr Fri Jun 8 05:52:45 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Fri, 08 Jun 2007 13:52:45 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <20070608094500.GC21069@elberon.bln.de.ingenico.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> Message-ID: <1181303565.11203.3.camel@localhost.localdomain> So maybe a better way should be to create a new Exception class which has a method "int getWrittenByte()". So the Exception should be use to send again bytes which are not printed yet. yves Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : > * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > > It is not possible that the rxtx java method write(byte[], int offset, > > int length) return anint which contains the number of byte really send > > to the printer instead of an exception ? > > So this is the programm which will see if all bytes have been sent. If > > not it can retry to send the unsended bytes. > > I think write() is void because in Java people love to do this > since OutputStream :-) Of course on such interfaces you cannot > implement something nice. If you would have a int write, you > would not implement the interface and no applications expecting > this interface would link/work/compile. > > oki, > > Steffen > > P.S.: (OT) > If you propose not to implement the Java interfaces (especially > not on JNI level), maybe optionally offering a wrapper that > removes e.g. the write return value and so on to downgrade the > powerful classic old POSIX read/write style to the modern limited > Java style, then I agree :-) Same for read. Instead of things > like "int avialable()" it is more powerful to have an approach as > select(2) offers (to guarante the caller that read/write will not > block [nothing else make sense anyway IMHO] but may read/write > less bytes then requested). The caller gets full control and the > higher level protocols can care about timeouts, invoking read in > some loops and/or implement retransmission. On top of such an > implementation, where everything is controlled, defined, > guaranteed and reliable, someone could use an InputStream or > OutputStream style interface. Or even better: don't use them at > all :) just BTW :-) > St. > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > 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. > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > 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. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Fri Jun 8 06:46:21 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 08:46:21 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181303565.11203.3.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> Message-ID: <46694F9D.5080501@gatworks.com> It seems that with outputstream.write(b[]), you become terribly uncoordinated as soon as an exception is thrown. Docs do not say what happens to the data. Yet from a practicable point of view, one would like to know if the write was accepted in-full, or rejected before any writes. There are no in betweens, as partial writes are not reportable. So for an outputstream.write(), in order for it to return, the full write request has to be taken, and stored in an internal output buffer. If there is no room, the write() is suspended, till there is room. Or throw's an IOException( "no room in buffer") ; As the select() loop for write reports buffer room avail, then more of the internal buffer is sent to the printer. yves pielusenet wrote: > So maybe a better way should be to create a new Exception class which > has a method "int getWrittenByte()". So the Exception should be use to > send again bytes which are not printed yet. > > yves > > Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : >> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: >>> It is not possible that the rxtx java method write(byte[], int offset, >>> int length) return anint which contains the number of byte really send >>> to the printer instead of an exception ? >>> So this is the programm which will see if all bytes have been sent. If >>> not it can retry to send the unsended bytes. >> I think write() is void because in Java people love to do this >> since OutputStream :-) Of course on such interfaces you cannot >> implement something nice. If you would have a int write, you >> would not implement the interface and no applications expecting >> this interface would link/work/compile. >> >> oki, >> >> Steffen >> >> P.S.: (OT) >> If you propose not to implement the Java interfaces (especially >> not on JNI level), maybe optionally offering a wrapper that >> removes e.g. the write return value and so on to downgrade the >> powerful classic old POSIX read/write style to the modern limited >> Java style, then I agree :-) Same for read. Instead of things >> like "int avialable()" it is more powerful to have an approach as >> select(2) offers (to guarante the caller that read/write will not >> block [nothing else make sense anyway IMHO] but may read/write >> less bytes then requested). The caller gets full control and the >> higher level protocols can care about timeouts, invoking read in >> some loops and/or implement retransmission. On top of such an >> implementation, where everything is controlled, defined, >> guaranteed and reliable, someone could use an InputStream or >> OutputStream style interface. Or even better: don't use them at >> all :) just BTW :-) >> St. >> >> About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. >> 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. >> >> About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. >> 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. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From Steffen.DETTMER at ingenico.com Fri Jun 8 08:12:18 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 16:12:18 +0200 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <46694F9D.5080501@gatworks.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: <20070608141218.GE21069@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 08:46 -0400: > It seems that with outputstream.write(b[]), you become terribly > uncoordinated as soon as an exception is thrown. Docs do not say what > happens to the data. (yes, so avoiding it seems to be good :)) > Yet from a practicable point of view, one would like to know if the > write was accepted in-full, or rejected before any writes. There are no > in betweens, as partial writes are not reportable. (which is an artificial API limitation. I never understood how this happend when they invented JDK because the well-known BSD socket API and thus [probably] WinSock does this correct, but anyway) > So for an outputstream.write(), in order for it to return, the full > write request has to be taken, and stored in an internal output buffer. > If there is no room, the write() is suspended, till there is room. Or > throw's an IOException( "no room in buffer") ; As the select() loop for > write reports buffer room avail, then more of the internal buffer is > sent to the printer. yes, might be good in case of a printer. May be horrible in case of PPP/TCP or some other transmission control protocol which may e.g. repeat data or even omit parts of it (e.g. internet realtime radio station broadcasting)... So I think the idea of "int write" (e.g. BSD sockets, linux files and so on) still is the best. A clean API / implementation should guarantee and allow implementations (users) to rely on that; assumptions and automatic background-sending and so on may look pragmatic and may even work on the first look, but may fail in other situations. BTW, if e.g. BSD socket API is known, why not simply copy it (until something better is invented :)) instead of fiddling around with JDK APIs? anyway, have a nice weekend everyone :-) oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Fri Jun 8 08:55:56 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 10:55:56 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070608141218.GE21069@elberon.bln.de.ingenico.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> Message-ID: <46696DFC.7000801@gatworks.com> >> write reports buffer room avail, then more of the internal buffer is >> sent to the printer. > > yes, might be good in case of a printer. May be horrible in case > of PPP/TCP or some other transmission control protocol which > may e.g. repeat data or even omit parts of it (e.g. internet > realtime radio station broadcasting)... So I think the idea of > "int write" (e.g. BSD sockets, linux files and so on) still is > the best. A clean API / implementation should guarantee and allow > implementations (users) to rely on that; assumptions and > automatic background-sending and so on may look pragmatic and may > even work on the first look, but may fail in other situations. > BTW, if e.g. BSD socket API is known, why not simply copy it > (until something better is invented :)) instead of fiddling > around with JDK APIs? But we were talking about the Parallel Port, and the transmission of data over the commapi/parallel-port schema. There isn't much in bi-directional software communication. Its a simple write one byte at a time interface. I'm not looking to change the comm-api. I'm just looking to alter the interaction between the Native ParallelPort functions, and the java ParallelPort functions that call them. This might be more readily doable than to get a committee to re-specify java-API specs. BTW: Whats is off-topic? ( help: not looking for def of off-topic ) From j.kenneth.gentle at acm.org Fri Jun 8 08:58:59 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Fri, 08 Jun 2007 10:58:59 -0400 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <20070608141218.GE21069@elberon.bln.de.ingenico.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> Message-ID: <200706081459.l58Ex5rA019991@qbang.org> Perhaps it is a bit late to jump in on this one, but here goes anyway. If the solutions all seem to "break" the contract with "java.io.outputstream", then, as noted, that may not be the appropriate contract. At the risk of being heretical, JDK1.4 introduced the "nio" package to address some of the compatibility issues with C apis mentioned in previous posts. The interface "java.nio.channels.WriteableByteChannel" defines the following single method: int write(ByteBuffer source); int, strangely enough, is the actual number of bytes written. So, if RXTX as written, against the JavaCOMM api and OutputStream, doesn't do what we want, how about writing a different set of bindings using the java.nio classes and as much of the underlying native code as possible. Note that just because the java.nio.channels.WriteableByteChannel sends back a result, OutputStream.write doesn't have to - and they could both call the same underlying native code. My 2 cents - maybe not worth even that... Ken From netbeans at gatworks.com Fri Jun 8 10:37:28 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 12:37:28 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <200706081459.l58Ex5rA019991@qbang.org> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> Message-ID: <466985C8.8000505@gatworks.com> Ken Gentle wrote: > Perhaps it is a bit late to jump in on this one, but here goes anyway. Common in, the waters fine. > > If the solutions all seem to "break" the contract with > "java.io.outputstream", then, as noted, that may not be the > appropriate contract. > How would the contract be broken? The machinery underneath is handling the contract. From j.kenneth.gentle at acm.org Fri Jun 8 10:48:01 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Fri, 08 Jun 2007 12:48:01 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466985C8.8000505@gatworks.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> Message-ID: <200706081648.l58Gm7YA022904@qbang.org> At 12:37 2007-06-08, you wrote: >Ken Gentle wrote: > > > > If the solutions all seem to "break" the contract with > > "java.io.outputstream", then, as noted, that may not be the > > appropriate contract. > > >How would the contract be broken? The machinery underneath is handling >the contract. It seems that a lot of the discussion has been about not only the timeout and being able to adjust it in the "machinery layer", but also about knowing in the Java layer, in the event of a timeout or exception, how many characters have been written to the device. An OutputStream won't ever do this with out an extension and including a return value "breaks" the contract, right? So, go with a Java IO api that *does* return the number of bytes written, out of the NIO package. I know it doesn't allow for a strict implementation of the JavaCOMM API - however, using NIO classes in place of the IO classes isn't that big a break and would allow those applications that need such information a way to get it. Maybe I'm misunderstanding the problem... Ken From netbeans at gatworks.com Fri Jun 8 11:24:14 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 13:24:14 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <200706081648.l58Gm7YA022904@qbang.org> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> Message-ID: <466990BE.7040100@gatworks.com> Ken Gentle wrote: An > OutputStream won't ever do this with out an extension and including a > return value "breaks" the contract, right? > i was not thinking of change the API to OutputSream. Are there specs for how output stream should work internally? for instance: String data = "Hello this is a line of data"; Outputstream.write( data.getbytes() ); ParallelPort.suspend(); int free = ParallelPort.getoutputbufferfree(); There is a symbiotic relationship between outputstream and the functionality of ParallelPort. From Steffen.DETTMER at ingenico.com Fri Jun 8 11:15:39 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 19:15:39 +0200 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <200706081459.l58Ex5rA019991@qbang.org> References: <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> Message-ID: <20070608171539.GK21069@elberon.bln.de.ingenico.com> * Ken Gentle wrote on Fri, Jun 08, 2007 at 10:58 -0400: > If the solutions all seem to "break" the contract with > "java.io.outputstream", then, as noted, that may not be the > appropriate contract. > > At the risk of being heretical, JDK1.4 introduced the "nio" package > to address some of the compatibility issues with C apis mentioned in > previous posts. The interface > "java.nio.channels.WriteableByteChannel" defines the following single method: > > int write(ByteBuffer source); > > int, strangely enough, is the actual number of bytes written. Yes, AFAIK one of the motivations for the NIO interface was, that the JDK-1.3 APIs (InputStream, e.g.) were not powerfull enough, especially for multi-connection-TCP servers or so. I don't know much about it but I've heard of a project where NIO usage was removed because of stability issues in multi-threaded environments and performance limitations under some circumstances. IIRC the "nio.ByteBuffer" is something very special (namely something you cannot implement in Java, it is "magic" or part of the language itself). Not sure if this is such a great idea (but for performance in the end sometimes heavy prices must be paid) :) > So, if RXTX as written, against the JavaCOMM api and OutputStream, > doesn't do what we want, how about writing a different set of > bindings using the java.nio classes and as much of the underlying > native code as possible. Yes, this would be an idea: use a full-featured interface on JNI, and, if wanted, deliver some wrappers converting this to a less-featured Java-compliant interface. However, powerful things as e.g. "select" are difficult to "emulate" if you are e.g. on some (older?) windows. But if you expose the full-featured APIs, you need to emulate them full-featured, theoretically. In the end it depends what you do on the serial line. If you just want to talk to a modem, then you may not need precise timeouts. But if you need to implement complexer protocols which define response times and timeouts, you may quickly get into difficulties. For instance, AFAIK, rxtx 1.7.2 (?) for windows is very messy with timeouts (there is a maximum, higher values are truncated; resolution is 100ms only; the function may take up to twice the timeout because internally it may be called twice). Probably for most people this is OK, but probably not for all. But having precise timeouts should be OK for all :-) Well, in the end it is nice to wish but somewhat hard to implement (many platforms, connections, USB, BlueTooth, whatever). oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Steffen.DETTMER at ingenico.com Fri Jun 8 11:04:22 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 19:04:22 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <46696DFC.7000801@gatworks.com> References: <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <46696DFC.7000801@gatworks.com> Message-ID: <20070608170422.GJ21069@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 10:55 -0400: > > BTW, if e.g. BSD socket API is known, why not simply copy it > > (until something better is invented :)) instead of fiddling > > around with JDK APIs? > > But we were talking about the Parallel Port, and the > transmission of data over the commapi/parallel-port schema. > There isn't much in bi-directional software communication. Its > a simple write one byte at a time interface. First, there are things like PLIP (http://en.wikipedia.org/wiki/Plip) - well, probably not widely used, sure ;) Second, I think if there is a good simple API known to support all that (with known "best practices") or so and there is no forcing need to invent a new one, why not simply using it? > I'm not looking to change the comm-api. I'm just looking to > alter the interaction between the Native ParallelPort > functions, and the java ParallelPort functions that call them. Ahh, yes. I think this is what I tried to ask. Having an usable JNI interface and on top (in pure java) some wrapper to InputStream or whatever could be done (e.g. by ignoring the return value of write or throwing if != length). Developers could then use the full-featured (non-JAVA-standard) API or select among various wrappers (as InputStream). > This might be more readily doable than to get a committee to > re-specify java-API specs. Yes, of course. I'm afraid that the Java APIs change regularily, but still yet with limited success it seems, so maybe they get it in one of the next iterations; who knows, maybe Java-9 has a BSD-like socket API :) SCNR. > BTW: Whats is off-topic? ( help: not looking for def of > off-topic ) I think I started some "re-specify java-API specs" which was OT probably. oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From lists at iDIAcomputing.com Fri Jun 8 18:48:54 2007 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Fri, 08 Jun 2007 20:48:54 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46684B62.7080802@gmail.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> Message-ID: <4669F8F6.3040101@iDIAcomputing.com> Vicne wrote: > Sorry to step in without a specific solution to your problem, but I > wanted to share my feeling regarding this proposal. AFAIK, it's > generally considered bad practice to pop-up a prompt from a library. ... > > My advice would be to think again and find another solution. Ideas are : > - make the number of retries a parameter so that you can tune it to what > you think is reasonable > - throw a more specific exception when the number of retries has been > reached, so that a specific prompt can be shown at a higher level You could also allow the client code to register a callback class which returns a boolean indicating whether to retry or cancel. This callback class could pop up a dialog, if appropriate, or follow some preset policy, or.... - George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From joachim at buechse.ch Sat Jun 9 09:43:16 2007 From: joachim at buechse.ch (Joachim Buechse) Date: Sat, 9 Jun 2007 17:43:16 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46694F9D.5080501@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: You should not forget, that in the case of an exception it may not even be known what happened to the data. You have a kernel buffer, outgoing chip buffer, incoming chip buffer, etc. So of course, it would be nice to know up to which point data was correctly processed, but this feedback does not exist on the hardware or protocol level and hence can in general not be magicly created on the software level... Regards, Joachim On 08.06.2007, at 14:46, Uncle George wrote: > It seems that with outputstream.write(b[]), you become terribly > uncoordinated as soon as an exception is thrown. Docs do not say what > happens to the data. > > Yet from a practicable point of view, one would like to know if the > write was accepted in-full, or rejected before any writes. There > are no > in betweens, as partial writes are not reportable. > > So for an outputstream.write(), in order for it to return, the full > write request has to be taken, and stored in an internal output > buffer. > If there is no room, the write() is suspended, till there is room. Or > throw's an IOException( "no room in buffer") ; As the select() loop > for > write reports buffer room avail, then more of the internal buffer is > sent to the printer. > > > > yves pielusenet wrote: >> So maybe a better way should be to create a new Exception class which >> has a method "int getWrittenByte()". So the Exception should be >> use to >> send again bytes which are not printed yet. >> >> yves >> >> Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : >>> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: >>>> It is not possible that the rxtx java method write(byte[], int >>>> offset, >>>> int length) return anint which contains the number of byte >>>> really send >>>> to the printer instead of an exception ? >>>> So this is the programm which will see if all bytes have been >>>> sent. If >>>> not it can retry to send the unsended bytes. >>> I think write() is void because in Java people love to do this >>> since OutputStream :-) Of course on such interfaces you cannot >>> implement something nice. If you would have a int write, you >>> would not implement the interface and no applications expecting >>> this interface would link/work/compile. >>> >>> oki, >>> >>> Steffen >>> >>> P.S.: (OT) >>> If you propose not to implement the Java interfaces (especially >>> not on JNI level), maybe optionally offering a wrapper that >>> removes e.g. the write return value and so on to downgrade the >>> powerful classic old POSIX read/write style to the modern limited >>> Java style, then I agree :-) Same for read. Instead of things >>> like "int avialable()" it is more powerful to have an approach as >>> select(2) offers (to guarante the caller that read/write will not >>> block [nothing else make sense anyway IMHO] but may read/write >>> less bytes then requested). The caller gets full control and the >>> higher level protocols can care about timeouts, invoking read in >>> some loops and/or implement retransmission. On top of such an >>> implementation, where everything is controlled, defined, >>> guaranteed and reliable, someone could use an InputStream or >>> OutputStream style interface. Or even better: don't use them at >>> all :) just BTW :-) >>> St. >>> >>> About Ingenico Throughout the world businesses rely on Ingenico >>> for secure and expedient electronic transaction acceptance. >>> Ingenico products leverage proven technology, established >>> standards and unparalleled ergonomics to provide optimal >>> reliability, versatility and usability. This comprehensive range >>> of products is complemented by a global array of services and >>> partnerships, enabling businesses in a number of vertical sectors >>> to accept transactions anywhere their business takes them. >>> 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. >>> >>> About Ingenico Throughout the world businesses rely on Ingenico >>> for secure and expedient electronic transaction acceptance. >>> Ingenico products leverage proven technology, established >>> standards and unparalleled ergonomics to provide optimal >>> reliability, versatility and usability. This comprehensive range >>> of products is complemented by a global array of services and >>> partnerships, enabling businesses in a number of vertical sectors >>> to accept transactions anywhere their business takes them. >>> 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. >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx 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 yvespielusenet at free.fr Mon Jun 11 03:15:12 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Mon, 11 Jun 2007 11:15:12 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: <1181553312.8335.14.camel@localhost.localdomain> So can someone tell a solution for my problem :( Must I say to the user to not put the printer off-line ? I can't since he has to do some pauses, verify print, paper conditioning etc... How do other people ? Before I use the parport librarry to read port status : http://www.geocities.com/Juanga69/parport/ (which doesn't work on windows XP) And I send data into the file LPT1 I use to have no problem when printer was disabled. thanks -- yves piel Le samedi 09 juin 2007 ? 17:43 +0200, Joachim Buechse a ?crit : > You should not forget, that in the case of an exception it may not > even be known what happened to the data. > > You have a kernel buffer, outgoing chip buffer, incoming chip buffer, > etc. So of course, it would be nice to know up to which point data > was correctly processed, but this feedback does not exist on the > hardware or protocol level and hence can in general not be magicly > created on the software level... > > Regards, > Joachim > > On 08.06.2007, at 14:46, Uncle George wrote: > > > It seems that with outputstream.write(b[]), you become terribly > > uncoordinated as soon as an exception is thrown. Docs do not say what > > happens to the data. > > > > Yet from a practicable point of view, one would like to know if the > > write was accepted in-full, or rejected before any writes. There > > are no > > in betweens, as partial writes are not reportable. > > > > So for an outputstream.write(), in order for it to return, the full > > write request has to be taken, and stored in an internal output > > buffer. > > If there is no room, the write() is suspended, till there is room. Or > > throw's an IOException( "no room in buffer") ; As the select() loop > > for > > write reports buffer room avail, then more of the internal buffer is > > sent to the printer. > > > > > > > > yves pielusenet wrote: > >> So maybe a better way should be to create a new Exception class which > >> has a method "int getWrittenByte()". So the Exception should be > >> use to > >> send again bytes which are not printed yet. > >> > >> yves > >> > >> Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : > >>> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > >>>> It is not possible that the rxtx java method write(byte[], int > >>>> offset, > >>>> int length) return anint which contains the number of byte > >>>> really send > >>>> to the printer instead of an exception ? > >>>> So this is the programm which will see if all bytes have been > >>>> sent. If > >>>> not it can retry to send the unsended bytes. > >>> I think write() is void because in Java people love to do this > >>> since OutputStream :-) Of course on such interfaces you cannot > >>> implement something nice. If you would have a int write, you > >>> would not implement the interface and no applications expecting > >>> this interface would link/work/compile. > >>> > >>> oki, > >>> > >>> Steffen > >>> > >>> P.S.: (OT) > >>> If you propose not to implement the Java interfaces (especially > >>> not on JNI level), maybe optionally offering a wrapper that > >>> removes e.g. the write return value and so on to downgrade the > >>> powerful classic old POSIX read/write style to the modern limited > >>> Java style, then I agree :-) Same for read. Instead of things > >>> like "int avialable()" it is more powerful to have an approach as > >>> select(2) offers (to guarante the caller that read/write will not > >>> block [nothing else make sense anyway IMHO] but may read/write > >>> less bytes then requested). The caller gets full control and the > >>> higher level protocols can care about timeouts, invoking read in > >>> some loops and/or implement retransmission. On top of such an > >>> implementation, where everything is controlled, defined, > >>> guaranteed and reliable, someone could use an InputStream or > >>> OutputStream style interface. Or even better: don't use them at > >>> all :) just BTW :-) > >>> St. > >>> > >>> About Ingenico Throughout the world businesses rely on Ingenico > >>> for secure and expedient electronic transaction acceptance. > >>> Ingenico products leverage proven technology, established > >>> standards and unparalleled ergonomics to provide optimal > >>> reliability, versatility and usability. This comprehensive range > >>> of products is complemented by a global array of services and > >>> partnerships, enabling businesses in a number of vertical sectors > >>> to accept transactions anywhere their business takes them. > >>> 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. > >>> > >>> About Ingenico Throughout the world businesses rely on Ingenico > >>> for secure and expedient electronic transaction acceptance. > >>> Ingenico products leverage proven technology, established > >>> standards and unparalleled ergonomics to provide optimal > >>> reliability, versatility and usability. This comprehensive range > >>> of products is complemented by a global array of services and > >>> partnerships, enabling businesses in a number of vertical sectors > >>> to accept transactions anywhere their business takes them. > >>> 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. > >>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx 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 > From Steffen.DETTMER at ingenico.com Mon Jun 11 03:56:18 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 11:56:18 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466990BE.7040100@gatworks.com> References: <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> Message-ID: <20070611095618.GA10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 13:24 -0400: > i was not thinking of change the API to OutputSream. Then I think either someone uses OutputStream (and has no reliable information about incomplete writes) or someone uses somethink else. > Are there specs for how output stream should work internally? > > for instance: > String data = "Hello this is a line of data"; > Outputstream.write( data.getbytes() ); > ParallelPort.suspend(); > int free = ParallelPort.getoutputbufferfree(); > > There is a symbiotic relationship between outputstream and the > functionality of ParallelPort. If you need OutputStream "plus something else", in short you're needing "something else". Personally I dislike the code above a lot. The stream "looks" like if it would be an OutputStream, but in fact it isn't. You need to call getoutputbufferfree later to check if write succeeded (but OutputStream promises that write succeedes synchronous, blocking, or throws an exception). So it is not an OutputStream. No application written for OutputStreams would work without change (because it won't know getoutputbufferfree at all). It is not abstracted from ParallelPort. I think this would be wrong. Then I think an alternative interface instead is better. Let's assume we had some "connection" (to distinguish between OutputStreams and Channels). Then why not working as on a file handle in POSIX: do { // ... select maybe using timer ... readyForWrite = ... if (readyForWrite) { int writtenBytes = connection.write(toWrite); toWrite.remove(0, writtenBytes); } while(readyForWrite && toWrite.length > 0); I think, having such a write isn't the big problem. I think, the difficult thing is around "select" - however this would look like. It should be OO, typesafe, performant, supporting multiple connections/channels/streams in various modes and should be orthogonal to other functionalities. Of course, this heavily depends on what the application is doing; for a simple situation (like reading a small, mandatory file from a local disk) this would be to uncomfortable (and offering unneeded features only). just BTW :) oki, Steffen -- // Modeline for VIM. Please don't remove. // (Help: autoindent, expandtab, shiftwidth=4, tabstop=4, textwidth=75) // vi: set ai et sw=4 ts=4 tw=75 ft=java: About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Mon Jun 11 05:38:33 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 07:38:33 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611095618.GA10821@elberon.bln.de.ingenico.com> References: <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> Message-ID: <466D3439.4020805@gatworks.com> Steffen DETTMER wrote: > (but OutputStream promises that write > succeedes synchronous, blocking, or throws an exception). Where is it so written? From Steffen.DETTMER at ingenico.com Mon Jun 11 06:36:50 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 14:36:50 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466D3439.4020805@gatworks.com> References: <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> <466D3439.4020805@gatworks.com> Message-ID: <20070611123650.GI10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Mon, Jun 11, 2007 at 07:38 -0400: > Steffen DETTMER wrote: > > > (but OutputStream promises that write > > succeedes synchronous, blocking, or throws an exception). > > Where is it so written? Now, as you ask, I think it is not written that clearly but follows from specification. mmm... Am I wrong? I understand the API doc in this way: * http://java.sun.com/j2se/1.4.2/docs/api/java/io/OutputStream.html#write(byte[]) > public void write(byte[] b) > throws IOException > > Writes b.length bytes from the specified byte array to this > output stream. The general contract for write(b) is that > it should have exactly the same effect as the call write(b, > 0, b.length). > > Parameters: > b - the data. > Throws: > IOException - if an I/O error occurs. > See Also: > write(byte[], int, int) and there is: > public void write(byte[] b, > int off, > int len) > throws IOException > > Writes len bytes from the specified byte array starting at > offset off to this output stream. The general contract for > write(b, off, len) is that some of the bytes in the array b > are written to the output stream in order; element b[off] > is the first byte written and b[off+len-1] is the last byte > written by this operation. > > The write method of OutputStream calls the write method of > one argument on each of the bytes to be written out. > Subclasses are encouraged to override this method and > provide a more efficient implementation. > > If b is null, a NullPointerException is thrown. > > If off is negative, or len is negative, or off+len is > greater than the length of the array b, then an > IndexOutOfBoundsException is thrown. > > Parameters: > b - the data. > off - the start offset in the data. > len - the number of bytes to write. > Throws: > IOException - if an I/O error occurs. In particular, an > IOException is thrown if the output stream is closed. In general, any specialisation (derived child class) must comform to this. So write in the end is specified (!) as "The write method ... calls the write method ... on each of the bytes to be written out". This is what must be implemented by ANY OutputStream. Of course, there is: "Subclasses are encouraged to override this method and provide a more efficient implementation." which IMHO does not contradict - the more efficient must behave in exactly the same way of course (just wasting less resources than a simple byte-by-byte write). So it does not matter here I think. The write that finally defines the behavior tells basically: > "Writes the specified byte to this output stream. The general > contract for write is that one byte is written to the output > stream. " > > Throws: > IOException - if an I/O error occurs. which IMHO is another way of saying "write writes the byte immediately and returns on success (only), otherwise an exception is thrown". Especially it cannot happen that zero bytes are written (i.e. the specified byte is NOT written) without an exception. So by this write must be synchronous and blocking, because otherwise it could not reliably know if an asynchronous operation will succeede or not (some getAsyncResult or so would be needed). Since write(byte[]) does this for each byte (or with a behavior beeing exactly the same as if it would do), I think this means that the write(byte[]) succeedes synchronous/blocking or throws an exception. Did I an error in reasoning or confused something or so? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From j.kenneth.gentle at acm.org Mon Jun 11 06:51:25 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 11 Jun 2007 08:51:25 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611123650.GI10821@elberon.bln.de.ingenico.com> References: <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> <466D3439.4020805@gatworks.com> <20070611123650.GI10821@elberon.bln.de.ingenico.com> Message-ID: <200706111251.l5BCpS9T017831@qbang.org> It is as Steffen describes. "InputStream" and "OutputStream" are inherently synchronous (which is why so many java programs resort to threads to use them). Anything outside of this "contract" is *not* an InputStream or OutputStream. That is why there is a new package for things that don't behave like the old *Stream classes - the NIO package. If you look carefully at the IO package, you'll note that almost all the classes are _Decorator_ pattern implementations of the *Stream classes - and the interface presents the _same_ behavior to the calling code in all cases - a synchronous operation that completes successfully or throws an exception (with the one exception of "read" that returns a "-1" on end-of-stream. I know I've read this numerous times - I'd suggest checking the Language Spec or one of the books by Bloch or Gosling. Ken At 08:36 2007-06-11, you wrote: >* Uncle George wrote on Mon, Jun 11, 2007 at 07:38 -0400: > > Steffen DETTMER wrote: > > > > > (but OutputStream promises that write > > > succeedes synchronous, blocking, or throws an exception). > > > > Where is it so written? > >Now, as you ask, I think it is not written that clearly but >follows from specification. mmm... > >Am I wrong? > >I understand the API doc in this way: > >* >http://java.sun.com/j2se/1.4.2/docs/api/java/io/OutputStream.html#write(byte[]) > > public void write(byte[] b) > > throws IOException > > > > Writes b.length bytes from the specified byte array to this > > output stream. The general contract for write(b) is that > > it should have exactly the same effect as the call write(b, > > 0, b.length). > > > > Parameters: > > b - the data. > > Throws: > > IOException - if an I/O error occurs. > > See Also: > > write(byte[], int, int) > > >and there is: > > > > public void write(byte[] b, > > int off, > > int len) > > throws IOException > > > > Writes len bytes from the specified byte array starting at > > offset off to this output stream. The general contract for > > write(b, off, len) is that some of the bytes in the array b > > are written to the output stream in order; element b[off] > > is the first byte written and b[off+len-1] is the last byte > > written by this operation. > > > > The write method of OutputStream calls the write method of > > one argument on each of the bytes to be written out. > > Subclasses are encouraged to override this method and > > provide a more efficient implementation. > > > > If b is null, a NullPointerException is thrown. > > > > If off is negative, or len is negative, or off+len is > > greater than the length of the array b, then an > > IndexOutOfBoundsException is thrown. > > > > Parameters: > > b - the data. > > off - the start offset in the data. > > len - the number of bytes to write. > > Throws: > > IOException - if an I/O error occurs. In particular, an > > IOException is thrown if the output stream is closed. > > >In general, any specialisation (derived child class) must comform >to this. So write in the end is specified (!) as "The write >method ... calls the write method ... on each of the bytes to be >written out". This is what must be implemented by ANY >OutputStream. > >Of course, there is: "Subclasses are encouraged to override this >method and provide a more efficient implementation." which IMHO >does not contradict - the more efficient must behave in exactly >the same way of course (just wasting less resources than a simple >byte-by-byte write). So it does not matter here I think. > > > >The write that finally defines the behavior tells basically: > > > "Writes the specified byte to this output stream. The general > > contract for write is that one byte is written to the output > > stream. " > > > > Throws: > > IOException - if an I/O error occurs. > > >which IMHO is another way of saying "write writes the byte >immediately and returns on success (only), otherwise an exception >is thrown". Especially it cannot happen that zero bytes are >written (i.e. the specified byte is NOT written) without an >exception. So by this write must be synchronous and blocking, >because otherwise it could not reliably know if an asynchronous >operation will succeede or not (some getAsyncResult or so would >be needed). > >Since write(byte[]) does this for each byte (or with a behavior >beeing exactly the same as if it would do), I think this means >that the write(byte[]) succeedes synchronous/blocking or throws >an exception. > >Did I an error in reasoning or confused something or so? > >oki, > >Steffen > >About Ingenico Throughout the world businesses rely on Ingenico for >secure and expedient electronic transaction acceptance. Ingenico >products leverage proven technology, established standards and >unparalleled ergonomics to provide optimal reliability, versatility >and usability. This comprehensive range of products is complemented >by a global array of services and partnerships, enabling businesses >in a number of vertical sectors to accept transactions anywhere >their business takes them. >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. > >About Ingenico Throughout the world businesses rely on Ingenico for >secure and expedient electronic transaction acceptance. Ingenico >products leverage proven technology, established standards and >unparalleled ergonomics to provide optimal reliability, versatility >and usability. This comprehensive range of products is complemented >by a global array of services and partnerships, enabling businesses >in a number of vertical sectors to accept transactions anywhere >their business takes them. >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. > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From alesinskyy at googlemail.com Mon Jun 11 07:25:33 2007 From: alesinskyy at googlemail.com (Oleksandr Alesinskyy) Date: Mon, 11 Jun 2007 15:25:33 +0200 Subject: [Rxtx] [OT] select :-) Message-ID: Sorry, but I have to disagree with following statement: "So write in the end is specified (!) as "The write method ... calls the write method ... on each of the bytes to be written out". This is what must be implemented by ANY OutputStream.". This is not part of the specification or contract, it is just revealed implementation detail of the OutputStream. It is not stated anywhere that behavoiur of derived classes shall conform with this one. Statement concerning "synchronous" nature of the output stream is invalid as well. Really synchronous stream does not require flush() but OutputStream has it. From Steffen.DETTMER at ingenico.com Mon Jun 11 08:21:16 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 16:21:16 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: Message-ID: <20070611142116.GN10821@elberon.bln.de.ingenico.com> * Oleksandr Alesinskyy wrote on Mon, Jun 11, 2007 at 15:25 +0200: > Sorry, but I have to disagree with following statement: > "So write in the end is specified (!) as "The write > method ... calls the write method ... on each of the bytes to be > written out". This is what must be implemented by ANY > OutputStream.". > > This is not part of the specification or contract, it is just > revealed implementation detail of the OutputStream. It is not > stated anywhere that behavoiur of derived classes shall conform > with this one. (I didn't meant that the implementation must really write byte by byte, but that it must "look as if it would do" - because all implementations of OutputStream must "look" in the same way [which is another way of saying "do abstract" I think]) I think the API doc is not "revealing implementation details" but it is the *specification* of that interface and derivations must (should) conform to this specification. Isn't this the idea of interfaces? A function that expects an OutputStream should work on ANY OutputStream, shouldn't it? just kidding: I mean, what would be the point in implementing a checksum function as OutputStream.write which throws its result as IOException? Or which requires to call close() as very first operation to tell that the application is about to transmit confidential data? :-) > Statement concerning "synchronous" nature of the output stream > is invalid as well. Really synchronous stream does not require > flush() but OutputStream has it. ahh, interesting point! I think this is another bug in the API. flush() is wrong. Because write specifies "The general contract for write is that one byte is written to the output stream." but not "a byte may be written or buffered". Actually, an application would need to call flush() after each write (or bunch of write calls) to ensure that write really did something otherwise I think. I didn't found in the spec of OutputStream that it would be required to call flush(). This should mean that calling flush is not required which in turn leads to the conclusion that write must be synchrous (private threads are forbidden because not specified :)) which in turn leads to the conclusion that flush() is not needed at all... I mean, what if someone would only store in write and do the "real write" in flush() and never else? An application could write in one stream and read on another one (e.g. in bidirectional communication) and would never get anything back, because nothing was actually written because no flush was called? Then someone could even think that on error in some write the data could remain buffered AND throw an exception, retrying to send the data in the next write. Ohh, and if there would be some message number inside, and underlaying write (e.g. a protocol offering InputStream/OutputStream) would check this and throw "DuplicatedMessageNumber" the stream would only throw it again and again beeing unusable... In short: I have no clue how someone could be able to implement an asynchrounos write (which is realiable and correct) without beeing specific to anything which is not specified by OutputStream. Well, I think in the end OutputStream was not intended for such communication or protocol implementations - but to read a local disk file or so. In case of I/O errors usually you can abort your application and change the hard disk :-) oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Bob_Jacobsen at lbl.gov Mon Jun 11 09:32:23 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Mon, 11 Jun 2007 08:32:23 -0700 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611142116.GN10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> Message-ID: At 4:21 PM +0200 6/11/07, Steffen DETTMER wrote: > > Statement concerning "synchronous" nature of the output stream >> is invalid as well. Really synchronous stream does not require >> flush() but OutputStream has it. > >ahh, interesting point! > >I think this is another bug in the API. flush() is wrong. Because >write specifies "The general contract for write is that one byte >is written to the output stream." but not "a byte may be written >or buffered". > >Actually, an application would need to call flush() after each >write (or bunch of write calls) to ensure that write really did >something otherwise I think. OutputStreams don't _have_ to be synchronous or asynchronous, but the OutputStream API was be arranged so that subclasses _can_ be synchronous or asynchronous. Such generality is the hardest part of getting an API right. Hence, if at some point a program using an OutputStream wants to be sure that the data has been pushed all the way out, flush() is available. For some subclasses, e.g. the buffered ones, this has important behavior. Others write the data from each call, and flush() doesn't do anything. You _can_ omit it in programs that are known to use this second type, but there's no requirement that you do so; the interface is general in that way. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From Steffen.DETTMER at ingenico.com Mon Jun 11 12:32:39 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 20:32:39 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> Message-ID: <20070611183239.GT10821@elberon.bln.de.ingenico.com> * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: > >Actually, an application would need to call flush() after each > >write (or bunch of write calls) to ensure that write really did > >something otherwise I think. > OutputStreams don't _have_ to be synchronous or asynchronous, > but the OutputStream API was be arranged so that subclasses > _can_ be synchronous or asynchronous. Ahh, oki. Thanks for the clarificaion. So in short, flush() MUST be called on OutputStream, this is just not documented correctly or so clearly (right?). So the overall usage semantics would be: 1. call write (multiple times if desired) 2. call flush only if both succeeded, write was successful. If flush fails it remains unknown if a part of the data was written and/or will be repeated. So the spec (API doc) is wrong. Correct would be to tell that write behaves as told as long as it is followed by a call to flush, otherwise data may or may not get lost (depending wheter close() is called and calls flush(), which seems not to be guaranteed/required). BTW, I think it is a little bit... erm... interesting to find the specification (java API doc reference) wrong, having a need to conclude it from the presence of some methods with "it would make no sense if they behave exactly as specified, so specification must be wrong (incomplete)". > Such generality is the hardest part of getting an API right. Yes, seems to be proven ;) > Hence, if at some point a program using an OutputStream wants > to be sure that the data has been pushed all the way out, > flush() is available. For some subclasses, e.g. the buffered > ones, this has important behavior. Others write the data from > each call, and flush() doesn't do anything. > You _can_ omit it in programs that are known to use this second > type, but there's no requirement that you do so; the interface > is general in that way. I think, it still it must be called always, otherwise the application could break if passing a different runtime type as OutputStream. I think, if the application/method needs a special "type of OutputStream" then the parameter type must be a subclass but not OutputStream, maybe a PrintStream or so - otherwise the compiler could not detect this error (passing wrong type). Is this correct? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Bob_Jacobsen at lbl.gov Mon Jun 11 13:00:52 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Mon, 11 Jun 2007 12:00:52 -0700 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611183239.GT10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> Message-ID: At 8:32 PM +0200 6/11/07, Steffen DETTMER wrote: >So the spec (API doc) is wrong. Correct would be to tell that >write behaves as told as long as it is followed by a call to >flush, otherwise data may or may not get lost (depending wheter >close() is called and calls flush(), which seems not to be >guaranteed/required). I'm not entirely sure that the spec is wrong, but reasonable people can differ on this. In the 1.5 JavaDocs, all that the docs say for the write methods is that they write to the _output_ _stream_; there is no guarantee of anything beyond that. Only the flush method has any guarantee about the data, which is >Flushes this output stream and forces any buffered output bytes to >be written out. The general contract of flush is that calling it is >an indication that, if any bytes previously written have been >buffered by the implementation of the output stream, such bytes >should immediately be written to their intended destination. People commonly use various OutputStreams without using flush(), and it often works, but it's a bad practice and will eventually bite them. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From netbeans at gatworks.com Mon Jun 11 13:31:57 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 15:31:57 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611183239.GT10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> Message-ID: <466DA32D.1010602@gatworks.com> Steffen DETTMER wrote: > * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: >>> Actually, an application would need to call flush() after each >>> write (or bunch of write calls) to ensure that write really did >>> something otherwise I think. > >> OutputStreams don't _have_ to be synchronous or asynchronous, >> but the OutputStream API was be arranged so that subclasses >> _can_ be synchronous or asynchronous. > > Ahh, oki. Thanks for the clarificaion. > > So in short, flush() MUST be called on OutputStream, this is just > not documented correctly or so clearly (right?). No. Flush can be called to force all current data in java buffer's to be written to the kernel - NOW. A flush() can also *imply* that, besides writing out the buffer's that java employs, may also imply/ask the kernel to write all data thusfar written to the kernel, to be physically placed on the destination device - NOW. For some OS's there is no need to do a kernel flush(), as the I/O is synchronized already. Since this is java, you never know what OS your on. From tjarvi at qbang.org Mon Jun 11 19:28:27 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Jun 2007 19:28:27 -0600 (MDT) Subject: [Rxtx] [OT] select :-) In-Reply-To: <466DA32D.1010602@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: On Mon, 11 Jun 2007, Uncle George wrote: > Steffen DETTMER wrote: >> * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: >>>> Actually, an application would need to call flush() after each >>>> write (or bunch of write calls) to ensure that write really did >>>> something otherwise I think. >> >>> OutputStreams don't _have_ to be synchronous or asynchronous, >>> but the OutputStream API was be arranged so that subclasses >>> _can_ be synchronous or asynchronous. >> >> Ahh, oki. Thanks for the clarificaion. >> >> So in short, flush() MUST be called on OutputStream, this is just >> not documented correctly or so clearly (right?). > No. > Flush can be called to force all current data in java buffer's to be > written to the kernel - NOW. > > A flush() can also *imply* that, besides writing out the buffer's that > java employs, may also imply/ask the kernel to write all data thusfar > written to the kernel, to be physically placed on the destination device > - NOW. > For some OS's there is no need to do a kernel flush(), as the I/O is > synchronized already. Since this is java, you never know what OS your on. To add to the confusion, flush on the C side throws away data. drain makes sure it is written. Looking at the ParallelImp.c we can probably do better. /* we set a timeout because all calls are sequentiell (also with asynchron) this means that the default timeout of unlimited blocks all calls (also close and status request) if the device is down */ GetCommTimeouts( (HANDLE)fd, &timeouts ); timeouts.WriteTotalTimeoutMultiplier = 0; timeouts.WriteTotalTimeoutConstant = 2000; /* 2000 is the min value for the default Windows NT and Windows 2000 driver */ SetCommTimeouts( (HANDLE)fd, &timeouts ); while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } errorCount = 0; bytes += countWritten; count -= countWritten; } LPRPort has some timeout code that appears to be doing nothing but flipping bits back and forth right now. The commapi rxtx follows allows for timeout control from javax.comm.CommPort. The above is a solution that worked in one specific use case. With timeouts in place, the original 'old printer going offline' problem could be solved. That printer code isn't written in stone. In fact it was ajusted from being able to print 'asdf' to a daisy wheel printer to working for one person. BTW, I've finished teaching after hours tonight and will be moving forward with a new rxtx release in my free time. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Jun 11 21:28:04 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 23:28:04 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: <466E12C4.1010305@gatworks.com> > Looking at the ParallelImp.c we can probably do better. > The problem stemmed from the possibility that the writev routine could have written some of the buffer, in chunks, printer pauses, refuses any more chunks, and a timeout occurs. Do you or do you not cause an exception to be thrown? Is there a way to set timeout for a ParallelPort data output stream? I cant find it. From tjarvi at qbang.org Mon Jun 11 22:17:23 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Jun 2007 22:17:23 -0600 (MDT) Subject: [Rxtx] [OT] select :-) In-Reply-To: <466E12C4.1010305@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> <466E12C4.1010305@gatworks.com> Message-ID: On Mon, 11 Jun 2007, Uncle George wrote: >> Looking at the ParallelImp.c we can probably do better. >> > The problem stemmed from the possibility that the writev routine could > have written some of the buffer, in chunks, printer pauses, refuses any > more chunks, and a timeout occurs. Do you or do you not cause an > exception to be thrown? > > Is there a way to set timeout for a ParallelPort data output stream? I > cant find it. hmm I looked again after you asked. The timeouts are only controllable on the receive side. This comes from CommPort; the parent. So what we are talking about is some bytes in memory that rxtx has and is supposed to write. A buffer perhaps? The approach with rxtx in the past has been to ignore output buffer sizes. The assumption is that the library does not know how to best handle buffers. There are buffered output streams that can do buffering on top of rxtx for instance. There is also a question regarding what was actually ment when the API was put together. My suspicion is that it was put together while looking at one OS API and was never ment to be anything more than a hook into that API. The comments are fairly telling combined with reading the w32 API. So looking at the problem again.. The current timeout behavior appears fairly arbitrary. Presumably this is to prevent a program from hanging instead of using a helper thread to write - heavy handed for new programmers. Even so, I don't think the write should timeout at all if it is not configurable. >From the API perspective, "What Timeout?" -- Trent Jarvi tjarvi at qbang.org From Steffen.DETTMER at ingenico.com Tue Jun 12 02:14:48 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 12 Jun 2007 10:14:48 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466DA32D.1010602@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: <20070612081447.GU10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Mon, Jun 11, 2007 at 15:31 -0400: > Steffen DETTMER wrote: > > Ahh, oki. Thanks for the clarificaion. > > > > So in short, flush() MUST be called on OutputStream, this is just > > not documented correctly or so clearly (right?). > No. hum (though now I got it, but...). > Flush can be called to force all current data in java buffer's to be > written to the kernel - NOW. > > A flush() can also *imply* that, besides writing out the > buffer's that java employs, may also imply/ask the kernel to > write all data thusfar written to the kernel, to be physically > placed on the destination device - NOW. > > For some OS's there is no need to do a kernel flush(), as the I/O is > synchronized already. Since this is java, you never know what OS your on. (well, but if you're going to kernel level, even flush cannot guarantee that data will "be physically placed". Maybe you're flushing to a file via NFS (and the client "thinks" that it was written, but maybe it was just buffered by the NFS server) or so... but of course such exceptions of the rules are constructable always.) Well, you tell that depending on the OS it can be that flush is needed or it can be that flush is not needed (beacuse the I/O is synchronized already), right? Also, applications should work on any OS, which includes the OSes that do need flush. Since the application cannot know whether flush is needed or not because it doesn't know what the OS is doing, it has to call flush, hasn't it? I mean, if it would not call flush then it would not work on such OSes (except the written data would not be needed at all, but in this would be an artificial example :)). Since applications are supposed to work this would be wrong, wouldn't it? So would it be correct to say: "Applications, that should work under all OSes (including the OSes where the I/O is not synchronised already), have to call flush on OutputStream to ensure the data is transfered to the kernel." or is this wrong? If so, then I'm afraid I missed the point again :( oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Tue Jun 12 04:46:52 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 12 Jun 2007 06:46:52 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070612081447.GU10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> <20070612081447.GU10821@elberon.bln.de.ingenico.com> Message-ID: <466E799C.7060700@gatworks.com> S > (well, but if you're going to kernel level, even flush cannot > guarantee that data will "be physically placed". Thats true now-a-days because ( from "man 2 sync" ) : > According to the standard specification (e.g., SVID), sync() schedules > the writes, but may return before the actual writing is done. However, > since version 1.3.20 Linux does actually wait. (This still does not > guarantee data integrity: modern disks have large caches.) My disk drive has 8mb cache. Maybe you're > flushing to a file via NFS (and the client "thinks" that it was > written, but maybe it was just buffered by the NFS server) or > so... but of course such exceptions of the rules are > constructable always.) > > Well, you tell that depending on the OS it can be that flush is > needed or it can be that flush is not needed (beacuse the I/O is > synchronized already), right? Also, applications should work on > any OS, which includes the OSes that do need flush. Its not OS's that need flush, its applications that want to have some assurance that data is written to the device that really needs to use flush. If your program ( or thread ) dies then it is in your best interest to write out the critical data as soon as possible, as economical as possible. These are trade-off's that the application programmer makes. A big buffer may mean big loss of data, a small buffer may mean spending too much time writing out data. > > > So would it be correct to say: > > "Applications, that should work under all OSes (including the > OSes where the I/O is not synchronised already), have to call > flush on OutputStream to ensure the data is transfered to the > kernel." > > or is this wrong? If so, then I'm afraid I missed the point again > :( > No that is not wrong. Ensuring that data is transfered to the OS is just about what any application can do. From tjarvi at qbang.org Thu Jun 14 08:16:47 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 14 Jun 2007 08:16:47 -0600 (MDT) Subject: [Rxtx] rxtx and usb-serial solution In-Reply-To: References: Message-ID: On Thu, 14 Jun 2007, Vladimir Kirtchev wrote: > Hi Trent, > > I develop a Java application which communicates with devices which have > USB-to-Serial bridge in them. The target OS is Linux. So for this purpose I > use RXTX. > > But I encountered a strange problem - when reading from the InputStream, I > receive series of zeros. I have this problem under Linux only. Under Windows > it is fine. > Actually this problem is the same as the one described here: > http://marc.info/?l=rxtx&m=109703190731748&w=2. > > > So I searched for the problem in the native code. And found that the root of > the problem is in SerialImp.c, > int configure_port( int fd ) > { > ... > ttyset.c_iflag = INPCK; > ... > } > > This line enables input parity checking, and the data sent from the device > is processed by the OS driver before being read with read(). > In this case the driver detects some problem and sets the received bytes to > zero. > > On the other hand in the Java part a set the serial port parameters with > SerialPort.PARITY_NONE. According to me, except all other things, this > should also disable INPCK in c_iflag. > > So I refactored the method translate_parity(...) to the following: > > int translate_parity( JNIEnv *env, struct termios *ttyset, jint parity ) > { > ENTER( "translate_parity" ); > #ifdef CMSPAR > ttyset->c_cflag &= ~(PARENB | PARODD | CMSPAR ); > #endif /* CMSPAR */ > switch( parity ) { > case JPARITY_NONE: > ttyset->c_iflag &= ~INPCK; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_EVEN: > ttyset->c_cflag |= PARENB; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_ODD: > ttyset->c_cflag |= PARENB | PARODD; > LEAVE( "translate_parity" ); > return 0; > #ifdef CMSPAR > case JPARITY_MARK: > ttyset->c_cflag |= PARENB | PARODD | CMSPAR; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_SPACE: > ttyset->c_cflag |= PARENB | CMSPAR; > LEAVE( "translate_parity" ); > return 0; > #endif /* CMSPAR */ > default: > printf("Parity missed %i\n", (int) parity ); > } > > LEAVE( "translate_parity" ); > /* > For some reason the native exceptions are not being caught. Moving this > to the Java side fixed the issue. taj. > throw_java_exception( env, UNSUPPORTED_COMM_OPERATION, > "", "parity value not supported" ); > */ > return 1; > } > > This modification solved the problem and now it works correctly under Linux. > > I think I will be a nice if this is idea is included in a future release of > RXTX. > > Thanks Vadim, I'll try that out. Forwarding to the rxtx mail-list too. This is probably not going to help USB drivers on windows which I'm sure some are looking for. As far as I can tell, windows USB bluetooth and serial dongles are limited by driver functionality. Some are good and others lack key features. -- Trent Jarvi tjarvi at qbang.org From dan.sandberg.lists at gmail.com Mon Jun 18 14:43:39 2007 From: dan.sandberg.lists at gmail.com (Dan Sandberg) Date: Mon, 18 Jun 2007 13:43:39 -0700 Subject: [Rxtx] Fix for JNI Get/Set Field Errors Message-ID: <4676EE7B.7060800@gmail.com> Hi, I've fixed the problems that cause the following JNI error when extra JNI checking ( -Xjni:check ) is turned on. FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) The problem was basically that GetLong was being used to get ints, and SetInt was used for longs. The patch below fixes this. Please let me know if there are any questions / problems. Cheers, -Dan diff -aur old/SerialImp.c src/SerialImp.c --- old/SerialImp.c 2007-06-18 13:24:33.000000000 -0700 +++ src/SerialImp.c 2007-06-18 06:26:26.000000000 -0700 @@ -1337,7 +1337,7 @@ report("init_threads: get eis\n"); jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); report("init_threads: set eis\n"); - (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); + (*eis->env)->SetLongField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); report("init_threads: stop\n"); report_time_end( ); return( 1 ); @@ -1530,7 +1530,7 @@ jobject jobj, jboolean interrupted ) { int fd = get_java_var( env, jobj,"fd","I" ); - struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var( env, jobj, "eis", "J" ); + struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var_long( env, jobj, "eis", "J" ); int result, count=0; char message[80]; @@ -2939,7 +2939,7 @@ /* TRENT */ int flag, count = 0; struct event_info_struct *eis = ( struct event_info_struct * ) - get_java_var( env, *jobj,"eis","J" ); + get_java_var_long( env, *jobj,"eis","J" ); report_time_start(); flag = eis->eventflags[SPE_DATA_AVAILABLE]; @@ -4873,9 +4873,9 @@ exceptions: none comments: ----------------------------------------------------------*/ -size_t get_java_var( JNIEnv *env, jobject jobj, char *id, char *type ) +long get_java_var_long( JNIEnv *env, jobject jobj, char *id, char *type ) { - int result = 0; + long result = 0; jclass jclazz = (*env)->GetObjectClass( env, jobj ); jfieldID jfd = (*env)->GetFieldID( env, jclazz, id, type ); @@ -4889,7 +4889,11 @@ LEAVE( "get_java_var" ); return result; } - result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); + if ( !strcmp( type, "J" ) ) { + result = (long)( (*env)->GetLongField( env, jobj, jfd ) ); + } else { + result = (int) ( (*env)->GetIntField( env, jobj, jfd ) ); + } /* ct7 & gel * Added DeleteLocalRef */ (*env)->DeleteLocalRef( env, jclazz ); if(!strncmp( "fd",id,2) && result == 0) @@ -4900,6 +4904,10 @@ return result; } +int get_java_var( JNIEnv *env, jobject jobj, char *id, char *type ) { + return (int) get_java_var_long( env, jobj, id, type ); +} + /*---------------------------------------------------------- throw_java_exception diff -aur old/SerialImp.h src/SerialImp.h --- old/SerialImp.h 2007-06-18 13:24:39.000000000 -0700 +++ src/SerialImp.h 2007-06-18 06:23:43.000000000 -0700 @@ -413,7 +413,8 @@ void system_wait(); void finalize_event_info_struct( struct event_info_struct * ); int read_byte_array( JNIEnv *, jobject *, int, unsigned char *, int, int ); -size_t get_java_var( JNIEnv *, jobject, char *, char * ); +int get_java_var( JNIEnv *, jobject, char *, char * ); +long get_java_var_long( JNIEnv *, jobject, char *, char * ); jboolean is_interrupted( struct event_info_struct * ); int send_event(struct event_info_struct *, jint, int ); void dump_termios(char *,struct termios *); From yvespielusenet at free.fr Tue Jun 26 03:41:58 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 11:41:58 +0200 Subject: [Rxtx] [PARALLEL] resource in use Message-ID: <1182850918.3483.10.camel@localhost.localdomain> Hello, So now I want to modify the timeout of the library for parallel port. I have downloaded source code. There is a makefile for migw. SO I have installed mingw on ubuntu and modified the makefile.mingw32 to set it for my system. I have no error but some warnings. The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But When I want to use it the jvm crash :( How can I know what is wrong ? How rxtx windows release has been done ? thanks -- yves piel From yvespielusenet at free.fr Tue Jun 26 07:17:02 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 15:17:02 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182850918.3483.10.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> Message-ID: <1182863822.3483.17.camel@localhost.localdomain> Here is the Makefile I use, the output of the 'make' and the log of the jvm when it crashed : - The Makefile : http://yvespiel.free.fr/rxtx/Makefile - The make output : http://yvespiel.free.fr/rxtx/compile.txt - The crash log : http://yvespiel.free.fr/rxtx/hs_err_pid2100.log I have compiled rxtx under Debian testing with mingw : narma at linimi:/tmp/err$ dpkg -l | grep mingw ii mingw32 3.4.5.20060117.1.dfsg-3 ii mingw32-binutils 2.17.50-20070129.1-1 ii mingw32-runtime 3.12-1 thanks fort help :) Le mardi 26 juin 2007 ? 11:41 +0200, yves pielusenet a ?crit : > Hello, > So now I want to modify the timeout of the library for parallel port. I > have downloaded source code. There is a makefile for migw. SO I have > installed mingw on ubuntu and modified the makefile.mingw32 to set it > for my system. > I have no error but some warnings. > The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But > When I want to use it the jvm crash :( > > How can I know what is wrong ? > > How rxtx windows release has been done ? > > thanks > From yvespielusenet at free.fr Tue Jun 26 07:40:11 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 15:40:11 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182863822.3483.17.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> <1182863822.3483.17.camel@localhost.localdomain> Message-ID: <1182865211.3483.21.camel@localhost.localdomain> I have add the options '--enable-stdcall-fixup' to the 'i586-mingw32msvc-ld' commande. Now I have no warning. But the JVM always crashes :( The output seems more detailled, but I don't understand anything... Here is files : http://yvespiel.free.fr/rxtx/2/ -- yves piel Le mardi 26 juin 2007 ? 15:17 +0200, yves pielusenet a ?crit : > Here is the Makefile I use, the output of the 'make' and the log of the > jvm when it crashed : > > - The Makefile : http://yvespiel.free.fr/rxtx/Makefile > - The make output : http://yvespiel.free.fr/rxtx/compile.txt > - The crash log : http://yvespiel.free.fr/rxtx/hs_err_pid2100.log > > I have compiled rxtx under Debian testing with mingw : > narma at linimi:/tmp/err$ dpkg -l | grep mingw > ii mingw32 3.4.5.20060117.1.dfsg-3 > ii mingw32-binutils 2.17.50-20070129.1-1 > ii mingw32-runtime 3.12-1 > > thanks fort help :) > > > Le mardi 26 juin 2007 ? 11:41 +0200, yves pielusenet a ?crit : > > Hello, > > So now I want to modify the timeout of the library for parallel port. I > > have downloaded source code. There is a makefile for migw. SO I have > > installed mingw on ubuntu and modified the makefile.mingw32 to set it > > for my system. > > I have no error but some warnings. > > The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But > > When I want to use it the jvm crash :( > > > > How can I know what is wrong ? > > > > How rxtx windows release has been done ? > > > > thanks > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From yvespielusenet at free.fr Tue Jun 26 08:27:42 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 16:27:42 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182865211.3483.21.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> <1182863822.3483.17.camel@localhost.localdomain> <1182865211.3483.21.camel@localhost.localdomain> Message-ID: <1182868062.3483.24.camel@localhost.localdomain> I think thant the include files of jdk were not for windows but for linux. So I have copied include/ folder from windows to linux and I modified the Makefile to use those file. It compile fine but the JVM always crash :( http://yvespiel.free.fr/rxtx/3/ Le mardi 26 juin 2007 ? 15:40 +0200, yves pielusenet a ?crit : > I have add the options '--enable-stdcall-fixup' to the > 'i586-mingw32msvc-ld' commande. Now I have no warning. But the JVM > always crashes :( The output seems more detailled, but I don't > understand anything... > Here is files : > http://yvespiel.free.fr/rxtx/2/ > From netbeans at gatworks.com Fri Jun 1 05:38:50 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 07:38:50 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <465F7ADD.1010501@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> Message-ID: <4660054A.2040202@gatworks.com> Manuel Naranjo wrote: In the case of my module, you can > unplug the device but it will not delete the symlink until those apps > that had opened the port has closed it. This is done this way to avoid > kernel panics. What does this mean to user code ? I have tried the alternate route ( other than closing ) which is sleep inbetween the I/O errors ( an unplugged USB device). When the device is plugged back in, The writes to the device still get an I/O error. This would seem to be a lost cause for the application. From netbeans at gatworks.com Fri Jun 1 06:35:48 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 08:35:48 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <465F7ADD.1010501@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> Message-ID: <466012A4.90608@gatworks.com> Manuel Naranjo wrote: In the case of my module, you can > unplug the device but it will not delete the symlink until those apps > that had opened the port has closed it. T Did u also mean for this to happen? USB0 was not closed by application. Apparently USB1 got created when USB device was plugged back in. There is only one USB device on a 4 port USB hub. This also seems to suggest that application recovery to be impossible. > Jun 1 07:10:08 mylaptop kernel: garmin_gps 1-1.4:1.0: Garmin GPS usb/tty converter detected > Jun 1 07:10:08 mylaptop kernel: usb 1-1.4: Garmin GPS usb/tty converter now attached to ttyUSB0 > Jun 1 07:15:17 mylaptop kernel: usb 1-1: USB disconnect, address 4 > Jun 1 07:15:17 mylaptop kernel: usb 1-1.4: USB disconnect, address 5 > Jun 1 07:15:17 mylaptop kernel: garmin_gps 1-1.4:1.0: device disconnected > Jun 1 07:15:26 mylaptop kernel: usb 1-1: new full speed USB device using uhci_hcd and address 6 > Jun 1 07:15:26 mylaptop kernel: hub 1-1:1.0: USB hub found > Jun 1 07:15:26 mylaptop kernel: hub 1-1:1.0: 4 ports detected > Jun 1 07:15:27 mylaptop kernel: usb 1-1.4: new full speed USB device using uhci_hcd and address 7 > Jun 1 07:15:27 mylaptop kernel: garmin_gps 1-1.4:1.0: Garmin GPS usb/tty converter detected > Jun 1 07:15:27 mylaptop kernel: usb 1-1.4: Garmin GPS usb/tty converter now attached to ttyUSB1 From naranjo.manuel at gmail.com Fri Jun 1 09:17:22 2007 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Fri, 01 Jun 2007 12:17:22 -0300 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <466012A4.90608@gatworks.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> <466012A4.90608@gatworks.com> Message-ID: <46603882.5050701@gmail.com> Uncle George escribi?: > Manuel Naranjo wrote: > In the case of my module, you can > >> unplug the device but it will not delete the symlink until those apps >> that had opened the port has closed it. T >> > > Did u also mean for this to happen? USB0 was not closed by application. > > Apparently USB1 got created when USB device was plugged back in. There > is only one USB device on a 4 port USB hub. > > This also seems to suggest that application recovery to be impossible. > Exactly there's a dead symlink (you can read and write to it and nothing will happen) and a new port will be created when a new device is connencted. From netbeans at gatworks.com Fri Jun 1 10:20:46 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 12:20:46 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <46603882.5050701@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> <466012A4.90608@gatworks.com> <46603882.5050701@gmail.com> Message-ID: <4660475E.5090202@gatworks.com> Not sure what u mean by "symlink". U cant read/write to it anymore. U get I/O error. In this scenario the device effectively went dead, and only solution is to close the channel. reconnecting the USB device, although dead, but not closed, will create a second device. This does not seem to be a desirable side-effect. The user will now have ttyUSB1, wondering where did ttyUSB0 go to. The application will also be in a confused state, as well as RXTX, because RXTX wont know about ttyUSB1. Manuel Naranjo wrote: > Uncle George escribi?: >> Manuel Naranjo wrote: >> In the case of my module, you can >> >>> unplug the device but it will not delete the symlink until those apps >>> that had opened the port has closed it. T >>> >> Did u also mean for this to happen? USB0 was not closed by application. >> >> Apparently USB1 got created when USB device was plugged back in. There >> is only one USB device on a 4 port USB hub. >> >> This also seems to suggest that application recovery to be impossible. >> > Exactly there's a dead symlink (you can read and write to it and nothing > will happen) and a new port will be created when a new device is connencted. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From arnab.bhaumik at gmail.com Mon Jun 4 01:40:16 2007 From: arnab.bhaumik at gmail.com (arnab bhaumik) Date: Mon, 4 Jun 2007 13:10:16 +0530 Subject: [Rxtx] full duplex com port with rxtx Message-ID: hi , till now i did half duplex communication with rxtx package on com package. my question is : is it possible to use com port with full duplex mode with rxtx package . ther is example of SimpleRead class and SimpleWrite class. it is clear that if i can use both the class simultaneously then full duplex is possible......... arnab/vu2bpw -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070604/6edb0453/attachment-0008.html From lists at iDIAcomputing.com Mon Jun 4 07:53:17 2007 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Mon, 04 Jun 2007 09:53:17 -0400 Subject: [Rxtx] full duplex com port with rxtx In-Reply-To: References: Message-ID: <4664194D.90301@iDIAcomputing.com> arnab bhaumik wrote: > hi , > > till now i did half duplex communication with rxtx package on com > package. > > my question is : is it possible to use com port with full duplex mode > with rxtx package . > > > ther is example of SimpleRead class and SimpleWrite class. it is > clear that if i can use both the class simultaneously then full duplex > is possible......... I haven't looked at the SimpleRead and SimpleWrite classes (I originally wrote my code for the javax.comm api), but full duplex is certainly possible. My CommReader class requires an object analogous to a OutputStream or Writer. When started, it spawns a thread that reads the comm port and writes to that output device. In this way the input is asynchronous and dependent on the actual input data. For full duplex, I extend that class with CommReaderWriter, which adds synchronous output methods. Hope that helps, George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From supsoop at hotmail.com Mon Jun 4 15:21:06 2007 From: supsoop at hotmail.com (soop soop) Date: Mon, 04 Jun 2007 21:21:06 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- Message-ID: Hi Guys, Looked through the archives but still cannot figure this out. I have a Motorola G24 GPRS/GSM modem that I am connecting to my server running Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not detecting the port, CommPortIdentifier.getPortIdentifiers(). I have added the line to RXTXCommDriver: "ttyACM" // for USB Modems Rxtx still does not seem to find the port. Is there something I am missing to make this port visable? [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control Model driver for USB modems and ISDN adapters I really need your help as I have moved my server from windows to Linux and have been down for a few days because of this .. Thanks so much! _________________________________________________________________ PC Magazine’s 2007 editors’ choice for best Web mail—award-winning Windows Live Hotmail. http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 From tjarvi at qbang.org Mon Jun 4 16:17:35 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Jun 2007 16:17:35 -0600 (MDT) Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: On Mon, 4 Jun 2007, soop soop wrote: > Hi Guys, > > Looked through the archives but still cannot figure this out. I have a > Motorola G24 GPRS/GSM modem that I am connecting to my server running Ubuntu. > I can see my modem as is shows up as ttyACM0, but RXTX is not detecting the > port, CommPortIdentifier.getPortIdentifiers(). > > I have added the line to RXTXCommDriver: > > "ttyACM" // for USB Modems > > Rxtx still does not seem to find the port. Is there something I am missing to > make this port visable? > > [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver > [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device > [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control Model > driver for USB modems and ISDN adapters > > I really need your help as I have moved my server from windows to Linux and > have been down for a few days because of this .. Thanks so much! > You could try the INSTALL documentation that comes with the source for possible solutions. Those usually involve lockfile creation, permissions on the device file or the device is in use by another application (even another session of your application). The usual commands: ls -l /dev/ttyACM0 fuser /dev/ttyACM0 touch /var/lock/LCK.testfile && rm -f /var/lock/LCK.testfile whoami To disable lockfiles: ../configure --disable-lockfiles && make install -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Jun 4 16:22:52 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 04 Jun 2007 18:22:52 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <466490BC.3090801@gatworks.com> soop soop wrote: > I really need your help as I have moved my server from windows to Linux > and have been down for a few days because of this .. Thanks so much! can u open the device ? ie is the file protection/permissions keeping you out? From supsoop at hotmail.com Mon Jun 4 16:44:40 2007 From: supsoop at hotmail.com (soop soop) Date: Mon, 04 Jun 2007 22:44:40 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <466490BC.3090801@gatworks.com> Message-ID: Thanks for the reply, I see no exceptions being thrown, just no detection of the port whats so ever. I will run rxtx in debug mode and log. If this were a permissions issue would I not see some exceptions being thrown? >From: Uncle George >Reply-To: RXTX Developers and Users >To: RXTX Developers and Users >Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >Date: Mon, 04 Jun 2007 18:22:52 -0400 > >soop soop wrote: > > > I really need your help as I have moved my server from windows to Linux > > and have been down for a few days because of this .. Thanks so much! > >can u open the device ? ie is the file protection/permissions keeping >you out? >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ Get a preview of Live Earth, the hottest event this summer - only on MSN http://liveearth.msn.com?source=msntaglineliveearthhm From netbeans at gatworks.com Mon Jun 4 17:06:15 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 04 Jun 2007 19:06:15 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <46649AE7.10405@gatworks.com> Exceptions on what? On startup it wants to lookup all devices in /dev that it is capable of opening ( within the list of specific 'comm' devices ). If it cannot open, then does not get onto list. Part of this process, if configured, will also test if the "LOCK" schema can also be opened for the device. then it gets on the list of avail comm port. soop soop wrote: > Thanks for the reply, > > I see no exceptions being thrown, just no detection of the port whats so > ever. I will run rxtx in debug mode and log. If this were a permissions > issue would I not see some exceptions being thrown? > > >> From: Uncle George >> Reply-To: RXTX Developers and Users >> To: RXTX Developers and Users >> Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >> Date: Mon, 04 Jun 2007 18:22:52 -0400 >> >> soop soop wrote: >> >>> I really need your help as I have moved my server from windows to Linux >>> and have been down for a few days because of this .. Thanks so much! >> can u open the device ? ie is the file protection/permissions keeping >> you out? >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _________________________________________________________________ > Get a preview of Live Earth, the hottest event this summer - only on MSN > http://liveearth.msn.com?source=msntaglineliveearthhm > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From alex.flint at gmail.com Mon Jun 4 21:31:49 2007 From: alex.flint at gmail.com (Alex Flint) Date: Tue, 5 Jun 2007 13:01:49 +0930 Subject: [Rxtx] random EXCEPTION_ACCESS_VIOLATION errors Message-ID: Hi All, I'm running winXP and RXTX 2.1-7r2 (the latest from the webpage as of June 2007). I'm sending sequences of 64 lines (each line has about 15 chars) at various intervals. The strings are sent fine, until I get the following error (from hs_err_pid3316.log, at the end of this email). What can I do to avoid the error? Obviously this is a low-level memory exception, but is there any way I can keep the JVM running after such an error? I noticed the exact same problem here: http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20070129/1180520.html Cheers, Alex # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x100034fb, pid=3316, tid=2400 # # Java VM: Java HotSpot(TM) Client VM (1.6.0_01-b06 mixed mode, sharing) # Problematic frame: # C [rxtxSerial.dll+0x34fb] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # --------------- T H R E A D --------------- Current thread (0x00386400): JavaThread "main" [_thread_in_native, id=2400] siginfo: ExceptionCode=0xc0000005, reading address 0x20726f78 Registers: EAX=0x20726f20, EBX=0x6d8922c0, ECX=0x00000005, EDX=0x20726f20 ESP=0x003efa30, EBP=0x003efb68, ESI=0x269728a0, EDI=0x00386400 EIP=0x100034fb, EFLAGS=0x00010212 Top of Stack: (sp=0x003efa30) 0x003efa30: 003efa3c 003efa64 0000000f ffffffff 0x003efa40: 003efa40 2a97f808 003efa6c 2b190ca8 0x003efa50: 00000000 2b190ec0 003efa90 008e2dd7 0x003efa60: 003efa90 008e2dd7 26977f88 6d815e72 0x003efa70: 00000004 2696eae0 0000008a 003efb0c 0x003efa80: 6d852b4a 2696eae0 00000003 26970930 0x003efa90: 000000cb 2696eae0 6d86b264 00385d40 0x003efaa0: 0000003f 003efb0c 26977f90 2ace65d8 Instructions: (pc=0x100034fb) 0x100034eb: ff ff 8d 76 00 eb 02 89 f6 90 8b 45 f8 8b 55 f8 0x100034fb: 8b 4a 58 83 c9 04 89 48 58 83 c4 f8 8b 45 f8 8b Stack: [0x003a0000,0x003f0000), sp=0x003efa30, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x34fb] Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j gnu.io.RXTXPort.writeArray([BIIZ)V+0 j gnu.io.RXTXPort$SerialOutputStream.write([B)V+76 j com.bjt.media.server.CommLink.send(Ljava/lang/String;)V+48 j com.bjt.media.server.DigitoolConnection.select(I)V+73 j com.bjt.media.server.DigitoolConnection.main([Ljava/lang/String;)V+74 v ~StubRoutines::call_stub --------------- P R O C E S S --------------- Java Threads: ( => current thread ) 0x02a69400 JavaThread "Thread-0" [_thread_in_native, id=3052] 0x02a4d000 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=3920] 0x02a48400 JavaThread "CompilerThread0" daemon [_thread_blocked, id=1968] 0x02a47400 JavaThread "Attach Listener" daemon [_thread_blocked, id=2984] 0x02a46400 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=2660] 0x02a41c00 JavaThread "Finalizer" daemon [_thread_blocked, id=3924] 0x02a3d800 JavaThread "Reference Handler" daemon [_thread_blocked, id=4008] =>0x00386400 JavaThread "main" [_thread_in_native, id=2400] Other Threads: 0x02a34400 VMThread [id=3708] 0x02a4e800 WatcherThread [id=3964] VM state:not at safepoint (normal execution) VM Mutex/Monitor currently owned by a thread: None Heap def new generation total 960K, used 131K [0x22960000, 0x22a60000, 0x22e40000) eden space 896K, 7% used [0x22960000, 0x22970ea8, 0x22a40000) from space 64K, 99% used [0x22a50000, 0x22a5fff8, 0x22a60000) to space 64K, 0% used [0x22a40000, 0x22a40000, 0x22a50000) tenured generation total 4096K, used 76K [0x22e40000, 0x23240000, 0x26960000) the space 4096K, 1% used [0x22e40000, 0x22e53060, 0x22e53200, 0x23240000) compacting perm gen total 12288K, used 137K [0x26960000, 0x27560000, 0x2a960000) the space 12288K, 1% used [0x26960000, 0x26982518, 0x26982600, 0x27560000) ro space 8192K, 62% used [0x2a960000, 0x2ae5e4e8, 0x2ae5e600, 0x2b160000) rw space 12288K, 52% used [0x2b160000, 0x2b7a0e78, 0x2b7a1000, 0x2bd60000) Dynamic libraries: 0x00400000 - 0x00423000 C:\Program Files\Java\jre1.6.0_01\bin\javaw.exe 0x7c900000 - 0x7c9b0000 C:\WINDOWS\system32\ntdll.dll 0x7c800000 - 0x7c8f4000 C:\WINDOWS\system32\kernel32.dll 0x77dd0000 - 0x77e6b000 C:\WINDOWS\system32\ADVAPI32.dll 0x77e70000 - 0x77f01000 C:\WINDOWS\system32\RPCRT4.dll 0x7e410000 - 0x7e4a0000 C:\WINDOWS\system32\USER32.dll 0x77f10000 - 0x77f57000 C:\WINDOWS\system32\GDI32.dll 0x76390000 - 0x763ad000 C:\WINDOWS\system32\IMM32.DLL 0x7c340000 - 0x7c396000 C:\Program Files\Java\jre1.6.0_01\bin\msvcr71.dll 0x6d7c0000 - 0x6da07000 C:\Program Files\Java\jre1.6.0_01\bin\client\jvm.dll 0x76b40000 - 0x76b6d000 C:\WINDOWS\system32\WINMM.dll 0x5cd70000 - 0x5cd77000 C:\WINDOWS\system32\serwvdrv.dll 0x5b0a0000 - 0x5b0a7000 C:\WINDOWS\system32\umdmxfrm.dll 0x6d310000 - 0x6d318000 C:\Program Files\Java\jre1.6.0_01\bin\hpi.dll 0x76bf0000 - 0x76bfb000 C:\WINDOWS\system32\PSAPI.DLL 0x6d770000 - 0x6d77c000 C:\Program Files\Java\jre1.6.0_01\bin\verify.dll 0x6d3b0000 - 0x6d3cf000 C:\Program Files\Java\jre1.6.0_01\bin\java.dll 0x6d7b0000 - 0x6d7bf000 C:\Program Files\Java\jre1.6.0_01\bin\zip.dll 0x10000000 - 0x10012000 C:\Documents and Settings\Alex\workspace\MediaServer\rxtxSerial.dll 0x73d90000 - 0x73db7000 C:\WINDOWS\system32\crtdll.dll VM Arguments: jvm_args: -Djava.library.path=C:\Documents and Settings\Alex\workspace\MediaServer java_command: com.bjt.media.server.DigitoolConnection Launcher Type: SUN_STANDARD Environment Variables: CLASSPATH=.;C:\Program Files\Java\j2re1.4.2_07\lib\ext\QTJava.zip PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\wbem;c:\applications\php;C:\Program Files\MATLAB\R2006a\bin\win32;C:\Roger\Projects\UAV\Bin\Debug;C:\Program Files\Microsoft SQL Server\80\Tools\Binn\;c:\Program Files\Microsoft SQL Server\90\Tools\binn\;C:\Program Files\QuickTime\QTSystem\;C:\Pfps\system;C:\Program Files\Java\jdk1.6.0_01\bin;C:\Program Files\Java\jdk1.6.0_01\jre\bin USERNAME=Alex OS=Windows_NT PROCESSOR_IDENTIFIER=x86 Family 15 Model 4 Stepping 1, GenuineIntel --------------- S Y S T E M --------------- OS: Windows XP Build 2600 Service Pack 2 CPU:total 1 family 15, cmov, cx8, fxsr, mmx, sse, sse2 Memory: 4k page, physical 1046508k(275288k free), swap 2522816k(1909176k free) vm_info: Java HotSpot(TM) Client VM (1.6.0_01-b06) for windows-x86, built on Mar 14 2007 00:24:02 by "java_re" with unknown MS VC++:1310 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070604/c87ae1f0/attachment-0008.html From alwyn.schoeman at gmail.com Tue Jun 5 00:10:19 2007 From: alwyn.schoeman at gmail.com (Alwyn Schoeman) Date: Tue, 5 Jun 2007 08:10:19 +0200 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Hi, I'm using a similar modem. By default rxtx doesn't look for devices that start with ACM, so you need to modify the source code and recompile. Look in RXTXCommDriver and add values for ACM in the registerScannedPorts method in the Linux specific parts. Look for osName.equals("Linux")... On 6/4/07, soop soop wrote: > > Hi Guys, > > Looked through the archives but still cannot figure this out. I have a > Motorola G24 GPRS/GSM modem that I am connecting to my server running > Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not > detecting the port, CommPortIdentifier.getPortIdentifiers(). > > I have added the line to RXTXCommDriver: > > "ttyACM" // for USB Modems > > Rxtx still does not seem to find the port. Is there something I am missing > to make this port visable? > > [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver > [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device > [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control > Model > driver for USB modems and ISDN adapters > > I really need your help as I have moved my server from windows to Linux > and > have been down for a few days because of this .. Thanks so much! > > _________________________________________________________________ > PC Magazine's 2007 editors' choice for best Web mail?award-winning Windows > Live Hotmail. > > http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -- Alwyn Schoeman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/b6cb3053/attachment-0008.html From naranjo.manuel at gmail.com Tue Jun 5 06:48:45 2007 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Tue, 05 Jun 2007 09:48:45 -0300 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> References: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Message-ID: <46655BAD.7010501@gmail.com> That's right, an easier solution is creating symlinks to acm. For example make ttyS70 to 79 point to ACM0 to 9 and that will help you a lot, and doesn't even require compile. > Hi, > > I'm using a similar modem. By default rxtx doesn't look for devices > that start with ACM, so you need to modify the > source code and recompile. > > Look in RXTXCommDriver and add values for ACM in the > registerScannedPorts method in the Linux specific parts. Look for > osName.equals("Linux")... > From juanemc2 at gmail.com Tue Jun 5 07:02:43 2007 From: juanemc2 at gmail.com (Juan) Date: Tue, 5 Jun 2007 10:02:43 -0300 Subject: [Rxtx] Problems with Epson TMU220B POSPrinter using XON/XOFF Flow Control and rxtx jar and dll's with the serial port. Message-ID: Hi!, I?m having trouble printing to the serial port using the latest version of rxtx jar and dll's with an Epson POSPrinter. I`ve switched the printer to work with XON/XOFF Flow Control and have watched the serial port to be sure the printer is sending the XON XOFF stop and go characters. I`ve setted the port like this: CommPortIdentifier commPortIdentifier = CommPortIdentifier.* getPortIdentifier*(_portName); SerialPort serialPort = (SerialPort)commPortIdentifier.open(*this*.getClass().getName(), 2000); serialPort.setSerialPortParams(_baudRate, _dataBits, _stopBits, _parity); serialPort.setFlowControlMode( SerialPort.*FLOWCONTROL_XONXOFF_IN* | SerialPort.*FLOWCONTROL_XONXOFF_OUT*); where the baudRate is 9600 the dataBits is 8 the stopBits is 1 and the parity is 0 It seems as the library isn`t taking into account the XON XOFF setting. I would like to know if I`m setting correctly the Flow Control and if you had had any experiences using XON XOFF flow control and could give me some help to solve my problem. I`m very thankful in advance, Yours, Juan Polero -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/b080995a/attachment-0008.html From ehdez.correo at gmail.com Tue Jun 5 07:12:53 2007 From: ehdez.correo at gmail.com (=?ISO-8859-1?Q?Enrique_Hern=E1ndez?=) Date: Tue, 5 Jun 2007 09:12:53 -0400 Subject: [Rxtx] problem with rxtx Message-ID: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Hello: I doing a simple test to show the serial ports. This is the code: import java.util.Enumeration; import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; public class Show { private Enumeration portList; private CommPortIdentifier portId; private SerialPort port; /** Creates a new instance of Show */ public Show() { } public static void main(String args[]){ Show show = new Show(); show.portList = CommPortIdentifier.getPortIdentifiers(); String tPort = ""; System.out.println("========================================="); while(show.portList.hasMoreElements()){ show.portId = (CommPortIdentifier)show.portList.nextElement(); if(show.portId.getPortType() == CommPortIdentifier.PORT_SERIAL) tPort = "Serial"; else tPort = "Parallel"; System.out.println(show.portId.getName() + " " + tPort); } } } whit The problem is that this code not show the serial ports, this show the no use serial ports. I want to connect whit the modem but when windows open and connect the modem my application don't see the port(COMM3) when it is connect. what I can do? Is that the correct way to know the ports? thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/eedd744b/attachment-0008.html From ehdez.correo at gmail.com Tue Jun 5 07:42:13 2007 From: ehdez.correo at gmail.com (=?ISO-8859-1?Q?Enrique_Hern=E1ndez?=) Date: Tue, 5 Jun 2007 09:42:13 -0400 Subject: [Rxtx] serial port Message-ID: <4a814e1f0706050642p4ce9ac7bka80f9479c524c5ea@mail.gmail.com> Hello: How I can ask to the port what device is connect and information about this device. thanks. bye. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/4d10d26a/attachment-0008.html From supsoop at hotmail.com Tue Jun 5 09:29:00 2007 From: supsoop at hotmail.com (soop soop) Date: Tue, 05 Jun 2007 15:29:00 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Message-ID: Hi Guys, Thanks for all your help. I found the problem. I created a user, Tomcat55, for my tomcat but it did not belong to any group. I then added this user to dialout group to have access to the device ttyACM0. Works perfectly! Again permissions was the issue. This also seems to be persistent as a server reboot does not effect the access. Cheers! >From: "Alwyn Schoeman" >Reply-To: RXTX Developers and Users >To: "RXTX Developers and Users" >Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >Date: Tue, 5 Jun 2007 08:10:19 +0200 > >Hi, > >I'm using a similar modem. By default rxtx doesn't look for devices that >start with ACM, so you need to modify the >source code and recompile. > >Look in RXTXCommDriver and add values for ACM in the registerScannedPorts >method in the Linux specific parts. Look for osName.equals("Linux")... > >On 6/4/07, soop soop wrote: >> >>Hi Guys, >> >>Looked through the archives but still cannot figure this out. I have a >>Motorola G24 GPRS/GSM modem that I am connecting to my server running >>Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not >>detecting the port, CommPortIdentifier.getPortIdentifiers(). >> >>I have added the line to RXTXCommDriver: >> >>"ttyACM" // for USB Modems >> >>Rxtx still does not seem to find the port. Is there something I am missing >>to make this port visable? >> >>[ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver >>[ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device >>[ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control >>Model >>driver for USB modems and ISDN adapters >> >>I really need your help as I have moved my server from windows to Linux >>and >>have been down for a few days because of this .. Thanks so much! >> >>_________________________________________________________________ >>PC Magazine's 2007 editors' choice for best Web mail—award-winning Windows >>Live Hotmail. >> >>http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 >> >> >>_______________________________________________ >>Rxtx mailing list >>Rxtx at qbang.org >>http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > >-- >Alwyn Schoeman >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ Need a break? Find your escape route with Live Search Maps. http://maps.live.com/default.aspx?ss=Restaurants~Hotels~Amusement%20Park&cp=33.832922~-117.915659&style=r&lvl=13&tilt=-90&dir=0&alt=-1000&scene=1118863&encType=1&FORM=MGAC01 From netbeans at gatworks.com Tue Jun 5 09:42:31 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 11:42:31 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <46658467.20101@gatworks.com> soop soop wrote: > > Hi Guys, > > Thanks for all your help. I found the problem. I created a user, > Tomcat55, for my tomcat but it did not belong to any group. I then added Look at man pages for the program udev. From tjarvi at qbang.org Tue Jun 5 18:18:17 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Jun 2007 18:18:17 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Message-ID: On Tue, 5 Jun 2007, Enrique Hern?ndez wrote: > The problem is that this code not show the serial ports, this show the no > use serial ports. I want to connect whit the modem but when windows open and > connect the modem my application don't see the port(COMM3) when it is > connect. > what I can do? > Is that the correct way to know the ports? > Hello, We may have problems understanding each other. On windows, the port will not be an available serial port if another application has the port open. That is just how the library behaves. If you can not see the port in the enumerated list, you could not open it. Also note that enumeration only happens once. If you add a port such as a new USB dongle, the port will not be visible until the next time your application runs. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Tue Jun 5 18:45:01 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 20:45:01 -0400 Subject: [Rxtx] problem with rxtx In-Reply-To: References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Message-ID: <4666038D.8090700@gatworks.com> Trent Jarvi wrote: > > > Also note that enumeration only happens once. If you add a port such as > a new USB dongle, the port will not be visible until the next time your > application runs. Is this written in stone ? somewhere? From tjarvi at qbang.org Tue Jun 5 18:54:36 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Jun 2007 18:54:36 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <4666038D.8090700@gatworks.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> Message-ID: On Tue, 5 Jun 2007, Uncle George wrote: > Trent Jarvi wrote: >> >> >> Also note that enumeration only happens once. If you add a port such as >> a new USB dongle, the port will not be visible until the next time your >> application runs. > > Is this written in stone ? somewhere? It is just the current behavior. There is nothing preventing a fix that allows reenumeration. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Tue Jun 5 19:55:19 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 21:55:19 -0400 Subject: [Rxtx] problem with rxtx In-Reply-To: References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> Message-ID: <46661407.4020308@gatworks.com> >> Is this written in stone ? somewhere? > > It is just the current behavior. There is nothing preventing a fix that > allows reenumeration. With usb, ..... , things come and go. Seems a shame that you have to kill application to get at the device u just plugged in. From joachim at buechse.ch Wed Jun 6 01:50:06 2007 From: joachim at buechse.ch (Joachim Buechse) Date: Wed, 6 Jun 2007 09:50:06 +0200 Subject: [Rxtx] problem with rxtx In-Reply-To: <46661407.4020308@gatworks.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> <46661407.4020308@gatworks.com> Message-ID: <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> On MacOS RXTX's enumeration handling is more flexible. It will find new ports that are added during the lifetime of the application. But this is inherently incompatible with suns javax.comm implementation... Regards, Joachim On 06.06.2007, at 03:55, Uncle George wrote: > >>> Is this written in stone ? somewhere? >> >> It is just the current behavior. There is nothing preventing a >> fix that >> allows reenumeration. > > With usb, ..... , things come and go. Seems a shame that you have to > kill application to get at the device u just plugged in. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Jun 6 06:06:48 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Jun 2007 06:06:48 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> <46661407.4020308@gatworks.com> <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> Message-ID: Sun's javax.comm is not a major concern going forward. As long as we do not break old applications using rxtx, I see no reason to limit rxtx to that convention. We have already rejected version 3 from Sun as a dead end and limited our compatability to version 2. That does not mean we will not try to work with Sun and others but the current javax.comm convention (v3) is not a well conceived path. There has been discussion about doing a JSR which is one valid option. On Wed, 6 Jun 2007, Joachim Buechse wrote: > On MacOS RXTX's enumeration handling is more flexible. It will find > new ports that are added during the lifetime of the application. But > this is inherently incompatible with suns javax.comm implementation... > > Regards, > Joachim > > On 06.06.2007, at 03:55, Uncle George wrote: > >> >>>> Is this written in stone ? somewhere? >>> >>> It is just the current behavior. There is nothing preventing a >>> fix that >>> allows reenumeration. >> >> With usb, ..... , things come and go. Seems a shame that you have to >> kill application to get at the device u just plugged in. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From yvespielusenet at free.fr Wed Jun 6 08:46:35 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 16:46:35 +0200 Subject: [Rxtx] [PARALLEL] resource in use Message-ID: <1181141195.3407.20.camel@localhost.localdomain> Hello, I want to use rxtx in my application. I haveto send data to a very old printer (which have a drum and hammers http://perso.orange.fr/tiie/page00010017.html) This is printer is connecter with centronics. It works well but, while it's writting and I putthe printer off-line, after about 45 seconds, I have this error : ------------------------------------- java.io.IOException: La ressource demand?e est en cours d'utilisation. in writeArray at gnu.io.LPRPort.writeArray(Native Method) at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:292) at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:161) at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:156) at mce.buffer.bufferManager.BufferManager$PrintBuffer.run(BufferManager.java:141) The IOexception means "The wanted resource is in use" ------------------------------------- Here is the line 141 of BufferManager : ------------------------------------- while(send){ try{ fos.write(bb); <=== line 141 send = false; } catch(Exception e){ javax.swing.JOptionPane.showMessageDialog(null, "Erreur d'envoie. Veuillez cliquer sur OK pour relancer l'impression de la vignette.\nV?rifiez votre impression !", "Erreur d'envoie", javax.swing.JOptionPane.WARNING_MESSAGE); e.printStackTrace(System.err); System.err.flush(); System.out.println(e); send = true; } } -------------------------------- 'fos' is an outputstream which contains the rxtx stream (this.os is the rxtx outputstream) : -------------------------------- public void write(byte[] bb) throws IOException{ this.write(bb, 0, bb.length); } public void write(byte[] bb, int off, int len) throws IOException{ while(!imp1.isPrinterSelected() || !imp2.isPrinterSelected()){ } this.os.write(bb, off, len); } -------------------------------- Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( can you help me ? thank you :) -- yves piel From yvespielusenet at free.fr Wed Jun 6 09:11:15 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 17:11:15 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181141195.3407.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> Message-ID: <1181142675.3407.23.camel@localhost.localdomain> I forgot to tell that It's under windows XP and java 1.5. Le mercredi 06 juin 2007 ? 16:46 +0200, yves pielusenet a ?crit : > Hello, > I want to use rxtx in my application. I haveto send data to a very old > printer (which have a drum and hammers > http://perso.orange.fr/tiie/page00010017.html) > This is printer is connecter with centronics. It works well but, while > it's writting and I putthe printer off-line, after about 45 seconds, I > have this error : > ------------------------------------- > java.io.IOException: La ressource demand?e est en cours d'utilisation. > in writeArray > at gnu.io.LPRPort.writeArray(Native Method) > at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:292) > at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:161) > at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:156) > at mce.buffer.bufferManager.BufferManager$PrintBuffer.run(BufferManager.java:141) > > The IOexception means "The wanted resource is in use" > ------------------------------------- > > Here is the line 141 of BufferManager : > > ------------------------------------- > while(send){ > try{ > fos.write(bb); <=== line 141 > send = false; > } > catch(Exception e){ > javax.swing.JOptionPane.showMessageDialog(null, "Erreur d'envoie. Veuillez cliquer sur OK pour relancer l'impression de la vignette.\nV?rifiez votre impression !", "Erreur d'envoie", javax.swing.JOptionPane.WARNING_MESSAGE); > e.printStackTrace(System.err); > System.err.flush(); > System.out.println(e); > send = true; > } > } > -------------------------------- > 'fos' is an outputstream which contains the rxtx stream (this.os is the rxtx outputstream) : > > -------------------------------- > public void write(byte[] bb) throws IOException{ > this.write(bb, 0, bb.length); > } > public void write(byte[] bb, int off, int len) throws IOException{ > while(!imp1.isPrinterSelected() || !imp2.isPrinterSelected()){ > } > this.os.write(bb, off, len); > } > -------------------------------- > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > can you help me ? > > thank you :) > From netbeans at gatworks.com Wed Jun 6 09:21:46 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 11:21:46 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181141195.3407.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> Message-ID: <4666D10A.8000507@gatworks.com> } > -------------------------------- > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > can you help me ? > > thank you :) > windoz or linux? ( I guess windoz ) for windoz, there appears to be a timeout ( as Comments suggest ) of about 40seconds. > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } for linux, there is no implied timeout. > if( write( fd, bytes, count ) < 0 ) > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); From netbeans at gatworks.com Wed Jun 6 09:39:41 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 11:39:41 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666D10A.8000507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> Message-ID: <4666D53D.90000@gatworks.com> Uncle George wrote: > } >> -------------------------------- >> >> Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( >> >> can you help me ? From reading the code, I can see your concern. And it appears you are correct, because some of the data will be sent to the OS printer buffers, and then it will refuse to accept anymore. Unfortunately, writeArray does not return the num of characters written :{ So application has no idea to how many characters were accepted by the OS. I dont do windoz, so I cant say with absolute certainty what windoz will do with an off-line condition. If you have the source, and can compile, then maybe u can increase the loop count to hit 4hours? From yvespielusenet at free.fr Wed Jun 6 09:53:25 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 17:53:25 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666D10A.8000507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> Message-ID: <1181145205.3407.35.camel@localhost.localdomain> Thank you for your explanation :) This timeout comes when no data has been send to the printer after 40seconds if I well understand. But why there is such a timeout ? If I setthe printer offline while it's printing I mustn't have an exception. I don't understand why the "printer should solv all problems like buffer full" in 40 seconds. If I pause the printer the buffer will not be emptied, isn't it ? I not very familiar with C/C++, but it seem that the exception is thrown only when countWritten == 0, that means no data at all has been sent. So Is my code is good since when I intercept this exception I send all my buffer again. There is no way that the printer receive two times same bytes ? thanks ps: yes the application is running on windows XP since I developpe under Debian Le mercredi 06 juin 2007 ? 11:21 -0400, Uncle George a ?crit : > } > > -------------------------------- > > > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > > > can you help me ? > > > > thank you :) > > > > windoz or linux? ( I guess windoz ) > > for windoz, there appears to be a timeout ( as Comments suggest ) of > about 40seconds. > > while( count > 0 ){ > > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > > /* > > this are 20 * 2 seconds, in this time a printer (or other parallel device) > > should solv all problems like buffer full, etc > > */ > > if(errorCount++ < 20){ > > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > > continue; > > } > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > for linux, there is no implied timeout. > > if( write( fd, bytes, count ) < 0 ) > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Wed Jun 6 10:34:24 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 12:34:24 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181145205.3407.35.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> Message-ID: <4666E210.30507@gatworks.com> yves pielusenet wrote: > Thank you for your explanation :) > This timeout comes when no data has been send to the printer after > 40seconds if I well understand. But why there is such a timeout ? If I > setthe printer offline while it's printing I mustn't have an exception. > I don't understand why the "printer should solv all problems like buffer > full" in 40 seconds. If I pause the printer the buffer will not be > emptied, isn't it ? > > I not very familiar with C/C++, but it seem that the exception is thrown > only when countWritten == 0, that means no data at all has been sent. So > Is my code is good since when I intercept this exception I send all my > buffer again. There is no way that the printer receive two times same > bytes ? More technically, the function call returns and reports that 0 characters was written in this call. when 0 characters are written, it will check how many times 0 characters was written. If it has tried LESS than 20 times(errorCount), it will sleep() and try to write again. After 20 times, it wont sleep, but throw you the exception. Now suppose you are writing a 120 character line. you off-lined/paused your printer. The OS has room for 80 more characters in it's printer buffer. The WriteFile() will have a char count of 120, but on return the countWritten = 80. You still have 40 more characters to print. Since countWritten != 0, the counters: bytes += countWritten; count -= countWritten; get updated, and the Writefile now has a count of 40 characters. Since the printer is off-line, the countwritten is 0. And so the loop continues, till 40 seconds is up. As to why it is this way, i dont know ( not a windoz maven ); Also the sleep(20) in the loop is not so intuitive to suggest 2 seconds of sleep. I would have guessed 20seconds, or 20milliseconds. But go figure. BTW: Since your computer sends you error messages in French, does it curse in English? :)))) From yvespielusenet at free.fr Thu Jun 7 02:27:44 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Thu, 07 Jun 2007 10:27:44 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666E210.30507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> Message-ID: <1181204864.3501.10.camel@localhost.localdomain> Maybe in my case I should re-compile rxtx and change the code. Instead of send an exception I should display a dialog box to ask if it's printer problem or if it should trie to send bytes. Something like : while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } if(displayDialogBox("Try again to send datas ??")){ errorCount = 0; } else{ throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } } Le mercredi 06 juin 2007 ? 12:34 -0400, Uncle George a ?crit : > yves pielusenet wrote: > > Thank you for your explanation :) > > This timeout comes when no data has been send to the printer after > > 40seconds if I well understand. But why there is such a timeout ? If I > > setthe printer offline while it's printing I mustn't have an exception. > > I don't understand why the "printer should solv all problems like buffer > > full" in 40 seconds. If I pause the printer the buffer will not be > > emptied, isn't it ? > > > > I not very familiar with C/C++, but it seem that the exception is thrown > > only when countWritten == 0, that means no data at all has been sent. So > > Is my code is good since when I intercept this exception I send all my > > buffer again. There is no way that the printer receive two times same > > bytes ? > More technically, the function call returns and reports that 0 > characters was written in this call. > when 0 characters are written, it will check how many times 0 characters > was written. If it has tried LESS than 20 times(errorCount), it will > sleep() and try to write again. > After 20 times, it wont sleep, but throw you the exception. > > Now suppose you are writing a 120 character line. you off-lined/paused > your printer. The OS has room for 80 more characters in it's printer > buffer. The WriteFile() will have a char count of 120, but on return the > countWritten = 80. You still have 40 more characters to print. > Since countWritten != 0, the counters: > bytes += countWritten; > count -= countWritten; > get updated, and the Writefile now has a count of 40 characters. Since > the printer is off-line, the countwritten is 0. And so the loop > continues, till 40 seconds is up. > > As to why it is this way, i dont know ( not a windoz maven ); > Also the sleep(20) in the loop is not so intuitive to suggest 2 seconds > of sleep. I would have guessed 20seconds, or 20milliseconds. But go figure. > > BTW: Since your computer sends you error messages in French, does it > curse in English? :)))) > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 06:11:43 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 08:11:43 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181204864.3501.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> Message-ID: <4667F5FF.8070903@gatworks.com> your suggestion appears good. I dont know what displayDialogBox exactly will do, so all I can say it that it looks good. But I'd like to wait 10min before first dialog box And a 5 min wait for every dialog box there after. And since these are custom solution/choices, maybe a more exact explanation of what the issue is. if(errorCount++ < 300){ // wait 10min ( 10min * 60sec / 2 ) Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } if(displayDialogBox("Printer has Paused. Retry sending data?")){ errorCount = 150; // Wait for 5 min thereafter continue; } > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } yves pielusenet wrote: > Maybe in my case I should re-compile rxtx and change the code. Instead > of send an exception I should display a dialog box to ask if it's > printer problem or if it should trie to send bytes. Something like : > > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > > if(displayDialogBox("Try again to send datas ??")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > } > From yvespielusenet at free.fr Thu Jun 7 07:17:21 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Thu, 07 Jun 2007 15:17:21 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4667F5FF.8070903@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <4667F5FF.8070903@gatworks.com> Message-ID: <1181222241.3501.20.camel@localhost.localdomain> thank you :) 'displayDialogBox()' I think doesn't exist. It was just for the example :) But I think It should not be so complicated to display a dialog box under windows with YES/NO buttons. When yes is clicked it return 0 other it returns 1. Le jeudi 07 juin 2007 ? 08:11 -0400, Uncle George a ?crit : > your suggestion appears good. I dont know what displayDialogBox exactly > will do, so all I can say it that it looks good. > > But I'd like to wait 10min before first dialog box And a 5 min wait for > every dialog box there after. And since these are custom > solution/choices, maybe a more exact explanation of what the issue is. > > if(errorCount++ < 300){ // wait 10min ( 10min * 60sec / 2 ) > Sleep( 20 ); /* make a small pause to execute all other requests > in all other threads */ > continue; > } > > if(displayDialogBox("Printer has Paused. Retry sending data?")){ > errorCount = 150; // Wait for 5 min thereafter > continue; > } > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > > yves pielusenet wrote: > > Maybe in my case I should re-compile rxtx and change the code. Instead > > of send an exception I should display a dialog box to ask if it's > > printer problem or if it should trie to send bytes. Something like : > > > > while( count > 0 ){ > > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > > /* > > this are 20 * 2 seconds, in this time a printer (or other parallel device) > > should solv all problems like buffer full, etc > > */ > > if(errorCount++ < 20){ > > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > > continue; > > } > > > > if(displayDialogBox("Try again to send datas ??")){ > > errorCount = 0; > > } > > else{ > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > } > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 07:41:43 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 09:41:43 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181222241.3501.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <4667F5FF.8070903@gatworks.com> <1181222241.3501.20.camel@localhost.localdomain> Message-ID: <46680B17.8050109@gatworks.com> yves pielusenet wrote: > thank you :) > 'displayDialogBox()' I think doesn't exist. It was just for the > example :) too bad. Good luck. From rtrout at webbresearch.com Thu Jun 7 11:23:04 2007 From: rtrout at webbresearch.com (Robert Trout) Date: Thu, 07 Jun 2007 13:23:04 -0400 Subject: [Rxtx] Disconnected PortServer TS causes Java to hang Message-ID: <1181236984.14186.33.camel@sisyphus.DinkumSoftware.com> I'm running Linux with sun's Java 1.4.2, Java comm API 2.0, RXTX 2.0-7pre1, and the RealPort digi driver. "/dev/ttyrp00" is a RealPort device. My Java application never returns from a ComPortIdentifier.getPortIdentifier("/dev/ttyrp00") call while the Digi PortServer TS 4 is disconnected from the network. If I later re-connect the PortServer, the call returns about 30 seconds later (it's like a serial port read or write is blocking until the PortServer is re- connected). With the PortServer disconnected, minicom immediately responds with "cannot open /dev/ttyrp00: No such file or directory". I would like my Java application to behave similarly. That is, respond with an error condition instead of hanging when the PortServer is not connected. Since minicom and Java behave differently, I think this "hanging" behavior may be due to RXTX or Java? Has anyone had a similar issue? Solutions? Suggestions? Thanks, Robert From vicnevicne at gmail.com Thu Jun 7 12:16:02 2007 From: vicnevicne at gmail.com (Vicne) Date: Thu, 07 Jun 2007 20:16:02 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181204864.3501.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> Message-ID: <46684B62.7080802@gmail.com> yves pielusenet wrote: > Maybe in my case I should re-compile rxtx and change the code. Instead > of send an exception I should display a dialog box to ask if it's > printer problem or if it should trie to send bytes. Something like : > > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > > if(displayDialogBox("Try again to send datas ??")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > } > Sorry to step in without a specific solution to your problem, but I wanted to share my feeling regarding this proposal. AFAIK, it's generally considered bad practice to pop-up a prompt from a library. The main reason is that in general use, you can't guarantee that someone is actually present behind the console. Imagine a print server in a machine room, connected to a park of printers. In that case, when one printer fails, the logical behaviour would be to use an other one. If you change RxTx the way you propose, the printer queue will simply be stuck with a useless "Try again to send data ?" prompt until an administrator opens a remote connection to the print server's console and clicks "no". Second, it would create a dependency upon the existence of a graphical console (if you go the graphical "dialogBox" way). On many applications (typically server or embedded ones), the JVM is "headless" and if you try to pop-up a dialog, your app would throw an exception (at best) or just wouldn't display the prompt anywhere... Going the "text console" way is not more reliable, because on graphical environments, the text console is hidden unless explicitly requested. My advice would be to think again and find another solution. Ideas are : - make the number of retries a parameter so that you can tune it to what you think is reasonable - throw a more specific exception when the number of retries has been reached, so that a specific prompt can be shown at a higher level Anyway, if you feel that the prompt is the way to go in your case, I would at least make that prompt conditional. The least intrusive way would probably be using a system property, like if("true".equals(System.getProperty("org.rxtx.usePrompt")) && displayDialogBox("Retry sending data ?")){ errorCount = 0; } else{ throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } By default, the behaviour would remain as it is now, but you could force the prompts by defining the property at VM launch if desired. (for example : java.exe -Dorg.rxtx.usePrompt=true myApp) Also, you seemed to say you wanted the printer to start again exactly where is stopped. It would indeed be the best way when the printer is put offline for a few seconds. On the other hand, if the printer is turned off (or the printer runs out of paper, or someone steps on the mains cable), then the only way to go back to a "stable" situation would be by printing the item (page, label, etc.) again from scratch... Just my two cents. Vicne PS : By the way, the dialog box thing is very platform dependant on the C-side, and I think the simplest way would probably be to bridge it to a Java call where you can implement it like you proposed : public boolean displayDialogBox(prompt) { return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); } From netbeans at gatworks.com Thu Jun 7 14:08:24 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 16:08:24 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46684B62.7080802@gmail.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> Message-ID: <466865B8.4060004@gatworks.com> My feeling is that the code that was suggested was for his environs ( his shop ). The issue here is that after a 40+ second wait, an exception will be thrown. But you really dont have a way of 'cancelling' all the WriteFiles() that have already occured before the exception so that your writeArray and the Commapi can backtrack to a position in which they are in sync. The main ( really mine ) concern is not to lose data, or replicate data. After 40seconds, 300 seconds, 55min, no matter how long, data should not be lost or duplicated. But as soon as the exception is thrown, that possibility exists. Maybe an event should be thrown instead? Vicne wrote: > yves pielusenet wrote: >> Maybe in my case I should re-compile rxtx and change the code. Instead >> of send an exception I should display a dialog box to ask if it's >> printer problem or if it should trie to send bytes. Something like : >> >> while( count > 0 ){ >> if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ >> /* >> this are 20 * 2 seconds, in this time a printer (or other parallel device) >> should solv all problems like buffer full, etc >> */ >> if(errorCount++ < 20){ >> Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ >> continue; >> } >> >> if(displayDialogBox("Try again to send datas ??")){ >> errorCount = 0; >> } >> else{ >> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >> break; >> } >> } >> > > Sorry to step in without a specific solution to your problem, but I > wanted to share my feeling regarding this proposal. AFAIK, it's > generally considered bad practice to pop-up a prompt from a library. > The main reason is that in general use, you can't guarantee that > someone is actually present behind the console. Imagine a print server > in a machine room, connected to a park of printers. In that case, when > one printer fails, the logical behaviour would be to use an other one. > If you change RxTx the way you propose, the printer queue will simply be > stuck with a useless "Try again to send data ?" prompt until an > administrator opens a remote connection to the print server's console > and clicks "no". > Second, it would create a dependency upon the existence of a > graphical console (if you go the graphical "dialogBox" way). On many > applications (typically server or embedded ones), the JVM is "headless" > and if you try to pop-up a dialog, your app would throw an exception (at > best) or just wouldn't display the prompt anywhere... Going the "text > console" way is not more reliable, because on graphical environments, > the text console is hidden unless explicitly requested. > > My advice would be to think again and find another solution. Ideas are : > - make the number of retries a parameter so that you can tune it to what > you think is reasonable > - throw a more specific exception when the number of retries has been > reached, so that a specific prompt can be shown at a higher level > > Anyway, if you feel that the prompt is the way to go in your case, I > would at least make that prompt conditional. The least intrusive way > would probably be using a system property, like > > if("true".equals(System.getProperty("org.rxtx.usePrompt")) > && displayDialogBox("Retry sending data ?")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > > > By default, the behaviour would remain as it is now, but you could > force the prompts by defining the property at VM launch if desired. (for > example : java.exe -Dorg.rxtx.usePrompt=true myApp) > > > Also, you seemed to say you wanted the printer to start again > exactly where is stopped. It would indeed be the best way when the > printer is put offline for a few seconds. On the other hand, if the > printer is turned off (or the printer runs out of paper, or someone > steps on the mains cable), then the only way to go back to a "stable" > situation would be by printing the item (page, label, etc.) again from > scratch... > > > Just my two cents. > > > Vicne > > PS : By the way, the dialog box thing is very platform dependant on the > C-side, and I think the simplest way would probably be to bridge it to a > Java call where you can implement it like you proposed : > > public boolean displayDialogBox(prompt) { > return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", > JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); > } > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Thu Jun 7 17:48:11 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 Jun 2007 17:48:11 -0600 (MDT) Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <466865B8.4060004@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> Message-ID: An event is possible. I'm amazed this is the largest problem encountered while using the parallel code. How would the write ever exit if we throw events? Isn't this going to lead to hung applications? On Thu, 7 Jun 2007, Uncle George wrote: > My feeling is that the code that was suggested was for his environs ( > his shop ). > > The issue here is that after a 40+ second wait, an exception will be > thrown. But you really dont have a way of 'cancelling' all the > WriteFiles() that have already occured before the exception so that your > writeArray and the Commapi can backtrack to a position in which they are > in sync. > > The main ( really mine ) concern is not to lose data, or replicate data. > After 40seconds, 300 seconds, 55min, no matter how long, data should > not be lost or duplicated. But as soon as the exception is thrown, that > possibility exists. > > Maybe an event should be thrown instead? > > Vicne wrote: >> yves pielusenet wrote: >>> Maybe in my case I should re-compile rxtx and change the code. Instead >>> of send an exception I should display a dialog box to ask if it's >>> printer problem or if it should trie to send bytes. Something like : >>> >>> while( count > 0 ){ >>> if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ >>> /* >>> this are 20 * 2 seconds, in this time a printer (or other parallel device) >>> should solv all problems like buffer full, etc >>> */ >>> if(errorCount++ < 20){ >>> Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ >>> continue; >>> } >>> >>> if(displayDialogBox("Try again to send datas ??")){ >>> errorCount = 0; >>> } >>> else{ >>> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >>> break; >>> } >>> } >>> >> >> Sorry to step in without a specific solution to your problem, but I >> wanted to share my feeling regarding this proposal. AFAIK, it's >> generally considered bad practice to pop-up a prompt from a library. >> The main reason is that in general use, you can't guarantee that >> someone is actually present behind the console. Imagine a print server >> in a machine room, connected to a park of printers. In that case, when >> one printer fails, the logical behaviour would be to use an other one. >> If you change RxTx the way you propose, the printer queue will simply be >> stuck with a useless "Try again to send data ?" prompt until an >> administrator opens a remote connection to the print server's console >> and clicks "no". >> Second, it would create a dependency upon the existence of a >> graphical console (if you go the graphical "dialogBox" way). On many >> applications (typically server or embedded ones), the JVM is "headless" >> and if you try to pop-up a dialog, your app would throw an exception (at >> best) or just wouldn't display the prompt anywhere... Going the "text >> console" way is not more reliable, because on graphical environments, >> the text console is hidden unless explicitly requested. >> >> My advice would be to think again and find another solution. Ideas are : >> - make the number of retries a parameter so that you can tune it to what >> you think is reasonable >> - throw a more specific exception when the number of retries has been >> reached, so that a specific prompt can be shown at a higher level >> >> Anyway, if you feel that the prompt is the way to go in your case, I >> would at least make that prompt conditional. The least intrusive way >> would probably be using a system property, like >> >> if("true".equals(System.getProperty("org.rxtx.usePrompt")) >> && displayDialogBox("Retry sending data ?")){ >> errorCount = 0; >> } >> else{ >> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >> break; >> } >> >> >> By default, the behaviour would remain as it is now, but you could >> force the prompts by defining the property at VM launch if desired. (for >> example : java.exe -Dorg.rxtx.usePrompt=true myApp) >> >> >> Also, you seemed to say you wanted the printer to start again >> exactly where is stopped. It would indeed be the best way when the >> printer is put offline for a few seconds. On the other hand, if the >> printer is turned off (or the printer runs out of paper, or someone >> steps on the mains cable), then the only way to go back to a "stable" >> situation would be by printing the item (page, label, etc.) again from >> scratch... >> >> >> Just my two cents. >> >> >> Vicne >> >> PS : By the way, the dialog box thing is very platform dependant on the >> C-side, and I think the simplest way would probably be to bridge it to a >> Java call where you can implement it like you proposed : >> >> public boolean displayDialogBox(prompt) { >> return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", >> JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); >> } >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 19:18:51 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 21:18:51 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> Message-ID: <4668AE7B.3060409@gatworks.com> The UNIX version of writeArray is not too great either. It is possible that the write will only process some of the bytes. #else if( write( fd, bytes, count ) < 0 ) throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); #endif -------------------------------- Maybe it might be better to have the native function inform the caller of the # of characters written, then the commapi/output-buffer can be modified to reflect the #of chars written. If an exception is to be thrown, for too many loops of chars written == 0, then exception wont affect the state of the output buffer. Then a ParallelPort.restart() can be called to resume printing whats in the buffer. Trent Jarvi wrote: > An event is possible. I'm amazed this is the largest problem encountered > while using the parallel code. > > How would the write ever exit if we throw events? Isn't this going to > lead to hung applications? Sure. If you dont time out, then there is nothing that will force an EXIT from the write(). Issue is what has the OS done with the write. > > On Thu, 7 Jun 2007, Uncle George wrote: > >> My feeling is that the code that was suggested was for his environs ( >> his shop ). From yvespielusenet at free.fr Fri Jun 8 01:09:01 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Fri, 08 Jun 2007 09:09:01 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4668AE7B.3060409@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> Message-ID: <1181286541.3674.10.camel@localhost.localdomain> It is not possible that the rxtx java method write(byte[], int offset, int length) return anint which contains the number of byte really send to the printer instead of an exception ? So this is the programm which will see if all bytes have been sent. If not it can retry to send the unsended bytes. -------------------------------------------------------- int sended = 0; while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ sended += countWritten; /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } return sended; /*throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break;*/ } ... ... return countWritten; ------------------------------------------------ Le jeudi 07 juin 2007 ? 21:18 -0400, Uncle George a ?crit : > The UNIX version of writeArray is not too great either. It is possible > that the write will only process some of the bytes. > > #else > if( write( fd, bytes, count ) < 0 ) > throw_java_exception_system_msg( env, IO_EXCEPTION, > "writeArray" ); > #endif > -------------------------------- > > Maybe it might be better to have the native function inform the caller > of the # of characters written, then the commapi/output-buffer can be > modified to reflect the #of chars written. If an exception is to be > thrown, for too many loops of chars written == 0, then exception wont > affect the state of the output buffer. Then a ParallelPort.restart() can > be called to resume printing whats in the buffer. > > > Trent Jarvi wrote: > > An event is possible. I'm amazed this is the largest problem encountered > > while using the parallel code. > > > > How would the write ever exit if we throw events? Isn't this going to > > lead to hung applications? > Sure. If you dont time out, then there is nothing that will force an > EXIT from the write(). Issue is what has the OS done with the write. > > > > On Thu, 7 Jun 2007, Uncle George wrote: > > > >> My feeling is that the code that was suggested was for his environs ( > >> his shop ). > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Fri Jun 8 03:45:00 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 11:45:00 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181286541.3674.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> Message-ID: <20070608094500.GC21069@elberon.bln.de.ingenico.com> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > It is not possible that the rxtx java method write(byte[], int offset, > int length) return anint which contains the number of byte really send > to the printer instead of an exception ? > So this is the programm which will see if all bytes have been sent. If > not it can retry to send the unsended bytes. I think write() is void because in Java people love to do this since OutputStream :-) Of course on such interfaces you cannot implement something nice. If you would have a int write, you would not implement the interface and no applications expecting this interface would link/work/compile. oki, Steffen P.S.: (OT) If you propose not to implement the Java interfaces (especially not on JNI level), maybe optionally offering a wrapper that removes e.g. the write return value and so on to downgrade the powerful classic old POSIX read/write style to the modern limited Java style, then I agree :-) Same for read. Instead of things like "int avialable()" it is more powerful to have an approach as select(2) offers (to guarante the caller that read/write will not block [nothing else make sense anyway IMHO] but may read/write less bytes then requested). The caller gets full control and the higher level protocols can care about timeouts, invoking read in some loops and/or implement retransmission. On top of such an implementation, where everything is controlled, defined, guaranteed and reliable, someone could use an InputStream or OutputStream style interface. Or even better: don't use them at all :) just BTW :-) St. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From yvespielusenet at free.fr Fri Jun 8 05:52:45 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Fri, 08 Jun 2007 13:52:45 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <20070608094500.GC21069@elberon.bln.de.ingenico.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> Message-ID: <1181303565.11203.3.camel@localhost.localdomain> So maybe a better way should be to create a new Exception class which has a method "int getWrittenByte()". So the Exception should be use to send again bytes which are not printed yet. yves Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : > * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > > It is not possible that the rxtx java method write(byte[], int offset, > > int length) return anint which contains the number of byte really send > > to the printer instead of an exception ? > > So this is the programm which will see if all bytes have been sent. If > > not it can retry to send the unsended bytes. > > I think write() is void because in Java people love to do this > since OutputStream :-) Of course on such interfaces you cannot > implement something nice. If you would have a int write, you > would not implement the interface and no applications expecting > this interface would link/work/compile. > > oki, > > Steffen > > P.S.: (OT) > If you propose not to implement the Java interfaces (especially > not on JNI level), maybe optionally offering a wrapper that > removes e.g. the write return value and so on to downgrade the > powerful classic old POSIX read/write style to the modern limited > Java style, then I agree :-) Same for read. Instead of things > like "int avialable()" it is more powerful to have an approach as > select(2) offers (to guarante the caller that read/write will not > block [nothing else make sense anyway IMHO] but may read/write > less bytes then requested). The caller gets full control and the > higher level protocols can care about timeouts, invoking read in > some loops and/or implement retransmission. On top of such an > implementation, where everything is controlled, defined, > guaranteed and reliable, someone could use an InputStream or > OutputStream style interface. Or even better: don't use them at > all :) just BTW :-) > St. > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > 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. > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > 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. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Fri Jun 8 06:46:21 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 08:46:21 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181303565.11203.3.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> Message-ID: <46694F9D.5080501@gatworks.com> It seems that with outputstream.write(b[]), you become terribly uncoordinated as soon as an exception is thrown. Docs do not say what happens to the data. Yet from a practicable point of view, one would like to know if the write was accepted in-full, or rejected before any writes. There are no in betweens, as partial writes are not reportable. So for an outputstream.write(), in order for it to return, the full write request has to be taken, and stored in an internal output buffer. If there is no room, the write() is suspended, till there is room. Or throw's an IOException( "no room in buffer") ; As the select() loop for write reports buffer room avail, then more of the internal buffer is sent to the printer. yves pielusenet wrote: > So maybe a better way should be to create a new Exception class which > has a method "int getWrittenByte()". So the Exception should be use to > send again bytes which are not printed yet. > > yves > > Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : >> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: >>> It is not possible that the rxtx java method write(byte[], int offset, >>> int length) return anint which contains the number of byte really send >>> to the printer instead of an exception ? >>> So this is the programm which will see if all bytes have been sent. If >>> not it can retry to send the unsended bytes. >> I think write() is void because in Java people love to do this >> since OutputStream :-) Of course on such interfaces you cannot >> implement something nice. If you would have a int write, you >> would not implement the interface and no applications expecting >> this interface would link/work/compile. >> >> oki, >> >> Steffen >> >> P.S.: (OT) >> If you propose not to implement the Java interfaces (especially >> not on JNI level), maybe optionally offering a wrapper that >> removes e.g. the write return value and so on to downgrade the >> powerful classic old POSIX read/write style to the modern limited >> Java style, then I agree :-) Same for read. Instead of things >> like "int avialable()" it is more powerful to have an approach as >> select(2) offers (to guarante the caller that read/write will not >> block [nothing else make sense anyway IMHO] but may read/write >> less bytes then requested). The caller gets full control and the >> higher level protocols can care about timeouts, invoking read in >> some loops and/or implement retransmission. On top of such an >> implementation, where everything is controlled, defined, >> guaranteed and reliable, someone could use an InputStream or >> OutputStream style interface. Or even better: don't use them at >> all :) just BTW :-) >> St. >> >> About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. >> 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. >> >> About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. >> 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. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From Steffen.DETTMER at ingenico.com Fri Jun 8 08:12:18 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 16:12:18 +0200 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <46694F9D.5080501@gatworks.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: <20070608141218.GE21069@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 08:46 -0400: > It seems that with outputstream.write(b[]), you become terribly > uncoordinated as soon as an exception is thrown. Docs do not say what > happens to the data. (yes, so avoiding it seems to be good :)) > Yet from a practicable point of view, one would like to know if the > write was accepted in-full, or rejected before any writes. There are no > in betweens, as partial writes are not reportable. (which is an artificial API limitation. I never understood how this happend when they invented JDK because the well-known BSD socket API and thus [probably] WinSock does this correct, but anyway) > So for an outputstream.write(), in order for it to return, the full > write request has to be taken, and stored in an internal output buffer. > If there is no room, the write() is suspended, till there is room. Or > throw's an IOException( "no room in buffer") ; As the select() loop for > write reports buffer room avail, then more of the internal buffer is > sent to the printer. yes, might be good in case of a printer. May be horrible in case of PPP/TCP or some other transmission control protocol which may e.g. repeat data or even omit parts of it (e.g. internet realtime radio station broadcasting)... So I think the idea of "int write" (e.g. BSD sockets, linux files and so on) still is the best. A clean API / implementation should guarantee and allow implementations (users) to rely on that; assumptions and automatic background-sending and so on may look pragmatic and may even work on the first look, but may fail in other situations. BTW, if e.g. BSD socket API is known, why not simply copy it (until something better is invented :)) instead of fiddling around with JDK APIs? anyway, have a nice weekend everyone :-) oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Fri Jun 8 08:55:56 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 10:55:56 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070608141218.GE21069@elberon.bln.de.ingenico.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> Message-ID: <46696DFC.7000801@gatworks.com> >> write reports buffer room avail, then more of the internal buffer is >> sent to the printer. > > yes, might be good in case of a printer. May be horrible in case > of PPP/TCP or some other transmission control protocol which > may e.g. repeat data or even omit parts of it (e.g. internet > realtime radio station broadcasting)... So I think the idea of > "int write" (e.g. BSD sockets, linux files and so on) still is > the best. A clean API / implementation should guarantee and allow > implementations (users) to rely on that; assumptions and > automatic background-sending and so on may look pragmatic and may > even work on the first look, but may fail in other situations. > BTW, if e.g. BSD socket API is known, why not simply copy it > (until something better is invented :)) instead of fiddling > around with JDK APIs? But we were talking about the Parallel Port, and the transmission of data over the commapi/parallel-port schema. There isn't much in bi-directional software communication. Its a simple write one byte at a time interface. I'm not looking to change the comm-api. I'm just looking to alter the interaction between the Native ParallelPort functions, and the java ParallelPort functions that call them. This might be more readily doable than to get a committee to re-specify java-API specs. BTW: Whats is off-topic? ( help: not looking for def of off-topic ) From j.kenneth.gentle at acm.org Fri Jun 8 08:58:59 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Fri, 08 Jun 2007 10:58:59 -0400 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <20070608141218.GE21069@elberon.bln.de.ingenico.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> Message-ID: <200706081459.l58Ex5rA019991@qbang.org> Perhaps it is a bit late to jump in on this one, but here goes anyway. If the solutions all seem to "break" the contract with "java.io.outputstream", then, as noted, that may not be the appropriate contract. At the risk of being heretical, JDK1.4 introduced the "nio" package to address some of the compatibility issues with C apis mentioned in previous posts. The interface "java.nio.channels.WriteableByteChannel" defines the following single method: int write(ByteBuffer source); int, strangely enough, is the actual number of bytes written. So, if RXTX as written, against the JavaCOMM api and OutputStream, doesn't do what we want, how about writing a different set of bindings using the java.nio classes and as much of the underlying native code as possible. Note that just because the java.nio.channels.WriteableByteChannel sends back a result, OutputStream.write doesn't have to - and they could both call the same underlying native code. My 2 cents - maybe not worth even that... Ken From netbeans at gatworks.com Fri Jun 8 10:37:28 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 12:37:28 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <200706081459.l58Ex5rA019991@qbang.org> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> Message-ID: <466985C8.8000505@gatworks.com> Ken Gentle wrote: > Perhaps it is a bit late to jump in on this one, but here goes anyway. Common in, the waters fine. > > If the solutions all seem to "break" the contract with > "java.io.outputstream", then, as noted, that may not be the > appropriate contract. > How would the contract be broken? The machinery underneath is handling the contract. From j.kenneth.gentle at acm.org Fri Jun 8 10:48:01 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Fri, 08 Jun 2007 12:48:01 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466985C8.8000505@gatworks.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> Message-ID: <200706081648.l58Gm7YA022904@qbang.org> At 12:37 2007-06-08, you wrote: >Ken Gentle wrote: > > > > If the solutions all seem to "break" the contract with > > "java.io.outputstream", then, as noted, that may not be the > > appropriate contract. > > >How would the contract be broken? The machinery underneath is handling >the contract. It seems that a lot of the discussion has been about not only the timeout and being able to adjust it in the "machinery layer", but also about knowing in the Java layer, in the event of a timeout or exception, how many characters have been written to the device. An OutputStream won't ever do this with out an extension and including a return value "breaks" the contract, right? So, go with a Java IO api that *does* return the number of bytes written, out of the NIO package. I know it doesn't allow for a strict implementation of the JavaCOMM API - however, using NIO classes in place of the IO classes isn't that big a break and would allow those applications that need such information a way to get it. Maybe I'm misunderstanding the problem... Ken From netbeans at gatworks.com Fri Jun 8 11:24:14 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 13:24:14 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <200706081648.l58Gm7YA022904@qbang.org> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> Message-ID: <466990BE.7040100@gatworks.com> Ken Gentle wrote: An > OutputStream won't ever do this with out an extension and including a > return value "breaks" the contract, right? > i was not thinking of change the API to OutputSream. Are there specs for how output stream should work internally? for instance: String data = "Hello this is a line of data"; Outputstream.write( data.getbytes() ); ParallelPort.suspend(); int free = ParallelPort.getoutputbufferfree(); There is a symbiotic relationship between outputstream and the functionality of ParallelPort. From Steffen.DETTMER at ingenico.com Fri Jun 8 11:15:39 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 19:15:39 +0200 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <200706081459.l58Ex5rA019991@qbang.org> References: <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> Message-ID: <20070608171539.GK21069@elberon.bln.de.ingenico.com> * Ken Gentle wrote on Fri, Jun 08, 2007 at 10:58 -0400: > If the solutions all seem to "break" the contract with > "java.io.outputstream", then, as noted, that may not be the > appropriate contract. > > At the risk of being heretical, JDK1.4 introduced the "nio" package > to address some of the compatibility issues with C apis mentioned in > previous posts. The interface > "java.nio.channels.WriteableByteChannel" defines the following single method: > > int write(ByteBuffer source); > > int, strangely enough, is the actual number of bytes written. Yes, AFAIK one of the motivations for the NIO interface was, that the JDK-1.3 APIs (InputStream, e.g.) were not powerfull enough, especially for multi-connection-TCP servers or so. I don't know much about it but I've heard of a project where NIO usage was removed because of stability issues in multi-threaded environments and performance limitations under some circumstances. IIRC the "nio.ByteBuffer" is something very special (namely something you cannot implement in Java, it is "magic" or part of the language itself). Not sure if this is such a great idea (but for performance in the end sometimes heavy prices must be paid) :) > So, if RXTX as written, against the JavaCOMM api and OutputStream, > doesn't do what we want, how about writing a different set of > bindings using the java.nio classes and as much of the underlying > native code as possible. Yes, this would be an idea: use a full-featured interface on JNI, and, if wanted, deliver some wrappers converting this to a less-featured Java-compliant interface. However, powerful things as e.g. "select" are difficult to "emulate" if you are e.g. on some (older?) windows. But if you expose the full-featured APIs, you need to emulate them full-featured, theoretically. In the end it depends what you do on the serial line. If you just want to talk to a modem, then you may not need precise timeouts. But if you need to implement complexer protocols which define response times and timeouts, you may quickly get into difficulties. For instance, AFAIK, rxtx 1.7.2 (?) for windows is very messy with timeouts (there is a maximum, higher values are truncated; resolution is 100ms only; the function may take up to twice the timeout because internally it may be called twice). Probably for most people this is OK, but probably not for all. But having precise timeouts should be OK for all :-) Well, in the end it is nice to wish but somewhat hard to implement (many platforms, connections, USB, BlueTooth, whatever). oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Steffen.DETTMER at ingenico.com Fri Jun 8 11:04:22 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 19:04:22 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <46696DFC.7000801@gatworks.com> References: <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <46696DFC.7000801@gatworks.com> Message-ID: <20070608170422.GJ21069@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 10:55 -0400: > > BTW, if e.g. BSD socket API is known, why not simply copy it > > (until something better is invented :)) instead of fiddling > > around with JDK APIs? > > But we were talking about the Parallel Port, and the > transmission of data over the commapi/parallel-port schema. > There isn't much in bi-directional software communication. Its > a simple write one byte at a time interface. First, there are things like PLIP (http://en.wikipedia.org/wiki/Plip) - well, probably not widely used, sure ;) Second, I think if there is a good simple API known to support all that (with known "best practices") or so and there is no forcing need to invent a new one, why not simply using it? > I'm not looking to change the comm-api. I'm just looking to > alter the interaction between the Native ParallelPort > functions, and the java ParallelPort functions that call them. Ahh, yes. I think this is what I tried to ask. Having an usable JNI interface and on top (in pure java) some wrapper to InputStream or whatever could be done (e.g. by ignoring the return value of write or throwing if != length). Developers could then use the full-featured (non-JAVA-standard) API or select among various wrappers (as InputStream). > This might be more readily doable than to get a committee to > re-specify java-API specs. Yes, of course. I'm afraid that the Java APIs change regularily, but still yet with limited success it seems, so maybe they get it in one of the next iterations; who knows, maybe Java-9 has a BSD-like socket API :) SCNR. > BTW: Whats is off-topic? ( help: not looking for def of > off-topic ) I think I started some "re-specify java-API specs" which was OT probably. oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From lists at iDIAcomputing.com Fri Jun 8 18:48:54 2007 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Fri, 08 Jun 2007 20:48:54 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46684B62.7080802@gmail.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> Message-ID: <4669F8F6.3040101@iDIAcomputing.com> Vicne wrote: > Sorry to step in without a specific solution to your problem, but I > wanted to share my feeling regarding this proposal. AFAIK, it's > generally considered bad practice to pop-up a prompt from a library. ... > > My advice would be to think again and find another solution. Ideas are : > - make the number of retries a parameter so that you can tune it to what > you think is reasonable > - throw a more specific exception when the number of retries has been > reached, so that a specific prompt can be shown at a higher level You could also allow the client code to register a callback class which returns a boolean indicating whether to retry or cancel. This callback class could pop up a dialog, if appropriate, or follow some preset policy, or.... - George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From joachim at buechse.ch Sat Jun 9 09:43:16 2007 From: joachim at buechse.ch (Joachim Buechse) Date: Sat, 9 Jun 2007 17:43:16 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46694F9D.5080501@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: You should not forget, that in the case of an exception it may not even be known what happened to the data. You have a kernel buffer, outgoing chip buffer, incoming chip buffer, etc. So of course, it would be nice to know up to which point data was correctly processed, but this feedback does not exist on the hardware or protocol level and hence can in general not be magicly created on the software level... Regards, Joachim On 08.06.2007, at 14:46, Uncle George wrote: > It seems that with outputstream.write(b[]), you become terribly > uncoordinated as soon as an exception is thrown. Docs do not say what > happens to the data. > > Yet from a practicable point of view, one would like to know if the > write was accepted in-full, or rejected before any writes. There > are no > in betweens, as partial writes are not reportable. > > So for an outputstream.write(), in order for it to return, the full > write request has to be taken, and stored in an internal output > buffer. > If there is no room, the write() is suspended, till there is room. Or > throw's an IOException( "no room in buffer") ; As the select() loop > for > write reports buffer room avail, then more of the internal buffer is > sent to the printer. > > > > yves pielusenet wrote: >> So maybe a better way should be to create a new Exception class which >> has a method "int getWrittenByte()". So the Exception should be >> use to >> send again bytes which are not printed yet. >> >> yves >> >> Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : >>> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: >>>> It is not possible that the rxtx java method write(byte[], int >>>> offset, >>>> int length) return anint which contains the number of byte >>>> really send >>>> to the printer instead of an exception ? >>>> So this is the programm which will see if all bytes have been >>>> sent. If >>>> not it can retry to send the unsended bytes. >>> I think write() is void because in Java people love to do this >>> since OutputStream :-) Of course on such interfaces you cannot >>> implement something nice. If you would have a int write, you >>> would not implement the interface and no applications expecting >>> this interface would link/work/compile. >>> >>> oki, >>> >>> Steffen >>> >>> P.S.: (OT) >>> If you propose not to implement the Java interfaces (especially >>> not on JNI level), maybe optionally offering a wrapper that >>> removes e.g. the write return value and so on to downgrade the >>> powerful classic old POSIX read/write style to the modern limited >>> Java style, then I agree :-) Same for read. Instead of things >>> like "int avialable()" it is more powerful to have an approach as >>> select(2) offers (to guarante the caller that read/write will not >>> block [nothing else make sense anyway IMHO] but may read/write >>> less bytes then requested). The caller gets full control and the >>> higher level protocols can care about timeouts, invoking read in >>> some loops and/or implement retransmission. On top of such an >>> implementation, where everything is controlled, defined, >>> guaranteed and reliable, someone could use an InputStream or >>> OutputStream style interface. Or even better: don't use them at >>> all :) just BTW :-) >>> St. >>> >>> About Ingenico Throughout the world businesses rely on Ingenico >>> for secure and expedient electronic transaction acceptance. >>> Ingenico products leverage proven technology, established >>> standards and unparalleled ergonomics to provide optimal >>> reliability, versatility and usability. This comprehensive range >>> of products is complemented by a global array of services and >>> partnerships, enabling businesses in a number of vertical sectors >>> to accept transactions anywhere their business takes them. >>> 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. >>> >>> About Ingenico Throughout the world businesses rely on Ingenico >>> for secure and expedient electronic transaction acceptance. >>> Ingenico products leverage proven technology, established >>> standards and unparalleled ergonomics to provide optimal >>> reliability, versatility and usability. This comprehensive range >>> of products is complemented by a global array of services and >>> partnerships, enabling businesses in a number of vertical sectors >>> to accept transactions anywhere their business takes them. >>> 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. >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx 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 yvespielusenet at free.fr Mon Jun 11 03:15:12 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Mon, 11 Jun 2007 11:15:12 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: <1181553312.8335.14.camel@localhost.localdomain> So can someone tell a solution for my problem :( Must I say to the user to not put the printer off-line ? I can't since he has to do some pauses, verify print, paper conditioning etc... How do other people ? Before I use the parport librarry to read port status : http://www.geocities.com/Juanga69/parport/ (which doesn't work on windows XP) And I send data into the file LPT1 I use to have no problem when printer was disabled. thanks -- yves piel Le samedi 09 juin 2007 ? 17:43 +0200, Joachim Buechse a ?crit : > You should not forget, that in the case of an exception it may not > even be known what happened to the data. > > You have a kernel buffer, outgoing chip buffer, incoming chip buffer, > etc. So of course, it would be nice to know up to which point data > was correctly processed, but this feedback does not exist on the > hardware or protocol level and hence can in general not be magicly > created on the software level... > > Regards, > Joachim > > On 08.06.2007, at 14:46, Uncle George wrote: > > > It seems that with outputstream.write(b[]), you become terribly > > uncoordinated as soon as an exception is thrown. Docs do not say what > > happens to the data. > > > > Yet from a practicable point of view, one would like to know if the > > write was accepted in-full, or rejected before any writes. There > > are no > > in betweens, as partial writes are not reportable. > > > > So for an outputstream.write(), in order for it to return, the full > > write request has to be taken, and stored in an internal output > > buffer. > > If there is no room, the write() is suspended, till there is room. Or > > throw's an IOException( "no room in buffer") ; As the select() loop > > for > > write reports buffer room avail, then more of the internal buffer is > > sent to the printer. > > > > > > > > yves pielusenet wrote: > >> So maybe a better way should be to create a new Exception class which > >> has a method "int getWrittenByte()". So the Exception should be > >> use to > >> send again bytes which are not printed yet. > >> > >> yves > >> > >> Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : > >>> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > >>>> It is not possible that the rxtx java method write(byte[], int > >>>> offset, > >>>> int length) return anint which contains the number of byte > >>>> really send > >>>> to the printer instead of an exception ? > >>>> So this is the programm which will see if all bytes have been > >>>> sent. If > >>>> not it can retry to send the unsended bytes. > >>> I think write() is void because in Java people love to do this > >>> since OutputStream :-) Of course on such interfaces you cannot > >>> implement something nice. If you would have a int write, you > >>> would not implement the interface and no applications expecting > >>> this interface would link/work/compile. > >>> > >>> oki, > >>> > >>> Steffen > >>> > >>> P.S.: (OT) > >>> If you propose not to implement the Java interfaces (especially > >>> not on JNI level), maybe optionally offering a wrapper that > >>> removes e.g. the write return value and so on to downgrade the > >>> powerful classic old POSIX read/write style to the modern limited > >>> Java style, then I agree :-) Same for read. Instead of things > >>> like "int avialable()" it is more powerful to have an approach as > >>> select(2) offers (to guarante the caller that read/write will not > >>> block [nothing else make sense anyway IMHO] but may read/write > >>> less bytes then requested). The caller gets full control and the > >>> higher level protocols can care about timeouts, invoking read in > >>> some loops and/or implement retransmission. On top of such an > >>> implementation, where everything is controlled, defined, > >>> guaranteed and reliable, someone could use an InputStream or > >>> OutputStream style interface. Or even better: don't use them at > >>> all :) just BTW :-) > >>> St. > >>> > >>> About Ingenico Throughout the world businesses rely on Ingenico > >>> for secure and expedient electronic transaction acceptance. > >>> Ingenico products leverage proven technology, established > >>> standards and unparalleled ergonomics to provide optimal > >>> reliability, versatility and usability. This comprehensive range > >>> of products is complemented by a global array of services and > >>> partnerships, enabling businesses in a number of vertical sectors > >>> to accept transactions anywhere their business takes them. > >>> 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. > >>> > >>> About Ingenico Throughout the world businesses rely on Ingenico > >>> for secure and expedient electronic transaction acceptance. > >>> Ingenico products leverage proven technology, established > >>> standards and unparalleled ergonomics to provide optimal > >>> reliability, versatility and usability. This comprehensive range > >>> of products is complemented by a global array of services and > >>> partnerships, enabling businesses in a number of vertical sectors > >>> to accept transactions anywhere their business takes them. > >>> 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. > >>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx 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 > From Steffen.DETTMER at ingenico.com Mon Jun 11 03:56:18 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 11:56:18 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466990BE.7040100@gatworks.com> References: <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> Message-ID: <20070611095618.GA10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 13:24 -0400: > i was not thinking of change the API to OutputSream. Then I think either someone uses OutputStream (and has no reliable information about incomplete writes) or someone uses somethink else. > Are there specs for how output stream should work internally? > > for instance: > String data = "Hello this is a line of data"; > Outputstream.write( data.getbytes() ); > ParallelPort.suspend(); > int free = ParallelPort.getoutputbufferfree(); > > There is a symbiotic relationship between outputstream and the > functionality of ParallelPort. If you need OutputStream "plus something else", in short you're needing "something else". Personally I dislike the code above a lot. The stream "looks" like if it would be an OutputStream, but in fact it isn't. You need to call getoutputbufferfree later to check if write succeeded (but OutputStream promises that write succeedes synchronous, blocking, or throws an exception). So it is not an OutputStream. No application written for OutputStreams would work without change (because it won't know getoutputbufferfree at all). It is not abstracted from ParallelPort. I think this would be wrong. Then I think an alternative interface instead is better. Let's assume we had some "connection" (to distinguish between OutputStreams and Channels). Then why not working as on a file handle in POSIX: do { // ... select maybe using timer ... readyForWrite = ... if (readyForWrite) { int writtenBytes = connection.write(toWrite); toWrite.remove(0, writtenBytes); } while(readyForWrite && toWrite.length > 0); I think, having such a write isn't the big problem. I think, the difficult thing is around "select" - however this would look like. It should be OO, typesafe, performant, supporting multiple connections/channels/streams in various modes and should be orthogonal to other functionalities. Of course, this heavily depends on what the application is doing; for a simple situation (like reading a small, mandatory file from a local disk) this would be to uncomfortable (and offering unneeded features only). just BTW :) oki, Steffen -- // Modeline for VIM. Please don't remove. // (Help: autoindent, expandtab, shiftwidth=4, tabstop=4, textwidth=75) // vi: set ai et sw=4 ts=4 tw=75 ft=java: About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Mon Jun 11 05:38:33 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 07:38:33 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611095618.GA10821@elberon.bln.de.ingenico.com> References: <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> Message-ID: <466D3439.4020805@gatworks.com> Steffen DETTMER wrote: > (but OutputStream promises that write > succeedes synchronous, blocking, or throws an exception). Where is it so written? From Steffen.DETTMER at ingenico.com Mon Jun 11 06:36:50 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 14:36:50 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466D3439.4020805@gatworks.com> References: <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> <466D3439.4020805@gatworks.com> Message-ID: <20070611123650.GI10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Mon, Jun 11, 2007 at 07:38 -0400: > Steffen DETTMER wrote: > > > (but OutputStream promises that write > > succeedes synchronous, blocking, or throws an exception). > > Where is it so written? Now, as you ask, I think it is not written that clearly but follows from specification. mmm... Am I wrong? I understand the API doc in this way: * http://java.sun.com/j2se/1.4.2/docs/api/java/io/OutputStream.html#write(byte[]) > public void write(byte[] b) > throws IOException > > Writes b.length bytes from the specified byte array to this > output stream. The general contract for write(b) is that > it should have exactly the same effect as the call write(b, > 0, b.length). > > Parameters: > b - the data. > Throws: > IOException - if an I/O error occurs. > See Also: > write(byte[], int, int) and there is: > public void write(byte[] b, > int off, > int len) > throws IOException > > Writes len bytes from the specified byte array starting at > offset off to this output stream. The general contract for > write(b, off, len) is that some of the bytes in the array b > are written to the output stream in order; element b[off] > is the first byte written and b[off+len-1] is the last byte > written by this operation. > > The write method of OutputStream calls the write method of > one argument on each of the bytes to be written out. > Subclasses are encouraged to override this method and > provide a more efficient implementation. > > If b is null, a NullPointerException is thrown. > > If off is negative, or len is negative, or off+len is > greater than the length of the array b, then an > IndexOutOfBoundsException is thrown. > > Parameters: > b - the data. > off - the start offset in the data. > len - the number of bytes to write. > Throws: > IOException - if an I/O error occurs. In particular, an > IOException is thrown if the output stream is closed. In general, any specialisation (derived child class) must comform to this. So write in the end is specified (!) as "The write method ... calls the write method ... on each of the bytes to be written out". This is what must be implemented by ANY OutputStream. Of course, there is: "Subclasses are encouraged to override this method and provide a more efficient implementation." which IMHO does not contradict - the more efficient must behave in exactly the same way of course (just wasting less resources than a simple byte-by-byte write). So it does not matter here I think. The write that finally defines the behavior tells basically: > "Writes the specified byte to this output stream. The general > contract for write is that one byte is written to the output > stream. " > > Throws: > IOException - if an I/O error occurs. which IMHO is another way of saying "write writes the byte immediately and returns on success (only), otherwise an exception is thrown". Especially it cannot happen that zero bytes are written (i.e. the specified byte is NOT written) without an exception. So by this write must be synchronous and blocking, because otherwise it could not reliably know if an asynchronous operation will succeede or not (some getAsyncResult or so would be needed). Since write(byte[]) does this for each byte (or with a behavior beeing exactly the same as if it would do), I think this means that the write(byte[]) succeedes synchronous/blocking or throws an exception. Did I an error in reasoning or confused something or so? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From j.kenneth.gentle at acm.org Mon Jun 11 06:51:25 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 11 Jun 2007 08:51:25 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611123650.GI10821@elberon.bln.de.ingenico.com> References: <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> <466D3439.4020805@gatworks.com> <20070611123650.GI10821@elberon.bln.de.ingenico.com> Message-ID: <200706111251.l5BCpS9T017831@qbang.org> It is as Steffen describes. "InputStream" and "OutputStream" are inherently synchronous (which is why so many java programs resort to threads to use them). Anything outside of this "contract" is *not* an InputStream or OutputStream. That is why there is a new package for things that don't behave like the old *Stream classes - the NIO package. If you look carefully at the IO package, you'll note that almost all the classes are _Decorator_ pattern implementations of the *Stream classes - and the interface presents the _same_ behavior to the calling code in all cases - a synchronous operation that completes successfully or throws an exception (with the one exception of "read" that returns a "-1" on end-of-stream. I know I've read this numerous times - I'd suggest checking the Language Spec or one of the books by Bloch or Gosling. Ken At 08:36 2007-06-11, you wrote: >* Uncle George wrote on Mon, Jun 11, 2007 at 07:38 -0400: > > Steffen DETTMER wrote: > > > > > (but OutputStream promises that write > > > succeedes synchronous, blocking, or throws an exception). > > > > Where is it so written? > >Now, as you ask, I think it is not written that clearly but >follows from specification. mmm... > >Am I wrong? > >I understand the API doc in this way: > >* >http://java.sun.com/j2se/1.4.2/docs/api/java/io/OutputStream.html#write(byte[]) > > public void write(byte[] b) > > throws IOException > > > > Writes b.length bytes from the specified byte array to this > > output stream. The general contract for write(b) is that > > it should have exactly the same effect as the call write(b, > > 0, b.length). > > > > Parameters: > > b - the data. > > Throws: > > IOException - if an I/O error occurs. > > See Also: > > write(byte[], int, int) > > >and there is: > > > > public void write(byte[] b, > > int off, > > int len) > > throws IOException > > > > Writes len bytes from the specified byte array starting at > > offset off to this output stream. The general contract for > > write(b, off, len) is that some of the bytes in the array b > > are written to the output stream in order; element b[off] > > is the first byte written and b[off+len-1] is the last byte > > written by this operation. > > > > The write method of OutputStream calls the write method of > > one argument on each of the bytes to be written out. > > Subclasses are encouraged to override this method and > > provide a more efficient implementation. > > > > If b is null, a NullPointerException is thrown. > > > > If off is negative, or len is negative, or off+len is > > greater than the length of the array b, then an > > IndexOutOfBoundsException is thrown. > > > > Parameters: > > b - the data. > > off - the start offset in the data. > > len - the number of bytes to write. > > Throws: > > IOException - if an I/O error occurs. In particular, an > > IOException is thrown if the output stream is closed. > > >In general, any specialisation (derived child class) must comform >to this. So write in the end is specified (!) as "The write >method ... calls the write method ... on each of the bytes to be >written out". This is what must be implemented by ANY >OutputStream. > >Of course, there is: "Subclasses are encouraged to override this >method and provide a more efficient implementation." which IMHO >does not contradict - the more efficient must behave in exactly >the same way of course (just wasting less resources than a simple >byte-by-byte write). So it does not matter here I think. > > > >The write that finally defines the behavior tells basically: > > > "Writes the specified byte to this output stream. The general > > contract for write is that one byte is written to the output > > stream. " > > > > Throws: > > IOException - if an I/O error occurs. > > >which IMHO is another way of saying "write writes the byte >immediately and returns on success (only), otherwise an exception >is thrown". Especially it cannot happen that zero bytes are >written (i.e. the specified byte is NOT written) without an >exception. So by this write must be synchronous and blocking, >because otherwise it could not reliably know if an asynchronous >operation will succeede or not (some getAsyncResult or so would >be needed). > >Since write(byte[]) does this for each byte (or with a behavior >beeing exactly the same as if it would do), I think this means >that the write(byte[]) succeedes synchronous/blocking or throws >an exception. > >Did I an error in reasoning or confused something or so? > >oki, > >Steffen > >About Ingenico Throughout the world businesses rely on Ingenico for >secure and expedient electronic transaction acceptance. Ingenico >products leverage proven technology, established standards and >unparalleled ergonomics to provide optimal reliability, versatility >and usability. This comprehensive range of products is complemented >by a global array of services and partnerships, enabling businesses >in a number of vertical sectors to accept transactions anywhere >their business takes them. >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. > >About Ingenico Throughout the world businesses rely on Ingenico for >secure and expedient electronic transaction acceptance. Ingenico >products leverage proven technology, established standards and >unparalleled ergonomics to provide optimal reliability, versatility >and usability. This comprehensive range of products is complemented >by a global array of services and partnerships, enabling businesses >in a number of vertical sectors to accept transactions anywhere >their business takes them. >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. > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From alesinskyy at googlemail.com Mon Jun 11 07:25:33 2007 From: alesinskyy at googlemail.com (Oleksandr Alesinskyy) Date: Mon, 11 Jun 2007 15:25:33 +0200 Subject: [Rxtx] [OT] select :-) Message-ID: Sorry, but I have to disagree with following statement: "So write in the end is specified (!) as "The write method ... calls the write method ... on each of the bytes to be written out". This is what must be implemented by ANY OutputStream.". This is not part of the specification or contract, it is just revealed implementation detail of the OutputStream. It is not stated anywhere that behavoiur of derived classes shall conform with this one. Statement concerning "synchronous" nature of the output stream is invalid as well. Really synchronous stream does not require flush() but OutputStream has it. From Steffen.DETTMER at ingenico.com Mon Jun 11 08:21:16 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 16:21:16 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: Message-ID: <20070611142116.GN10821@elberon.bln.de.ingenico.com> * Oleksandr Alesinskyy wrote on Mon, Jun 11, 2007 at 15:25 +0200: > Sorry, but I have to disagree with following statement: > "So write in the end is specified (!) as "The write > method ... calls the write method ... on each of the bytes to be > written out". This is what must be implemented by ANY > OutputStream.". > > This is not part of the specification or contract, it is just > revealed implementation detail of the OutputStream. It is not > stated anywhere that behavoiur of derived classes shall conform > with this one. (I didn't meant that the implementation must really write byte by byte, but that it must "look as if it would do" - because all implementations of OutputStream must "look" in the same way [which is another way of saying "do abstract" I think]) I think the API doc is not "revealing implementation details" but it is the *specification* of that interface and derivations must (should) conform to this specification. Isn't this the idea of interfaces? A function that expects an OutputStream should work on ANY OutputStream, shouldn't it? just kidding: I mean, what would be the point in implementing a checksum function as OutputStream.write which throws its result as IOException? Or which requires to call close() as very first operation to tell that the application is about to transmit confidential data? :-) > Statement concerning "synchronous" nature of the output stream > is invalid as well. Really synchronous stream does not require > flush() but OutputStream has it. ahh, interesting point! I think this is another bug in the API. flush() is wrong. Because write specifies "The general contract for write is that one byte is written to the output stream." but not "a byte may be written or buffered". Actually, an application would need to call flush() after each write (or bunch of write calls) to ensure that write really did something otherwise I think. I didn't found in the spec of OutputStream that it would be required to call flush(). This should mean that calling flush is not required which in turn leads to the conclusion that write must be synchrous (private threads are forbidden because not specified :)) which in turn leads to the conclusion that flush() is not needed at all... I mean, what if someone would only store in write and do the "real write" in flush() and never else? An application could write in one stream and read on another one (e.g. in bidirectional communication) and would never get anything back, because nothing was actually written because no flush was called? Then someone could even think that on error in some write the data could remain buffered AND throw an exception, retrying to send the data in the next write. Ohh, and if there would be some message number inside, and underlaying write (e.g. a protocol offering InputStream/OutputStream) would check this and throw "DuplicatedMessageNumber" the stream would only throw it again and again beeing unusable... In short: I have no clue how someone could be able to implement an asynchrounos write (which is realiable and correct) without beeing specific to anything which is not specified by OutputStream. Well, I think in the end OutputStream was not intended for such communication or protocol implementations - but to read a local disk file or so. In case of I/O errors usually you can abort your application and change the hard disk :-) oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Bob_Jacobsen at lbl.gov Mon Jun 11 09:32:23 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Mon, 11 Jun 2007 08:32:23 -0700 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611142116.GN10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> Message-ID: At 4:21 PM +0200 6/11/07, Steffen DETTMER wrote: > > Statement concerning "synchronous" nature of the output stream >> is invalid as well. Really synchronous stream does not require >> flush() but OutputStream has it. > >ahh, interesting point! > >I think this is another bug in the API. flush() is wrong. Because >write specifies "The general contract for write is that one byte >is written to the output stream." but not "a byte may be written >or buffered". > >Actually, an application would need to call flush() after each >write (or bunch of write calls) to ensure that write really did >something otherwise I think. OutputStreams don't _have_ to be synchronous or asynchronous, but the OutputStream API was be arranged so that subclasses _can_ be synchronous or asynchronous. Such generality is the hardest part of getting an API right. Hence, if at some point a program using an OutputStream wants to be sure that the data has been pushed all the way out, flush() is available. For some subclasses, e.g. the buffered ones, this has important behavior. Others write the data from each call, and flush() doesn't do anything. You _can_ omit it in programs that are known to use this second type, but there's no requirement that you do so; the interface is general in that way. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From Steffen.DETTMER at ingenico.com Mon Jun 11 12:32:39 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 20:32:39 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> Message-ID: <20070611183239.GT10821@elberon.bln.de.ingenico.com> * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: > >Actually, an application would need to call flush() after each > >write (or bunch of write calls) to ensure that write really did > >something otherwise I think. > OutputStreams don't _have_ to be synchronous or asynchronous, > but the OutputStream API was be arranged so that subclasses > _can_ be synchronous or asynchronous. Ahh, oki. Thanks for the clarificaion. So in short, flush() MUST be called on OutputStream, this is just not documented correctly or so clearly (right?). So the overall usage semantics would be: 1. call write (multiple times if desired) 2. call flush only if both succeeded, write was successful. If flush fails it remains unknown if a part of the data was written and/or will be repeated. So the spec (API doc) is wrong. Correct would be to tell that write behaves as told as long as it is followed by a call to flush, otherwise data may or may not get lost (depending wheter close() is called and calls flush(), which seems not to be guaranteed/required). BTW, I think it is a little bit... erm... interesting to find the specification (java API doc reference) wrong, having a need to conclude it from the presence of some methods with "it would make no sense if they behave exactly as specified, so specification must be wrong (incomplete)". > Such generality is the hardest part of getting an API right. Yes, seems to be proven ;) > Hence, if at some point a program using an OutputStream wants > to be sure that the data has been pushed all the way out, > flush() is available. For some subclasses, e.g. the buffered > ones, this has important behavior. Others write the data from > each call, and flush() doesn't do anything. > You _can_ omit it in programs that are known to use this second > type, but there's no requirement that you do so; the interface > is general in that way. I think, it still it must be called always, otherwise the application could break if passing a different runtime type as OutputStream. I think, if the application/method needs a special "type of OutputStream" then the parameter type must be a subclass but not OutputStream, maybe a PrintStream or so - otherwise the compiler could not detect this error (passing wrong type). Is this correct? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Bob_Jacobsen at lbl.gov Mon Jun 11 13:00:52 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Mon, 11 Jun 2007 12:00:52 -0700 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611183239.GT10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> Message-ID: At 8:32 PM +0200 6/11/07, Steffen DETTMER wrote: >So the spec (API doc) is wrong. Correct would be to tell that >write behaves as told as long as it is followed by a call to >flush, otherwise data may or may not get lost (depending wheter >close() is called and calls flush(), which seems not to be >guaranteed/required). I'm not entirely sure that the spec is wrong, but reasonable people can differ on this. In the 1.5 JavaDocs, all that the docs say for the write methods is that they write to the _output_ _stream_; there is no guarantee of anything beyond that. Only the flush method has any guarantee about the data, which is >Flushes this output stream and forces any buffered output bytes to >be written out. The general contract of flush is that calling it is >an indication that, if any bytes previously written have been >buffered by the implementation of the output stream, such bytes >should immediately be written to their intended destination. People commonly use various OutputStreams without using flush(), and it often works, but it's a bad practice and will eventually bite them. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From netbeans at gatworks.com Mon Jun 11 13:31:57 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 15:31:57 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611183239.GT10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> Message-ID: <466DA32D.1010602@gatworks.com> Steffen DETTMER wrote: > * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: >>> Actually, an application would need to call flush() after each >>> write (or bunch of write calls) to ensure that write really did >>> something otherwise I think. > >> OutputStreams don't _have_ to be synchronous or asynchronous, >> but the OutputStream API was be arranged so that subclasses >> _can_ be synchronous or asynchronous. > > Ahh, oki. Thanks for the clarificaion. > > So in short, flush() MUST be called on OutputStream, this is just > not documented correctly or so clearly (right?). No. Flush can be called to force all current data in java buffer's to be written to the kernel - NOW. A flush() can also *imply* that, besides writing out the buffer's that java employs, may also imply/ask the kernel to write all data thusfar written to the kernel, to be physically placed on the destination device - NOW. For some OS's there is no need to do a kernel flush(), as the I/O is synchronized already. Since this is java, you never know what OS your on. From tjarvi at qbang.org Mon Jun 11 19:28:27 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Jun 2007 19:28:27 -0600 (MDT) Subject: [Rxtx] [OT] select :-) In-Reply-To: <466DA32D.1010602@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: On Mon, 11 Jun 2007, Uncle George wrote: > Steffen DETTMER wrote: >> * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: >>>> Actually, an application would need to call flush() after each >>>> write (or bunch of write calls) to ensure that write really did >>>> something otherwise I think. >> >>> OutputStreams don't _have_ to be synchronous or asynchronous, >>> but the OutputStream API was be arranged so that subclasses >>> _can_ be synchronous or asynchronous. >> >> Ahh, oki. Thanks for the clarificaion. >> >> So in short, flush() MUST be called on OutputStream, this is just >> not documented correctly or so clearly (right?). > No. > Flush can be called to force all current data in java buffer's to be > written to the kernel - NOW. > > A flush() can also *imply* that, besides writing out the buffer's that > java employs, may also imply/ask the kernel to write all data thusfar > written to the kernel, to be physically placed on the destination device > - NOW. > For some OS's there is no need to do a kernel flush(), as the I/O is > synchronized already. Since this is java, you never know what OS your on. To add to the confusion, flush on the C side throws away data. drain makes sure it is written. Looking at the ParallelImp.c we can probably do better. /* we set a timeout because all calls are sequentiell (also with asynchron) this means that the default timeout of unlimited blocks all calls (also close and status request) if the device is down */ GetCommTimeouts( (HANDLE)fd, &timeouts ); timeouts.WriteTotalTimeoutMultiplier = 0; timeouts.WriteTotalTimeoutConstant = 2000; /* 2000 is the min value for the default Windows NT and Windows 2000 driver */ SetCommTimeouts( (HANDLE)fd, &timeouts ); while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } errorCount = 0; bytes += countWritten; count -= countWritten; } LPRPort has some timeout code that appears to be doing nothing but flipping bits back and forth right now. The commapi rxtx follows allows for timeout control from javax.comm.CommPort. The above is a solution that worked in one specific use case. With timeouts in place, the original 'old printer going offline' problem could be solved. That printer code isn't written in stone. In fact it was ajusted from being able to print 'asdf' to a daisy wheel printer to working for one person. BTW, I've finished teaching after hours tonight and will be moving forward with a new rxtx release in my free time. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Jun 11 21:28:04 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 23:28:04 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: <466E12C4.1010305@gatworks.com> > Looking at the ParallelImp.c we can probably do better. > The problem stemmed from the possibility that the writev routine could have written some of the buffer, in chunks, printer pauses, refuses any more chunks, and a timeout occurs. Do you or do you not cause an exception to be thrown? Is there a way to set timeout for a ParallelPort data output stream? I cant find it. From tjarvi at qbang.org Mon Jun 11 22:17:23 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Jun 2007 22:17:23 -0600 (MDT) Subject: [Rxtx] [OT] select :-) In-Reply-To: <466E12C4.1010305@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> <466E12C4.1010305@gatworks.com> Message-ID: On Mon, 11 Jun 2007, Uncle George wrote: >> Looking at the ParallelImp.c we can probably do better. >> > The problem stemmed from the possibility that the writev routine could > have written some of the buffer, in chunks, printer pauses, refuses any > more chunks, and a timeout occurs. Do you or do you not cause an > exception to be thrown? > > Is there a way to set timeout for a ParallelPort data output stream? I > cant find it. hmm I looked again after you asked. The timeouts are only controllable on the receive side. This comes from CommPort; the parent. So what we are talking about is some bytes in memory that rxtx has and is supposed to write. A buffer perhaps? The approach with rxtx in the past has been to ignore output buffer sizes. The assumption is that the library does not know how to best handle buffers. There are buffered output streams that can do buffering on top of rxtx for instance. There is also a question regarding what was actually ment when the API was put together. My suspicion is that it was put together while looking at one OS API and was never ment to be anything more than a hook into that API. The comments are fairly telling combined with reading the w32 API. So looking at the problem again.. The current timeout behavior appears fairly arbitrary. Presumably this is to prevent a program from hanging instead of using a helper thread to write - heavy handed for new programmers. Even so, I don't think the write should timeout at all if it is not configurable. >From the API perspective, "What Timeout?" -- Trent Jarvi tjarvi at qbang.org From Steffen.DETTMER at ingenico.com Tue Jun 12 02:14:48 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 12 Jun 2007 10:14:48 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466DA32D.1010602@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: <20070612081447.GU10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Mon, Jun 11, 2007 at 15:31 -0400: > Steffen DETTMER wrote: > > Ahh, oki. Thanks for the clarificaion. > > > > So in short, flush() MUST be called on OutputStream, this is just > > not documented correctly or so clearly (right?). > No. hum (though now I got it, but...). > Flush can be called to force all current data in java buffer's to be > written to the kernel - NOW. > > A flush() can also *imply* that, besides writing out the > buffer's that java employs, may also imply/ask the kernel to > write all data thusfar written to the kernel, to be physically > placed on the destination device - NOW. > > For some OS's there is no need to do a kernel flush(), as the I/O is > synchronized already. Since this is java, you never know what OS your on. (well, but if you're going to kernel level, even flush cannot guarantee that data will "be physically placed". Maybe you're flushing to a file via NFS (and the client "thinks" that it was written, but maybe it was just buffered by the NFS server) or so... but of course such exceptions of the rules are constructable always.) Well, you tell that depending on the OS it can be that flush is needed or it can be that flush is not needed (beacuse the I/O is synchronized already), right? Also, applications should work on any OS, which includes the OSes that do need flush. Since the application cannot know whether flush is needed or not because it doesn't know what the OS is doing, it has to call flush, hasn't it? I mean, if it would not call flush then it would not work on such OSes (except the written data would not be needed at all, but in this would be an artificial example :)). Since applications are supposed to work this would be wrong, wouldn't it? So would it be correct to say: "Applications, that should work under all OSes (including the OSes where the I/O is not synchronised already), have to call flush on OutputStream to ensure the data is transfered to the kernel." or is this wrong? If so, then I'm afraid I missed the point again :( oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Tue Jun 12 04:46:52 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 12 Jun 2007 06:46:52 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070612081447.GU10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> <20070612081447.GU10821@elberon.bln.de.ingenico.com> Message-ID: <466E799C.7060700@gatworks.com> S > (well, but if you're going to kernel level, even flush cannot > guarantee that data will "be physically placed". Thats true now-a-days because ( from "man 2 sync" ) : > According to the standard specification (e.g., SVID), sync() schedules > the writes, but may return before the actual writing is done. However, > since version 1.3.20 Linux does actually wait. (This still does not > guarantee data integrity: modern disks have large caches.) My disk drive has 8mb cache. Maybe you're > flushing to a file via NFS (and the client "thinks" that it was > written, but maybe it was just buffered by the NFS server) or > so... but of course such exceptions of the rules are > constructable always.) > > Well, you tell that depending on the OS it can be that flush is > needed or it can be that flush is not needed (beacuse the I/O is > synchronized already), right? Also, applications should work on > any OS, which includes the OSes that do need flush. Its not OS's that need flush, its applications that want to have some assurance that data is written to the device that really needs to use flush. If your program ( or thread ) dies then it is in your best interest to write out the critical data as soon as possible, as economical as possible. These are trade-off's that the application programmer makes. A big buffer may mean big loss of data, a small buffer may mean spending too much time writing out data. > > > So would it be correct to say: > > "Applications, that should work under all OSes (including the > OSes where the I/O is not synchronised already), have to call > flush on OutputStream to ensure the data is transfered to the > kernel." > > or is this wrong? If so, then I'm afraid I missed the point again > :( > No that is not wrong. Ensuring that data is transfered to the OS is just about what any application can do. From tjarvi at qbang.org Thu Jun 14 08:16:47 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 14 Jun 2007 08:16:47 -0600 (MDT) Subject: [Rxtx] rxtx and usb-serial solution In-Reply-To: References: Message-ID: On Thu, 14 Jun 2007, Vladimir Kirtchev wrote: > Hi Trent, > > I develop a Java application which communicates with devices which have > USB-to-Serial bridge in them. The target OS is Linux. So for this purpose I > use RXTX. > > But I encountered a strange problem - when reading from the InputStream, I > receive series of zeros. I have this problem under Linux only. Under Windows > it is fine. > Actually this problem is the same as the one described here: > http://marc.info/?l=rxtx&m=109703190731748&w=2. > > > So I searched for the problem in the native code. And found that the root of > the problem is in SerialImp.c, > int configure_port( int fd ) > { > ... > ttyset.c_iflag = INPCK; > ... > } > > This line enables input parity checking, and the data sent from the device > is processed by the OS driver before being read with read(). > In this case the driver detects some problem and sets the received bytes to > zero. > > On the other hand in the Java part a set the serial port parameters with > SerialPort.PARITY_NONE. According to me, except all other things, this > should also disable INPCK in c_iflag. > > So I refactored the method translate_parity(...) to the following: > > int translate_parity( JNIEnv *env, struct termios *ttyset, jint parity ) > { > ENTER( "translate_parity" ); > #ifdef CMSPAR > ttyset->c_cflag &= ~(PARENB | PARODD | CMSPAR ); > #endif /* CMSPAR */ > switch( parity ) { > case JPARITY_NONE: > ttyset->c_iflag &= ~INPCK; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_EVEN: > ttyset->c_cflag |= PARENB; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_ODD: > ttyset->c_cflag |= PARENB | PARODD; > LEAVE( "translate_parity" ); > return 0; > #ifdef CMSPAR > case JPARITY_MARK: > ttyset->c_cflag |= PARENB | PARODD | CMSPAR; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_SPACE: > ttyset->c_cflag |= PARENB | CMSPAR; > LEAVE( "translate_parity" ); > return 0; > #endif /* CMSPAR */ > default: > printf("Parity missed %i\n", (int) parity ); > } > > LEAVE( "translate_parity" ); > /* > For some reason the native exceptions are not being caught. Moving this > to the Java side fixed the issue. taj. > throw_java_exception( env, UNSUPPORTED_COMM_OPERATION, > "", "parity value not supported" ); > */ > return 1; > } > > This modification solved the problem and now it works correctly under Linux. > > I think I will be a nice if this is idea is included in a future release of > RXTX. > > Thanks Vadim, I'll try that out. Forwarding to the rxtx mail-list too. This is probably not going to help USB drivers on windows which I'm sure some are looking for. As far as I can tell, windows USB bluetooth and serial dongles are limited by driver functionality. Some are good and others lack key features. -- Trent Jarvi tjarvi at qbang.org From dan.sandberg.lists at gmail.com Mon Jun 18 14:43:39 2007 From: dan.sandberg.lists at gmail.com (Dan Sandberg) Date: Mon, 18 Jun 2007 13:43:39 -0700 Subject: [Rxtx] Fix for JNI Get/Set Field Errors Message-ID: <4676EE7B.7060800@gmail.com> Hi, I've fixed the problems that cause the following JNI error when extra JNI checking ( -Xjni:check ) is turned on. FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) The problem was basically that GetLong was being used to get ints, and SetInt was used for longs. The patch below fixes this. Please let me know if there are any questions / problems. Cheers, -Dan diff -aur old/SerialImp.c src/SerialImp.c --- old/SerialImp.c 2007-06-18 13:24:33.000000000 -0700 +++ src/SerialImp.c 2007-06-18 06:26:26.000000000 -0700 @@ -1337,7 +1337,7 @@ report("init_threads: get eis\n"); jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); report("init_threads: set eis\n"); - (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); + (*eis->env)->SetLongField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); report("init_threads: stop\n"); report_time_end( ); return( 1 ); @@ -1530,7 +1530,7 @@ jobject jobj, jboolean interrupted ) { int fd = get_java_var( env, jobj,"fd","I" ); - struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var( env, jobj, "eis", "J" ); + struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var_long( env, jobj, "eis", "J" ); int result, count=0; char message[80]; @@ -2939,7 +2939,7 @@ /* TRENT */ int flag, count = 0; struct event_info_struct *eis = ( struct event_info_struct * ) - get_java_var( env, *jobj,"eis","J" ); + get_java_var_long( env, *jobj,"eis","J" ); report_time_start(); flag = eis->eventflags[SPE_DATA_AVAILABLE]; @@ -4873,9 +4873,9 @@ exceptions: none comments: ----------------------------------------------------------*/ -size_t get_java_var( JNIEnv *env, jobject jobj, char *id, char *type ) +long get_java_var_long( JNIEnv *env, jobject jobj, char *id, char *type ) { - int result = 0; + long result = 0; jclass jclazz = (*env)->GetObjectClass( env, jobj ); jfieldID jfd = (*env)->GetFieldID( env, jclazz, id, type ); @@ -4889,7 +4889,11 @@ LEAVE( "get_java_var" ); return result; } - result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); + if ( !strcmp( type, "J" ) ) { + result = (long)( (*env)->GetLongField( env, jobj, jfd ) ); + } else { + result = (int) ( (*env)->GetIntField( env, jobj, jfd ) ); + } /* ct7 & gel * Added DeleteLocalRef */ (*env)->DeleteLocalRef( env, jclazz ); if(!strncmp( "fd",id,2) && result == 0) @@ -4900,6 +4904,10 @@ return result; } +int get_java_var( JNIEnv *env, jobject jobj, char *id, char *type ) { + return (int) get_java_var_long( env, jobj, id, type ); +} + /*---------------------------------------------------------- throw_java_exception diff -aur old/SerialImp.h src/SerialImp.h --- old/SerialImp.h 2007-06-18 13:24:39.000000000 -0700 +++ src/SerialImp.h 2007-06-18 06:23:43.000000000 -0700 @@ -413,7 +413,8 @@ void system_wait(); void finalize_event_info_struct( struct event_info_struct * ); int read_byte_array( JNIEnv *, jobject *, int, unsigned char *, int, int ); -size_t get_java_var( JNIEnv *, jobject, char *, char * ); +int get_java_var( JNIEnv *, jobject, char *, char * ); +long get_java_var_long( JNIEnv *, jobject, char *, char * ); jboolean is_interrupted( struct event_info_struct * ); int send_event(struct event_info_struct *, jint, int ); void dump_termios(char *,struct termios *); From yvespielusenet at free.fr Tue Jun 26 03:41:58 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 11:41:58 +0200 Subject: [Rxtx] [PARALLEL] resource in use Message-ID: <1182850918.3483.10.camel@localhost.localdomain> Hello, So now I want to modify the timeout of the library for parallel port. I have downloaded source code. There is a makefile for migw. SO I have installed mingw on ubuntu and modified the makefile.mingw32 to set it for my system. I have no error but some warnings. The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But When I want to use it the jvm crash :( How can I know what is wrong ? How rxtx windows release has been done ? thanks -- yves piel From yvespielusenet at free.fr Tue Jun 26 07:17:02 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 15:17:02 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182850918.3483.10.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> Message-ID: <1182863822.3483.17.camel@localhost.localdomain> Here is the Makefile I use, the output of the 'make' and the log of the jvm when it crashed : - The Makefile : http://yvespiel.free.fr/rxtx/Makefile - The make output : http://yvespiel.free.fr/rxtx/compile.txt - The crash log : http://yvespiel.free.fr/rxtx/hs_err_pid2100.log I have compiled rxtx under Debian testing with mingw : narma at linimi:/tmp/err$ dpkg -l | grep mingw ii mingw32 3.4.5.20060117.1.dfsg-3 ii mingw32-binutils 2.17.50-20070129.1-1 ii mingw32-runtime 3.12-1 thanks fort help :) Le mardi 26 juin 2007 ? 11:41 +0200, yves pielusenet a ?crit : > Hello, > So now I want to modify the timeout of the library for parallel port. I > have downloaded source code. There is a makefile for migw. SO I have > installed mingw on ubuntu and modified the makefile.mingw32 to set it > for my system. > I have no error but some warnings. > The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But > When I want to use it the jvm crash :( > > How can I know what is wrong ? > > How rxtx windows release has been done ? > > thanks > From yvespielusenet at free.fr Tue Jun 26 07:40:11 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 15:40:11 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182863822.3483.17.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> <1182863822.3483.17.camel@localhost.localdomain> Message-ID: <1182865211.3483.21.camel@localhost.localdomain> I have add the options '--enable-stdcall-fixup' to the 'i586-mingw32msvc-ld' commande. Now I have no warning. But the JVM always crashes :( The output seems more detailled, but I don't understand anything... Here is files : http://yvespiel.free.fr/rxtx/2/ -- yves piel Le mardi 26 juin 2007 ? 15:17 +0200, yves pielusenet a ?crit : > Here is the Makefile I use, the output of the 'make' and the log of the > jvm when it crashed : > > - The Makefile : http://yvespiel.free.fr/rxtx/Makefile > - The make output : http://yvespiel.free.fr/rxtx/compile.txt > - The crash log : http://yvespiel.free.fr/rxtx/hs_err_pid2100.log > > I have compiled rxtx under Debian testing with mingw : > narma at linimi:/tmp/err$ dpkg -l | grep mingw > ii mingw32 3.4.5.20060117.1.dfsg-3 > ii mingw32-binutils 2.17.50-20070129.1-1 > ii mingw32-runtime 3.12-1 > > thanks fort help :) > > > Le mardi 26 juin 2007 ? 11:41 +0200, yves pielusenet a ?crit : > > Hello, > > So now I want to modify the timeout of the library for parallel port. I > > have downloaded source code. There is a makefile for migw. SO I have > > installed mingw on ubuntu and modified the makefile.mingw32 to set it > > for my system. > > I have no error but some warnings. > > The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But > > When I want to use it the jvm crash :( > > > > How can I know what is wrong ? > > > > How rxtx windows release has been done ? > > > > thanks > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From yvespielusenet at free.fr Tue Jun 26 08:27:42 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 16:27:42 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182865211.3483.21.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> <1182863822.3483.17.camel@localhost.localdomain> <1182865211.3483.21.camel@localhost.localdomain> Message-ID: <1182868062.3483.24.camel@localhost.localdomain> I think thant the include files of jdk were not for windows but for linux. So I have copied include/ folder from windows to linux and I modified the Makefile to use those file. It compile fine but the JVM always crash :( http://yvespiel.free.fr/rxtx/3/ Le mardi 26 juin 2007 ? 15:40 +0200, yves pielusenet a ?crit : > I have add the options '--enable-stdcall-fixup' to the > 'i586-mingw32msvc-ld' commande. Now I have no warning. But the JVM > always crashes :( The output seems more detailled, but I don't > understand anything... > Here is files : > http://yvespiel.free.fr/rxtx/2/ > From netbeans at gatworks.com Fri Jun 1 05:38:50 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 07:38:50 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <465F7ADD.1010501@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> Message-ID: <4660054A.2040202@gatworks.com> Manuel Naranjo wrote: In the case of my module, you can > unplug the device but it will not delete the symlink until those apps > that had opened the port has closed it. This is done this way to avoid > kernel panics. What does this mean to user code ? I have tried the alternate route ( other than closing ) which is sleep inbetween the I/O errors ( an unplugged USB device). When the device is plugged back in, The writes to the device still get an I/O error. This would seem to be a lost cause for the application. From netbeans at gatworks.com Fri Jun 1 06:35:48 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 08:35:48 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <465F7ADD.1010501@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> Message-ID: <466012A4.90608@gatworks.com> Manuel Naranjo wrote: In the case of my module, you can > unplug the device but it will not delete the symlink until those apps > that had opened the port has closed it. T Did u also mean for this to happen? USB0 was not closed by application. Apparently USB1 got created when USB device was plugged back in. There is only one USB device on a 4 port USB hub. This also seems to suggest that application recovery to be impossible. > Jun 1 07:10:08 mylaptop kernel: garmin_gps 1-1.4:1.0: Garmin GPS usb/tty converter detected > Jun 1 07:10:08 mylaptop kernel: usb 1-1.4: Garmin GPS usb/tty converter now attached to ttyUSB0 > Jun 1 07:15:17 mylaptop kernel: usb 1-1: USB disconnect, address 4 > Jun 1 07:15:17 mylaptop kernel: usb 1-1.4: USB disconnect, address 5 > Jun 1 07:15:17 mylaptop kernel: garmin_gps 1-1.4:1.0: device disconnected > Jun 1 07:15:26 mylaptop kernel: usb 1-1: new full speed USB device using uhci_hcd and address 6 > Jun 1 07:15:26 mylaptop kernel: hub 1-1:1.0: USB hub found > Jun 1 07:15:26 mylaptop kernel: hub 1-1:1.0: 4 ports detected > Jun 1 07:15:27 mylaptop kernel: usb 1-1.4: new full speed USB device using uhci_hcd and address 7 > Jun 1 07:15:27 mylaptop kernel: garmin_gps 1-1.4:1.0: Garmin GPS usb/tty converter detected > Jun 1 07:15:27 mylaptop kernel: usb 1-1.4: Garmin GPS usb/tty converter now attached to ttyUSB1 From naranjo.manuel at gmail.com Fri Jun 1 09:17:22 2007 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Fri, 01 Jun 2007 12:17:22 -0300 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <466012A4.90608@gatworks.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> <466012A4.90608@gatworks.com> Message-ID: <46603882.5050701@gmail.com> Uncle George escribi?: > Manuel Naranjo wrote: > In the case of my module, you can > >> unplug the device but it will not delete the symlink until those apps >> that had opened the port has closed it. T >> > > Did u also mean for this to happen? USB0 was not closed by application. > > Apparently USB1 got created when USB device was plugged back in. There > is only one USB device on a 4 port USB hub. > > This also seems to suggest that application recovery to be impossible. > Exactly there's a dead symlink (you can read and write to it and nothing will happen) and a new port will be created when a new device is connencted. From netbeans at gatworks.com Fri Jun 1 10:20:46 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 12:20:46 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <46603882.5050701@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> <466012A4.90608@gatworks.com> <46603882.5050701@gmail.com> Message-ID: <4660475E.5090202@gatworks.com> Not sure what u mean by "symlink". U cant read/write to it anymore. U get I/O error. In this scenario the device effectively went dead, and only solution is to close the channel. reconnecting the USB device, although dead, but not closed, will create a second device. This does not seem to be a desirable side-effect. The user will now have ttyUSB1, wondering where did ttyUSB0 go to. The application will also be in a confused state, as well as RXTX, because RXTX wont know about ttyUSB1. Manuel Naranjo wrote: > Uncle George escribi?: >> Manuel Naranjo wrote: >> In the case of my module, you can >> >>> unplug the device but it will not delete the symlink until those apps >>> that had opened the port has closed it. T >>> >> Did u also mean for this to happen? USB0 was not closed by application. >> >> Apparently USB1 got created when USB device was plugged back in. There >> is only one USB device on a 4 port USB hub. >> >> This also seems to suggest that application recovery to be impossible. >> > Exactly there's a dead symlink (you can read and write to it and nothing > will happen) and a new port will be created when a new device is connencted. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From arnab.bhaumik at gmail.com Mon Jun 4 01:40:16 2007 From: arnab.bhaumik at gmail.com (arnab bhaumik) Date: Mon, 4 Jun 2007 13:10:16 +0530 Subject: [Rxtx] full duplex com port with rxtx Message-ID: hi , till now i did half duplex communication with rxtx package on com package. my question is : is it possible to use com port with full duplex mode with rxtx package . ther is example of SimpleRead class and SimpleWrite class. it is clear that if i can use both the class simultaneously then full duplex is possible......... arnab/vu2bpw -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070604/6edb0453/attachment-0009.html From lists at iDIAcomputing.com Mon Jun 4 07:53:17 2007 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Mon, 04 Jun 2007 09:53:17 -0400 Subject: [Rxtx] full duplex com port with rxtx In-Reply-To: References: Message-ID: <4664194D.90301@iDIAcomputing.com> arnab bhaumik wrote: > hi , > > till now i did half duplex communication with rxtx package on com > package. > > my question is : is it possible to use com port with full duplex mode > with rxtx package . > > > ther is example of SimpleRead class and SimpleWrite class. it is > clear that if i can use both the class simultaneously then full duplex > is possible......... I haven't looked at the SimpleRead and SimpleWrite classes (I originally wrote my code for the javax.comm api), but full duplex is certainly possible. My CommReader class requires an object analogous to a OutputStream or Writer. When started, it spawns a thread that reads the comm port and writes to that output device. In this way the input is asynchronous and dependent on the actual input data. For full duplex, I extend that class with CommReaderWriter, which adds synchronous output methods. Hope that helps, George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From supsoop at hotmail.com Mon Jun 4 15:21:06 2007 From: supsoop at hotmail.com (soop soop) Date: Mon, 04 Jun 2007 21:21:06 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- Message-ID: Hi Guys, Looked through the archives but still cannot figure this out. I have a Motorola G24 GPRS/GSM modem that I am connecting to my server running Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not detecting the port, CommPortIdentifier.getPortIdentifiers(). I have added the line to RXTXCommDriver: "ttyACM" // for USB Modems Rxtx still does not seem to find the port. Is there something I am missing to make this port visable? [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control Model driver for USB modems and ISDN adapters I really need your help as I have moved my server from windows to Linux and have been down for a few days because of this .. Thanks so much! _________________________________________________________________ PC Magazine’s 2007 editors’ choice for best Web mail—award-winning Windows Live Hotmail. http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 From tjarvi at qbang.org Mon Jun 4 16:17:35 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Jun 2007 16:17:35 -0600 (MDT) Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: On Mon, 4 Jun 2007, soop soop wrote: > Hi Guys, > > Looked through the archives but still cannot figure this out. I have a > Motorola G24 GPRS/GSM modem that I am connecting to my server running Ubuntu. > I can see my modem as is shows up as ttyACM0, but RXTX is not detecting the > port, CommPortIdentifier.getPortIdentifiers(). > > I have added the line to RXTXCommDriver: > > "ttyACM" // for USB Modems > > Rxtx still does not seem to find the port. Is there something I am missing to > make this port visable? > > [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver > [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device > [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control Model > driver for USB modems and ISDN adapters > > I really need your help as I have moved my server from windows to Linux and > have been down for a few days because of this .. Thanks so much! > You could try the INSTALL documentation that comes with the source for possible solutions. Those usually involve lockfile creation, permissions on the device file or the device is in use by another application (even another session of your application). The usual commands: ls -l /dev/ttyACM0 fuser /dev/ttyACM0 touch /var/lock/LCK.testfile && rm -f /var/lock/LCK.testfile whoami To disable lockfiles: ../configure --disable-lockfiles && make install -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Jun 4 16:22:52 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 04 Jun 2007 18:22:52 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <466490BC.3090801@gatworks.com> soop soop wrote: > I really need your help as I have moved my server from windows to Linux > and have been down for a few days because of this .. Thanks so much! can u open the device ? ie is the file protection/permissions keeping you out? From supsoop at hotmail.com Mon Jun 4 16:44:40 2007 From: supsoop at hotmail.com (soop soop) Date: Mon, 04 Jun 2007 22:44:40 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <466490BC.3090801@gatworks.com> Message-ID: Thanks for the reply, I see no exceptions being thrown, just no detection of the port whats so ever. I will run rxtx in debug mode and log. If this were a permissions issue would I not see some exceptions being thrown? >From: Uncle George >Reply-To: RXTX Developers and Users >To: RXTX Developers and Users >Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >Date: Mon, 04 Jun 2007 18:22:52 -0400 > >soop soop wrote: > > > I really need your help as I have moved my server from windows to Linux > > and have been down for a few days because of this .. Thanks so much! > >can u open the device ? ie is the file protection/permissions keeping >you out? >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ Get a preview of Live Earth, the hottest event this summer - only on MSN http://liveearth.msn.com?source=msntaglineliveearthhm From netbeans at gatworks.com Mon Jun 4 17:06:15 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 04 Jun 2007 19:06:15 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <46649AE7.10405@gatworks.com> Exceptions on what? On startup it wants to lookup all devices in /dev that it is capable of opening ( within the list of specific 'comm' devices ). If it cannot open, then does not get onto list. Part of this process, if configured, will also test if the "LOCK" schema can also be opened for the device. then it gets on the list of avail comm port. soop soop wrote: > Thanks for the reply, > > I see no exceptions being thrown, just no detection of the port whats so > ever. I will run rxtx in debug mode and log. If this were a permissions > issue would I not see some exceptions being thrown? > > >> From: Uncle George >> Reply-To: RXTX Developers and Users >> To: RXTX Developers and Users >> Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >> Date: Mon, 04 Jun 2007 18:22:52 -0400 >> >> soop soop wrote: >> >>> I really need your help as I have moved my server from windows to Linux >>> and have been down for a few days because of this .. Thanks so much! >> can u open the device ? ie is the file protection/permissions keeping >> you out? >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _________________________________________________________________ > Get a preview of Live Earth, the hottest event this summer - only on MSN > http://liveearth.msn.com?source=msntaglineliveearthhm > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From alex.flint at gmail.com Mon Jun 4 21:31:49 2007 From: alex.flint at gmail.com (Alex Flint) Date: Tue, 5 Jun 2007 13:01:49 +0930 Subject: [Rxtx] random EXCEPTION_ACCESS_VIOLATION errors Message-ID: Hi All, I'm running winXP and RXTX 2.1-7r2 (the latest from the webpage as of June 2007). I'm sending sequences of 64 lines (each line has about 15 chars) at various intervals. The strings are sent fine, until I get the following error (from hs_err_pid3316.log, at the end of this email). What can I do to avoid the error? Obviously this is a low-level memory exception, but is there any way I can keep the JVM running after such an error? I noticed the exact same problem here: http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20070129/1180520.html Cheers, Alex # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x100034fb, pid=3316, tid=2400 # # Java VM: Java HotSpot(TM) Client VM (1.6.0_01-b06 mixed mode, sharing) # Problematic frame: # C [rxtxSerial.dll+0x34fb] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # --------------- T H R E A D --------------- Current thread (0x00386400): JavaThread "main" [_thread_in_native, id=2400] siginfo: ExceptionCode=0xc0000005, reading address 0x20726f78 Registers: EAX=0x20726f20, EBX=0x6d8922c0, ECX=0x00000005, EDX=0x20726f20 ESP=0x003efa30, EBP=0x003efb68, ESI=0x269728a0, EDI=0x00386400 EIP=0x100034fb, EFLAGS=0x00010212 Top of Stack: (sp=0x003efa30) 0x003efa30: 003efa3c 003efa64 0000000f ffffffff 0x003efa40: 003efa40 2a97f808 003efa6c 2b190ca8 0x003efa50: 00000000 2b190ec0 003efa90 008e2dd7 0x003efa60: 003efa90 008e2dd7 26977f88 6d815e72 0x003efa70: 00000004 2696eae0 0000008a 003efb0c 0x003efa80: 6d852b4a 2696eae0 00000003 26970930 0x003efa90: 000000cb 2696eae0 6d86b264 00385d40 0x003efaa0: 0000003f 003efb0c 26977f90 2ace65d8 Instructions: (pc=0x100034fb) 0x100034eb: ff ff 8d 76 00 eb 02 89 f6 90 8b 45 f8 8b 55 f8 0x100034fb: 8b 4a 58 83 c9 04 89 48 58 83 c4 f8 8b 45 f8 8b Stack: [0x003a0000,0x003f0000), sp=0x003efa30, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x34fb] Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j gnu.io.RXTXPort.writeArray([BIIZ)V+0 j gnu.io.RXTXPort$SerialOutputStream.write([B)V+76 j com.bjt.media.server.CommLink.send(Ljava/lang/String;)V+48 j com.bjt.media.server.DigitoolConnection.select(I)V+73 j com.bjt.media.server.DigitoolConnection.main([Ljava/lang/String;)V+74 v ~StubRoutines::call_stub --------------- P R O C E S S --------------- Java Threads: ( => current thread ) 0x02a69400 JavaThread "Thread-0" [_thread_in_native, id=3052] 0x02a4d000 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=3920] 0x02a48400 JavaThread "CompilerThread0" daemon [_thread_blocked, id=1968] 0x02a47400 JavaThread "Attach Listener" daemon [_thread_blocked, id=2984] 0x02a46400 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=2660] 0x02a41c00 JavaThread "Finalizer" daemon [_thread_blocked, id=3924] 0x02a3d800 JavaThread "Reference Handler" daemon [_thread_blocked, id=4008] =>0x00386400 JavaThread "main" [_thread_in_native, id=2400] Other Threads: 0x02a34400 VMThread [id=3708] 0x02a4e800 WatcherThread [id=3964] VM state:not at safepoint (normal execution) VM Mutex/Monitor currently owned by a thread: None Heap def new generation total 960K, used 131K [0x22960000, 0x22a60000, 0x22e40000) eden space 896K, 7% used [0x22960000, 0x22970ea8, 0x22a40000) from space 64K, 99% used [0x22a50000, 0x22a5fff8, 0x22a60000) to space 64K, 0% used [0x22a40000, 0x22a40000, 0x22a50000) tenured generation total 4096K, used 76K [0x22e40000, 0x23240000, 0x26960000) the space 4096K, 1% used [0x22e40000, 0x22e53060, 0x22e53200, 0x23240000) compacting perm gen total 12288K, used 137K [0x26960000, 0x27560000, 0x2a960000) the space 12288K, 1% used [0x26960000, 0x26982518, 0x26982600, 0x27560000) ro space 8192K, 62% used [0x2a960000, 0x2ae5e4e8, 0x2ae5e600, 0x2b160000) rw space 12288K, 52% used [0x2b160000, 0x2b7a0e78, 0x2b7a1000, 0x2bd60000) Dynamic libraries: 0x00400000 - 0x00423000 C:\Program Files\Java\jre1.6.0_01\bin\javaw.exe 0x7c900000 - 0x7c9b0000 C:\WINDOWS\system32\ntdll.dll 0x7c800000 - 0x7c8f4000 C:\WINDOWS\system32\kernel32.dll 0x77dd0000 - 0x77e6b000 C:\WINDOWS\system32\ADVAPI32.dll 0x77e70000 - 0x77f01000 C:\WINDOWS\system32\RPCRT4.dll 0x7e410000 - 0x7e4a0000 C:\WINDOWS\system32\USER32.dll 0x77f10000 - 0x77f57000 C:\WINDOWS\system32\GDI32.dll 0x76390000 - 0x763ad000 C:\WINDOWS\system32\IMM32.DLL 0x7c340000 - 0x7c396000 C:\Program Files\Java\jre1.6.0_01\bin\msvcr71.dll 0x6d7c0000 - 0x6da07000 C:\Program Files\Java\jre1.6.0_01\bin\client\jvm.dll 0x76b40000 - 0x76b6d000 C:\WINDOWS\system32\WINMM.dll 0x5cd70000 - 0x5cd77000 C:\WINDOWS\system32\serwvdrv.dll 0x5b0a0000 - 0x5b0a7000 C:\WINDOWS\system32\umdmxfrm.dll 0x6d310000 - 0x6d318000 C:\Program Files\Java\jre1.6.0_01\bin\hpi.dll 0x76bf0000 - 0x76bfb000 C:\WINDOWS\system32\PSAPI.DLL 0x6d770000 - 0x6d77c000 C:\Program Files\Java\jre1.6.0_01\bin\verify.dll 0x6d3b0000 - 0x6d3cf000 C:\Program Files\Java\jre1.6.0_01\bin\java.dll 0x6d7b0000 - 0x6d7bf000 C:\Program Files\Java\jre1.6.0_01\bin\zip.dll 0x10000000 - 0x10012000 C:\Documents and Settings\Alex\workspace\MediaServer\rxtxSerial.dll 0x73d90000 - 0x73db7000 C:\WINDOWS\system32\crtdll.dll VM Arguments: jvm_args: -Djava.library.path=C:\Documents and Settings\Alex\workspace\MediaServer java_command: com.bjt.media.server.DigitoolConnection Launcher Type: SUN_STANDARD Environment Variables: CLASSPATH=.;C:\Program Files\Java\j2re1.4.2_07\lib\ext\QTJava.zip PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\wbem;c:\applications\php;C:\Program Files\MATLAB\R2006a\bin\win32;C:\Roger\Projects\UAV\Bin\Debug;C:\Program Files\Microsoft SQL Server\80\Tools\Binn\;c:\Program Files\Microsoft SQL Server\90\Tools\binn\;C:\Program Files\QuickTime\QTSystem\;C:\Pfps\system;C:\Program Files\Java\jdk1.6.0_01\bin;C:\Program Files\Java\jdk1.6.0_01\jre\bin USERNAME=Alex OS=Windows_NT PROCESSOR_IDENTIFIER=x86 Family 15 Model 4 Stepping 1, GenuineIntel --------------- S Y S T E M --------------- OS: Windows XP Build 2600 Service Pack 2 CPU:total 1 family 15, cmov, cx8, fxsr, mmx, sse, sse2 Memory: 4k page, physical 1046508k(275288k free), swap 2522816k(1909176k free) vm_info: Java HotSpot(TM) Client VM (1.6.0_01-b06) for windows-x86, built on Mar 14 2007 00:24:02 by "java_re" with unknown MS VC++:1310 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070604/c87ae1f0/attachment-0009.html From alwyn.schoeman at gmail.com Tue Jun 5 00:10:19 2007 From: alwyn.schoeman at gmail.com (Alwyn Schoeman) Date: Tue, 5 Jun 2007 08:10:19 +0200 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Hi, I'm using a similar modem. By default rxtx doesn't look for devices that start with ACM, so you need to modify the source code and recompile. Look in RXTXCommDriver and add values for ACM in the registerScannedPorts method in the Linux specific parts. Look for osName.equals("Linux")... On 6/4/07, soop soop wrote: > > Hi Guys, > > Looked through the archives but still cannot figure this out. I have a > Motorola G24 GPRS/GSM modem that I am connecting to my server running > Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not > detecting the port, CommPortIdentifier.getPortIdentifiers(). > > I have added the line to RXTXCommDriver: > > "ttyACM" // for USB Modems > > Rxtx still does not seem to find the port. Is there something I am missing > to make this port visable? > > [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver > [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device > [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control > Model > driver for USB modems and ISDN adapters > > I really need your help as I have moved my server from windows to Linux > and > have been down for a few days because of this .. Thanks so much! > > _________________________________________________________________ > PC Magazine's 2007 editors' choice for best Web mail?award-winning Windows > Live Hotmail. > > http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -- Alwyn Schoeman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/b6cb3053/attachment-0009.html From naranjo.manuel at gmail.com Tue Jun 5 06:48:45 2007 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Tue, 05 Jun 2007 09:48:45 -0300 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> References: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Message-ID: <46655BAD.7010501@gmail.com> That's right, an easier solution is creating symlinks to acm. For example make ttyS70 to 79 point to ACM0 to 9 and that will help you a lot, and doesn't even require compile. > Hi, > > I'm using a similar modem. By default rxtx doesn't look for devices > that start with ACM, so you need to modify the > source code and recompile. > > Look in RXTXCommDriver and add values for ACM in the > registerScannedPorts method in the Linux specific parts. Look for > osName.equals("Linux")... > From juanemc2 at gmail.com Tue Jun 5 07:02:43 2007 From: juanemc2 at gmail.com (Juan) Date: Tue, 5 Jun 2007 10:02:43 -0300 Subject: [Rxtx] Problems with Epson TMU220B POSPrinter using XON/XOFF Flow Control and rxtx jar and dll's with the serial port. Message-ID: Hi!, I?m having trouble printing to the serial port using the latest version of rxtx jar and dll's with an Epson POSPrinter. I`ve switched the printer to work with XON/XOFF Flow Control and have watched the serial port to be sure the printer is sending the XON XOFF stop and go characters. I`ve setted the port like this: CommPortIdentifier commPortIdentifier = CommPortIdentifier.* getPortIdentifier*(_portName); SerialPort serialPort = (SerialPort)commPortIdentifier.open(*this*.getClass().getName(), 2000); serialPort.setSerialPortParams(_baudRate, _dataBits, _stopBits, _parity); serialPort.setFlowControlMode( SerialPort.*FLOWCONTROL_XONXOFF_IN* | SerialPort.*FLOWCONTROL_XONXOFF_OUT*); where the baudRate is 9600 the dataBits is 8 the stopBits is 1 and the parity is 0 It seems as the library isn`t taking into account the XON XOFF setting. I would like to know if I`m setting correctly the Flow Control and if you had had any experiences using XON XOFF flow control and could give me some help to solve my problem. I`m very thankful in advance, Yours, Juan Polero -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/b080995a/attachment-0009.html From ehdez.correo at gmail.com Tue Jun 5 07:12:53 2007 From: ehdez.correo at gmail.com (=?ISO-8859-1?Q?Enrique_Hern=E1ndez?=) Date: Tue, 5 Jun 2007 09:12:53 -0400 Subject: [Rxtx] problem with rxtx Message-ID: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Hello: I doing a simple test to show the serial ports. This is the code: import java.util.Enumeration; import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; public class Show { private Enumeration portList; private CommPortIdentifier portId; private SerialPort port; /** Creates a new instance of Show */ public Show() { } public static void main(String args[]){ Show show = new Show(); show.portList = CommPortIdentifier.getPortIdentifiers(); String tPort = ""; System.out.println("========================================="); while(show.portList.hasMoreElements()){ show.portId = (CommPortIdentifier)show.portList.nextElement(); if(show.portId.getPortType() == CommPortIdentifier.PORT_SERIAL) tPort = "Serial"; else tPort = "Parallel"; System.out.println(show.portId.getName() + " " + tPort); } } } whit The problem is that this code not show the serial ports, this show the no use serial ports. I want to connect whit the modem but when windows open and connect the modem my application don't see the port(COMM3) when it is connect. what I can do? Is that the correct way to know the ports? thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/eedd744b/attachment-0009.html From ehdez.correo at gmail.com Tue Jun 5 07:42:13 2007 From: ehdez.correo at gmail.com (=?ISO-8859-1?Q?Enrique_Hern=E1ndez?=) Date: Tue, 5 Jun 2007 09:42:13 -0400 Subject: [Rxtx] serial port Message-ID: <4a814e1f0706050642p4ce9ac7bka80f9479c524c5ea@mail.gmail.com> Hello: How I can ask to the port what device is connect and information about this device. thanks. bye. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/4d10d26a/attachment-0009.html From supsoop at hotmail.com Tue Jun 5 09:29:00 2007 From: supsoop at hotmail.com (soop soop) Date: Tue, 05 Jun 2007 15:29:00 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Message-ID: Hi Guys, Thanks for all your help. I found the problem. I created a user, Tomcat55, for my tomcat but it did not belong to any group. I then added this user to dialout group to have access to the device ttyACM0. Works perfectly! Again permissions was the issue. This also seems to be persistent as a server reboot does not effect the access. Cheers! >From: "Alwyn Schoeman" >Reply-To: RXTX Developers and Users >To: "RXTX Developers and Users" >Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >Date: Tue, 5 Jun 2007 08:10:19 +0200 > >Hi, > >I'm using a similar modem. By default rxtx doesn't look for devices that >start with ACM, so you need to modify the >source code and recompile. > >Look in RXTXCommDriver and add values for ACM in the registerScannedPorts >method in the Linux specific parts. Look for osName.equals("Linux")... > >On 6/4/07, soop soop wrote: >> >>Hi Guys, >> >>Looked through the archives but still cannot figure this out. I have a >>Motorola G24 GPRS/GSM modem that I am connecting to my server running >>Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not >>detecting the port, CommPortIdentifier.getPortIdentifiers(). >> >>I have added the line to RXTXCommDriver: >> >>"ttyACM" // for USB Modems >> >>Rxtx still does not seem to find the port. Is there something I am missing >>to make this port visable? >> >>[ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver >>[ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device >>[ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control >>Model >>driver for USB modems and ISDN adapters >> >>I really need your help as I have moved my server from windows to Linux >>and >>have been down for a few days because of this .. Thanks so much! >> >>_________________________________________________________________ >>PC Magazine's 2007 editors' choice for best Web mail—award-winning Windows >>Live Hotmail. >> >>http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 >> >> >>_______________________________________________ >>Rxtx mailing list >>Rxtx at qbang.org >>http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > >-- >Alwyn Schoeman >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ Need a break? Find your escape route with Live Search Maps. http://maps.live.com/default.aspx?ss=Restaurants~Hotels~Amusement%20Park&cp=33.832922~-117.915659&style=r&lvl=13&tilt=-90&dir=0&alt=-1000&scene=1118863&encType=1&FORM=MGAC01 From netbeans at gatworks.com Tue Jun 5 09:42:31 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 11:42:31 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <46658467.20101@gatworks.com> soop soop wrote: > > Hi Guys, > > Thanks for all your help. I found the problem. I created a user, > Tomcat55, for my tomcat but it did not belong to any group. I then added Look at man pages for the program udev. From tjarvi at qbang.org Tue Jun 5 18:18:17 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Jun 2007 18:18:17 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Message-ID: On Tue, 5 Jun 2007, Enrique Hern?ndez wrote: > The problem is that this code not show the serial ports, this show the no > use serial ports. I want to connect whit the modem but when windows open and > connect the modem my application don't see the port(COMM3) when it is > connect. > what I can do? > Is that the correct way to know the ports? > Hello, We may have problems understanding each other. On windows, the port will not be an available serial port if another application has the port open. That is just how the library behaves. If you can not see the port in the enumerated list, you could not open it. Also note that enumeration only happens once. If you add a port such as a new USB dongle, the port will not be visible until the next time your application runs. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Tue Jun 5 18:45:01 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 20:45:01 -0400 Subject: [Rxtx] problem with rxtx In-Reply-To: References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Message-ID: <4666038D.8090700@gatworks.com> Trent Jarvi wrote: > > > Also note that enumeration only happens once. If you add a port such as > a new USB dongle, the port will not be visible until the next time your > application runs. Is this written in stone ? somewhere? From tjarvi at qbang.org Tue Jun 5 18:54:36 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Jun 2007 18:54:36 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <4666038D.8090700@gatworks.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> Message-ID: On Tue, 5 Jun 2007, Uncle George wrote: > Trent Jarvi wrote: >> >> >> Also note that enumeration only happens once. If you add a port such as >> a new USB dongle, the port will not be visible until the next time your >> application runs. > > Is this written in stone ? somewhere? It is just the current behavior. There is nothing preventing a fix that allows reenumeration. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Tue Jun 5 19:55:19 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 21:55:19 -0400 Subject: [Rxtx] problem with rxtx In-Reply-To: References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> Message-ID: <46661407.4020308@gatworks.com> >> Is this written in stone ? somewhere? > > It is just the current behavior. There is nothing preventing a fix that > allows reenumeration. With usb, ..... , things come and go. Seems a shame that you have to kill application to get at the device u just plugged in. From joachim at buechse.ch Wed Jun 6 01:50:06 2007 From: joachim at buechse.ch (Joachim Buechse) Date: Wed, 6 Jun 2007 09:50:06 +0200 Subject: [Rxtx] problem with rxtx In-Reply-To: <46661407.4020308@gatworks.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> <46661407.4020308@gatworks.com> Message-ID: <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> On MacOS RXTX's enumeration handling is more flexible. It will find new ports that are added during the lifetime of the application. But this is inherently incompatible with suns javax.comm implementation... Regards, Joachim On 06.06.2007, at 03:55, Uncle George wrote: > >>> Is this written in stone ? somewhere? >> >> It is just the current behavior. There is nothing preventing a >> fix that >> allows reenumeration. > > With usb, ..... , things come and go. Seems a shame that you have to > kill application to get at the device u just plugged in. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Jun 6 06:06:48 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Jun 2007 06:06:48 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> <46661407.4020308@gatworks.com> <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> Message-ID: Sun's javax.comm is not a major concern going forward. As long as we do not break old applications using rxtx, I see no reason to limit rxtx to that convention. We have already rejected version 3 from Sun as a dead end and limited our compatability to version 2. That does not mean we will not try to work with Sun and others but the current javax.comm convention (v3) is not a well conceived path. There has been discussion about doing a JSR which is one valid option. On Wed, 6 Jun 2007, Joachim Buechse wrote: > On MacOS RXTX's enumeration handling is more flexible. It will find > new ports that are added during the lifetime of the application. But > this is inherently incompatible with suns javax.comm implementation... > > Regards, > Joachim > > On 06.06.2007, at 03:55, Uncle George wrote: > >> >>>> Is this written in stone ? somewhere? >>> >>> It is just the current behavior. There is nothing preventing a >>> fix that >>> allows reenumeration. >> >> With usb, ..... , things come and go. Seems a shame that you have to >> kill application to get at the device u just plugged in. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From yvespielusenet at free.fr Wed Jun 6 08:46:35 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 16:46:35 +0200 Subject: [Rxtx] [PARALLEL] resource in use Message-ID: <1181141195.3407.20.camel@localhost.localdomain> Hello, I want to use rxtx in my application. I haveto send data to a very old printer (which have a drum and hammers http://perso.orange.fr/tiie/page00010017.html) This is printer is connecter with centronics. It works well but, while it's writting and I putthe printer off-line, after about 45 seconds, I have this error : ------------------------------------- java.io.IOException: La ressource demand?e est en cours d'utilisation. in writeArray at gnu.io.LPRPort.writeArray(Native Method) at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:292) at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:161) at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:156) at mce.buffer.bufferManager.BufferManager$PrintBuffer.run(BufferManager.java:141) The IOexception means "The wanted resource is in use" ------------------------------------- Here is the line 141 of BufferManager : ------------------------------------- while(send){ try{ fos.write(bb); <=== line 141 send = false; } catch(Exception e){ javax.swing.JOptionPane.showMessageDialog(null, "Erreur d'envoie. Veuillez cliquer sur OK pour relancer l'impression de la vignette.\nV?rifiez votre impression !", "Erreur d'envoie", javax.swing.JOptionPane.WARNING_MESSAGE); e.printStackTrace(System.err); System.err.flush(); System.out.println(e); send = true; } } -------------------------------- 'fos' is an outputstream which contains the rxtx stream (this.os is the rxtx outputstream) : -------------------------------- public void write(byte[] bb) throws IOException{ this.write(bb, 0, bb.length); } public void write(byte[] bb, int off, int len) throws IOException{ while(!imp1.isPrinterSelected() || !imp2.isPrinterSelected()){ } this.os.write(bb, off, len); } -------------------------------- Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( can you help me ? thank you :) -- yves piel From yvespielusenet at free.fr Wed Jun 6 09:11:15 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 17:11:15 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181141195.3407.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> Message-ID: <1181142675.3407.23.camel@localhost.localdomain> I forgot to tell that It's under windows XP and java 1.5. Le mercredi 06 juin 2007 ? 16:46 +0200, yves pielusenet a ?crit : > Hello, > I want to use rxtx in my application. I haveto send data to a very old > printer (which have a drum and hammers > http://perso.orange.fr/tiie/page00010017.html) > This is printer is connecter with centronics. It works well but, while > it's writting and I putthe printer off-line, after about 45 seconds, I > have this error : > ------------------------------------- > java.io.IOException: La ressource demand?e est en cours d'utilisation. > in writeArray > at gnu.io.LPRPort.writeArray(Native Method) > at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:292) > at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:161) > at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:156) > at mce.buffer.bufferManager.BufferManager$PrintBuffer.run(BufferManager.java:141) > > The IOexception means "The wanted resource is in use" > ------------------------------------- > > Here is the line 141 of BufferManager : > > ------------------------------------- > while(send){ > try{ > fos.write(bb); <=== line 141 > send = false; > } > catch(Exception e){ > javax.swing.JOptionPane.showMessageDialog(null, "Erreur d'envoie. Veuillez cliquer sur OK pour relancer l'impression de la vignette.\nV?rifiez votre impression !", "Erreur d'envoie", javax.swing.JOptionPane.WARNING_MESSAGE); > e.printStackTrace(System.err); > System.err.flush(); > System.out.println(e); > send = true; > } > } > -------------------------------- > 'fos' is an outputstream which contains the rxtx stream (this.os is the rxtx outputstream) : > > -------------------------------- > public void write(byte[] bb) throws IOException{ > this.write(bb, 0, bb.length); > } > public void write(byte[] bb, int off, int len) throws IOException{ > while(!imp1.isPrinterSelected() || !imp2.isPrinterSelected()){ > } > this.os.write(bb, off, len); > } > -------------------------------- > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > can you help me ? > > thank you :) > From netbeans at gatworks.com Wed Jun 6 09:21:46 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 11:21:46 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181141195.3407.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> Message-ID: <4666D10A.8000507@gatworks.com> } > -------------------------------- > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > can you help me ? > > thank you :) > windoz or linux? ( I guess windoz ) for windoz, there appears to be a timeout ( as Comments suggest ) of about 40seconds. > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } for linux, there is no implied timeout. > if( write( fd, bytes, count ) < 0 ) > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); From netbeans at gatworks.com Wed Jun 6 09:39:41 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 11:39:41 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666D10A.8000507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> Message-ID: <4666D53D.90000@gatworks.com> Uncle George wrote: > } >> -------------------------------- >> >> Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( >> >> can you help me ? From reading the code, I can see your concern. And it appears you are correct, because some of the data will be sent to the OS printer buffers, and then it will refuse to accept anymore. Unfortunately, writeArray does not return the num of characters written :{ So application has no idea to how many characters were accepted by the OS. I dont do windoz, so I cant say with absolute certainty what windoz will do with an off-line condition. If you have the source, and can compile, then maybe u can increase the loop count to hit 4hours? From yvespielusenet at free.fr Wed Jun 6 09:53:25 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 17:53:25 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666D10A.8000507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> Message-ID: <1181145205.3407.35.camel@localhost.localdomain> Thank you for your explanation :) This timeout comes when no data has been send to the printer after 40seconds if I well understand. But why there is such a timeout ? If I setthe printer offline while it's printing I mustn't have an exception. I don't understand why the "printer should solv all problems like buffer full" in 40 seconds. If I pause the printer the buffer will not be emptied, isn't it ? I not very familiar with C/C++, but it seem that the exception is thrown only when countWritten == 0, that means no data at all has been sent. So Is my code is good since when I intercept this exception I send all my buffer again. There is no way that the printer receive two times same bytes ? thanks ps: yes the application is running on windows XP since I developpe under Debian Le mercredi 06 juin 2007 ? 11:21 -0400, Uncle George a ?crit : > } > > -------------------------------- > > > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > > > can you help me ? > > > > thank you :) > > > > windoz or linux? ( I guess windoz ) > > for windoz, there appears to be a timeout ( as Comments suggest ) of > about 40seconds. > > while( count > 0 ){ > > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > > /* > > this are 20 * 2 seconds, in this time a printer (or other parallel device) > > should solv all problems like buffer full, etc > > */ > > if(errorCount++ < 20){ > > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > > continue; > > } > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > for linux, there is no implied timeout. > > if( write( fd, bytes, count ) < 0 ) > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Wed Jun 6 10:34:24 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 12:34:24 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181145205.3407.35.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> Message-ID: <4666E210.30507@gatworks.com> yves pielusenet wrote: > Thank you for your explanation :) > This timeout comes when no data has been send to the printer after > 40seconds if I well understand. But why there is such a timeout ? If I > setthe printer offline while it's printing I mustn't have an exception. > I don't understand why the "printer should solv all problems like buffer > full" in 40 seconds. If I pause the printer the buffer will not be > emptied, isn't it ? > > I not very familiar with C/C++, but it seem that the exception is thrown > only when countWritten == 0, that means no data at all has been sent. So > Is my code is good since when I intercept this exception I send all my > buffer again. There is no way that the printer receive two times same > bytes ? More technically, the function call returns and reports that 0 characters was written in this call. when 0 characters are written, it will check how many times 0 characters was written. If it has tried LESS than 20 times(errorCount), it will sleep() and try to write again. After 20 times, it wont sleep, but throw you the exception. Now suppose you are writing a 120 character line. you off-lined/paused your printer. The OS has room for 80 more characters in it's printer buffer. The WriteFile() will have a char count of 120, but on return the countWritten = 80. You still have 40 more characters to print. Since countWritten != 0, the counters: bytes += countWritten; count -= countWritten; get updated, and the Writefile now has a count of 40 characters. Since the printer is off-line, the countwritten is 0. And so the loop continues, till 40 seconds is up. As to why it is this way, i dont know ( not a windoz maven ); Also the sleep(20) in the loop is not so intuitive to suggest 2 seconds of sleep. I would have guessed 20seconds, or 20milliseconds. But go figure. BTW: Since your computer sends you error messages in French, does it curse in English? :)))) From yvespielusenet at free.fr Thu Jun 7 02:27:44 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Thu, 07 Jun 2007 10:27:44 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666E210.30507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> Message-ID: <1181204864.3501.10.camel@localhost.localdomain> Maybe in my case I should re-compile rxtx and change the code. Instead of send an exception I should display a dialog box to ask if it's printer problem or if it should trie to send bytes. Something like : while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } if(displayDialogBox("Try again to send datas ??")){ errorCount = 0; } else{ throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } } Le mercredi 06 juin 2007 ? 12:34 -0400, Uncle George a ?crit : > yves pielusenet wrote: > > Thank you for your explanation :) > > This timeout comes when no data has been send to the printer after > > 40seconds if I well understand. But why there is such a timeout ? If I > > setthe printer offline while it's printing I mustn't have an exception. > > I don't understand why the "printer should solv all problems like buffer > > full" in 40 seconds. If I pause the printer the buffer will not be > > emptied, isn't it ? > > > > I not very familiar with C/C++, but it seem that the exception is thrown > > only when countWritten == 0, that means no data at all has been sent. So > > Is my code is good since when I intercept this exception I send all my > > buffer again. There is no way that the printer receive two times same > > bytes ? > More technically, the function call returns and reports that 0 > characters was written in this call. > when 0 characters are written, it will check how many times 0 characters > was written. If it has tried LESS than 20 times(errorCount), it will > sleep() and try to write again. > After 20 times, it wont sleep, but throw you the exception. > > Now suppose you are writing a 120 character line. you off-lined/paused > your printer. The OS has room for 80 more characters in it's printer > buffer. The WriteFile() will have a char count of 120, but on return the > countWritten = 80. You still have 40 more characters to print. > Since countWritten != 0, the counters: > bytes += countWritten; > count -= countWritten; > get updated, and the Writefile now has a count of 40 characters. Since > the printer is off-line, the countwritten is 0. And so the loop > continues, till 40 seconds is up. > > As to why it is this way, i dont know ( not a windoz maven ); > Also the sleep(20) in the loop is not so intuitive to suggest 2 seconds > of sleep. I would have guessed 20seconds, or 20milliseconds. But go figure. > > BTW: Since your computer sends you error messages in French, does it > curse in English? :)))) > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 06:11:43 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 08:11:43 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181204864.3501.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> Message-ID: <4667F5FF.8070903@gatworks.com> your suggestion appears good. I dont know what displayDialogBox exactly will do, so all I can say it that it looks good. But I'd like to wait 10min before first dialog box And a 5 min wait for every dialog box there after. And since these are custom solution/choices, maybe a more exact explanation of what the issue is. if(errorCount++ < 300){ // wait 10min ( 10min * 60sec / 2 ) Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } if(displayDialogBox("Printer has Paused. Retry sending data?")){ errorCount = 150; // Wait for 5 min thereafter continue; } > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } yves pielusenet wrote: > Maybe in my case I should re-compile rxtx and change the code. Instead > of send an exception I should display a dialog box to ask if it's > printer problem or if it should trie to send bytes. Something like : > > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > > if(displayDialogBox("Try again to send datas ??")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > } > From yvespielusenet at free.fr Thu Jun 7 07:17:21 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Thu, 07 Jun 2007 15:17:21 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4667F5FF.8070903@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <4667F5FF.8070903@gatworks.com> Message-ID: <1181222241.3501.20.camel@localhost.localdomain> thank you :) 'displayDialogBox()' I think doesn't exist. It was just for the example :) But I think It should not be so complicated to display a dialog box under windows with YES/NO buttons. When yes is clicked it return 0 other it returns 1. Le jeudi 07 juin 2007 ? 08:11 -0400, Uncle George a ?crit : > your suggestion appears good. I dont know what displayDialogBox exactly > will do, so all I can say it that it looks good. > > But I'd like to wait 10min before first dialog box And a 5 min wait for > every dialog box there after. And since these are custom > solution/choices, maybe a more exact explanation of what the issue is. > > if(errorCount++ < 300){ // wait 10min ( 10min * 60sec / 2 ) > Sleep( 20 ); /* make a small pause to execute all other requests > in all other threads */ > continue; > } > > if(displayDialogBox("Printer has Paused. Retry sending data?")){ > errorCount = 150; // Wait for 5 min thereafter > continue; > } > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > > yves pielusenet wrote: > > Maybe in my case I should re-compile rxtx and change the code. Instead > > of send an exception I should display a dialog box to ask if it's > > printer problem or if it should trie to send bytes. Something like : > > > > while( count > 0 ){ > > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > > /* > > this are 20 * 2 seconds, in this time a printer (or other parallel device) > > should solv all problems like buffer full, etc > > */ > > if(errorCount++ < 20){ > > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > > continue; > > } > > > > if(displayDialogBox("Try again to send datas ??")){ > > errorCount = 0; > > } > > else{ > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > } > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 07:41:43 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 09:41:43 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181222241.3501.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <4667F5FF.8070903@gatworks.com> <1181222241.3501.20.camel@localhost.localdomain> Message-ID: <46680B17.8050109@gatworks.com> yves pielusenet wrote: > thank you :) > 'displayDialogBox()' I think doesn't exist. It was just for the > example :) too bad. Good luck. From rtrout at webbresearch.com Thu Jun 7 11:23:04 2007 From: rtrout at webbresearch.com (Robert Trout) Date: Thu, 07 Jun 2007 13:23:04 -0400 Subject: [Rxtx] Disconnected PortServer TS causes Java to hang Message-ID: <1181236984.14186.33.camel@sisyphus.DinkumSoftware.com> I'm running Linux with sun's Java 1.4.2, Java comm API 2.0, RXTX 2.0-7pre1, and the RealPort digi driver. "/dev/ttyrp00" is a RealPort device. My Java application never returns from a ComPortIdentifier.getPortIdentifier("/dev/ttyrp00") call while the Digi PortServer TS 4 is disconnected from the network. If I later re-connect the PortServer, the call returns about 30 seconds later (it's like a serial port read or write is blocking until the PortServer is re- connected). With the PortServer disconnected, minicom immediately responds with "cannot open /dev/ttyrp00: No such file or directory". I would like my Java application to behave similarly. That is, respond with an error condition instead of hanging when the PortServer is not connected. Since minicom and Java behave differently, I think this "hanging" behavior may be due to RXTX or Java? Has anyone had a similar issue? Solutions? Suggestions? Thanks, Robert From vicnevicne at gmail.com Thu Jun 7 12:16:02 2007 From: vicnevicne at gmail.com (Vicne) Date: Thu, 07 Jun 2007 20:16:02 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181204864.3501.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> Message-ID: <46684B62.7080802@gmail.com> yves pielusenet wrote: > Maybe in my case I should re-compile rxtx and change the code. Instead > of send an exception I should display a dialog box to ask if it's > printer problem or if it should trie to send bytes. Something like : > > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > > if(displayDialogBox("Try again to send datas ??")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > } > Sorry to step in without a specific solution to your problem, but I wanted to share my feeling regarding this proposal. AFAIK, it's generally considered bad practice to pop-up a prompt from a library. The main reason is that in general use, you can't guarantee that someone is actually present behind the console. Imagine a print server in a machine room, connected to a park of printers. In that case, when one printer fails, the logical behaviour would be to use an other one. If you change RxTx the way you propose, the printer queue will simply be stuck with a useless "Try again to send data ?" prompt until an administrator opens a remote connection to the print server's console and clicks "no". Second, it would create a dependency upon the existence of a graphical console (if you go the graphical "dialogBox" way). On many applications (typically server or embedded ones), the JVM is "headless" and if you try to pop-up a dialog, your app would throw an exception (at best) or just wouldn't display the prompt anywhere... Going the "text console" way is not more reliable, because on graphical environments, the text console is hidden unless explicitly requested. My advice would be to think again and find another solution. Ideas are : - make the number of retries a parameter so that you can tune it to what you think is reasonable - throw a more specific exception when the number of retries has been reached, so that a specific prompt can be shown at a higher level Anyway, if you feel that the prompt is the way to go in your case, I would at least make that prompt conditional. The least intrusive way would probably be using a system property, like if("true".equals(System.getProperty("org.rxtx.usePrompt")) && displayDialogBox("Retry sending data ?")){ errorCount = 0; } else{ throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } By default, the behaviour would remain as it is now, but you could force the prompts by defining the property at VM launch if desired. (for example : java.exe -Dorg.rxtx.usePrompt=true myApp) Also, you seemed to say you wanted the printer to start again exactly where is stopped. It would indeed be the best way when the printer is put offline for a few seconds. On the other hand, if the printer is turned off (or the printer runs out of paper, or someone steps on the mains cable), then the only way to go back to a "stable" situation would be by printing the item (page, label, etc.) again from scratch... Just my two cents. Vicne PS : By the way, the dialog box thing is very platform dependant on the C-side, and I think the simplest way would probably be to bridge it to a Java call where you can implement it like you proposed : public boolean displayDialogBox(prompt) { return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); } From netbeans at gatworks.com Thu Jun 7 14:08:24 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 16:08:24 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46684B62.7080802@gmail.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> Message-ID: <466865B8.4060004@gatworks.com> My feeling is that the code that was suggested was for his environs ( his shop ). The issue here is that after a 40+ second wait, an exception will be thrown. But you really dont have a way of 'cancelling' all the WriteFiles() that have already occured before the exception so that your writeArray and the Commapi can backtrack to a position in which they are in sync. The main ( really mine ) concern is not to lose data, or replicate data. After 40seconds, 300 seconds, 55min, no matter how long, data should not be lost or duplicated. But as soon as the exception is thrown, that possibility exists. Maybe an event should be thrown instead? Vicne wrote: > yves pielusenet wrote: >> Maybe in my case I should re-compile rxtx and change the code. Instead >> of send an exception I should display a dialog box to ask if it's >> printer problem or if it should trie to send bytes. Something like : >> >> while( count > 0 ){ >> if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ >> /* >> this are 20 * 2 seconds, in this time a printer (or other parallel device) >> should solv all problems like buffer full, etc >> */ >> if(errorCount++ < 20){ >> Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ >> continue; >> } >> >> if(displayDialogBox("Try again to send datas ??")){ >> errorCount = 0; >> } >> else{ >> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >> break; >> } >> } >> > > Sorry to step in without a specific solution to your problem, but I > wanted to share my feeling regarding this proposal. AFAIK, it's > generally considered bad practice to pop-up a prompt from a library. > The main reason is that in general use, you can't guarantee that > someone is actually present behind the console. Imagine a print server > in a machine room, connected to a park of printers. In that case, when > one printer fails, the logical behaviour would be to use an other one. > If you change RxTx the way you propose, the printer queue will simply be > stuck with a useless "Try again to send data ?" prompt until an > administrator opens a remote connection to the print server's console > and clicks "no". > Second, it would create a dependency upon the existence of a > graphical console (if you go the graphical "dialogBox" way). On many > applications (typically server or embedded ones), the JVM is "headless" > and if you try to pop-up a dialog, your app would throw an exception (at > best) or just wouldn't display the prompt anywhere... Going the "text > console" way is not more reliable, because on graphical environments, > the text console is hidden unless explicitly requested. > > My advice would be to think again and find another solution. Ideas are : > - make the number of retries a parameter so that you can tune it to what > you think is reasonable > - throw a more specific exception when the number of retries has been > reached, so that a specific prompt can be shown at a higher level > > Anyway, if you feel that the prompt is the way to go in your case, I > would at least make that prompt conditional. The least intrusive way > would probably be using a system property, like > > if("true".equals(System.getProperty("org.rxtx.usePrompt")) > && displayDialogBox("Retry sending data ?")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > > > By default, the behaviour would remain as it is now, but you could > force the prompts by defining the property at VM launch if desired. (for > example : java.exe -Dorg.rxtx.usePrompt=true myApp) > > > Also, you seemed to say you wanted the printer to start again > exactly where is stopped. It would indeed be the best way when the > printer is put offline for a few seconds. On the other hand, if the > printer is turned off (or the printer runs out of paper, or someone > steps on the mains cable), then the only way to go back to a "stable" > situation would be by printing the item (page, label, etc.) again from > scratch... > > > Just my two cents. > > > Vicne > > PS : By the way, the dialog box thing is very platform dependant on the > C-side, and I think the simplest way would probably be to bridge it to a > Java call where you can implement it like you proposed : > > public boolean displayDialogBox(prompt) { > return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", > JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); > } > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Thu Jun 7 17:48:11 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 Jun 2007 17:48:11 -0600 (MDT) Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <466865B8.4060004@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> Message-ID: An event is possible. I'm amazed this is the largest problem encountered while using the parallel code. How would the write ever exit if we throw events? Isn't this going to lead to hung applications? On Thu, 7 Jun 2007, Uncle George wrote: > My feeling is that the code that was suggested was for his environs ( > his shop ). > > The issue here is that after a 40+ second wait, an exception will be > thrown. But you really dont have a way of 'cancelling' all the > WriteFiles() that have already occured before the exception so that your > writeArray and the Commapi can backtrack to a position in which they are > in sync. > > The main ( really mine ) concern is not to lose data, or replicate data. > After 40seconds, 300 seconds, 55min, no matter how long, data should > not be lost or duplicated. But as soon as the exception is thrown, that > possibility exists. > > Maybe an event should be thrown instead? > > Vicne wrote: >> yves pielusenet wrote: >>> Maybe in my case I should re-compile rxtx and change the code. Instead >>> of send an exception I should display a dialog box to ask if it's >>> printer problem or if it should trie to send bytes. Something like : >>> >>> while( count > 0 ){ >>> if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ >>> /* >>> this are 20 * 2 seconds, in this time a printer (or other parallel device) >>> should solv all problems like buffer full, etc >>> */ >>> if(errorCount++ < 20){ >>> Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ >>> continue; >>> } >>> >>> if(displayDialogBox("Try again to send datas ??")){ >>> errorCount = 0; >>> } >>> else{ >>> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >>> break; >>> } >>> } >>> >> >> Sorry to step in without a specific solution to your problem, but I >> wanted to share my feeling regarding this proposal. AFAIK, it's >> generally considered bad practice to pop-up a prompt from a library. >> The main reason is that in general use, you can't guarantee that >> someone is actually present behind the console. Imagine a print server >> in a machine room, connected to a park of printers. In that case, when >> one printer fails, the logical behaviour would be to use an other one. >> If you change RxTx the way you propose, the printer queue will simply be >> stuck with a useless "Try again to send data ?" prompt until an >> administrator opens a remote connection to the print server's console >> and clicks "no". >> Second, it would create a dependency upon the existence of a >> graphical console (if you go the graphical "dialogBox" way). On many >> applications (typically server or embedded ones), the JVM is "headless" >> and if you try to pop-up a dialog, your app would throw an exception (at >> best) or just wouldn't display the prompt anywhere... Going the "text >> console" way is not more reliable, because on graphical environments, >> the text console is hidden unless explicitly requested. >> >> My advice would be to think again and find another solution. Ideas are : >> - make the number of retries a parameter so that you can tune it to what >> you think is reasonable >> - throw a more specific exception when the number of retries has been >> reached, so that a specific prompt can be shown at a higher level >> >> Anyway, if you feel that the prompt is the way to go in your case, I >> would at least make that prompt conditional. The least intrusive way >> would probably be using a system property, like >> >> if("true".equals(System.getProperty("org.rxtx.usePrompt")) >> && displayDialogBox("Retry sending data ?")){ >> errorCount = 0; >> } >> else{ >> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >> break; >> } >> >> >> By default, the behaviour would remain as it is now, but you could >> force the prompts by defining the property at VM launch if desired. (for >> example : java.exe -Dorg.rxtx.usePrompt=true myApp) >> >> >> Also, you seemed to say you wanted the printer to start again >> exactly where is stopped. It would indeed be the best way when the >> printer is put offline for a few seconds. On the other hand, if the >> printer is turned off (or the printer runs out of paper, or someone >> steps on the mains cable), then the only way to go back to a "stable" >> situation would be by printing the item (page, label, etc.) again from >> scratch... >> >> >> Just my two cents. >> >> >> Vicne >> >> PS : By the way, the dialog box thing is very platform dependant on the >> C-side, and I think the simplest way would probably be to bridge it to a >> Java call where you can implement it like you proposed : >> >> public boolean displayDialogBox(prompt) { >> return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", >> JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); >> } >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 19:18:51 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 21:18:51 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> Message-ID: <4668AE7B.3060409@gatworks.com> The UNIX version of writeArray is not too great either. It is possible that the write will only process some of the bytes. #else if( write( fd, bytes, count ) < 0 ) throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); #endif -------------------------------- Maybe it might be better to have the native function inform the caller of the # of characters written, then the commapi/output-buffer can be modified to reflect the #of chars written. If an exception is to be thrown, for too many loops of chars written == 0, then exception wont affect the state of the output buffer. Then a ParallelPort.restart() can be called to resume printing whats in the buffer. Trent Jarvi wrote: > An event is possible. I'm amazed this is the largest problem encountered > while using the parallel code. > > How would the write ever exit if we throw events? Isn't this going to > lead to hung applications? Sure. If you dont time out, then there is nothing that will force an EXIT from the write(). Issue is what has the OS done with the write. > > On Thu, 7 Jun 2007, Uncle George wrote: > >> My feeling is that the code that was suggested was for his environs ( >> his shop ). From yvespielusenet at free.fr Fri Jun 8 01:09:01 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Fri, 08 Jun 2007 09:09:01 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4668AE7B.3060409@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> Message-ID: <1181286541.3674.10.camel@localhost.localdomain> It is not possible that the rxtx java method write(byte[], int offset, int length) return anint which contains the number of byte really send to the printer instead of an exception ? So this is the programm which will see if all bytes have been sent. If not it can retry to send the unsended bytes. -------------------------------------------------------- int sended = 0; while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ sended += countWritten; /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } return sended; /*throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break;*/ } ... ... return countWritten; ------------------------------------------------ Le jeudi 07 juin 2007 ? 21:18 -0400, Uncle George a ?crit : > The UNIX version of writeArray is not too great either. It is possible > that the write will only process some of the bytes. > > #else > if( write( fd, bytes, count ) < 0 ) > throw_java_exception_system_msg( env, IO_EXCEPTION, > "writeArray" ); > #endif > -------------------------------- > > Maybe it might be better to have the native function inform the caller > of the # of characters written, then the commapi/output-buffer can be > modified to reflect the #of chars written. If an exception is to be > thrown, for too many loops of chars written == 0, then exception wont > affect the state of the output buffer. Then a ParallelPort.restart() can > be called to resume printing whats in the buffer. > > > Trent Jarvi wrote: > > An event is possible. I'm amazed this is the largest problem encountered > > while using the parallel code. > > > > How would the write ever exit if we throw events? Isn't this going to > > lead to hung applications? > Sure. If you dont time out, then there is nothing that will force an > EXIT from the write(). Issue is what has the OS done with the write. > > > > On Thu, 7 Jun 2007, Uncle George wrote: > > > >> My feeling is that the code that was suggested was for his environs ( > >> his shop ). > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Fri Jun 8 03:45:00 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 11:45:00 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181286541.3674.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> Message-ID: <20070608094500.GC21069@elberon.bln.de.ingenico.com> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > It is not possible that the rxtx java method write(byte[], int offset, > int length) return anint which contains the number of byte really send > to the printer instead of an exception ? > So this is the programm which will see if all bytes have been sent. If > not it can retry to send the unsended bytes. I think write() is void because in Java people love to do this since OutputStream :-) Of course on such interfaces you cannot implement something nice. If you would have a int write, you would not implement the interface and no applications expecting this interface would link/work/compile. oki, Steffen P.S.: (OT) If you propose not to implement the Java interfaces (especially not on JNI level), maybe optionally offering a wrapper that removes e.g. the write return value and so on to downgrade the powerful classic old POSIX read/write style to the modern limited Java style, then I agree :-) Same for read. Instead of things like "int avialable()" it is more powerful to have an approach as select(2) offers (to guarante the caller that read/write will not block [nothing else make sense anyway IMHO] but may read/write less bytes then requested). The caller gets full control and the higher level protocols can care about timeouts, invoking read in some loops and/or implement retransmission. On top of such an implementation, where everything is controlled, defined, guaranteed and reliable, someone could use an InputStream or OutputStream style interface. Or even better: don't use them at all :) just BTW :-) St. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From yvespielusenet at free.fr Fri Jun 8 05:52:45 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Fri, 08 Jun 2007 13:52:45 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <20070608094500.GC21069@elberon.bln.de.ingenico.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> Message-ID: <1181303565.11203.3.camel@localhost.localdomain> So maybe a better way should be to create a new Exception class which has a method "int getWrittenByte()". So the Exception should be use to send again bytes which are not printed yet. yves Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : > * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > > It is not possible that the rxtx java method write(byte[], int offset, > > int length) return anint which contains the number of byte really send > > to the printer instead of an exception ? > > So this is the programm which will see if all bytes have been sent. If > > not it can retry to send the unsended bytes. > > I think write() is void because in Java people love to do this > since OutputStream :-) Of course on such interfaces you cannot > implement something nice. If you would have a int write, you > would not implement the interface and no applications expecting > this interface would link/work/compile. > > oki, > > Steffen > > P.S.: (OT) > If you propose not to implement the Java interfaces (especially > not on JNI level), maybe optionally offering a wrapper that > removes e.g. the write return value and so on to downgrade the > powerful classic old POSIX read/write style to the modern limited > Java style, then I agree :-) Same for read. Instead of things > like "int avialable()" it is more powerful to have an approach as > select(2) offers (to guarante the caller that read/write will not > block [nothing else make sense anyway IMHO] but may read/write > less bytes then requested). The caller gets full control and the > higher level protocols can care about timeouts, invoking read in > some loops and/or implement retransmission. On top of such an > implementation, where everything is controlled, defined, > guaranteed and reliable, someone could use an InputStream or > OutputStream style interface. Or even better: don't use them at > all :) just BTW :-) > St. > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > 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. > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > 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. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Fri Jun 8 06:46:21 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 08:46:21 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181303565.11203.3.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> Message-ID: <46694F9D.5080501@gatworks.com> It seems that with outputstream.write(b[]), you become terribly uncoordinated as soon as an exception is thrown. Docs do not say what happens to the data. Yet from a practicable point of view, one would like to know if the write was accepted in-full, or rejected before any writes. There are no in betweens, as partial writes are not reportable. So for an outputstream.write(), in order for it to return, the full write request has to be taken, and stored in an internal output buffer. If there is no room, the write() is suspended, till there is room. Or throw's an IOException( "no room in buffer") ; As the select() loop for write reports buffer room avail, then more of the internal buffer is sent to the printer. yves pielusenet wrote: > So maybe a better way should be to create a new Exception class which > has a method "int getWrittenByte()". So the Exception should be use to > send again bytes which are not printed yet. > > yves > > Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : >> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: >>> It is not possible that the rxtx java method write(byte[], int offset, >>> int length) return anint which contains the number of byte really send >>> to the printer instead of an exception ? >>> So this is the programm which will see if all bytes have been sent. If >>> not it can retry to send the unsended bytes. >> I think write() is void because in Java people love to do this >> since OutputStream :-) Of course on such interfaces you cannot >> implement something nice. If you would have a int write, you >> would not implement the interface and no applications expecting >> this interface would link/work/compile. >> >> oki, >> >> Steffen >> >> P.S.: (OT) >> If you propose not to implement the Java interfaces (especially >> not on JNI level), maybe optionally offering a wrapper that >> removes e.g. the write return value and so on to downgrade the >> powerful classic old POSIX read/write style to the modern limited >> Java style, then I agree :-) Same for read. Instead of things >> like "int avialable()" it is more powerful to have an approach as >> select(2) offers (to guarante the caller that read/write will not >> block [nothing else make sense anyway IMHO] but may read/write >> less bytes then requested). The caller gets full control and the >> higher level protocols can care about timeouts, invoking read in >> some loops and/or implement retransmission. On top of such an >> implementation, where everything is controlled, defined, >> guaranteed and reliable, someone could use an InputStream or >> OutputStream style interface. Or even better: don't use them at >> all :) just BTW :-) >> St. >> >> About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. >> 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. >> >> About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. >> 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. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From Steffen.DETTMER at ingenico.com Fri Jun 8 08:12:18 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 16:12:18 +0200 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <46694F9D.5080501@gatworks.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: <20070608141218.GE21069@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 08:46 -0400: > It seems that with outputstream.write(b[]), you become terribly > uncoordinated as soon as an exception is thrown. Docs do not say what > happens to the data. (yes, so avoiding it seems to be good :)) > Yet from a practicable point of view, one would like to know if the > write was accepted in-full, or rejected before any writes. There are no > in betweens, as partial writes are not reportable. (which is an artificial API limitation. I never understood how this happend when they invented JDK because the well-known BSD socket API and thus [probably] WinSock does this correct, but anyway) > So for an outputstream.write(), in order for it to return, the full > write request has to be taken, and stored in an internal output buffer. > If there is no room, the write() is suspended, till there is room. Or > throw's an IOException( "no room in buffer") ; As the select() loop for > write reports buffer room avail, then more of the internal buffer is > sent to the printer. yes, might be good in case of a printer. May be horrible in case of PPP/TCP or some other transmission control protocol which may e.g. repeat data or even omit parts of it (e.g. internet realtime radio station broadcasting)... So I think the idea of "int write" (e.g. BSD sockets, linux files and so on) still is the best. A clean API / implementation should guarantee and allow implementations (users) to rely on that; assumptions and automatic background-sending and so on may look pragmatic and may even work on the first look, but may fail in other situations. BTW, if e.g. BSD socket API is known, why not simply copy it (until something better is invented :)) instead of fiddling around with JDK APIs? anyway, have a nice weekend everyone :-) oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Fri Jun 8 08:55:56 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 10:55:56 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070608141218.GE21069@elberon.bln.de.ingenico.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> Message-ID: <46696DFC.7000801@gatworks.com> >> write reports buffer room avail, then more of the internal buffer is >> sent to the printer. > > yes, might be good in case of a printer. May be horrible in case > of PPP/TCP or some other transmission control protocol which > may e.g. repeat data or even omit parts of it (e.g. internet > realtime radio station broadcasting)... So I think the idea of > "int write" (e.g. BSD sockets, linux files and so on) still is > the best. A clean API / implementation should guarantee and allow > implementations (users) to rely on that; assumptions and > automatic background-sending and so on may look pragmatic and may > even work on the first look, but may fail in other situations. > BTW, if e.g. BSD socket API is known, why not simply copy it > (until something better is invented :)) instead of fiddling > around with JDK APIs? But we were talking about the Parallel Port, and the transmission of data over the commapi/parallel-port schema. There isn't much in bi-directional software communication. Its a simple write one byte at a time interface. I'm not looking to change the comm-api. I'm just looking to alter the interaction between the Native ParallelPort functions, and the java ParallelPort functions that call them. This might be more readily doable than to get a committee to re-specify java-API specs. BTW: Whats is off-topic? ( help: not looking for def of off-topic ) From j.kenneth.gentle at acm.org Fri Jun 8 08:58:59 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Fri, 08 Jun 2007 10:58:59 -0400 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <20070608141218.GE21069@elberon.bln.de.ingenico.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> Message-ID: <200706081459.l58Ex5rA019991@qbang.org> Perhaps it is a bit late to jump in on this one, but here goes anyway. If the solutions all seem to "break" the contract with "java.io.outputstream", then, as noted, that may not be the appropriate contract. At the risk of being heretical, JDK1.4 introduced the "nio" package to address some of the compatibility issues with C apis mentioned in previous posts. The interface "java.nio.channels.WriteableByteChannel" defines the following single method: int write(ByteBuffer source); int, strangely enough, is the actual number of bytes written. So, if RXTX as written, against the JavaCOMM api and OutputStream, doesn't do what we want, how about writing a different set of bindings using the java.nio classes and as much of the underlying native code as possible. Note that just because the java.nio.channels.WriteableByteChannel sends back a result, OutputStream.write doesn't have to - and they could both call the same underlying native code. My 2 cents - maybe not worth even that... Ken From netbeans at gatworks.com Fri Jun 8 10:37:28 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 12:37:28 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <200706081459.l58Ex5rA019991@qbang.org> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> Message-ID: <466985C8.8000505@gatworks.com> Ken Gentle wrote: > Perhaps it is a bit late to jump in on this one, but here goes anyway. Common in, the waters fine. > > If the solutions all seem to "break" the contract with > "java.io.outputstream", then, as noted, that may not be the > appropriate contract. > How would the contract be broken? The machinery underneath is handling the contract. From j.kenneth.gentle at acm.org Fri Jun 8 10:48:01 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Fri, 08 Jun 2007 12:48:01 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466985C8.8000505@gatworks.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> Message-ID: <200706081648.l58Gm7YA022904@qbang.org> At 12:37 2007-06-08, you wrote: >Ken Gentle wrote: > > > > If the solutions all seem to "break" the contract with > > "java.io.outputstream", then, as noted, that may not be the > > appropriate contract. > > >How would the contract be broken? The machinery underneath is handling >the contract. It seems that a lot of the discussion has been about not only the timeout and being able to adjust it in the "machinery layer", but also about knowing in the Java layer, in the event of a timeout or exception, how many characters have been written to the device. An OutputStream won't ever do this with out an extension and including a return value "breaks" the contract, right? So, go with a Java IO api that *does* return the number of bytes written, out of the NIO package. I know it doesn't allow for a strict implementation of the JavaCOMM API - however, using NIO classes in place of the IO classes isn't that big a break and would allow those applications that need such information a way to get it. Maybe I'm misunderstanding the problem... Ken From netbeans at gatworks.com Fri Jun 8 11:24:14 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 13:24:14 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <200706081648.l58Gm7YA022904@qbang.org> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> Message-ID: <466990BE.7040100@gatworks.com> Ken Gentle wrote: An > OutputStream won't ever do this with out an extension and including a > return value "breaks" the contract, right? > i was not thinking of change the API to OutputSream. Are there specs for how output stream should work internally? for instance: String data = "Hello this is a line of data"; Outputstream.write( data.getbytes() ); ParallelPort.suspend(); int free = ParallelPort.getoutputbufferfree(); There is a symbiotic relationship between outputstream and the functionality of ParallelPort. From Steffen.DETTMER at ingenico.com Fri Jun 8 11:15:39 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 19:15:39 +0200 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <200706081459.l58Ex5rA019991@qbang.org> References: <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> Message-ID: <20070608171539.GK21069@elberon.bln.de.ingenico.com> * Ken Gentle wrote on Fri, Jun 08, 2007 at 10:58 -0400: > If the solutions all seem to "break" the contract with > "java.io.outputstream", then, as noted, that may not be the > appropriate contract. > > At the risk of being heretical, JDK1.4 introduced the "nio" package > to address some of the compatibility issues with C apis mentioned in > previous posts. The interface > "java.nio.channels.WriteableByteChannel" defines the following single method: > > int write(ByteBuffer source); > > int, strangely enough, is the actual number of bytes written. Yes, AFAIK one of the motivations for the NIO interface was, that the JDK-1.3 APIs (InputStream, e.g.) were not powerfull enough, especially for multi-connection-TCP servers or so. I don't know much about it but I've heard of a project where NIO usage was removed because of stability issues in multi-threaded environments and performance limitations under some circumstances. IIRC the "nio.ByteBuffer" is something very special (namely something you cannot implement in Java, it is "magic" or part of the language itself). Not sure if this is such a great idea (but for performance in the end sometimes heavy prices must be paid) :) > So, if RXTX as written, against the JavaCOMM api and OutputStream, > doesn't do what we want, how about writing a different set of > bindings using the java.nio classes and as much of the underlying > native code as possible. Yes, this would be an idea: use a full-featured interface on JNI, and, if wanted, deliver some wrappers converting this to a less-featured Java-compliant interface. However, powerful things as e.g. "select" are difficult to "emulate" if you are e.g. on some (older?) windows. But if you expose the full-featured APIs, you need to emulate them full-featured, theoretically. In the end it depends what you do on the serial line. If you just want to talk to a modem, then you may not need precise timeouts. But if you need to implement complexer protocols which define response times and timeouts, you may quickly get into difficulties. For instance, AFAIK, rxtx 1.7.2 (?) for windows is very messy with timeouts (there is a maximum, higher values are truncated; resolution is 100ms only; the function may take up to twice the timeout because internally it may be called twice). Probably for most people this is OK, but probably not for all. But having precise timeouts should be OK for all :-) Well, in the end it is nice to wish but somewhat hard to implement (many platforms, connections, USB, BlueTooth, whatever). oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Steffen.DETTMER at ingenico.com Fri Jun 8 11:04:22 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 19:04:22 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <46696DFC.7000801@gatworks.com> References: <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <46696DFC.7000801@gatworks.com> Message-ID: <20070608170422.GJ21069@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 10:55 -0400: > > BTW, if e.g. BSD socket API is known, why not simply copy it > > (until something better is invented :)) instead of fiddling > > around with JDK APIs? > > But we were talking about the Parallel Port, and the > transmission of data over the commapi/parallel-port schema. > There isn't much in bi-directional software communication. Its > a simple write one byte at a time interface. First, there are things like PLIP (http://en.wikipedia.org/wiki/Plip) - well, probably not widely used, sure ;) Second, I think if there is a good simple API known to support all that (with known "best practices") or so and there is no forcing need to invent a new one, why not simply using it? > I'm not looking to change the comm-api. I'm just looking to > alter the interaction between the Native ParallelPort > functions, and the java ParallelPort functions that call them. Ahh, yes. I think this is what I tried to ask. Having an usable JNI interface and on top (in pure java) some wrapper to InputStream or whatever could be done (e.g. by ignoring the return value of write or throwing if != length). Developers could then use the full-featured (non-JAVA-standard) API or select among various wrappers (as InputStream). > This might be more readily doable than to get a committee to > re-specify java-API specs. Yes, of course. I'm afraid that the Java APIs change regularily, but still yet with limited success it seems, so maybe they get it in one of the next iterations; who knows, maybe Java-9 has a BSD-like socket API :) SCNR. > BTW: Whats is off-topic? ( help: not looking for def of > off-topic ) I think I started some "re-specify java-API specs" which was OT probably. oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From lists at iDIAcomputing.com Fri Jun 8 18:48:54 2007 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Fri, 08 Jun 2007 20:48:54 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46684B62.7080802@gmail.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> Message-ID: <4669F8F6.3040101@iDIAcomputing.com> Vicne wrote: > Sorry to step in without a specific solution to your problem, but I > wanted to share my feeling regarding this proposal. AFAIK, it's > generally considered bad practice to pop-up a prompt from a library. ... > > My advice would be to think again and find another solution. Ideas are : > - make the number of retries a parameter so that you can tune it to what > you think is reasonable > - throw a more specific exception when the number of retries has been > reached, so that a specific prompt can be shown at a higher level You could also allow the client code to register a callback class which returns a boolean indicating whether to retry or cancel. This callback class could pop up a dialog, if appropriate, or follow some preset policy, or.... - George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From joachim at buechse.ch Sat Jun 9 09:43:16 2007 From: joachim at buechse.ch (Joachim Buechse) Date: Sat, 9 Jun 2007 17:43:16 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46694F9D.5080501@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: You should not forget, that in the case of an exception it may not even be known what happened to the data. You have a kernel buffer, outgoing chip buffer, incoming chip buffer, etc. So of course, it would be nice to know up to which point data was correctly processed, but this feedback does not exist on the hardware or protocol level and hence can in general not be magicly created on the software level... Regards, Joachim On 08.06.2007, at 14:46, Uncle George wrote: > It seems that with outputstream.write(b[]), you become terribly > uncoordinated as soon as an exception is thrown. Docs do not say what > happens to the data. > > Yet from a practicable point of view, one would like to know if the > write was accepted in-full, or rejected before any writes. There > are no > in betweens, as partial writes are not reportable. > > So for an outputstream.write(), in order for it to return, the full > write request has to be taken, and stored in an internal output > buffer. > If there is no room, the write() is suspended, till there is room. Or > throw's an IOException( "no room in buffer") ; As the select() loop > for > write reports buffer room avail, then more of the internal buffer is > sent to the printer. > > > > yves pielusenet wrote: >> So maybe a better way should be to create a new Exception class which >> has a method "int getWrittenByte()". So the Exception should be >> use to >> send again bytes which are not printed yet. >> >> yves >> >> Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : >>> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: >>>> It is not possible that the rxtx java method write(byte[], int >>>> offset, >>>> int length) return anint which contains the number of byte >>>> really send >>>> to the printer instead of an exception ? >>>> So this is the programm which will see if all bytes have been >>>> sent. If >>>> not it can retry to send the unsended bytes. >>> I think write() is void because in Java people love to do this >>> since OutputStream :-) Of course on such interfaces you cannot >>> implement something nice. If you would have a int write, you >>> would not implement the interface and no applications expecting >>> this interface would link/work/compile. >>> >>> oki, >>> >>> Steffen >>> >>> P.S.: (OT) >>> If you propose not to implement the Java interfaces (especially >>> not on JNI level), maybe optionally offering a wrapper that >>> removes e.g. the write return value and so on to downgrade the >>> powerful classic old POSIX read/write style to the modern limited >>> Java style, then I agree :-) Same for read. Instead of things >>> like "int avialable()" it is more powerful to have an approach as >>> select(2) offers (to guarante the caller that read/write will not >>> block [nothing else make sense anyway IMHO] but may read/write >>> less bytes then requested). The caller gets full control and the >>> higher level protocols can care about timeouts, invoking read in >>> some loops and/or implement retransmission. On top of such an >>> implementation, where everything is controlled, defined, >>> guaranteed and reliable, someone could use an InputStream or >>> OutputStream style interface. Or even better: don't use them at >>> all :) just BTW :-) >>> St. >>> >>> About Ingenico Throughout the world businesses rely on Ingenico >>> for secure and expedient electronic transaction acceptance. >>> Ingenico products leverage proven technology, established >>> standards and unparalleled ergonomics to provide optimal >>> reliability, versatility and usability. This comprehensive range >>> of products is complemented by a global array of services and >>> partnerships, enabling businesses in a number of vertical sectors >>> to accept transactions anywhere their business takes them. >>> 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. >>> >>> About Ingenico Throughout the world businesses rely on Ingenico >>> for secure and expedient electronic transaction acceptance. >>> Ingenico products leverage proven technology, established >>> standards and unparalleled ergonomics to provide optimal >>> reliability, versatility and usability. This comprehensive range >>> of products is complemented by a global array of services and >>> partnerships, enabling businesses in a number of vertical sectors >>> to accept transactions anywhere their business takes them. >>> 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. >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx 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 yvespielusenet at free.fr Mon Jun 11 03:15:12 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Mon, 11 Jun 2007 11:15:12 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: <1181553312.8335.14.camel@localhost.localdomain> So can someone tell a solution for my problem :( Must I say to the user to not put the printer off-line ? I can't since he has to do some pauses, verify print, paper conditioning etc... How do other people ? Before I use the parport librarry to read port status : http://www.geocities.com/Juanga69/parport/ (which doesn't work on windows XP) And I send data into the file LPT1 I use to have no problem when printer was disabled. thanks -- yves piel Le samedi 09 juin 2007 ? 17:43 +0200, Joachim Buechse a ?crit : > You should not forget, that in the case of an exception it may not > even be known what happened to the data. > > You have a kernel buffer, outgoing chip buffer, incoming chip buffer, > etc. So of course, it would be nice to know up to which point data > was correctly processed, but this feedback does not exist on the > hardware or protocol level and hence can in general not be magicly > created on the software level... > > Regards, > Joachim > > On 08.06.2007, at 14:46, Uncle George wrote: > > > It seems that with outputstream.write(b[]), you become terribly > > uncoordinated as soon as an exception is thrown. Docs do not say what > > happens to the data. > > > > Yet from a practicable point of view, one would like to know if the > > write was accepted in-full, or rejected before any writes. There > > are no > > in betweens, as partial writes are not reportable. > > > > So for an outputstream.write(), in order for it to return, the full > > write request has to be taken, and stored in an internal output > > buffer. > > If there is no room, the write() is suspended, till there is room. Or > > throw's an IOException( "no room in buffer") ; As the select() loop > > for > > write reports buffer room avail, then more of the internal buffer is > > sent to the printer. > > > > > > > > yves pielusenet wrote: > >> So maybe a better way should be to create a new Exception class which > >> has a method "int getWrittenByte()". So the Exception should be > >> use to > >> send again bytes which are not printed yet. > >> > >> yves > >> > >> Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : > >>> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > >>>> It is not possible that the rxtx java method write(byte[], int > >>>> offset, > >>>> int length) return anint which contains the number of byte > >>>> really send > >>>> to the printer instead of an exception ? > >>>> So this is the programm which will see if all bytes have been > >>>> sent. If > >>>> not it can retry to send the unsended bytes. > >>> I think write() is void because in Java people love to do this > >>> since OutputStream :-) Of course on such interfaces you cannot > >>> implement something nice. If you would have a int write, you > >>> would not implement the interface and no applications expecting > >>> this interface would link/work/compile. > >>> > >>> oki, > >>> > >>> Steffen > >>> > >>> P.S.: (OT) > >>> If you propose not to implement the Java interfaces (especially > >>> not on JNI level), maybe optionally offering a wrapper that > >>> removes e.g. the write return value and so on to downgrade the > >>> powerful classic old POSIX read/write style to the modern limited > >>> Java style, then I agree :-) Same for read. Instead of things > >>> like "int avialable()" it is more powerful to have an approach as > >>> select(2) offers (to guarante the caller that read/write will not > >>> block [nothing else make sense anyway IMHO] but may read/write > >>> less bytes then requested). The caller gets full control and the > >>> higher level protocols can care about timeouts, invoking read in > >>> some loops and/or implement retransmission. On top of such an > >>> implementation, where everything is controlled, defined, > >>> guaranteed and reliable, someone could use an InputStream or > >>> OutputStream style interface. Or even better: don't use them at > >>> all :) just BTW :-) > >>> St. > >>> > >>> About Ingenico Throughout the world businesses rely on Ingenico > >>> for secure and expedient electronic transaction acceptance. > >>> Ingenico products leverage proven technology, established > >>> standards and unparalleled ergonomics to provide optimal > >>> reliability, versatility and usability. This comprehensive range > >>> of products is complemented by a global array of services and > >>> partnerships, enabling businesses in a number of vertical sectors > >>> to accept transactions anywhere their business takes them. > >>> 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. > >>> > >>> About Ingenico Throughout the world businesses rely on Ingenico > >>> for secure and expedient electronic transaction acceptance. > >>> Ingenico products leverage proven technology, established > >>> standards and unparalleled ergonomics to provide optimal > >>> reliability, versatility and usability. This comprehensive range > >>> of products is complemented by a global array of services and > >>> partnerships, enabling businesses in a number of vertical sectors > >>> to accept transactions anywhere their business takes them. > >>> 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. > >>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx 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 > From Steffen.DETTMER at ingenico.com Mon Jun 11 03:56:18 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 11:56:18 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466990BE.7040100@gatworks.com> References: <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> Message-ID: <20070611095618.GA10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 13:24 -0400: > i was not thinking of change the API to OutputSream. Then I think either someone uses OutputStream (and has no reliable information about incomplete writes) or someone uses somethink else. > Are there specs for how output stream should work internally? > > for instance: > String data = "Hello this is a line of data"; > Outputstream.write( data.getbytes() ); > ParallelPort.suspend(); > int free = ParallelPort.getoutputbufferfree(); > > There is a symbiotic relationship between outputstream and the > functionality of ParallelPort. If you need OutputStream "plus something else", in short you're needing "something else". Personally I dislike the code above a lot. The stream "looks" like if it would be an OutputStream, but in fact it isn't. You need to call getoutputbufferfree later to check if write succeeded (but OutputStream promises that write succeedes synchronous, blocking, or throws an exception). So it is not an OutputStream. No application written for OutputStreams would work without change (because it won't know getoutputbufferfree at all). It is not abstracted from ParallelPort. I think this would be wrong. Then I think an alternative interface instead is better. Let's assume we had some "connection" (to distinguish between OutputStreams and Channels). Then why not working as on a file handle in POSIX: do { // ... select maybe using timer ... readyForWrite = ... if (readyForWrite) { int writtenBytes = connection.write(toWrite); toWrite.remove(0, writtenBytes); } while(readyForWrite && toWrite.length > 0); I think, having such a write isn't the big problem. I think, the difficult thing is around "select" - however this would look like. It should be OO, typesafe, performant, supporting multiple connections/channels/streams in various modes and should be orthogonal to other functionalities. Of course, this heavily depends on what the application is doing; for a simple situation (like reading a small, mandatory file from a local disk) this would be to uncomfortable (and offering unneeded features only). just BTW :) oki, Steffen -- // Modeline for VIM. Please don't remove. // (Help: autoindent, expandtab, shiftwidth=4, tabstop=4, textwidth=75) // vi: set ai et sw=4 ts=4 tw=75 ft=java: About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Mon Jun 11 05:38:33 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 07:38:33 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611095618.GA10821@elberon.bln.de.ingenico.com> References: <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> Message-ID: <466D3439.4020805@gatworks.com> Steffen DETTMER wrote: > (but OutputStream promises that write > succeedes synchronous, blocking, or throws an exception). Where is it so written? From Steffen.DETTMER at ingenico.com Mon Jun 11 06:36:50 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 14:36:50 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466D3439.4020805@gatworks.com> References: <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> <466D3439.4020805@gatworks.com> Message-ID: <20070611123650.GI10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Mon, Jun 11, 2007 at 07:38 -0400: > Steffen DETTMER wrote: > > > (but OutputStream promises that write > > succeedes synchronous, blocking, or throws an exception). > > Where is it so written? Now, as you ask, I think it is not written that clearly but follows from specification. mmm... Am I wrong? I understand the API doc in this way: * http://java.sun.com/j2se/1.4.2/docs/api/java/io/OutputStream.html#write(byte[]) > public void write(byte[] b) > throws IOException > > Writes b.length bytes from the specified byte array to this > output stream. The general contract for write(b) is that > it should have exactly the same effect as the call write(b, > 0, b.length). > > Parameters: > b - the data. > Throws: > IOException - if an I/O error occurs. > See Also: > write(byte[], int, int) and there is: > public void write(byte[] b, > int off, > int len) > throws IOException > > Writes len bytes from the specified byte array starting at > offset off to this output stream. The general contract for > write(b, off, len) is that some of the bytes in the array b > are written to the output stream in order; element b[off] > is the first byte written and b[off+len-1] is the last byte > written by this operation. > > The write method of OutputStream calls the write method of > one argument on each of the bytes to be written out. > Subclasses are encouraged to override this method and > provide a more efficient implementation. > > If b is null, a NullPointerException is thrown. > > If off is negative, or len is negative, or off+len is > greater than the length of the array b, then an > IndexOutOfBoundsException is thrown. > > Parameters: > b - the data. > off - the start offset in the data. > len - the number of bytes to write. > Throws: > IOException - if an I/O error occurs. In particular, an > IOException is thrown if the output stream is closed. In general, any specialisation (derived child class) must comform to this. So write in the end is specified (!) as "The write method ... calls the write method ... on each of the bytes to be written out". This is what must be implemented by ANY OutputStream. Of course, there is: "Subclasses are encouraged to override this method and provide a more efficient implementation." which IMHO does not contradict - the more efficient must behave in exactly the same way of course (just wasting less resources than a simple byte-by-byte write). So it does not matter here I think. The write that finally defines the behavior tells basically: > "Writes the specified byte to this output stream. The general > contract for write is that one byte is written to the output > stream. " > > Throws: > IOException - if an I/O error occurs. which IMHO is another way of saying "write writes the byte immediately and returns on success (only), otherwise an exception is thrown". Especially it cannot happen that zero bytes are written (i.e. the specified byte is NOT written) without an exception. So by this write must be synchronous and blocking, because otherwise it could not reliably know if an asynchronous operation will succeede or not (some getAsyncResult or so would be needed). Since write(byte[]) does this for each byte (or with a behavior beeing exactly the same as if it would do), I think this means that the write(byte[]) succeedes synchronous/blocking or throws an exception. Did I an error in reasoning or confused something or so? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From j.kenneth.gentle at acm.org Mon Jun 11 06:51:25 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 11 Jun 2007 08:51:25 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611123650.GI10821@elberon.bln.de.ingenico.com> References: <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> <466D3439.4020805@gatworks.com> <20070611123650.GI10821@elberon.bln.de.ingenico.com> Message-ID: <200706111251.l5BCpS9T017831@qbang.org> It is as Steffen describes. "InputStream" and "OutputStream" are inherently synchronous (which is why so many java programs resort to threads to use them). Anything outside of this "contract" is *not* an InputStream or OutputStream. That is why there is a new package for things that don't behave like the old *Stream classes - the NIO package. If you look carefully at the IO package, you'll note that almost all the classes are _Decorator_ pattern implementations of the *Stream classes - and the interface presents the _same_ behavior to the calling code in all cases - a synchronous operation that completes successfully or throws an exception (with the one exception of "read" that returns a "-1" on end-of-stream. I know I've read this numerous times - I'd suggest checking the Language Spec or one of the books by Bloch or Gosling. Ken At 08:36 2007-06-11, you wrote: >* Uncle George wrote on Mon, Jun 11, 2007 at 07:38 -0400: > > Steffen DETTMER wrote: > > > > > (but OutputStream promises that write > > > succeedes synchronous, blocking, or throws an exception). > > > > Where is it so written? > >Now, as you ask, I think it is not written that clearly but >follows from specification. mmm... > >Am I wrong? > >I understand the API doc in this way: > >* >http://java.sun.com/j2se/1.4.2/docs/api/java/io/OutputStream.html#write(byte[]) > > public void write(byte[] b) > > throws IOException > > > > Writes b.length bytes from the specified byte array to this > > output stream. The general contract for write(b) is that > > it should have exactly the same effect as the call write(b, > > 0, b.length). > > > > Parameters: > > b - the data. > > Throws: > > IOException - if an I/O error occurs. > > See Also: > > write(byte[], int, int) > > >and there is: > > > > public void write(byte[] b, > > int off, > > int len) > > throws IOException > > > > Writes len bytes from the specified byte array starting at > > offset off to this output stream. The general contract for > > write(b, off, len) is that some of the bytes in the array b > > are written to the output stream in order; element b[off] > > is the first byte written and b[off+len-1] is the last byte > > written by this operation. > > > > The write method of OutputStream calls the write method of > > one argument on each of the bytes to be written out. > > Subclasses are encouraged to override this method and > > provide a more efficient implementation. > > > > If b is null, a NullPointerException is thrown. > > > > If off is negative, or len is negative, or off+len is > > greater than the length of the array b, then an > > IndexOutOfBoundsException is thrown. > > > > Parameters: > > b - the data. > > off - the start offset in the data. > > len - the number of bytes to write. > > Throws: > > IOException - if an I/O error occurs. In particular, an > > IOException is thrown if the output stream is closed. > > >In general, any specialisation (derived child class) must comform >to this. So write in the end is specified (!) as "The write >method ... calls the write method ... on each of the bytes to be >written out". This is what must be implemented by ANY >OutputStream. > >Of course, there is: "Subclasses are encouraged to override this >method and provide a more efficient implementation." which IMHO >does not contradict - the more efficient must behave in exactly >the same way of course (just wasting less resources than a simple >byte-by-byte write). So it does not matter here I think. > > > >The write that finally defines the behavior tells basically: > > > "Writes the specified byte to this output stream. The general > > contract for write is that one byte is written to the output > > stream. " > > > > Throws: > > IOException - if an I/O error occurs. > > >which IMHO is another way of saying "write writes the byte >immediately and returns on success (only), otherwise an exception >is thrown". Especially it cannot happen that zero bytes are >written (i.e. the specified byte is NOT written) without an >exception. So by this write must be synchronous and blocking, >because otherwise it could not reliably know if an asynchronous >operation will succeede or not (some getAsyncResult or so would >be needed). > >Since write(byte[]) does this for each byte (or with a behavior >beeing exactly the same as if it would do), I think this means >that the write(byte[]) succeedes synchronous/blocking or throws >an exception. > >Did I an error in reasoning or confused something or so? > >oki, > >Steffen > >About Ingenico Throughout the world businesses rely on Ingenico for >secure and expedient electronic transaction acceptance. Ingenico >products leverage proven technology, established standards and >unparalleled ergonomics to provide optimal reliability, versatility >and usability. This comprehensive range of products is complemented >by a global array of services and partnerships, enabling businesses >in a number of vertical sectors to accept transactions anywhere >their business takes them. >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. > >About Ingenico Throughout the world businesses rely on Ingenico for >secure and expedient electronic transaction acceptance. Ingenico >products leverage proven technology, established standards and >unparalleled ergonomics to provide optimal reliability, versatility >and usability. This comprehensive range of products is complemented >by a global array of services and partnerships, enabling businesses >in a number of vertical sectors to accept transactions anywhere >their business takes them. >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. > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From alesinskyy at googlemail.com Mon Jun 11 07:25:33 2007 From: alesinskyy at googlemail.com (Oleksandr Alesinskyy) Date: Mon, 11 Jun 2007 15:25:33 +0200 Subject: [Rxtx] [OT] select :-) Message-ID: Sorry, but I have to disagree with following statement: "So write in the end is specified (!) as "The write method ... calls the write method ... on each of the bytes to be written out". This is what must be implemented by ANY OutputStream.". This is not part of the specification or contract, it is just revealed implementation detail of the OutputStream. It is not stated anywhere that behavoiur of derived classes shall conform with this one. Statement concerning "synchronous" nature of the output stream is invalid as well. Really synchronous stream does not require flush() but OutputStream has it. From Steffen.DETTMER at ingenico.com Mon Jun 11 08:21:16 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 16:21:16 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: Message-ID: <20070611142116.GN10821@elberon.bln.de.ingenico.com> * Oleksandr Alesinskyy wrote on Mon, Jun 11, 2007 at 15:25 +0200: > Sorry, but I have to disagree with following statement: > "So write in the end is specified (!) as "The write > method ... calls the write method ... on each of the bytes to be > written out". This is what must be implemented by ANY > OutputStream.". > > This is not part of the specification or contract, it is just > revealed implementation detail of the OutputStream. It is not > stated anywhere that behavoiur of derived classes shall conform > with this one. (I didn't meant that the implementation must really write byte by byte, but that it must "look as if it would do" - because all implementations of OutputStream must "look" in the same way [which is another way of saying "do abstract" I think]) I think the API doc is not "revealing implementation details" but it is the *specification* of that interface and derivations must (should) conform to this specification. Isn't this the idea of interfaces? A function that expects an OutputStream should work on ANY OutputStream, shouldn't it? just kidding: I mean, what would be the point in implementing a checksum function as OutputStream.write which throws its result as IOException? Or which requires to call close() as very first operation to tell that the application is about to transmit confidential data? :-) > Statement concerning "synchronous" nature of the output stream > is invalid as well. Really synchronous stream does not require > flush() but OutputStream has it. ahh, interesting point! I think this is another bug in the API. flush() is wrong. Because write specifies "The general contract for write is that one byte is written to the output stream." but not "a byte may be written or buffered". Actually, an application would need to call flush() after each write (or bunch of write calls) to ensure that write really did something otherwise I think. I didn't found in the spec of OutputStream that it would be required to call flush(). This should mean that calling flush is not required which in turn leads to the conclusion that write must be synchrous (private threads are forbidden because not specified :)) which in turn leads to the conclusion that flush() is not needed at all... I mean, what if someone would only store in write and do the "real write" in flush() and never else? An application could write in one stream and read on another one (e.g. in bidirectional communication) and would never get anything back, because nothing was actually written because no flush was called? Then someone could even think that on error in some write the data could remain buffered AND throw an exception, retrying to send the data in the next write. Ohh, and if there would be some message number inside, and underlaying write (e.g. a protocol offering InputStream/OutputStream) would check this and throw "DuplicatedMessageNumber" the stream would only throw it again and again beeing unusable... In short: I have no clue how someone could be able to implement an asynchrounos write (which is realiable and correct) without beeing specific to anything which is not specified by OutputStream. Well, I think in the end OutputStream was not intended for such communication or protocol implementations - but to read a local disk file or so. In case of I/O errors usually you can abort your application and change the hard disk :-) oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Bob_Jacobsen at lbl.gov Mon Jun 11 09:32:23 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Mon, 11 Jun 2007 08:32:23 -0700 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611142116.GN10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> Message-ID: At 4:21 PM +0200 6/11/07, Steffen DETTMER wrote: > > Statement concerning "synchronous" nature of the output stream >> is invalid as well. Really synchronous stream does not require >> flush() but OutputStream has it. > >ahh, interesting point! > >I think this is another bug in the API. flush() is wrong. Because >write specifies "The general contract for write is that one byte >is written to the output stream." but not "a byte may be written >or buffered". > >Actually, an application would need to call flush() after each >write (or bunch of write calls) to ensure that write really did >something otherwise I think. OutputStreams don't _have_ to be synchronous or asynchronous, but the OutputStream API was be arranged so that subclasses _can_ be synchronous or asynchronous. Such generality is the hardest part of getting an API right. Hence, if at some point a program using an OutputStream wants to be sure that the data has been pushed all the way out, flush() is available. For some subclasses, e.g. the buffered ones, this has important behavior. Others write the data from each call, and flush() doesn't do anything. You _can_ omit it in programs that are known to use this second type, but there's no requirement that you do so; the interface is general in that way. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From Steffen.DETTMER at ingenico.com Mon Jun 11 12:32:39 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 20:32:39 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> Message-ID: <20070611183239.GT10821@elberon.bln.de.ingenico.com> * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: > >Actually, an application would need to call flush() after each > >write (or bunch of write calls) to ensure that write really did > >something otherwise I think. > OutputStreams don't _have_ to be synchronous or asynchronous, > but the OutputStream API was be arranged so that subclasses > _can_ be synchronous or asynchronous. Ahh, oki. Thanks for the clarificaion. So in short, flush() MUST be called on OutputStream, this is just not documented correctly or so clearly (right?). So the overall usage semantics would be: 1. call write (multiple times if desired) 2. call flush only if both succeeded, write was successful. If flush fails it remains unknown if a part of the data was written and/or will be repeated. So the spec (API doc) is wrong. Correct would be to tell that write behaves as told as long as it is followed by a call to flush, otherwise data may or may not get lost (depending wheter close() is called and calls flush(), which seems not to be guaranteed/required). BTW, I think it is a little bit... erm... interesting to find the specification (java API doc reference) wrong, having a need to conclude it from the presence of some methods with "it would make no sense if they behave exactly as specified, so specification must be wrong (incomplete)". > Such generality is the hardest part of getting an API right. Yes, seems to be proven ;) > Hence, if at some point a program using an OutputStream wants > to be sure that the data has been pushed all the way out, > flush() is available. For some subclasses, e.g. the buffered > ones, this has important behavior. Others write the data from > each call, and flush() doesn't do anything. > You _can_ omit it in programs that are known to use this second > type, but there's no requirement that you do so; the interface > is general in that way. I think, it still it must be called always, otherwise the application could break if passing a different runtime type as OutputStream. I think, if the application/method needs a special "type of OutputStream" then the parameter type must be a subclass but not OutputStream, maybe a PrintStream or so - otherwise the compiler could not detect this error (passing wrong type). Is this correct? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Bob_Jacobsen at lbl.gov Mon Jun 11 13:00:52 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Mon, 11 Jun 2007 12:00:52 -0700 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611183239.GT10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> Message-ID: At 8:32 PM +0200 6/11/07, Steffen DETTMER wrote: >So the spec (API doc) is wrong. Correct would be to tell that >write behaves as told as long as it is followed by a call to >flush, otherwise data may or may not get lost (depending wheter >close() is called and calls flush(), which seems not to be >guaranteed/required). I'm not entirely sure that the spec is wrong, but reasonable people can differ on this. In the 1.5 JavaDocs, all that the docs say for the write methods is that they write to the _output_ _stream_; there is no guarantee of anything beyond that. Only the flush method has any guarantee about the data, which is >Flushes this output stream and forces any buffered output bytes to >be written out. The general contract of flush is that calling it is >an indication that, if any bytes previously written have been >buffered by the implementation of the output stream, such bytes >should immediately be written to their intended destination. People commonly use various OutputStreams without using flush(), and it often works, but it's a bad practice and will eventually bite them. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From netbeans at gatworks.com Mon Jun 11 13:31:57 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 15:31:57 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611183239.GT10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> Message-ID: <466DA32D.1010602@gatworks.com> Steffen DETTMER wrote: > * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: >>> Actually, an application would need to call flush() after each >>> write (or bunch of write calls) to ensure that write really did >>> something otherwise I think. > >> OutputStreams don't _have_ to be synchronous or asynchronous, >> but the OutputStream API was be arranged so that subclasses >> _can_ be synchronous or asynchronous. > > Ahh, oki. Thanks for the clarificaion. > > So in short, flush() MUST be called on OutputStream, this is just > not documented correctly or so clearly (right?). No. Flush can be called to force all current data in java buffer's to be written to the kernel - NOW. A flush() can also *imply* that, besides writing out the buffer's that java employs, may also imply/ask the kernel to write all data thusfar written to the kernel, to be physically placed on the destination device - NOW. For some OS's there is no need to do a kernel flush(), as the I/O is synchronized already. Since this is java, you never know what OS your on. From tjarvi at qbang.org Mon Jun 11 19:28:27 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Jun 2007 19:28:27 -0600 (MDT) Subject: [Rxtx] [OT] select :-) In-Reply-To: <466DA32D.1010602@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: On Mon, 11 Jun 2007, Uncle George wrote: > Steffen DETTMER wrote: >> * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: >>>> Actually, an application would need to call flush() after each >>>> write (or bunch of write calls) to ensure that write really did >>>> something otherwise I think. >> >>> OutputStreams don't _have_ to be synchronous or asynchronous, >>> but the OutputStream API was be arranged so that subclasses >>> _can_ be synchronous or asynchronous. >> >> Ahh, oki. Thanks for the clarificaion. >> >> So in short, flush() MUST be called on OutputStream, this is just >> not documented correctly or so clearly (right?). > No. > Flush can be called to force all current data in java buffer's to be > written to the kernel - NOW. > > A flush() can also *imply* that, besides writing out the buffer's that > java employs, may also imply/ask the kernel to write all data thusfar > written to the kernel, to be physically placed on the destination device > - NOW. > For some OS's there is no need to do a kernel flush(), as the I/O is > synchronized already. Since this is java, you never know what OS your on. To add to the confusion, flush on the C side throws away data. drain makes sure it is written. Looking at the ParallelImp.c we can probably do better. /* we set a timeout because all calls are sequentiell (also with asynchron) this means that the default timeout of unlimited blocks all calls (also close and status request) if the device is down */ GetCommTimeouts( (HANDLE)fd, &timeouts ); timeouts.WriteTotalTimeoutMultiplier = 0; timeouts.WriteTotalTimeoutConstant = 2000; /* 2000 is the min value for the default Windows NT and Windows 2000 driver */ SetCommTimeouts( (HANDLE)fd, &timeouts ); while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } errorCount = 0; bytes += countWritten; count -= countWritten; } LPRPort has some timeout code that appears to be doing nothing but flipping bits back and forth right now. The commapi rxtx follows allows for timeout control from javax.comm.CommPort. The above is a solution that worked in one specific use case. With timeouts in place, the original 'old printer going offline' problem could be solved. That printer code isn't written in stone. In fact it was ajusted from being able to print 'asdf' to a daisy wheel printer to working for one person. BTW, I've finished teaching after hours tonight and will be moving forward with a new rxtx release in my free time. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Jun 11 21:28:04 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 23:28:04 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: <466E12C4.1010305@gatworks.com> > Looking at the ParallelImp.c we can probably do better. > The problem stemmed from the possibility that the writev routine could have written some of the buffer, in chunks, printer pauses, refuses any more chunks, and a timeout occurs. Do you or do you not cause an exception to be thrown? Is there a way to set timeout for a ParallelPort data output stream? I cant find it. From tjarvi at qbang.org Mon Jun 11 22:17:23 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Jun 2007 22:17:23 -0600 (MDT) Subject: [Rxtx] [OT] select :-) In-Reply-To: <466E12C4.1010305@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> <466E12C4.1010305@gatworks.com> Message-ID: On Mon, 11 Jun 2007, Uncle George wrote: >> Looking at the ParallelImp.c we can probably do better. >> > The problem stemmed from the possibility that the writev routine could > have written some of the buffer, in chunks, printer pauses, refuses any > more chunks, and a timeout occurs. Do you or do you not cause an > exception to be thrown? > > Is there a way to set timeout for a ParallelPort data output stream? I > cant find it. hmm I looked again after you asked. The timeouts are only controllable on the receive side. This comes from CommPort; the parent. So what we are talking about is some bytes in memory that rxtx has and is supposed to write. A buffer perhaps? The approach with rxtx in the past has been to ignore output buffer sizes. The assumption is that the library does not know how to best handle buffers. There are buffered output streams that can do buffering on top of rxtx for instance. There is also a question regarding what was actually ment when the API was put together. My suspicion is that it was put together while looking at one OS API and was never ment to be anything more than a hook into that API. The comments are fairly telling combined with reading the w32 API. So looking at the problem again.. The current timeout behavior appears fairly arbitrary. Presumably this is to prevent a program from hanging instead of using a helper thread to write - heavy handed for new programmers. Even so, I don't think the write should timeout at all if it is not configurable. >From the API perspective, "What Timeout?" -- Trent Jarvi tjarvi at qbang.org From Steffen.DETTMER at ingenico.com Tue Jun 12 02:14:48 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 12 Jun 2007 10:14:48 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466DA32D.1010602@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: <20070612081447.GU10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Mon, Jun 11, 2007 at 15:31 -0400: > Steffen DETTMER wrote: > > Ahh, oki. Thanks for the clarificaion. > > > > So in short, flush() MUST be called on OutputStream, this is just > > not documented correctly or so clearly (right?). > No. hum (though now I got it, but...). > Flush can be called to force all current data in java buffer's to be > written to the kernel - NOW. > > A flush() can also *imply* that, besides writing out the > buffer's that java employs, may also imply/ask the kernel to > write all data thusfar written to the kernel, to be physically > placed on the destination device - NOW. > > For some OS's there is no need to do a kernel flush(), as the I/O is > synchronized already. Since this is java, you never know what OS your on. (well, but if you're going to kernel level, even flush cannot guarantee that data will "be physically placed". Maybe you're flushing to a file via NFS (and the client "thinks" that it was written, but maybe it was just buffered by the NFS server) or so... but of course such exceptions of the rules are constructable always.) Well, you tell that depending on the OS it can be that flush is needed or it can be that flush is not needed (beacuse the I/O is synchronized already), right? Also, applications should work on any OS, which includes the OSes that do need flush. Since the application cannot know whether flush is needed or not because it doesn't know what the OS is doing, it has to call flush, hasn't it? I mean, if it would not call flush then it would not work on such OSes (except the written data would not be needed at all, but in this would be an artificial example :)). Since applications are supposed to work this would be wrong, wouldn't it? So would it be correct to say: "Applications, that should work under all OSes (including the OSes where the I/O is not synchronised already), have to call flush on OutputStream to ensure the data is transfered to the kernel." or is this wrong? If so, then I'm afraid I missed the point again :( oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Tue Jun 12 04:46:52 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 12 Jun 2007 06:46:52 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070612081447.GU10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> <20070612081447.GU10821@elberon.bln.de.ingenico.com> Message-ID: <466E799C.7060700@gatworks.com> S > (well, but if you're going to kernel level, even flush cannot > guarantee that data will "be physically placed". Thats true now-a-days because ( from "man 2 sync" ) : > According to the standard specification (e.g., SVID), sync() schedules > the writes, but may return before the actual writing is done. However, > since version 1.3.20 Linux does actually wait. (This still does not > guarantee data integrity: modern disks have large caches.) My disk drive has 8mb cache. Maybe you're > flushing to a file via NFS (and the client "thinks" that it was > written, but maybe it was just buffered by the NFS server) or > so... but of course such exceptions of the rules are > constructable always.) > > Well, you tell that depending on the OS it can be that flush is > needed or it can be that flush is not needed (beacuse the I/O is > synchronized already), right? Also, applications should work on > any OS, which includes the OSes that do need flush. Its not OS's that need flush, its applications that want to have some assurance that data is written to the device that really needs to use flush. If your program ( or thread ) dies then it is in your best interest to write out the critical data as soon as possible, as economical as possible. These are trade-off's that the application programmer makes. A big buffer may mean big loss of data, a small buffer may mean spending too much time writing out data. > > > So would it be correct to say: > > "Applications, that should work under all OSes (including the > OSes where the I/O is not synchronised already), have to call > flush on OutputStream to ensure the data is transfered to the > kernel." > > or is this wrong? If so, then I'm afraid I missed the point again > :( > No that is not wrong. Ensuring that data is transfered to the OS is just about what any application can do. From tjarvi at qbang.org Thu Jun 14 08:16:47 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 14 Jun 2007 08:16:47 -0600 (MDT) Subject: [Rxtx] rxtx and usb-serial solution In-Reply-To: References: Message-ID: On Thu, 14 Jun 2007, Vladimir Kirtchev wrote: > Hi Trent, > > I develop a Java application which communicates with devices which have > USB-to-Serial bridge in them. The target OS is Linux. So for this purpose I > use RXTX. > > But I encountered a strange problem - when reading from the InputStream, I > receive series of zeros. I have this problem under Linux only. Under Windows > it is fine. > Actually this problem is the same as the one described here: > http://marc.info/?l=rxtx&m=109703190731748&w=2. > > > So I searched for the problem in the native code. And found that the root of > the problem is in SerialImp.c, > int configure_port( int fd ) > { > ... > ttyset.c_iflag = INPCK; > ... > } > > This line enables input parity checking, and the data sent from the device > is processed by the OS driver before being read with read(). > In this case the driver detects some problem and sets the received bytes to > zero. > > On the other hand in the Java part a set the serial port parameters with > SerialPort.PARITY_NONE. According to me, except all other things, this > should also disable INPCK in c_iflag. > > So I refactored the method translate_parity(...) to the following: > > int translate_parity( JNIEnv *env, struct termios *ttyset, jint parity ) > { > ENTER( "translate_parity" ); > #ifdef CMSPAR > ttyset->c_cflag &= ~(PARENB | PARODD | CMSPAR ); > #endif /* CMSPAR */ > switch( parity ) { > case JPARITY_NONE: > ttyset->c_iflag &= ~INPCK; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_EVEN: > ttyset->c_cflag |= PARENB; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_ODD: > ttyset->c_cflag |= PARENB | PARODD; > LEAVE( "translate_parity" ); > return 0; > #ifdef CMSPAR > case JPARITY_MARK: > ttyset->c_cflag |= PARENB | PARODD | CMSPAR; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_SPACE: > ttyset->c_cflag |= PARENB | CMSPAR; > LEAVE( "translate_parity" ); > return 0; > #endif /* CMSPAR */ > default: > printf("Parity missed %i\n", (int) parity ); > } > > LEAVE( "translate_parity" ); > /* > For some reason the native exceptions are not being caught. Moving this > to the Java side fixed the issue. taj. > throw_java_exception( env, UNSUPPORTED_COMM_OPERATION, > "", "parity value not supported" ); > */ > return 1; > } > > This modification solved the problem and now it works correctly under Linux. > > I think I will be a nice if this is idea is included in a future release of > RXTX. > > Thanks Vadim, I'll try that out. Forwarding to the rxtx mail-list too. This is probably not going to help USB drivers on windows which I'm sure some are looking for. As far as I can tell, windows USB bluetooth and serial dongles are limited by driver functionality. Some are good and others lack key features. -- Trent Jarvi tjarvi at qbang.org From dan.sandberg.lists at gmail.com Mon Jun 18 14:43:39 2007 From: dan.sandberg.lists at gmail.com (Dan Sandberg) Date: Mon, 18 Jun 2007 13:43:39 -0700 Subject: [Rxtx] Fix for JNI Get/Set Field Errors Message-ID: <4676EE7B.7060800@gmail.com> Hi, I've fixed the problems that cause the following JNI error when extra JNI checking ( -Xjni:check ) is turned on. FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) The problem was basically that GetLong was being used to get ints, and SetInt was used for longs. The patch below fixes this. Please let me know if there are any questions / problems. Cheers, -Dan diff -aur old/SerialImp.c src/SerialImp.c --- old/SerialImp.c 2007-06-18 13:24:33.000000000 -0700 +++ src/SerialImp.c 2007-06-18 06:26:26.000000000 -0700 @@ -1337,7 +1337,7 @@ report("init_threads: get eis\n"); jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); report("init_threads: set eis\n"); - (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); + (*eis->env)->SetLongField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); report("init_threads: stop\n"); report_time_end( ); return( 1 ); @@ -1530,7 +1530,7 @@ jobject jobj, jboolean interrupted ) { int fd = get_java_var( env, jobj,"fd","I" ); - struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var( env, jobj, "eis", "J" ); + struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var_long( env, jobj, "eis", "J" ); int result, count=0; char message[80]; @@ -2939,7 +2939,7 @@ /* TRENT */ int flag, count = 0; struct event_info_struct *eis = ( struct event_info_struct * ) - get_java_var( env, *jobj,"eis","J" ); + get_java_var_long( env, *jobj,"eis","J" ); report_time_start(); flag = eis->eventflags[SPE_DATA_AVAILABLE]; @@ -4873,9 +4873,9 @@ exceptions: none comments: ----------------------------------------------------------*/ -size_t get_java_var( JNIEnv *env, jobject jobj, char *id, char *type ) +long get_java_var_long( JNIEnv *env, jobject jobj, char *id, char *type ) { - int result = 0; + long result = 0; jclass jclazz = (*env)->GetObjectClass( env, jobj ); jfieldID jfd = (*env)->GetFieldID( env, jclazz, id, type ); @@ -4889,7 +4889,11 @@ LEAVE( "get_java_var" ); return result; } - result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); + if ( !strcmp( type, "J" ) ) { + result = (long)( (*env)->GetLongField( env, jobj, jfd ) ); + } else { + result = (int) ( (*env)->GetIntField( env, jobj, jfd ) ); + } /* ct7 & gel * Added DeleteLocalRef */ (*env)->DeleteLocalRef( env, jclazz ); if(!strncmp( "fd",id,2) && result == 0) @@ -4900,6 +4904,10 @@ return result; } +int get_java_var( JNIEnv *env, jobject jobj, char *id, char *type ) { + return (int) get_java_var_long( env, jobj, id, type ); +} + /*---------------------------------------------------------- throw_java_exception diff -aur old/SerialImp.h src/SerialImp.h --- old/SerialImp.h 2007-06-18 13:24:39.000000000 -0700 +++ src/SerialImp.h 2007-06-18 06:23:43.000000000 -0700 @@ -413,7 +413,8 @@ void system_wait(); void finalize_event_info_struct( struct event_info_struct * ); int read_byte_array( JNIEnv *, jobject *, int, unsigned char *, int, int ); -size_t get_java_var( JNIEnv *, jobject, char *, char * ); +int get_java_var( JNIEnv *, jobject, char *, char * ); +long get_java_var_long( JNIEnv *, jobject, char *, char * ); jboolean is_interrupted( struct event_info_struct * ); int send_event(struct event_info_struct *, jint, int ); void dump_termios(char *,struct termios *); From yvespielusenet at free.fr Tue Jun 26 03:41:58 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 11:41:58 +0200 Subject: [Rxtx] [PARALLEL] resource in use Message-ID: <1182850918.3483.10.camel@localhost.localdomain> Hello, So now I want to modify the timeout of the library for parallel port. I have downloaded source code. There is a makefile for migw. SO I have installed mingw on ubuntu and modified the makefile.mingw32 to set it for my system. I have no error but some warnings. The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But When I want to use it the jvm crash :( How can I know what is wrong ? How rxtx windows release has been done ? thanks -- yves piel From yvespielusenet at free.fr Tue Jun 26 07:17:02 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 15:17:02 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182850918.3483.10.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> Message-ID: <1182863822.3483.17.camel@localhost.localdomain> Here is the Makefile I use, the output of the 'make' and the log of the jvm when it crashed : - The Makefile : http://yvespiel.free.fr/rxtx/Makefile - The make output : http://yvespiel.free.fr/rxtx/compile.txt - The crash log : http://yvespiel.free.fr/rxtx/hs_err_pid2100.log I have compiled rxtx under Debian testing with mingw : narma at linimi:/tmp/err$ dpkg -l | grep mingw ii mingw32 3.4.5.20060117.1.dfsg-3 ii mingw32-binutils 2.17.50-20070129.1-1 ii mingw32-runtime 3.12-1 thanks fort help :) Le mardi 26 juin 2007 ? 11:41 +0200, yves pielusenet a ?crit : > Hello, > So now I want to modify the timeout of the library for parallel port. I > have downloaded source code. There is a makefile for migw. SO I have > installed mingw on ubuntu and modified the makefile.mingw32 to set it > for my system. > I have no error but some warnings. > The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But > When I want to use it the jvm crash :( > > How can I know what is wrong ? > > How rxtx windows release has been done ? > > thanks > From yvespielusenet at free.fr Tue Jun 26 07:40:11 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 15:40:11 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182863822.3483.17.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> <1182863822.3483.17.camel@localhost.localdomain> Message-ID: <1182865211.3483.21.camel@localhost.localdomain> I have add the options '--enable-stdcall-fixup' to the 'i586-mingw32msvc-ld' commande. Now I have no warning. But the JVM always crashes :( The output seems more detailled, but I don't understand anything... Here is files : http://yvespiel.free.fr/rxtx/2/ -- yves piel Le mardi 26 juin 2007 ? 15:17 +0200, yves pielusenet a ?crit : > Here is the Makefile I use, the output of the 'make' and the log of the > jvm when it crashed : > > - The Makefile : http://yvespiel.free.fr/rxtx/Makefile > - The make output : http://yvespiel.free.fr/rxtx/compile.txt > - The crash log : http://yvespiel.free.fr/rxtx/hs_err_pid2100.log > > I have compiled rxtx under Debian testing with mingw : > narma at linimi:/tmp/err$ dpkg -l | grep mingw > ii mingw32 3.4.5.20060117.1.dfsg-3 > ii mingw32-binutils 2.17.50-20070129.1-1 > ii mingw32-runtime 3.12-1 > > thanks fort help :) > > > Le mardi 26 juin 2007 ? 11:41 +0200, yves pielusenet a ?crit : > > Hello, > > So now I want to modify the timeout of the library for parallel port. I > > have downloaded source code. There is a makefile for migw. SO I have > > installed mingw on ubuntu and modified the makefile.mingw32 to set it > > for my system. > > I have no error but some warnings. > > The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But > > When I want to use it the jvm crash :( > > > > How can I know what is wrong ? > > > > How rxtx windows release has been done ? > > > > thanks > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From yvespielusenet at free.fr Tue Jun 26 08:27:42 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 16:27:42 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182865211.3483.21.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> <1182863822.3483.17.camel@localhost.localdomain> <1182865211.3483.21.camel@localhost.localdomain> Message-ID: <1182868062.3483.24.camel@localhost.localdomain> I think thant the include files of jdk were not for windows but for linux. So I have copied include/ folder from windows to linux and I modified the Makefile to use those file. It compile fine but the JVM always crash :( http://yvespiel.free.fr/rxtx/3/ Le mardi 26 juin 2007 ? 15:40 +0200, yves pielusenet a ?crit : > I have add the options '--enable-stdcall-fixup' to the > 'i586-mingw32msvc-ld' commande. Now I have no warning. But the JVM > always crashes :( The output seems more detailled, but I don't > understand anything... > Here is files : > http://yvespiel.free.fr/rxtx/2/ > From netbeans at gatworks.com Fri Jun 1 05:38:50 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 07:38:50 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <465F7ADD.1010501@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> Message-ID: <4660054A.2040202@gatworks.com> Manuel Naranjo wrote: In the case of my module, you can > unplug the device but it will not delete the symlink until those apps > that had opened the port has closed it. This is done this way to avoid > kernel panics. What does this mean to user code ? I have tried the alternate route ( other than closing ) which is sleep inbetween the I/O errors ( an unplugged USB device). When the device is plugged back in, The writes to the device still get an I/O error. This would seem to be a lost cause for the application. From netbeans at gatworks.com Fri Jun 1 06:35:48 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 08:35:48 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <465F7ADD.1010501@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> Message-ID: <466012A4.90608@gatworks.com> Manuel Naranjo wrote: In the case of my module, you can > unplug the device but it will not delete the symlink until those apps > that had opened the port has closed it. T Did u also mean for this to happen? USB0 was not closed by application. Apparently USB1 got created when USB device was plugged back in. There is only one USB device on a 4 port USB hub. This also seems to suggest that application recovery to be impossible. > Jun 1 07:10:08 mylaptop kernel: garmin_gps 1-1.4:1.0: Garmin GPS usb/tty converter detected > Jun 1 07:10:08 mylaptop kernel: usb 1-1.4: Garmin GPS usb/tty converter now attached to ttyUSB0 > Jun 1 07:15:17 mylaptop kernel: usb 1-1: USB disconnect, address 4 > Jun 1 07:15:17 mylaptop kernel: usb 1-1.4: USB disconnect, address 5 > Jun 1 07:15:17 mylaptop kernel: garmin_gps 1-1.4:1.0: device disconnected > Jun 1 07:15:26 mylaptop kernel: usb 1-1: new full speed USB device using uhci_hcd and address 6 > Jun 1 07:15:26 mylaptop kernel: hub 1-1:1.0: USB hub found > Jun 1 07:15:26 mylaptop kernel: hub 1-1:1.0: 4 ports detected > Jun 1 07:15:27 mylaptop kernel: usb 1-1.4: new full speed USB device using uhci_hcd and address 7 > Jun 1 07:15:27 mylaptop kernel: garmin_gps 1-1.4:1.0: Garmin GPS usb/tty converter detected > Jun 1 07:15:27 mylaptop kernel: usb 1-1.4: Garmin GPS usb/tty converter now attached to ttyUSB1 From naranjo.manuel at gmail.com Fri Jun 1 09:17:22 2007 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Fri, 01 Jun 2007 12:17:22 -0300 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <466012A4.90608@gatworks.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> <466012A4.90608@gatworks.com> Message-ID: <46603882.5050701@gmail.com> Uncle George escribi?: > Manuel Naranjo wrote: > In the case of my module, you can > >> unplug the device but it will not delete the symlink until those apps >> that had opened the port has closed it. T >> > > Did u also mean for this to happen? USB0 was not closed by application. > > Apparently USB1 got created when USB device was plugged back in. There > is only one USB device on a 4 port USB hub. > > This also seems to suggest that application recovery to be impossible. > Exactly there's a dead symlink (you can read and write to it and nothing will happen) and a new port will be created when a new device is connencted. From netbeans at gatworks.com Fri Jun 1 10:20:46 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 12:20:46 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <46603882.5050701@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> <466012A4.90608@gatworks.com> <46603882.5050701@gmail.com> Message-ID: <4660475E.5090202@gatworks.com> Not sure what u mean by "symlink". U cant read/write to it anymore. U get I/O error. In this scenario the device effectively went dead, and only solution is to close the channel. reconnecting the USB device, although dead, but not closed, will create a second device. This does not seem to be a desirable side-effect. The user will now have ttyUSB1, wondering where did ttyUSB0 go to. The application will also be in a confused state, as well as RXTX, because RXTX wont know about ttyUSB1. Manuel Naranjo wrote: > Uncle George escribi?: >> Manuel Naranjo wrote: >> In the case of my module, you can >> >>> unplug the device but it will not delete the symlink until those apps >>> that had opened the port has closed it. T >>> >> Did u also mean for this to happen? USB0 was not closed by application. >> >> Apparently USB1 got created when USB device was plugged back in. There >> is only one USB device on a 4 port USB hub. >> >> This also seems to suggest that application recovery to be impossible. >> > Exactly there's a dead symlink (you can read and write to it and nothing > will happen) and a new port will be created when a new device is connencted. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From arnab.bhaumik at gmail.com Mon Jun 4 01:40:16 2007 From: arnab.bhaumik at gmail.com (arnab bhaumik) Date: Mon, 4 Jun 2007 13:10:16 +0530 Subject: [Rxtx] full duplex com port with rxtx Message-ID: hi , till now i did half duplex communication with rxtx package on com package. my question is : is it possible to use com port with full duplex mode with rxtx package . ther is example of SimpleRead class and SimpleWrite class. it is clear that if i can use both the class simultaneously then full duplex is possible......... arnab/vu2bpw -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070604/6edb0453/attachment-0010.html From lists at iDIAcomputing.com Mon Jun 4 07:53:17 2007 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Mon, 04 Jun 2007 09:53:17 -0400 Subject: [Rxtx] full duplex com port with rxtx In-Reply-To: References: Message-ID: <4664194D.90301@iDIAcomputing.com> arnab bhaumik wrote: > hi , > > till now i did half duplex communication with rxtx package on com > package. > > my question is : is it possible to use com port with full duplex mode > with rxtx package . > > > ther is example of SimpleRead class and SimpleWrite class. it is > clear that if i can use both the class simultaneously then full duplex > is possible......... I haven't looked at the SimpleRead and SimpleWrite classes (I originally wrote my code for the javax.comm api), but full duplex is certainly possible. My CommReader class requires an object analogous to a OutputStream or Writer. When started, it spawns a thread that reads the comm port and writes to that output device. In this way the input is asynchronous and dependent on the actual input data. For full duplex, I extend that class with CommReaderWriter, which adds synchronous output methods. Hope that helps, George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From supsoop at hotmail.com Mon Jun 4 15:21:06 2007 From: supsoop at hotmail.com (soop soop) Date: Mon, 04 Jun 2007 21:21:06 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- Message-ID: Hi Guys, Looked through the archives but still cannot figure this out. I have a Motorola G24 GPRS/GSM modem that I am connecting to my server running Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not detecting the port, CommPortIdentifier.getPortIdentifiers(). I have added the line to RXTXCommDriver: "ttyACM" // for USB Modems Rxtx still does not seem to find the port. Is there something I am missing to make this port visable? [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control Model driver for USB modems and ISDN adapters I really need your help as I have moved my server from windows to Linux and have been down for a few days because of this .. Thanks so much! _________________________________________________________________ PC Magazine’s 2007 editors’ choice for best Web mail—award-winning Windows Live Hotmail. http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 From tjarvi at qbang.org Mon Jun 4 16:17:35 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Jun 2007 16:17:35 -0600 (MDT) Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: On Mon, 4 Jun 2007, soop soop wrote: > Hi Guys, > > Looked through the archives but still cannot figure this out. I have a > Motorola G24 GPRS/GSM modem that I am connecting to my server running Ubuntu. > I can see my modem as is shows up as ttyACM0, but RXTX is not detecting the > port, CommPortIdentifier.getPortIdentifiers(). > > I have added the line to RXTXCommDriver: > > "ttyACM" // for USB Modems > > Rxtx still does not seem to find the port. Is there something I am missing to > make this port visable? > > [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver > [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device > [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control Model > driver for USB modems and ISDN adapters > > I really need your help as I have moved my server from windows to Linux and > have been down for a few days because of this .. Thanks so much! > You could try the INSTALL documentation that comes with the source for possible solutions. Those usually involve lockfile creation, permissions on the device file or the device is in use by another application (even another session of your application). The usual commands: ls -l /dev/ttyACM0 fuser /dev/ttyACM0 touch /var/lock/LCK.testfile && rm -f /var/lock/LCK.testfile whoami To disable lockfiles: ../configure --disable-lockfiles && make install -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Jun 4 16:22:52 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 04 Jun 2007 18:22:52 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <466490BC.3090801@gatworks.com> soop soop wrote: > I really need your help as I have moved my server from windows to Linux > and have been down for a few days because of this .. Thanks so much! can u open the device ? ie is the file protection/permissions keeping you out? From supsoop at hotmail.com Mon Jun 4 16:44:40 2007 From: supsoop at hotmail.com (soop soop) Date: Mon, 04 Jun 2007 22:44:40 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <466490BC.3090801@gatworks.com> Message-ID: Thanks for the reply, I see no exceptions being thrown, just no detection of the port whats so ever. I will run rxtx in debug mode and log. If this were a permissions issue would I not see some exceptions being thrown? >From: Uncle George >Reply-To: RXTX Developers and Users >To: RXTX Developers and Users >Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >Date: Mon, 04 Jun 2007 18:22:52 -0400 > >soop soop wrote: > > > I really need your help as I have moved my server from windows to Linux > > and have been down for a few days because of this .. Thanks so much! > >can u open the device ? ie is the file protection/permissions keeping >you out? >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ Get a preview of Live Earth, the hottest event this summer - only on MSN http://liveearth.msn.com?source=msntaglineliveearthhm From netbeans at gatworks.com Mon Jun 4 17:06:15 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 04 Jun 2007 19:06:15 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <46649AE7.10405@gatworks.com> Exceptions on what? On startup it wants to lookup all devices in /dev that it is capable of opening ( within the list of specific 'comm' devices ). If it cannot open, then does not get onto list. Part of this process, if configured, will also test if the "LOCK" schema can also be opened for the device. then it gets on the list of avail comm port. soop soop wrote: > Thanks for the reply, > > I see no exceptions being thrown, just no detection of the port whats so > ever. I will run rxtx in debug mode and log. If this were a permissions > issue would I not see some exceptions being thrown? > > >> From: Uncle George >> Reply-To: RXTX Developers and Users >> To: RXTX Developers and Users >> Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >> Date: Mon, 04 Jun 2007 18:22:52 -0400 >> >> soop soop wrote: >> >>> I really need your help as I have moved my server from windows to Linux >>> and have been down for a few days because of this .. Thanks so much! >> can u open the device ? ie is the file protection/permissions keeping >> you out? >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _________________________________________________________________ > Get a preview of Live Earth, the hottest event this summer - only on MSN > http://liveearth.msn.com?source=msntaglineliveearthhm > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From alex.flint at gmail.com Mon Jun 4 21:31:49 2007 From: alex.flint at gmail.com (Alex Flint) Date: Tue, 5 Jun 2007 13:01:49 +0930 Subject: [Rxtx] random EXCEPTION_ACCESS_VIOLATION errors Message-ID: Hi All, I'm running winXP and RXTX 2.1-7r2 (the latest from the webpage as of June 2007). I'm sending sequences of 64 lines (each line has about 15 chars) at various intervals. The strings are sent fine, until I get the following error (from hs_err_pid3316.log, at the end of this email). What can I do to avoid the error? Obviously this is a low-level memory exception, but is there any way I can keep the JVM running after such an error? I noticed the exact same problem here: http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20070129/1180520.html Cheers, Alex # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x100034fb, pid=3316, tid=2400 # # Java VM: Java HotSpot(TM) Client VM (1.6.0_01-b06 mixed mode, sharing) # Problematic frame: # C [rxtxSerial.dll+0x34fb] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # --------------- T H R E A D --------------- Current thread (0x00386400): JavaThread "main" [_thread_in_native, id=2400] siginfo: ExceptionCode=0xc0000005, reading address 0x20726f78 Registers: EAX=0x20726f20, EBX=0x6d8922c0, ECX=0x00000005, EDX=0x20726f20 ESP=0x003efa30, EBP=0x003efb68, ESI=0x269728a0, EDI=0x00386400 EIP=0x100034fb, EFLAGS=0x00010212 Top of Stack: (sp=0x003efa30) 0x003efa30: 003efa3c 003efa64 0000000f ffffffff 0x003efa40: 003efa40 2a97f808 003efa6c 2b190ca8 0x003efa50: 00000000 2b190ec0 003efa90 008e2dd7 0x003efa60: 003efa90 008e2dd7 26977f88 6d815e72 0x003efa70: 00000004 2696eae0 0000008a 003efb0c 0x003efa80: 6d852b4a 2696eae0 00000003 26970930 0x003efa90: 000000cb 2696eae0 6d86b264 00385d40 0x003efaa0: 0000003f 003efb0c 26977f90 2ace65d8 Instructions: (pc=0x100034fb) 0x100034eb: ff ff 8d 76 00 eb 02 89 f6 90 8b 45 f8 8b 55 f8 0x100034fb: 8b 4a 58 83 c9 04 89 48 58 83 c4 f8 8b 45 f8 8b Stack: [0x003a0000,0x003f0000), sp=0x003efa30, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x34fb] Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j gnu.io.RXTXPort.writeArray([BIIZ)V+0 j gnu.io.RXTXPort$SerialOutputStream.write([B)V+76 j com.bjt.media.server.CommLink.send(Ljava/lang/String;)V+48 j com.bjt.media.server.DigitoolConnection.select(I)V+73 j com.bjt.media.server.DigitoolConnection.main([Ljava/lang/String;)V+74 v ~StubRoutines::call_stub --------------- P R O C E S S --------------- Java Threads: ( => current thread ) 0x02a69400 JavaThread "Thread-0" [_thread_in_native, id=3052] 0x02a4d000 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=3920] 0x02a48400 JavaThread "CompilerThread0" daemon [_thread_blocked, id=1968] 0x02a47400 JavaThread "Attach Listener" daemon [_thread_blocked, id=2984] 0x02a46400 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=2660] 0x02a41c00 JavaThread "Finalizer" daemon [_thread_blocked, id=3924] 0x02a3d800 JavaThread "Reference Handler" daemon [_thread_blocked, id=4008] =>0x00386400 JavaThread "main" [_thread_in_native, id=2400] Other Threads: 0x02a34400 VMThread [id=3708] 0x02a4e800 WatcherThread [id=3964] VM state:not at safepoint (normal execution) VM Mutex/Monitor currently owned by a thread: None Heap def new generation total 960K, used 131K [0x22960000, 0x22a60000, 0x22e40000) eden space 896K, 7% used [0x22960000, 0x22970ea8, 0x22a40000) from space 64K, 99% used [0x22a50000, 0x22a5fff8, 0x22a60000) to space 64K, 0% used [0x22a40000, 0x22a40000, 0x22a50000) tenured generation total 4096K, used 76K [0x22e40000, 0x23240000, 0x26960000) the space 4096K, 1% used [0x22e40000, 0x22e53060, 0x22e53200, 0x23240000) compacting perm gen total 12288K, used 137K [0x26960000, 0x27560000, 0x2a960000) the space 12288K, 1% used [0x26960000, 0x26982518, 0x26982600, 0x27560000) ro space 8192K, 62% used [0x2a960000, 0x2ae5e4e8, 0x2ae5e600, 0x2b160000) rw space 12288K, 52% used [0x2b160000, 0x2b7a0e78, 0x2b7a1000, 0x2bd60000) Dynamic libraries: 0x00400000 - 0x00423000 C:\Program Files\Java\jre1.6.0_01\bin\javaw.exe 0x7c900000 - 0x7c9b0000 C:\WINDOWS\system32\ntdll.dll 0x7c800000 - 0x7c8f4000 C:\WINDOWS\system32\kernel32.dll 0x77dd0000 - 0x77e6b000 C:\WINDOWS\system32\ADVAPI32.dll 0x77e70000 - 0x77f01000 C:\WINDOWS\system32\RPCRT4.dll 0x7e410000 - 0x7e4a0000 C:\WINDOWS\system32\USER32.dll 0x77f10000 - 0x77f57000 C:\WINDOWS\system32\GDI32.dll 0x76390000 - 0x763ad000 C:\WINDOWS\system32\IMM32.DLL 0x7c340000 - 0x7c396000 C:\Program Files\Java\jre1.6.0_01\bin\msvcr71.dll 0x6d7c0000 - 0x6da07000 C:\Program Files\Java\jre1.6.0_01\bin\client\jvm.dll 0x76b40000 - 0x76b6d000 C:\WINDOWS\system32\WINMM.dll 0x5cd70000 - 0x5cd77000 C:\WINDOWS\system32\serwvdrv.dll 0x5b0a0000 - 0x5b0a7000 C:\WINDOWS\system32\umdmxfrm.dll 0x6d310000 - 0x6d318000 C:\Program Files\Java\jre1.6.0_01\bin\hpi.dll 0x76bf0000 - 0x76bfb000 C:\WINDOWS\system32\PSAPI.DLL 0x6d770000 - 0x6d77c000 C:\Program Files\Java\jre1.6.0_01\bin\verify.dll 0x6d3b0000 - 0x6d3cf000 C:\Program Files\Java\jre1.6.0_01\bin\java.dll 0x6d7b0000 - 0x6d7bf000 C:\Program Files\Java\jre1.6.0_01\bin\zip.dll 0x10000000 - 0x10012000 C:\Documents and Settings\Alex\workspace\MediaServer\rxtxSerial.dll 0x73d90000 - 0x73db7000 C:\WINDOWS\system32\crtdll.dll VM Arguments: jvm_args: -Djava.library.path=C:\Documents and Settings\Alex\workspace\MediaServer java_command: com.bjt.media.server.DigitoolConnection Launcher Type: SUN_STANDARD Environment Variables: CLASSPATH=.;C:\Program Files\Java\j2re1.4.2_07\lib\ext\QTJava.zip PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\wbem;c:\applications\php;C:\Program Files\MATLAB\R2006a\bin\win32;C:\Roger\Projects\UAV\Bin\Debug;C:\Program Files\Microsoft SQL Server\80\Tools\Binn\;c:\Program Files\Microsoft SQL Server\90\Tools\binn\;C:\Program Files\QuickTime\QTSystem\;C:\Pfps\system;C:\Program Files\Java\jdk1.6.0_01\bin;C:\Program Files\Java\jdk1.6.0_01\jre\bin USERNAME=Alex OS=Windows_NT PROCESSOR_IDENTIFIER=x86 Family 15 Model 4 Stepping 1, GenuineIntel --------------- S Y S T E M --------------- OS: Windows XP Build 2600 Service Pack 2 CPU:total 1 family 15, cmov, cx8, fxsr, mmx, sse, sse2 Memory: 4k page, physical 1046508k(275288k free), swap 2522816k(1909176k free) vm_info: Java HotSpot(TM) Client VM (1.6.0_01-b06) for windows-x86, built on Mar 14 2007 00:24:02 by "java_re" with unknown MS VC++:1310 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070604/c87ae1f0/attachment-0010.html From alwyn.schoeman at gmail.com Tue Jun 5 00:10:19 2007 From: alwyn.schoeman at gmail.com (Alwyn Schoeman) Date: Tue, 5 Jun 2007 08:10:19 +0200 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Hi, I'm using a similar modem. By default rxtx doesn't look for devices that start with ACM, so you need to modify the source code and recompile. Look in RXTXCommDriver and add values for ACM in the registerScannedPorts method in the Linux specific parts. Look for osName.equals("Linux")... On 6/4/07, soop soop wrote: > > Hi Guys, > > Looked through the archives but still cannot figure this out. I have a > Motorola G24 GPRS/GSM modem that I am connecting to my server running > Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not > detecting the port, CommPortIdentifier.getPortIdentifiers(). > > I have added the line to RXTXCommDriver: > > "ttyACM" // for USB Modems > > Rxtx still does not seem to find the port. Is there something I am missing > to make this port visable? > > [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver > [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device > [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control > Model > driver for USB modems and ISDN adapters > > I really need your help as I have moved my server from windows to Linux > and > have been down for a few days because of this .. Thanks so much! > > _________________________________________________________________ > PC Magazine's 2007 editors' choice for best Web mail?award-winning Windows > Live Hotmail. > > http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > -- Alwyn Schoeman -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/b6cb3053/attachment-0010.html From naranjo.manuel at gmail.com Tue Jun 5 06:48:45 2007 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Tue, 05 Jun 2007 09:48:45 -0300 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> References: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Message-ID: <46655BAD.7010501@gmail.com> That's right, an easier solution is creating symlinks to acm. For example make ttyS70 to 79 point to ACM0 to 9 and that will help you a lot, and doesn't even require compile. > Hi, > > I'm using a similar modem. By default rxtx doesn't look for devices > that start with ACM, so you need to modify the > source code and recompile. > > Look in RXTXCommDriver and add values for ACM in the > registerScannedPorts method in the Linux specific parts. Look for > osName.equals("Linux")... > From juanemc2 at gmail.com Tue Jun 5 07:02:43 2007 From: juanemc2 at gmail.com (Juan) Date: Tue, 5 Jun 2007 10:02:43 -0300 Subject: [Rxtx] Problems with Epson TMU220B POSPrinter using XON/XOFF Flow Control and rxtx jar and dll's with the serial port. Message-ID: Hi!, I?m having trouble printing to the serial port using the latest version of rxtx jar and dll's with an Epson POSPrinter. I`ve switched the printer to work with XON/XOFF Flow Control and have watched the serial port to be sure the printer is sending the XON XOFF stop and go characters. I`ve setted the port like this: CommPortIdentifier commPortIdentifier = CommPortIdentifier.* getPortIdentifier*(_portName); SerialPort serialPort = (SerialPort)commPortIdentifier.open(*this*.getClass().getName(), 2000); serialPort.setSerialPortParams(_baudRate, _dataBits, _stopBits, _parity); serialPort.setFlowControlMode( SerialPort.*FLOWCONTROL_XONXOFF_IN* | SerialPort.*FLOWCONTROL_XONXOFF_OUT*); where the baudRate is 9600 the dataBits is 8 the stopBits is 1 and the parity is 0 It seems as the library isn`t taking into account the XON XOFF setting. I would like to know if I`m setting correctly the Flow Control and if you had had any experiences using XON XOFF flow control and could give me some help to solve my problem. I`m very thankful in advance, Yours, Juan Polero -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/b080995a/attachment-0010.html From ehdez.correo at gmail.com Tue Jun 5 07:12:53 2007 From: ehdez.correo at gmail.com (=?ISO-8859-1?Q?Enrique_Hern=E1ndez?=) Date: Tue, 5 Jun 2007 09:12:53 -0400 Subject: [Rxtx] problem with rxtx Message-ID: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Hello: I doing a simple test to show the serial ports. This is the code: import java.util.Enumeration; import gnu.io.CommPortIdentifier; import gnu.io.SerialPort; public class Show { private Enumeration portList; private CommPortIdentifier portId; private SerialPort port; /** Creates a new instance of Show */ public Show() { } public static void main(String args[]){ Show show = new Show(); show.portList = CommPortIdentifier.getPortIdentifiers(); String tPort = ""; System.out.println("========================================="); while(show.portList.hasMoreElements()){ show.portId = (CommPortIdentifier)show.portList.nextElement(); if(show.portId.getPortType() == CommPortIdentifier.PORT_SERIAL) tPort = "Serial"; else tPort = "Parallel"; System.out.println(show.portId.getName() + " " + tPort); } } } whit The problem is that this code not show the serial ports, this show the no use serial ports. I want to connect whit the modem but when windows open and connect the modem my application don't see the port(COMM3) when it is connect. what I can do? Is that the correct way to know the ports? thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/eedd744b/attachment-0010.html From ehdez.correo at gmail.com Tue Jun 5 07:42:13 2007 From: ehdez.correo at gmail.com (=?ISO-8859-1?Q?Enrique_Hern=E1ndez?=) Date: Tue, 5 Jun 2007 09:42:13 -0400 Subject: [Rxtx] serial port Message-ID: <4a814e1f0706050642p4ce9ac7bka80f9479c524c5ea@mail.gmail.com> Hello: How I can ask to the port what device is connect and information about this device. thanks. bye. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070605/4d10d26a/attachment-0010.html From supsoop at hotmail.com Tue Jun 5 09:29:00 2007 From: supsoop at hotmail.com (soop soop) Date: Tue, 05 Jun 2007 15:29:00 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <22d55aea0706042310x3db2bbefve1a848a384b917a7@mail.gmail.com> Message-ID: Hi Guys, Thanks for all your help. I found the problem. I created a user, Tomcat55, for my tomcat but it did not belong to any group. I then added this user to dialout group to have access to the device ttyACM0. Works perfectly! Again permissions was the issue. This also seems to be persistent as a server reboot does not effect the access. Cheers! >From: "Alwyn Schoeman" >Reply-To: RXTX Developers and Users >To: "RXTX Developers and Users" >Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >Date: Tue, 5 Jun 2007 08:10:19 +0200 > >Hi, > >I'm using a similar modem. By default rxtx doesn't look for devices that >start with ACM, so you need to modify the >source code and recompile. > >Look in RXTXCommDriver and add values for ACM in the registerScannedPorts >method in the Linux specific parts. Look for osName.equals("Linux")... > >On 6/4/07, soop soop wrote: >> >>Hi Guys, >> >>Looked through the archives but still cannot figure this out. I have a >>Motorola G24 GPRS/GSM modem that I am connecting to my server running >>Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not >>detecting the port, CommPortIdentifier.getPortIdentifiers(). >> >>I have added the line to RXTXCommDriver: >> >>"ttyACM" // for USB Modems >> >>Rxtx still does not seem to find the port. Is there something I am missing >>to make this port visable? >> >>[ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver >>[ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device >>[ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control >>Model >>driver for USB modems and ISDN adapters >> >>I really need your help as I have moved my server from windows to Linux >>and >>have been down for a few days because of this .. Thanks so much! >> >>_________________________________________________________________ >>PC Magazine's 2007 editors' choice for best Web mail—award-winning Windows >>Live Hotmail. >> >>http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 >> >> >>_______________________________________________ >>Rxtx mailing list >>Rxtx at qbang.org >>http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > >-- >Alwyn Schoeman >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ Need a break? Find your escape route with Live Search Maps. http://maps.live.com/default.aspx?ss=Restaurants~Hotels~Amusement%20Park&cp=33.832922~-117.915659&style=r&lvl=13&tilt=-90&dir=0&alt=-1000&scene=1118863&encType=1&FORM=MGAC01 From netbeans at gatworks.com Tue Jun 5 09:42:31 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 11:42:31 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <46658467.20101@gatworks.com> soop soop wrote: > > Hi Guys, > > Thanks for all your help. I found the problem. I created a user, > Tomcat55, for my tomcat but it did not belong to any group. I then added Look at man pages for the program udev. From tjarvi at qbang.org Tue Jun 5 18:18:17 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Jun 2007 18:18:17 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Message-ID: On Tue, 5 Jun 2007, Enrique Hern?ndez wrote: > The problem is that this code not show the serial ports, this show the no > use serial ports. I want to connect whit the modem but when windows open and > connect the modem my application don't see the port(COMM3) when it is > connect. > what I can do? > Is that the correct way to know the ports? > Hello, We may have problems understanding each other. On windows, the port will not be an available serial port if another application has the port open. That is just how the library behaves. If you can not see the port in the enumerated list, you could not open it. Also note that enumeration only happens once. If you add a port such as a new USB dongle, the port will not be visible until the next time your application runs. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Tue Jun 5 18:45:01 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 20:45:01 -0400 Subject: [Rxtx] problem with rxtx In-Reply-To: References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> Message-ID: <4666038D.8090700@gatworks.com> Trent Jarvi wrote: > > > Also note that enumeration only happens once. If you add a port such as > a new USB dongle, the port will not be visible until the next time your > application runs. Is this written in stone ? somewhere? From tjarvi at qbang.org Tue Jun 5 18:54:36 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Tue, 5 Jun 2007 18:54:36 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <4666038D.8090700@gatworks.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> Message-ID: On Tue, 5 Jun 2007, Uncle George wrote: > Trent Jarvi wrote: >> >> >> Also note that enumeration only happens once. If you add a port such as >> a new USB dongle, the port will not be visible until the next time your >> application runs. > > Is this written in stone ? somewhere? It is just the current behavior. There is nothing preventing a fix that allows reenumeration. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Tue Jun 5 19:55:19 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 05 Jun 2007 21:55:19 -0400 Subject: [Rxtx] problem with rxtx In-Reply-To: References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> Message-ID: <46661407.4020308@gatworks.com> >> Is this written in stone ? somewhere? > > It is just the current behavior. There is nothing preventing a fix that > allows reenumeration. With usb, ..... , things come and go. Seems a shame that you have to kill application to get at the device u just plugged in. From joachim at buechse.ch Wed Jun 6 01:50:06 2007 From: joachim at buechse.ch (Joachim Buechse) Date: Wed, 6 Jun 2007 09:50:06 +0200 Subject: [Rxtx] problem with rxtx In-Reply-To: <46661407.4020308@gatworks.com> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> <46661407.4020308@gatworks.com> Message-ID: <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> On MacOS RXTX's enumeration handling is more flexible. It will find new ports that are added during the lifetime of the application. But this is inherently incompatible with suns javax.comm implementation... Regards, Joachim On 06.06.2007, at 03:55, Uncle George wrote: > >>> Is this written in stone ? somewhere? >> >> It is just the current behavior. There is nothing preventing a >> fix that >> allows reenumeration. > > With usb, ..... , things come and go. Seems a shame that you have to > kill application to get at the device u just plugged in. > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx From tjarvi at qbang.org Wed Jun 6 06:06:48 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Wed, 6 Jun 2007 06:06:48 -0600 (MDT) Subject: [Rxtx] problem with rxtx In-Reply-To: <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> References: <4a814e1f0706050612r5d87cd4j1e227b6ae1f34917@mail.gmail.com> <4666038D.8090700@gatworks.com> <46661407.4020308@gatworks.com> <580D1B93-B8A8-4C45-BFD0-05DD117D2093@buechse.ch> Message-ID: Sun's javax.comm is not a major concern going forward. As long as we do not break old applications using rxtx, I see no reason to limit rxtx to that convention. We have already rejected version 3 from Sun as a dead end and limited our compatability to version 2. That does not mean we will not try to work with Sun and others but the current javax.comm convention (v3) is not a well conceived path. There has been discussion about doing a JSR which is one valid option. On Wed, 6 Jun 2007, Joachim Buechse wrote: > On MacOS RXTX's enumeration handling is more flexible. It will find > new ports that are added during the lifetime of the application. But > this is inherently incompatible with suns javax.comm implementation... > > Regards, > Joachim > > On 06.06.2007, at 03:55, Uncle George wrote: > >> >>>> Is this written in stone ? somewhere? >>> >>> It is just the current behavior. There is nothing preventing a >>> fix that >>> allows reenumeration. >> >> With usb, ..... , things come and go. Seems a shame that you have to >> kill application to get at the device u just plugged in. >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From yvespielusenet at free.fr Wed Jun 6 08:46:35 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 16:46:35 +0200 Subject: [Rxtx] [PARALLEL] resource in use Message-ID: <1181141195.3407.20.camel@localhost.localdomain> Hello, I want to use rxtx in my application. I haveto send data to a very old printer (which have a drum and hammers http://perso.orange.fr/tiie/page00010017.html) This is printer is connecter with centronics. It works well but, while it's writting and I putthe printer off-line, after about 45 seconds, I have this error : ------------------------------------- java.io.IOException: La ressource demand?e est en cours d'utilisation. in writeArray at gnu.io.LPRPort.writeArray(Native Method) at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:292) at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:161) at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:156) at mce.buffer.bufferManager.BufferManager$PrintBuffer.run(BufferManager.java:141) The IOexception means "The wanted resource is in use" ------------------------------------- Here is the line 141 of BufferManager : ------------------------------------- while(send){ try{ fos.write(bb); <=== line 141 send = false; } catch(Exception e){ javax.swing.JOptionPane.showMessageDialog(null, "Erreur d'envoie. Veuillez cliquer sur OK pour relancer l'impression de la vignette.\nV?rifiez votre impression !", "Erreur d'envoie", javax.swing.JOptionPane.WARNING_MESSAGE); e.printStackTrace(System.err); System.err.flush(); System.out.println(e); send = true; } } -------------------------------- 'fos' is an outputstream which contains the rxtx stream (this.os is the rxtx outputstream) : -------------------------------- public void write(byte[] bb) throws IOException{ this.write(bb, 0, bb.length); } public void write(byte[] bb, int off, int len) throws IOException{ while(!imp1.isPrinterSelected() || !imp2.isPrinterSelected()){ } this.os.write(bb, off, len); } -------------------------------- Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( can you help me ? thank you :) -- yves piel From yvespielusenet at free.fr Wed Jun 6 09:11:15 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 17:11:15 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181141195.3407.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> Message-ID: <1181142675.3407.23.camel@localhost.localdomain> I forgot to tell that It's under windows XP and java 1.5. Le mercredi 06 juin 2007 ? 16:46 +0200, yves pielusenet a ?crit : > Hello, > I want to use rxtx in my application. I haveto send data to a very old > printer (which have a drum and hammers > http://perso.orange.fr/tiie/page00010017.html) > This is printer is connecter with centronics. It works well but, while > it's writting and I putthe printer off-line, after about 45 seconds, I > have this error : > ------------------------------------- > java.io.IOException: La ressource demand?e est en cours d'utilisation. > in writeArray > at gnu.io.LPRPort.writeArray(Native Method) > at gnu.io.LPRPort$ParallelOutputStream.write(LPRPort.java:292) > at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:161) > at mce.port.RXTXManager$OutputStreamRXTX.write(RXTXManager.java:156) > at mce.buffer.bufferManager.BufferManager$PrintBuffer.run(BufferManager.java:141) > > The IOexception means "The wanted resource is in use" > ------------------------------------- > > Here is the line 141 of BufferManager : > > ------------------------------------- > while(send){ > try{ > fos.write(bb); <=== line 141 > send = false; > } > catch(Exception e){ > javax.swing.JOptionPane.showMessageDialog(null, "Erreur d'envoie. Veuillez cliquer sur OK pour relancer l'impression de la vignette.\nV?rifiez votre impression !", "Erreur d'envoie", javax.swing.JOptionPane.WARNING_MESSAGE); > e.printStackTrace(System.err); > System.err.flush(); > System.out.println(e); > send = true; > } > } > -------------------------------- > 'fos' is an outputstream which contains the rxtx stream (this.os is the rxtx outputstream) : > > -------------------------------- > public void write(byte[] bb) throws IOException{ > this.write(bb, 0, bb.length); > } > public void write(byte[] bb, int off, int len) throws IOException{ > while(!imp1.isPrinterSelected() || !imp2.isPrinterSelected()){ > } > this.os.write(bb, off, len); > } > -------------------------------- > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > can you help me ? > > thank you :) > From netbeans at gatworks.com Wed Jun 6 09:21:46 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 11:21:46 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181141195.3407.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> Message-ID: <4666D10A.8000507@gatworks.com> } > -------------------------------- > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > can you help me ? > > thank you :) > windoz or linux? ( I guess windoz ) for windoz, there appears to be a timeout ( as Comments suggest ) of about 40seconds. > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } for linux, there is no implied timeout. > if( write( fd, bytes, count ) < 0 ) > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); From netbeans at gatworks.com Wed Jun 6 09:39:41 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 11:39:41 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666D10A.8000507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> Message-ID: <4666D53D.90000@gatworks.com> Uncle George wrote: > } >> -------------------------------- >> >> Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( >> >> can you help me ? From reading the code, I can see your concern. And it appears you are correct, because some of the data will be sent to the OS printer buffers, and then it will refuse to accept anymore. Unfortunately, writeArray does not return the num of characters written :{ So application has no idea to how many characters were accepted by the OS. I dont do windoz, so I cant say with absolute certainty what windoz will do with an off-line condition. If you have the source, and can compile, then maybe u can increase the loop count to hit 4hours? From yvespielusenet at free.fr Wed Jun 6 09:53:25 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Wed, 06 Jun 2007 17:53:25 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666D10A.8000507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> Message-ID: <1181145205.3407.35.camel@localhost.localdomain> Thank you for your explanation :) This timeout comes when no data has been send to the printer after 40seconds if I well understand. But why there is such a timeout ? If I setthe printer offline while it's printing I mustn't have an exception. I don't understand why the "printer should solv all problems like buffer full" in 40 seconds. If I pause the printer the buffer will not be emptied, isn't it ? I not very familiar with C/C++, but it seem that the exception is thrown only when countWritten == 0, that means no data at all has been sent. So Is my code is good since when I intercept this exception I send all my buffer again. There is no way that the printer receive two times same bytes ? thanks ps: yes the application is running on windows XP since I developpe under Debian Le mercredi 06 juin 2007 ? 11:21 -0400, Uncle George a ?crit : > } > > -------------------------------- > > > > Is there someone who understand why I have this exception ? How can I be sure that data are well printed (send into the printer) ? At this time, as you can see, If I have the exception I send the byte[] again, but I don't like this since I can print two times the same thing :( > > > > can you help me ? > > > > thank you :) > > > > windoz or linux? ( I guess windoz ) > > for windoz, there appears to be a timeout ( as Comments suggest ) of > about 40seconds. > > while( count > 0 ){ > > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > > /* > > this are 20 * 2 seconds, in this time a printer (or other parallel device) > > should solv all problems like buffer full, etc > > */ > > if(errorCount++ < 20){ > > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > > continue; > > } > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > for linux, there is no implied timeout. > > if( write( fd, bytes, count ) < 0 ) > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Wed Jun 6 10:34:24 2007 From: netbeans at gatworks.com (Uncle George) Date: Wed, 06 Jun 2007 12:34:24 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181145205.3407.35.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> Message-ID: <4666E210.30507@gatworks.com> yves pielusenet wrote: > Thank you for your explanation :) > This timeout comes when no data has been send to the printer after > 40seconds if I well understand. But why there is such a timeout ? If I > setthe printer offline while it's printing I mustn't have an exception. > I don't understand why the "printer should solv all problems like buffer > full" in 40 seconds. If I pause the printer the buffer will not be > emptied, isn't it ? > > I not very familiar with C/C++, but it seem that the exception is thrown > only when countWritten == 0, that means no data at all has been sent. So > Is my code is good since when I intercept this exception I send all my > buffer again. There is no way that the printer receive two times same > bytes ? More technically, the function call returns and reports that 0 characters was written in this call. when 0 characters are written, it will check how many times 0 characters was written. If it has tried LESS than 20 times(errorCount), it will sleep() and try to write again. After 20 times, it wont sleep, but throw you the exception. Now suppose you are writing a 120 character line. you off-lined/paused your printer. The OS has room for 80 more characters in it's printer buffer. The WriteFile() will have a char count of 120, but on return the countWritten = 80. You still have 40 more characters to print. Since countWritten != 0, the counters: bytes += countWritten; count -= countWritten; get updated, and the Writefile now has a count of 40 characters. Since the printer is off-line, the countwritten is 0. And so the loop continues, till 40 seconds is up. As to why it is this way, i dont know ( not a windoz maven ); Also the sleep(20) in the loop is not so intuitive to suggest 2 seconds of sleep. I would have guessed 20seconds, or 20milliseconds. But go figure. BTW: Since your computer sends you error messages in French, does it curse in English? :)))) From yvespielusenet at free.fr Thu Jun 7 02:27:44 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Thu, 07 Jun 2007 10:27:44 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4666E210.30507@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> Message-ID: <1181204864.3501.10.camel@localhost.localdomain> Maybe in my case I should re-compile rxtx and change the code. Instead of send an exception I should display a dialog box to ask if it's printer problem or if it should trie to send bytes. Something like : while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } if(displayDialogBox("Try again to send datas ??")){ errorCount = 0; } else{ throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } } Le mercredi 06 juin 2007 ? 12:34 -0400, Uncle George a ?crit : > yves pielusenet wrote: > > Thank you for your explanation :) > > This timeout comes when no data has been send to the printer after > > 40seconds if I well understand. But why there is such a timeout ? If I > > setthe printer offline while it's printing I mustn't have an exception. > > I don't understand why the "printer should solv all problems like buffer > > full" in 40 seconds. If I pause the printer the buffer will not be > > emptied, isn't it ? > > > > I not very familiar with C/C++, but it seem that the exception is thrown > > only when countWritten == 0, that means no data at all has been sent. So > > Is my code is good since when I intercept this exception I send all my > > buffer again. There is no way that the printer receive two times same > > bytes ? > More technically, the function call returns and reports that 0 > characters was written in this call. > when 0 characters are written, it will check how many times 0 characters > was written. If it has tried LESS than 20 times(errorCount), it will > sleep() and try to write again. > After 20 times, it wont sleep, but throw you the exception. > > Now suppose you are writing a 120 character line. you off-lined/paused > your printer. The OS has room for 80 more characters in it's printer > buffer. The WriteFile() will have a char count of 120, but on return the > countWritten = 80. You still have 40 more characters to print. > Since countWritten != 0, the counters: > bytes += countWritten; > count -= countWritten; > get updated, and the Writefile now has a count of 40 characters. Since > the printer is off-line, the countwritten is 0. And so the loop > continues, till 40 seconds is up. > > As to why it is this way, i dont know ( not a windoz maven ); > Also the sleep(20) in the loop is not so intuitive to suggest 2 seconds > of sleep. I would have guessed 20seconds, or 20milliseconds. But go figure. > > BTW: Since your computer sends you error messages in French, does it > curse in English? :)))) > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 06:11:43 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 08:11:43 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181204864.3501.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> Message-ID: <4667F5FF.8070903@gatworks.com> your suggestion appears good. I dont know what displayDialogBox exactly will do, so all I can say it that it looks good. But I'd like to wait 10min before first dialog box And a 5 min wait for every dialog box there after. And since these are custom solution/choices, maybe a more exact explanation of what the issue is. if(errorCount++ < 300){ // wait 10min ( 10min * 60sec / 2 ) Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } if(displayDialogBox("Printer has Paused. Retry sending data?")){ errorCount = 150; // Wait for 5 min thereafter continue; } > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } yves pielusenet wrote: > Maybe in my case I should re-compile rxtx and change the code. Instead > of send an exception I should display a dialog box to ask if it's > printer problem or if it should trie to send bytes. Something like : > > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > > if(displayDialogBox("Try again to send datas ??")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > } > From yvespielusenet at free.fr Thu Jun 7 07:17:21 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Thu, 07 Jun 2007 15:17:21 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4667F5FF.8070903@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <4667F5FF.8070903@gatworks.com> Message-ID: <1181222241.3501.20.camel@localhost.localdomain> thank you :) 'displayDialogBox()' I think doesn't exist. It was just for the example :) But I think It should not be so complicated to display a dialog box under windows with YES/NO buttons. When yes is clicked it return 0 other it returns 1. Le jeudi 07 juin 2007 ? 08:11 -0400, Uncle George a ?crit : > your suggestion appears good. I dont know what displayDialogBox exactly > will do, so all I can say it that it looks good. > > But I'd like to wait 10min before first dialog box And a 5 min wait for > every dialog box there after. And since these are custom > solution/choices, maybe a more exact explanation of what the issue is. > > if(errorCount++ < 300){ // wait 10min ( 10min * 60sec / 2 ) > Sleep( 20 ); /* make a small pause to execute all other requests > in all other threads */ > continue; > } > > if(displayDialogBox("Printer has Paused. Retry sending data?")){ > errorCount = 150; // Wait for 5 min thereafter > continue; > } > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > > yves pielusenet wrote: > > Maybe in my case I should re-compile rxtx and change the code. Instead > > of send an exception I should display a dialog box to ask if it's > > printer problem or if it should trie to send bytes. Something like : > > > > while( count > 0 ){ > > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > > /* > > this are 20 * 2 seconds, in this time a printer (or other parallel device) > > should solv all problems like buffer full, etc > > */ > > if(errorCount++ < 20){ > > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > > continue; > > } > > > > if(displayDialogBox("Try again to send datas ??")){ > > errorCount = 0; > > } > > else{ > > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > > break; > > } > > } > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 07:41:43 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 09:41:43 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181222241.3501.20.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <4667F5FF.8070903@gatworks.com> <1181222241.3501.20.camel@localhost.localdomain> Message-ID: <46680B17.8050109@gatworks.com> yves pielusenet wrote: > thank you :) > 'displayDialogBox()' I think doesn't exist. It was just for the > example :) too bad. Good luck. From rtrout at webbresearch.com Thu Jun 7 11:23:04 2007 From: rtrout at webbresearch.com (Robert Trout) Date: Thu, 07 Jun 2007 13:23:04 -0400 Subject: [Rxtx] Disconnected PortServer TS causes Java to hang Message-ID: <1181236984.14186.33.camel@sisyphus.DinkumSoftware.com> I'm running Linux with sun's Java 1.4.2, Java comm API 2.0, RXTX 2.0-7pre1, and the RealPort digi driver. "/dev/ttyrp00" is a RealPort device. My Java application never returns from a ComPortIdentifier.getPortIdentifier("/dev/ttyrp00") call while the Digi PortServer TS 4 is disconnected from the network. If I later re-connect the PortServer, the call returns about 30 seconds later (it's like a serial port read or write is blocking until the PortServer is re- connected). With the PortServer disconnected, minicom immediately responds with "cannot open /dev/ttyrp00: No such file or directory". I would like my Java application to behave similarly. That is, respond with an error condition instead of hanging when the PortServer is not connected. Since minicom and Java behave differently, I think this "hanging" behavior may be due to RXTX or Java? Has anyone had a similar issue? Solutions? Suggestions? Thanks, Robert From vicnevicne at gmail.com Thu Jun 7 12:16:02 2007 From: vicnevicne at gmail.com (Vicne) Date: Thu, 07 Jun 2007 20:16:02 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181204864.3501.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> Message-ID: <46684B62.7080802@gmail.com> yves pielusenet wrote: > Maybe in my case I should re-compile rxtx and change the code. Instead > of send an exception I should display a dialog box to ask if it's > printer problem or if it should trie to send bytes. Something like : > > while( count > 0 ){ > if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ > /* > this are 20 * 2 seconds, in this time a printer (or other parallel device) > should solv all problems like buffer full, etc > */ > if(errorCount++ < 20){ > Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ > continue; > } > > if(displayDialogBox("Try again to send datas ??")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > } > Sorry to step in without a specific solution to your problem, but I wanted to share my feeling regarding this proposal. AFAIK, it's generally considered bad practice to pop-up a prompt from a library. The main reason is that in general use, you can't guarantee that someone is actually present behind the console. Imagine a print server in a machine room, connected to a park of printers. In that case, when one printer fails, the logical behaviour would be to use an other one. If you change RxTx the way you propose, the printer queue will simply be stuck with a useless "Try again to send data ?" prompt until an administrator opens a remote connection to the print server's console and clicks "no". Second, it would create a dependency upon the existence of a graphical console (if you go the graphical "dialogBox" way). On many applications (typically server or embedded ones), the JVM is "headless" and if you try to pop-up a dialog, your app would throw an exception (at best) or just wouldn't display the prompt anywhere... Going the "text console" way is not more reliable, because on graphical environments, the text console is hidden unless explicitly requested. My advice would be to think again and find another solution. Ideas are : - make the number of retries a parameter so that you can tune it to what you think is reasonable - throw a more specific exception when the number of retries has been reached, so that a specific prompt can be shown at a higher level Anyway, if you feel that the prompt is the way to go in your case, I would at least make that prompt conditional. The least intrusive way would probably be using a system property, like if("true".equals(System.getProperty("org.rxtx.usePrompt")) && displayDialogBox("Retry sending data ?")){ errorCount = 0; } else{ throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } By default, the behaviour would remain as it is now, but you could force the prompts by defining the property at VM launch if desired. (for example : java.exe -Dorg.rxtx.usePrompt=true myApp) Also, you seemed to say you wanted the printer to start again exactly where is stopped. It would indeed be the best way when the printer is put offline for a few seconds. On the other hand, if the printer is turned off (or the printer runs out of paper, or someone steps on the mains cable), then the only way to go back to a "stable" situation would be by printing the item (page, label, etc.) again from scratch... Just my two cents. Vicne PS : By the way, the dialog box thing is very platform dependant on the C-side, and I think the simplest way would probably be to bridge it to a Java call where you can implement it like you proposed : public boolean displayDialogBox(prompt) { return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); } From netbeans at gatworks.com Thu Jun 7 14:08:24 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 16:08:24 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46684B62.7080802@gmail.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> Message-ID: <466865B8.4060004@gatworks.com> My feeling is that the code that was suggested was for his environs ( his shop ). The issue here is that after a 40+ second wait, an exception will be thrown. But you really dont have a way of 'cancelling' all the WriteFiles() that have already occured before the exception so that your writeArray and the Commapi can backtrack to a position in which they are in sync. The main ( really mine ) concern is not to lose data, or replicate data. After 40seconds, 300 seconds, 55min, no matter how long, data should not be lost or duplicated. But as soon as the exception is thrown, that possibility exists. Maybe an event should be thrown instead? Vicne wrote: > yves pielusenet wrote: >> Maybe in my case I should re-compile rxtx and change the code. Instead >> of send an exception I should display a dialog box to ask if it's >> printer problem or if it should trie to send bytes. Something like : >> >> while( count > 0 ){ >> if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ >> /* >> this are 20 * 2 seconds, in this time a printer (or other parallel device) >> should solv all problems like buffer full, etc >> */ >> if(errorCount++ < 20){ >> Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ >> continue; >> } >> >> if(displayDialogBox("Try again to send datas ??")){ >> errorCount = 0; >> } >> else{ >> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >> break; >> } >> } >> > > Sorry to step in without a specific solution to your problem, but I > wanted to share my feeling regarding this proposal. AFAIK, it's > generally considered bad practice to pop-up a prompt from a library. > The main reason is that in general use, you can't guarantee that > someone is actually present behind the console. Imagine a print server > in a machine room, connected to a park of printers. In that case, when > one printer fails, the logical behaviour would be to use an other one. > If you change RxTx the way you propose, the printer queue will simply be > stuck with a useless "Try again to send data ?" prompt until an > administrator opens a remote connection to the print server's console > and clicks "no". > Second, it would create a dependency upon the existence of a > graphical console (if you go the graphical "dialogBox" way). On many > applications (typically server or embedded ones), the JVM is "headless" > and if you try to pop-up a dialog, your app would throw an exception (at > best) or just wouldn't display the prompt anywhere... Going the "text > console" way is not more reliable, because on graphical environments, > the text console is hidden unless explicitly requested. > > My advice would be to think again and find another solution. Ideas are : > - make the number of retries a parameter so that you can tune it to what > you think is reasonable > - throw a more specific exception when the number of retries has been > reached, so that a specific prompt can be shown at a higher level > > Anyway, if you feel that the prompt is the way to go in your case, I > would at least make that prompt conditional. The least intrusive way > would probably be using a system property, like > > if("true".equals(System.getProperty("org.rxtx.usePrompt")) > && displayDialogBox("Retry sending data ?")){ > errorCount = 0; > } > else{ > throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); > break; > } > > > By default, the behaviour would remain as it is now, but you could > force the prompts by defining the property at VM launch if desired. (for > example : java.exe -Dorg.rxtx.usePrompt=true myApp) > > > Also, you seemed to say you wanted the printer to start again > exactly where is stopped. It would indeed be the best way when the > printer is put offline for a few seconds. On the other hand, if the > printer is turned off (or the printer runs out of paper, or someone > steps on the mains cable), then the only way to go back to a "stable" > situation would be by printing the item (page, label, etc.) again from > scratch... > > > Just my two cents. > > > Vicne > > PS : By the way, the dialog box thing is very platform dependant on the > C-side, and I think the simplest way would probably be to bridge it to a > Java call where you can implement it like you proposed : > > public boolean displayDialogBox(prompt) { > return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", > JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); > } > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From tjarvi at qbang.org Thu Jun 7 17:48:11 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 7 Jun 2007 17:48:11 -0600 (MDT) Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <466865B8.4060004@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> Message-ID: An event is possible. I'm amazed this is the largest problem encountered while using the parallel code. How would the write ever exit if we throw events? Isn't this going to lead to hung applications? On Thu, 7 Jun 2007, Uncle George wrote: > My feeling is that the code that was suggested was for his environs ( > his shop ). > > The issue here is that after a 40+ second wait, an exception will be > thrown. But you really dont have a way of 'cancelling' all the > WriteFiles() that have already occured before the exception so that your > writeArray and the Commapi can backtrack to a position in which they are > in sync. > > The main ( really mine ) concern is not to lose data, or replicate data. > After 40seconds, 300 seconds, 55min, no matter how long, data should > not be lost or duplicated. But as soon as the exception is thrown, that > possibility exists. > > Maybe an event should be thrown instead? > > Vicne wrote: >> yves pielusenet wrote: >>> Maybe in my case I should re-compile rxtx and change the code. Instead >>> of send an exception I should display a dialog box to ask if it's >>> printer problem or if it should trie to send bytes. Something like : >>> >>> while( count > 0 ){ >>> if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ >>> /* >>> this are 20 * 2 seconds, in this time a printer (or other parallel device) >>> should solv all problems like buffer full, etc >>> */ >>> if(errorCount++ < 20){ >>> Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ >>> continue; >>> } >>> >>> if(displayDialogBox("Try again to send datas ??")){ >>> errorCount = 0; >>> } >>> else{ >>> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >>> break; >>> } >>> } >>> >> >> Sorry to step in without a specific solution to your problem, but I >> wanted to share my feeling regarding this proposal. AFAIK, it's >> generally considered bad practice to pop-up a prompt from a library. >> The main reason is that in general use, you can't guarantee that >> someone is actually present behind the console. Imagine a print server >> in a machine room, connected to a park of printers. In that case, when >> one printer fails, the logical behaviour would be to use an other one. >> If you change RxTx the way you propose, the printer queue will simply be >> stuck with a useless "Try again to send data ?" prompt until an >> administrator opens a remote connection to the print server's console >> and clicks "no". >> Second, it would create a dependency upon the existence of a >> graphical console (if you go the graphical "dialogBox" way). On many >> applications (typically server or embedded ones), the JVM is "headless" >> and if you try to pop-up a dialog, your app would throw an exception (at >> best) or just wouldn't display the prompt anywhere... Going the "text >> console" way is not more reliable, because on graphical environments, >> the text console is hidden unless explicitly requested. >> >> My advice would be to think again and find another solution. Ideas are : >> - make the number of retries a parameter so that you can tune it to what >> you think is reasonable >> - throw a more specific exception when the number of retries has been >> reached, so that a specific prompt can be shown at a higher level >> >> Anyway, if you feel that the prompt is the way to go in your case, I >> would at least make that prompt conditional. The least intrusive way >> would probably be using a system property, like >> >> if("true".equals(System.getProperty("org.rxtx.usePrompt")) >> && displayDialogBox("Retry sending data ?")){ >> errorCount = 0; >> } >> else{ >> throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); >> break; >> } >> >> >> By default, the behaviour would remain as it is now, but you could >> force the prompts by defining the property at VM launch if desired. (for >> example : java.exe -Dorg.rxtx.usePrompt=true myApp) >> >> >> Also, you seemed to say you wanted the printer to start again >> exactly where is stopped. It would indeed be the best way when the >> printer is put offline for a few seconds. On the other hand, if the >> printer is turned off (or the printer runs out of paper, or someone >> steps on the mains cable), then the only way to go back to a "stable" >> situation would be by printing the item (page, label, etc.) again from >> scratch... >> >> >> Just my two cents. >> >> >> Vicne >> >> PS : By the way, the dialog box thing is very platform dependant on the >> C-side, and I think the simplest way would probably be to bridge it to a >> Java call where you can implement it like you proposed : >> >> public boolean displayDialogBox(prompt) { >> return (JOptionPane.showConfirmDialog(null, prompt, "RxTx", >> JOptionPane.YES_NO_OPTION) == JOptionPane.YES_OPTION); >> } >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Thu Jun 7 19:18:51 2007 From: netbeans at gatworks.com (Uncle George) Date: Thu, 07 Jun 2007 21:18:51 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> Message-ID: <4668AE7B.3060409@gatworks.com> The UNIX version of writeArray is not too great either. It is possible that the write will only process some of the bytes. #else if( write( fd, bytes, count ) < 0 ) throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); #endif -------------------------------- Maybe it might be better to have the native function inform the caller of the # of characters written, then the commapi/output-buffer can be modified to reflect the #of chars written. If an exception is to be thrown, for too many loops of chars written == 0, then exception wont affect the state of the output buffer. Then a ParallelPort.restart() can be called to resume printing whats in the buffer. Trent Jarvi wrote: > An event is possible. I'm amazed this is the largest problem encountered > while using the parallel code. > > How would the write ever exit if we throw events? Isn't this going to > lead to hung applications? Sure. If you dont time out, then there is nothing that will force an EXIT from the write(). Issue is what has the OS done with the write. > > On Thu, 7 Jun 2007, Uncle George wrote: > >> My feeling is that the code that was suggested was for his environs ( >> his shop ). From yvespielusenet at free.fr Fri Jun 8 01:09:01 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Fri, 08 Jun 2007 09:09:01 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <4668AE7B.3060409@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> Message-ID: <1181286541.3674.10.camel@localhost.localdomain> It is not possible that the rxtx java method write(byte[], int offset, int length) return anint which contains the number of byte really send to the printer instead of an exception ? So this is the programm which will see if all bytes have been sent. If not it can retry to send the unsended bytes. -------------------------------------------------------- int sended = 0; while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ sended += countWritten; /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } return sended; /*throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break;*/ } ... ... return countWritten; ------------------------------------------------ Le jeudi 07 juin 2007 ? 21:18 -0400, Uncle George a ?crit : > The UNIX version of writeArray is not too great either. It is possible > that the write will only process some of the bytes. > > #else > if( write( fd, bytes, count ) < 0 ) > throw_java_exception_system_msg( env, IO_EXCEPTION, > "writeArray" ); > #endif > -------------------------------- > > Maybe it might be better to have the native function inform the caller > of the # of characters written, then the commapi/output-buffer can be > modified to reflect the #of chars written. If an exception is to be > thrown, for too many loops of chars written == 0, then exception wont > affect the state of the output buffer. Then a ParallelPort.restart() can > be called to resume printing whats in the buffer. > > > Trent Jarvi wrote: > > An event is possible. I'm amazed this is the largest problem encountered > > while using the parallel code. > > > > How would the write ever exit if we throw events? Isn't this going to > > lead to hung applications? > Sure. If you dont time out, then there is nothing that will force an > EXIT from the write(). Issue is what has the OS done with the write. > > > > On Thu, 7 Jun 2007, Uncle George wrote: > > > >> My feeling is that the code that was suggested was for his environs ( > >> his shop ). > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From Steffen.DETTMER at ingenico.com Fri Jun 8 03:45:00 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 11:45:00 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181286541.3674.10.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> Message-ID: <20070608094500.GC21069@elberon.bln.de.ingenico.com> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > It is not possible that the rxtx java method write(byte[], int offset, > int length) return anint which contains the number of byte really send > to the printer instead of an exception ? > So this is the programm which will see if all bytes have been sent. If > not it can retry to send the unsended bytes. I think write() is void because in Java people love to do this since OutputStream :-) Of course on such interfaces you cannot implement something nice. If you would have a int write, you would not implement the interface and no applications expecting this interface would link/work/compile. oki, Steffen P.S.: (OT) If you propose not to implement the Java interfaces (especially not on JNI level), maybe optionally offering a wrapper that removes e.g. the write return value and so on to downgrade the powerful classic old POSIX read/write style to the modern limited Java style, then I agree :-) Same for read. Instead of things like "int avialable()" it is more powerful to have an approach as select(2) offers (to guarante the caller that read/write will not block [nothing else make sense anyway IMHO] but may read/write less bytes then requested). The caller gets full control and the higher level protocols can care about timeouts, invoking read in some loops and/or implement retransmission. On top of such an implementation, where everything is controlled, defined, guaranteed and reliable, someone could use an InputStream or OutputStream style interface. Or even better: don't use them at all :) just BTW :-) St. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From yvespielusenet at free.fr Fri Jun 8 05:52:45 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Fri, 08 Jun 2007 13:52:45 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <20070608094500.GC21069@elberon.bln.de.ingenico.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> Message-ID: <1181303565.11203.3.camel@localhost.localdomain> So maybe a better way should be to create a new Exception class which has a method "int getWrittenByte()". So the Exception should be use to send again bytes which are not printed yet. yves Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : > * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > > It is not possible that the rxtx java method write(byte[], int offset, > > int length) return anint which contains the number of byte really send > > to the printer instead of an exception ? > > So this is the programm which will see if all bytes have been sent. If > > not it can retry to send the unsended bytes. > > I think write() is void because in Java people love to do this > since OutputStream :-) Of course on such interfaces you cannot > implement something nice. If you would have a int write, you > would not implement the interface and no applications expecting > this interface would link/work/compile. > > oki, > > Steffen > > P.S.: (OT) > If you propose not to implement the Java interfaces (especially > not on JNI level), maybe optionally offering a wrapper that > removes e.g. the write return value and so on to downgrade the > powerful classic old POSIX read/write style to the modern limited > Java style, then I agree :-) Same for read. Instead of things > like "int avialable()" it is more powerful to have an approach as > select(2) offers (to guarante the caller that read/write will not > block [nothing else make sense anyway IMHO] but may read/write > less bytes then requested). The caller gets full control and the > higher level protocols can care about timeouts, invoking read in > some loops and/or implement retransmission. On top of such an > implementation, where everything is controlled, defined, > guaranteed and reliable, someone could use an InputStream or > OutputStream style interface. Or even better: don't use them at > all :) just BTW :-) > St. > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > 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. > > About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. > 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. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From netbeans at gatworks.com Fri Jun 8 06:46:21 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 08:46:21 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1181303565.11203.3.camel@localhost.localdomain> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> Message-ID: <46694F9D.5080501@gatworks.com> It seems that with outputstream.write(b[]), you become terribly uncoordinated as soon as an exception is thrown. Docs do not say what happens to the data. Yet from a practicable point of view, one would like to know if the write was accepted in-full, or rejected before any writes. There are no in betweens, as partial writes are not reportable. So for an outputstream.write(), in order for it to return, the full write request has to be taken, and stored in an internal output buffer. If there is no room, the write() is suspended, till there is room. Or throw's an IOException( "no room in buffer") ; As the select() loop for write reports buffer room avail, then more of the internal buffer is sent to the printer. yves pielusenet wrote: > So maybe a better way should be to create a new Exception class which > has a method "int getWrittenByte()". So the Exception should be use to > send again bytes which are not printed yet. > > yves > > Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : >> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: >>> It is not possible that the rxtx java method write(byte[], int offset, >>> int length) return anint which contains the number of byte really send >>> to the printer instead of an exception ? >>> So this is the programm which will see if all bytes have been sent. If >>> not it can retry to send the unsended bytes. >> I think write() is void because in Java people love to do this >> since OutputStream :-) Of course on such interfaces you cannot >> implement something nice. If you would have a int write, you >> would not implement the interface and no applications expecting >> this interface would link/work/compile. >> >> oki, >> >> Steffen >> >> P.S.: (OT) >> If you propose not to implement the Java interfaces (especially >> not on JNI level), maybe optionally offering a wrapper that >> removes e.g. the write return value and so on to downgrade the >> powerful classic old POSIX read/write style to the modern limited >> Java style, then I agree :-) Same for read. Instead of things >> like "int avialable()" it is more powerful to have an approach as >> select(2) offers (to guarante the caller that read/write will not >> block [nothing else make sense anyway IMHO] but may read/write >> less bytes then requested). The caller gets full control and the >> higher level protocols can care about timeouts, invoking read in >> some loops and/or implement retransmission. On top of such an >> implementation, where everything is controlled, defined, >> guaranteed and reliable, someone could use an InputStream or >> OutputStream style interface. Or even better: don't use them at >> all :) just BTW :-) >> St. >> >> About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. >> 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. >> >> About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. >> 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. >> >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx >> > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From Steffen.DETTMER at ingenico.com Fri Jun 8 08:12:18 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 16:12:18 +0200 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <46694F9D.5080501@gatworks.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: <20070608141218.GE21069@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 08:46 -0400: > It seems that with outputstream.write(b[]), you become terribly > uncoordinated as soon as an exception is thrown. Docs do not say what > happens to the data. (yes, so avoiding it seems to be good :)) > Yet from a practicable point of view, one would like to know if the > write was accepted in-full, or rejected before any writes. There are no > in betweens, as partial writes are not reportable. (which is an artificial API limitation. I never understood how this happend when they invented JDK because the well-known BSD socket API and thus [probably] WinSock does this correct, but anyway) > So for an outputstream.write(), in order for it to return, the full > write request has to be taken, and stored in an internal output buffer. > If there is no room, the write() is suspended, till there is room. Or > throw's an IOException( "no room in buffer") ; As the select() loop for > write reports buffer room avail, then more of the internal buffer is > sent to the printer. yes, might be good in case of a printer. May be horrible in case of PPP/TCP or some other transmission control protocol which may e.g. repeat data or even omit parts of it (e.g. internet realtime radio station broadcasting)... So I think the idea of "int write" (e.g. BSD sockets, linux files and so on) still is the best. A clean API / implementation should guarantee and allow implementations (users) to rely on that; assumptions and automatic background-sending and so on may look pragmatic and may even work on the first look, but may fail in other situations. BTW, if e.g. BSD socket API is known, why not simply copy it (until something better is invented :)) instead of fiddling around with JDK APIs? anyway, have a nice weekend everyone :-) oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Fri Jun 8 08:55:56 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 10:55:56 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070608141218.GE21069@elberon.bln.de.ingenico.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> Message-ID: <46696DFC.7000801@gatworks.com> >> write reports buffer room avail, then more of the internal buffer is >> sent to the printer. > > yes, might be good in case of a printer. May be horrible in case > of PPP/TCP or some other transmission control protocol which > may e.g. repeat data or even omit parts of it (e.g. internet > realtime radio station broadcasting)... So I think the idea of > "int write" (e.g. BSD sockets, linux files and so on) still is > the best. A clean API / implementation should guarantee and allow > implementations (users) to rely on that; assumptions and > automatic background-sending and so on may look pragmatic and may > even work on the first look, but may fail in other situations. > BTW, if e.g. BSD socket API is known, why not simply copy it > (until something better is invented :)) instead of fiddling > around with JDK APIs? But we were talking about the Parallel Port, and the transmission of data over the commapi/parallel-port schema. There isn't much in bi-directional software communication. Its a simple write one byte at a time interface. I'm not looking to change the comm-api. I'm just looking to alter the interaction between the Native ParallelPort functions, and the java ParallelPort functions that call them. This might be more readily doable than to get a committee to re-specify java-API specs. BTW: Whats is off-topic? ( help: not looking for def of off-topic ) From j.kenneth.gentle at acm.org Fri Jun 8 08:58:59 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Fri, 08 Jun 2007 10:58:59 -0400 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <20070608141218.GE21069@elberon.bln.de.ingenico.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> Message-ID: <200706081459.l58Ex5rA019991@qbang.org> Perhaps it is a bit late to jump in on this one, but here goes anyway. If the solutions all seem to "break" the contract with "java.io.outputstream", then, as noted, that may not be the appropriate contract. At the risk of being heretical, JDK1.4 introduced the "nio" package to address some of the compatibility issues with C apis mentioned in previous posts. The interface "java.nio.channels.WriteableByteChannel" defines the following single method: int write(ByteBuffer source); int, strangely enough, is the actual number of bytes written. So, if RXTX as written, against the JavaCOMM api and OutputStream, doesn't do what we want, how about writing a different set of bindings using the java.nio classes and as much of the underlying native code as possible. Note that just because the java.nio.channels.WriteableByteChannel sends back a result, OutputStream.write doesn't have to - and they could both call the same underlying native code. My 2 cents - maybe not worth even that... Ken From netbeans at gatworks.com Fri Jun 8 10:37:28 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 12:37:28 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <200706081459.l58Ex5rA019991@qbang.org> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> Message-ID: <466985C8.8000505@gatworks.com> Ken Gentle wrote: > Perhaps it is a bit late to jump in on this one, but here goes anyway. Common in, the waters fine. > > If the solutions all seem to "break" the contract with > "java.io.outputstream", then, as noted, that may not be the > appropriate contract. > How would the contract be broken? The machinery underneath is handling the contract. From j.kenneth.gentle at acm.org Fri Jun 8 10:48:01 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Fri, 08 Jun 2007 12:48:01 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466985C8.8000505@gatworks.com> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> Message-ID: <200706081648.l58Gm7YA022904@qbang.org> At 12:37 2007-06-08, you wrote: >Ken Gentle wrote: > > > > If the solutions all seem to "break" the contract with > > "java.io.outputstream", then, as noted, that may not be the > > appropriate contract. > > >How would the contract be broken? The machinery underneath is handling >the contract. It seems that a lot of the discussion has been about not only the timeout and being able to adjust it in the "machinery layer", but also about knowing in the Java layer, in the event of a timeout or exception, how many characters have been written to the device. An OutputStream won't ever do this with out an extension and including a return value "breaks" the contract, right? So, go with a Java IO api that *does* return the number of bytes written, out of the NIO package. I know it doesn't allow for a strict implementation of the JavaCOMM API - however, using NIO classes in place of the IO classes isn't that big a break and would allow those applications that need such information a way to get it. Maybe I'm misunderstanding the problem... Ken From netbeans at gatworks.com Fri Jun 8 11:24:14 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 08 Jun 2007 13:24:14 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <200706081648.l58Gm7YA022904@qbang.org> References: <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> Message-ID: <466990BE.7040100@gatworks.com> Ken Gentle wrote: An > OutputStream won't ever do this with out an extension and including a > return value "breaks" the contract, right? > i was not thinking of change the API to OutputSream. Are there specs for how output stream should work internally? for instance: String data = "Hello this is a line of data"; Outputstream.write( data.getbytes() ); ParallelPort.suspend(); int free = ParallelPort.getoutputbufferfree(); There is a symbiotic relationship between outputstream and the functionality of ParallelPort. From Steffen.DETTMER at ingenico.com Fri Jun 8 11:15:39 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 19:15:39 +0200 Subject: [Rxtx] [OT] select :-) (was: Re: [PARALLEL] resource in use) In-Reply-To: <200706081459.l58Ex5rA019991@qbang.org> References: <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> Message-ID: <20070608171539.GK21069@elberon.bln.de.ingenico.com> * Ken Gentle wrote on Fri, Jun 08, 2007 at 10:58 -0400: > If the solutions all seem to "break" the contract with > "java.io.outputstream", then, as noted, that may not be the > appropriate contract. > > At the risk of being heretical, JDK1.4 introduced the "nio" package > to address some of the compatibility issues with C apis mentioned in > previous posts. The interface > "java.nio.channels.WriteableByteChannel" defines the following single method: > > int write(ByteBuffer source); > > int, strangely enough, is the actual number of bytes written. Yes, AFAIK one of the motivations for the NIO interface was, that the JDK-1.3 APIs (InputStream, e.g.) were not powerfull enough, especially for multi-connection-TCP servers or so. I don't know much about it but I've heard of a project where NIO usage was removed because of stability issues in multi-threaded environments and performance limitations under some circumstances. IIRC the "nio.ByteBuffer" is something very special (namely something you cannot implement in Java, it is "magic" or part of the language itself). Not sure if this is such a great idea (but for performance in the end sometimes heavy prices must be paid) :) > So, if RXTX as written, against the JavaCOMM api and OutputStream, > doesn't do what we want, how about writing a different set of > bindings using the java.nio classes and as much of the underlying > native code as possible. Yes, this would be an idea: use a full-featured interface on JNI, and, if wanted, deliver some wrappers converting this to a less-featured Java-compliant interface. However, powerful things as e.g. "select" are difficult to "emulate" if you are e.g. on some (older?) windows. But if you expose the full-featured APIs, you need to emulate them full-featured, theoretically. In the end it depends what you do on the serial line. If you just want to talk to a modem, then you may not need precise timeouts. But if you need to implement complexer protocols which define response times and timeouts, you may quickly get into difficulties. For instance, AFAIK, rxtx 1.7.2 (?) for windows is very messy with timeouts (there is a maximum, higher values are truncated; resolution is 100ms only; the function may take up to twice the timeout because internally it may be called twice). Probably for most people this is OK, but probably not for all. But having precise timeouts should be OK for all :-) Well, in the end it is nice to wish but somewhat hard to implement (many platforms, connections, USB, BlueTooth, whatever). oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Steffen.DETTMER at ingenico.com Fri Jun 8 11:04:22 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Fri, 8 Jun 2007 19:04:22 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <46696DFC.7000801@gatworks.com> References: <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <46696DFC.7000801@gatworks.com> Message-ID: <20070608170422.GJ21069@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 10:55 -0400: > > BTW, if e.g. BSD socket API is known, why not simply copy it > > (until something better is invented :)) instead of fiddling > > around with JDK APIs? > > But we were talking about the Parallel Port, and the > transmission of data over the commapi/parallel-port schema. > There isn't much in bi-directional software communication. Its > a simple write one byte at a time interface. First, there are things like PLIP (http://en.wikipedia.org/wiki/Plip) - well, probably not widely used, sure ;) Second, I think if there is a good simple API known to support all that (with known "best practices") or so and there is no forcing need to invent a new one, why not simply using it? > I'm not looking to change the comm-api. I'm just looking to > alter the interaction between the Native ParallelPort > functions, and the java ParallelPort functions that call them. Ahh, yes. I think this is what I tried to ask. Having an usable JNI interface and on top (in pure java) some wrapper to InputStream or whatever could be done (e.g. by ignoring the return value of write or throwing if != length). Developers could then use the full-featured (non-JAVA-standard) API or select among various wrappers (as InputStream). > This might be more readily doable than to get a committee to > re-specify java-API specs. Yes, of course. I'm afraid that the Java APIs change regularily, but still yet with limited success it seems, so maybe they get it in one of the next iterations; who knows, maybe Java-9 has a BSD-like socket API :) SCNR. > BTW: Whats is off-topic? ( help: not looking for def of > off-topic ) I think I started some "re-specify java-API specs" which was OT probably. oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From lists at iDIAcomputing.com Fri Jun 8 18:48:54 2007 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Fri, 08 Jun 2007 20:48:54 -0400 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46684B62.7080802@gmail.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> Message-ID: <4669F8F6.3040101@iDIAcomputing.com> Vicne wrote: > Sorry to step in without a specific solution to your problem, but I > wanted to share my feeling regarding this proposal. AFAIK, it's > generally considered bad practice to pop-up a prompt from a library. ... > > My advice would be to think again and find another solution. Ideas are : > - make the number of retries a parameter so that you can tune it to what > you think is reasonable > - throw a more specific exception when the number of retries has been > reached, so that a specific prompt can be shown at a higher level You could also allow the client code to register a callback class which returns a boolean indicating whether to retry or cancel. This callback class could pop up a dialog, if appropriate, or follow some preset policy, or.... - George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From joachim at buechse.ch Sat Jun 9 09:43:16 2007 From: joachim at buechse.ch (Joachim Buechse) Date: Sat, 9 Jun 2007 17:43:16 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <46694F9D.5080501@gatworks.com> References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: You should not forget, that in the case of an exception it may not even be known what happened to the data. You have a kernel buffer, outgoing chip buffer, incoming chip buffer, etc. So of course, it would be nice to know up to which point data was correctly processed, but this feedback does not exist on the hardware or protocol level and hence can in general not be magicly created on the software level... Regards, Joachim On 08.06.2007, at 14:46, Uncle George wrote: > It seems that with outputstream.write(b[]), you become terribly > uncoordinated as soon as an exception is thrown. Docs do not say what > happens to the data. > > Yet from a practicable point of view, one would like to know if the > write was accepted in-full, or rejected before any writes. There > are no > in betweens, as partial writes are not reportable. > > So for an outputstream.write(), in order for it to return, the full > write request has to be taken, and stored in an internal output > buffer. > If there is no room, the write() is suspended, till there is room. Or > throw's an IOException( "no room in buffer") ; As the select() loop > for > write reports buffer room avail, then more of the internal buffer is > sent to the printer. > > > > yves pielusenet wrote: >> So maybe a better way should be to create a new Exception class which >> has a method "int getWrittenByte()". So the Exception should be >> use to >> send again bytes which are not printed yet. >> >> yves >> >> Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : >>> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: >>>> It is not possible that the rxtx java method write(byte[], int >>>> offset, >>>> int length) return anint which contains the number of byte >>>> really send >>>> to the printer instead of an exception ? >>>> So this is the programm which will see if all bytes have been >>>> sent. If >>>> not it can retry to send the unsended bytes. >>> I think write() is void because in Java people love to do this >>> since OutputStream :-) Of course on such interfaces you cannot >>> implement something nice. If you would have a int write, you >>> would not implement the interface and no applications expecting >>> this interface would link/work/compile. >>> >>> oki, >>> >>> Steffen >>> >>> P.S.: (OT) >>> If you propose not to implement the Java interfaces (especially >>> not on JNI level), maybe optionally offering a wrapper that >>> removes e.g. the write return value and so on to downgrade the >>> powerful classic old POSIX read/write style to the modern limited >>> Java style, then I agree :-) Same for read. Instead of things >>> like "int avialable()" it is more powerful to have an approach as >>> select(2) offers (to guarante the caller that read/write will not >>> block [nothing else make sense anyway IMHO] but may read/write >>> less bytes then requested). The caller gets full control and the >>> higher level protocols can care about timeouts, invoking read in >>> some loops and/or implement retransmission. On top of such an >>> implementation, where everything is controlled, defined, >>> guaranteed and reliable, someone could use an InputStream or >>> OutputStream style interface. Or even better: don't use them at >>> all :) just BTW :-) >>> St. >>> >>> About Ingenico Throughout the world businesses rely on Ingenico >>> for secure and expedient electronic transaction acceptance. >>> Ingenico products leverage proven technology, established >>> standards and unparalleled ergonomics to provide optimal >>> reliability, versatility and usability. This comprehensive range >>> of products is complemented by a global array of services and >>> partnerships, enabling businesses in a number of vertical sectors >>> to accept transactions anywhere their business takes them. >>> 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. >>> >>> About Ingenico Throughout the world businesses rely on Ingenico >>> for secure and expedient electronic transaction acceptance. >>> Ingenico products leverage proven technology, established >>> standards and unparalleled ergonomics to provide optimal >>> reliability, versatility and usability. This comprehensive range >>> of products is complemented by a global array of services and >>> partnerships, enabling businesses in a number of vertical sectors >>> to accept transactions anywhere their business takes them. >>> 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. >>> >>> _______________________________________________ >>> Rxtx mailing list >>> Rxtx 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 yvespielusenet at free.fr Mon Jun 11 03:15:12 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Mon, 11 Jun 2007 11:15:12 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: References: <1181141195.3407.20.camel@localhost.localdomain> <4666D10A.8000507@gatworks.com> <1181145205.3407.35.camel@localhost.localdomain> <4666E210.30507@gatworks.com> <1181204864.3501.10.camel@localhost.localdomain> <46684B62.7080802@gmail.com> <466865B8.4060004@gatworks.com> <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> Message-ID: <1181553312.8335.14.camel@localhost.localdomain> So can someone tell a solution for my problem :( Must I say to the user to not put the printer off-line ? I can't since he has to do some pauses, verify print, paper conditioning etc... How do other people ? Before I use the parport librarry to read port status : http://www.geocities.com/Juanga69/parport/ (which doesn't work on windows XP) And I send data into the file LPT1 I use to have no problem when printer was disabled. thanks -- yves piel Le samedi 09 juin 2007 ? 17:43 +0200, Joachim Buechse a ?crit : > You should not forget, that in the case of an exception it may not > even be known what happened to the data. > > You have a kernel buffer, outgoing chip buffer, incoming chip buffer, > etc. So of course, it would be nice to know up to which point data > was correctly processed, but this feedback does not exist on the > hardware or protocol level and hence can in general not be magicly > created on the software level... > > Regards, > Joachim > > On 08.06.2007, at 14:46, Uncle George wrote: > > > It seems that with outputstream.write(b[]), you become terribly > > uncoordinated as soon as an exception is thrown. Docs do not say what > > happens to the data. > > > > Yet from a practicable point of view, one would like to know if the > > write was accepted in-full, or rejected before any writes. There > > are no > > in betweens, as partial writes are not reportable. > > > > So for an outputstream.write(), in order for it to return, the full > > write request has to be taken, and stored in an internal output > > buffer. > > If there is no room, the write() is suspended, till there is room. Or > > throw's an IOException( "no room in buffer") ; As the select() loop > > for > > write reports buffer room avail, then more of the internal buffer is > > sent to the printer. > > > > > > > > yves pielusenet wrote: > >> So maybe a better way should be to create a new Exception class which > >> has a method "int getWrittenByte()". So the Exception should be > >> use to > >> send again bytes which are not printed yet. > >> > >> yves > >> > >> Le vendredi 08 juin 2007 ? 11:45 +0200, Steffen DETTMER a ?crit : > >>> * yves pielusenet wrote on Fri, Jun 08, 2007 at 09:09 +0200: > >>>> It is not possible that the rxtx java method write(byte[], int > >>>> offset, > >>>> int length) return anint which contains the number of byte > >>>> really send > >>>> to the printer instead of an exception ? > >>>> So this is the programm which will see if all bytes have been > >>>> sent. If > >>>> not it can retry to send the unsended bytes. > >>> I think write() is void because in Java people love to do this > >>> since OutputStream :-) Of course on such interfaces you cannot > >>> implement something nice. If you would have a int write, you > >>> would not implement the interface and no applications expecting > >>> this interface would link/work/compile. > >>> > >>> oki, > >>> > >>> Steffen > >>> > >>> P.S.: (OT) > >>> If you propose not to implement the Java interfaces (especially > >>> not on JNI level), maybe optionally offering a wrapper that > >>> removes e.g. the write return value and so on to downgrade the > >>> powerful classic old POSIX read/write style to the modern limited > >>> Java style, then I agree :-) Same for read. Instead of things > >>> like "int avialable()" it is more powerful to have an approach as > >>> select(2) offers (to guarante the caller that read/write will not > >>> block [nothing else make sense anyway IMHO] but may read/write > >>> less bytes then requested). The caller gets full control and the > >>> higher level protocols can care about timeouts, invoking read in > >>> some loops and/or implement retransmission. On top of such an > >>> implementation, where everything is controlled, defined, > >>> guaranteed and reliable, someone could use an InputStream or > >>> OutputStream style interface. Or even better: don't use them at > >>> all :) just BTW :-) > >>> St. > >>> > >>> About Ingenico Throughout the world businesses rely on Ingenico > >>> for secure and expedient electronic transaction acceptance. > >>> Ingenico products leverage proven technology, established > >>> standards and unparalleled ergonomics to provide optimal > >>> reliability, versatility and usability. This comprehensive range > >>> of products is complemented by a global array of services and > >>> partnerships, enabling businesses in a number of vertical sectors > >>> to accept transactions anywhere their business takes them. > >>> 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. > >>> > >>> About Ingenico Throughout the world businesses rely on Ingenico > >>> for secure and expedient electronic transaction acceptance. > >>> Ingenico products leverage proven technology, established > >>> standards and unparalleled ergonomics to provide optimal > >>> reliability, versatility and usability. This comprehensive range > >>> of products is complemented by a global array of services and > >>> partnerships, enabling businesses in a number of vertical sectors > >>> to accept transactions anywhere their business takes them. > >>> 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. > >>> > >>> _______________________________________________ > >>> Rxtx mailing list > >>> Rxtx 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 > From Steffen.DETTMER at ingenico.com Mon Jun 11 03:56:18 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 11:56:18 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466990BE.7040100@gatworks.com> References: <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> Message-ID: <20070611095618.GA10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Fri, Jun 08, 2007 at 13:24 -0400: > i was not thinking of change the API to OutputSream. Then I think either someone uses OutputStream (and has no reliable information about incomplete writes) or someone uses somethink else. > Are there specs for how output stream should work internally? > > for instance: > String data = "Hello this is a line of data"; > Outputstream.write( data.getbytes() ); > ParallelPort.suspend(); > int free = ParallelPort.getoutputbufferfree(); > > There is a symbiotic relationship between outputstream and the > functionality of ParallelPort. If you need OutputStream "plus something else", in short you're needing "something else". Personally I dislike the code above a lot. The stream "looks" like if it would be an OutputStream, but in fact it isn't. You need to call getoutputbufferfree later to check if write succeeded (but OutputStream promises that write succeedes synchronous, blocking, or throws an exception). So it is not an OutputStream. No application written for OutputStreams would work without change (because it won't know getoutputbufferfree at all). It is not abstracted from ParallelPort. I think this would be wrong. Then I think an alternative interface instead is better. Let's assume we had some "connection" (to distinguish between OutputStreams and Channels). Then why not working as on a file handle in POSIX: do { // ... select maybe using timer ... readyForWrite = ... if (readyForWrite) { int writtenBytes = connection.write(toWrite); toWrite.remove(0, writtenBytes); } while(readyForWrite && toWrite.length > 0); I think, having such a write isn't the big problem. I think, the difficult thing is around "select" - however this would look like. It should be OO, typesafe, performant, supporting multiple connections/channels/streams in various modes and should be orthogonal to other functionalities. Of course, this heavily depends on what the application is doing; for a simple situation (like reading a small, mandatory file from a local disk) this would be to uncomfortable (and offering unneeded features only). just BTW :) oki, Steffen -- // Modeline for VIM. Please don't remove. // (Help: autoindent, expandtab, shiftwidth=4, tabstop=4, textwidth=75) // vi: set ai et sw=4 ts=4 tw=75 ft=java: About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Mon Jun 11 05:38:33 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 07:38:33 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611095618.GA10821@elberon.bln.de.ingenico.com> References: <4668AE7B.3060409@gatworks.com> <1181286541.3674.10.camel@localhost.localdomain> <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> Message-ID: <466D3439.4020805@gatworks.com> Steffen DETTMER wrote: > (but OutputStream promises that write > succeedes synchronous, blocking, or throws an exception). Where is it so written? From Steffen.DETTMER at ingenico.com Mon Jun 11 06:36:50 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 14:36:50 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466D3439.4020805@gatworks.com> References: <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> <466D3439.4020805@gatworks.com> Message-ID: <20070611123650.GI10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Mon, Jun 11, 2007 at 07:38 -0400: > Steffen DETTMER wrote: > > > (but OutputStream promises that write > > succeedes synchronous, blocking, or throws an exception). > > Where is it so written? Now, as you ask, I think it is not written that clearly but follows from specification. mmm... Am I wrong? I understand the API doc in this way: * http://java.sun.com/j2se/1.4.2/docs/api/java/io/OutputStream.html#write(byte[]) > public void write(byte[] b) > throws IOException > > Writes b.length bytes from the specified byte array to this > output stream. The general contract for write(b) is that > it should have exactly the same effect as the call write(b, > 0, b.length). > > Parameters: > b - the data. > Throws: > IOException - if an I/O error occurs. > See Also: > write(byte[], int, int) and there is: > public void write(byte[] b, > int off, > int len) > throws IOException > > Writes len bytes from the specified byte array starting at > offset off to this output stream. The general contract for > write(b, off, len) is that some of the bytes in the array b > are written to the output stream in order; element b[off] > is the first byte written and b[off+len-1] is the last byte > written by this operation. > > The write method of OutputStream calls the write method of > one argument on each of the bytes to be written out. > Subclasses are encouraged to override this method and > provide a more efficient implementation. > > If b is null, a NullPointerException is thrown. > > If off is negative, or len is negative, or off+len is > greater than the length of the array b, then an > IndexOutOfBoundsException is thrown. > > Parameters: > b - the data. > off - the start offset in the data. > len - the number of bytes to write. > Throws: > IOException - if an I/O error occurs. In particular, an > IOException is thrown if the output stream is closed. In general, any specialisation (derived child class) must comform to this. So write in the end is specified (!) as "The write method ... calls the write method ... on each of the bytes to be written out". This is what must be implemented by ANY OutputStream. Of course, there is: "Subclasses are encouraged to override this method and provide a more efficient implementation." which IMHO does not contradict - the more efficient must behave in exactly the same way of course (just wasting less resources than a simple byte-by-byte write). So it does not matter here I think. The write that finally defines the behavior tells basically: > "Writes the specified byte to this output stream. The general > contract for write is that one byte is written to the output > stream. " > > Throws: > IOException - if an I/O error occurs. which IMHO is another way of saying "write writes the byte immediately and returns on success (only), otherwise an exception is thrown". Especially it cannot happen that zero bytes are written (i.e. the specified byte is NOT written) without an exception. So by this write must be synchronous and blocking, because otherwise it could not reliably know if an asynchronous operation will succeede or not (some getAsyncResult or so would be needed). Since write(byte[]) does this for each byte (or with a behavior beeing exactly the same as if it would do), I think this means that the write(byte[]) succeedes synchronous/blocking or throws an exception. Did I an error in reasoning or confused something or so? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From j.kenneth.gentle at acm.org Mon Jun 11 06:51:25 2007 From: j.kenneth.gentle at acm.org (Ken Gentle) Date: Mon, 11 Jun 2007 08:51:25 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611123650.GI10821@elberon.bln.de.ingenico.com> References: <20070608094500.GC21069@elberon.bln.de.ingenico.com> <1181303565.11203.3.camel@localhost.localdomain> <46694F9D.5080501@gatworks.com> <20070608141218.GE21069@elberon.bln.de.ingenico.com> <200706081459.l58Ex5rA019991@qbang.org> <466985C8.8000505@gatworks.com> <200706081648.l58Gm7YA022904@qbang.org> <466990BE.7040100@gatworks.com> <20070611095618.GA10821@elberon.bln.de.ingenico.com> <466D3439.4020805@gatworks.com> <20070611123650.GI10821@elberon.bln.de.ingenico.com> Message-ID: <200706111251.l5BCpS9T017831@qbang.org> It is as Steffen describes. "InputStream" and "OutputStream" are inherently synchronous (which is why so many java programs resort to threads to use them). Anything outside of this "contract" is *not* an InputStream or OutputStream. That is why there is a new package for things that don't behave like the old *Stream classes - the NIO package. If you look carefully at the IO package, you'll note that almost all the classes are _Decorator_ pattern implementations of the *Stream classes - and the interface presents the _same_ behavior to the calling code in all cases - a synchronous operation that completes successfully or throws an exception (with the one exception of "read" that returns a "-1" on end-of-stream. I know I've read this numerous times - I'd suggest checking the Language Spec or one of the books by Bloch or Gosling. Ken At 08:36 2007-06-11, you wrote: >* Uncle George wrote on Mon, Jun 11, 2007 at 07:38 -0400: > > Steffen DETTMER wrote: > > > > > (but OutputStream promises that write > > > succeedes synchronous, blocking, or throws an exception). > > > > Where is it so written? > >Now, as you ask, I think it is not written that clearly but >follows from specification. mmm... > >Am I wrong? > >I understand the API doc in this way: > >* >http://java.sun.com/j2se/1.4.2/docs/api/java/io/OutputStream.html#write(byte[]) > > public void write(byte[] b) > > throws IOException > > > > Writes b.length bytes from the specified byte array to this > > output stream. The general contract for write(b) is that > > it should have exactly the same effect as the call write(b, > > 0, b.length). > > > > Parameters: > > b - the data. > > Throws: > > IOException - if an I/O error occurs. > > See Also: > > write(byte[], int, int) > > >and there is: > > > > public void write(byte[] b, > > int off, > > int len) > > throws IOException > > > > Writes len bytes from the specified byte array starting at > > offset off to this output stream. The general contract for > > write(b, off, len) is that some of the bytes in the array b > > are written to the output stream in order; element b[off] > > is the first byte written and b[off+len-1] is the last byte > > written by this operation. > > > > The write method of OutputStream calls the write method of > > one argument on each of the bytes to be written out. > > Subclasses are encouraged to override this method and > > provide a more efficient implementation. > > > > If b is null, a NullPointerException is thrown. > > > > If off is negative, or len is negative, or off+len is > > greater than the length of the array b, then an > > IndexOutOfBoundsException is thrown. > > > > Parameters: > > b - the data. > > off - the start offset in the data. > > len - the number of bytes to write. > > Throws: > > IOException - if an I/O error occurs. In particular, an > > IOException is thrown if the output stream is closed. > > >In general, any specialisation (derived child class) must comform >to this. So write in the end is specified (!) as "The write >method ... calls the write method ... on each of the bytes to be >written out". This is what must be implemented by ANY >OutputStream. > >Of course, there is: "Subclasses are encouraged to override this >method and provide a more efficient implementation." which IMHO >does not contradict - the more efficient must behave in exactly >the same way of course (just wasting less resources than a simple >byte-by-byte write). So it does not matter here I think. > > > >The write that finally defines the behavior tells basically: > > > "Writes the specified byte to this output stream. The general > > contract for write is that one byte is written to the output > > stream. " > > > > Throws: > > IOException - if an I/O error occurs. > > >which IMHO is another way of saying "write writes the byte >immediately and returns on success (only), otherwise an exception >is thrown". Especially it cannot happen that zero bytes are >written (i.e. the specified byte is NOT written) without an >exception. So by this write must be synchronous and blocking, >because otherwise it could not reliably know if an asynchronous >operation will succeede or not (some getAsyncResult or so would >be needed). > >Since write(byte[]) does this for each byte (or with a behavior >beeing exactly the same as if it would do), I think this means >that the write(byte[]) succeedes synchronous/blocking or throws >an exception. > >Did I an error in reasoning or confused something or so? > >oki, > >Steffen > >About Ingenico Throughout the world businesses rely on Ingenico for >secure and expedient electronic transaction acceptance. Ingenico >products leverage proven technology, established standards and >unparalleled ergonomics to provide optimal reliability, versatility >and usability. This comprehensive range of products is complemented >by a global array of services and partnerships, enabling businesses >in a number of vertical sectors to accept transactions anywhere >their business takes them. >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. > >About Ingenico Throughout the world businesses rely on Ingenico for >secure and expedient electronic transaction acceptance. Ingenico >products leverage proven technology, established standards and >unparalleled ergonomics to provide optimal reliability, versatility >and usability. This comprehensive range of products is complemented >by a global array of services and partnerships, enabling businesses >in a number of vertical sectors to accept transactions anywhere >their business takes them. >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. > >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx From alesinskyy at googlemail.com Mon Jun 11 07:25:33 2007 From: alesinskyy at googlemail.com (Oleksandr Alesinskyy) Date: Mon, 11 Jun 2007 15:25:33 +0200 Subject: [Rxtx] [OT] select :-) Message-ID: Sorry, but I have to disagree with following statement: "So write in the end is specified (!) as "The write method ... calls the write method ... on each of the bytes to be written out". This is what must be implemented by ANY OutputStream.". This is not part of the specification or contract, it is just revealed implementation detail of the OutputStream. It is not stated anywhere that behavoiur of derived classes shall conform with this one. Statement concerning "synchronous" nature of the output stream is invalid as well. Really synchronous stream does not require flush() but OutputStream has it. From Steffen.DETTMER at ingenico.com Mon Jun 11 08:21:16 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 16:21:16 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: Message-ID: <20070611142116.GN10821@elberon.bln.de.ingenico.com> * Oleksandr Alesinskyy wrote on Mon, Jun 11, 2007 at 15:25 +0200: > Sorry, but I have to disagree with following statement: > "So write in the end is specified (!) as "The write > method ... calls the write method ... on each of the bytes to be > written out". This is what must be implemented by ANY > OutputStream.". > > This is not part of the specification or contract, it is just > revealed implementation detail of the OutputStream. It is not > stated anywhere that behavoiur of derived classes shall conform > with this one. (I didn't meant that the implementation must really write byte by byte, but that it must "look as if it would do" - because all implementations of OutputStream must "look" in the same way [which is another way of saying "do abstract" I think]) I think the API doc is not "revealing implementation details" but it is the *specification* of that interface and derivations must (should) conform to this specification. Isn't this the idea of interfaces? A function that expects an OutputStream should work on ANY OutputStream, shouldn't it? just kidding: I mean, what would be the point in implementing a checksum function as OutputStream.write which throws its result as IOException? Or which requires to call close() as very first operation to tell that the application is about to transmit confidential data? :-) > Statement concerning "synchronous" nature of the output stream > is invalid as well. Really synchronous stream does not require > flush() but OutputStream has it. ahh, interesting point! I think this is another bug in the API. flush() is wrong. Because write specifies "The general contract for write is that one byte is written to the output stream." but not "a byte may be written or buffered". Actually, an application would need to call flush() after each write (or bunch of write calls) to ensure that write really did something otherwise I think. I didn't found in the spec of OutputStream that it would be required to call flush(). This should mean that calling flush is not required which in turn leads to the conclusion that write must be synchrous (private threads are forbidden because not specified :)) which in turn leads to the conclusion that flush() is not needed at all... I mean, what if someone would only store in write and do the "real write" in flush() and never else? An application could write in one stream and read on another one (e.g. in bidirectional communication) and would never get anything back, because nothing was actually written because no flush was called? Then someone could even think that on error in some write the data could remain buffered AND throw an exception, retrying to send the data in the next write. Ohh, and if there would be some message number inside, and underlaying write (e.g. a protocol offering InputStream/OutputStream) would check this and throw "DuplicatedMessageNumber" the stream would only throw it again and again beeing unusable... In short: I have no clue how someone could be able to implement an asynchrounos write (which is realiable and correct) without beeing specific to anything which is not specified by OutputStream. Well, I think in the end OutputStream was not intended for such communication or protocol implementations - but to read a local disk file or so. In case of I/O errors usually you can abort your application and change the hard disk :-) oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Bob_Jacobsen at lbl.gov Mon Jun 11 09:32:23 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Mon, 11 Jun 2007 08:32:23 -0700 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611142116.GN10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> Message-ID: At 4:21 PM +0200 6/11/07, Steffen DETTMER wrote: > > Statement concerning "synchronous" nature of the output stream >> is invalid as well. Really synchronous stream does not require >> flush() but OutputStream has it. > >ahh, interesting point! > >I think this is another bug in the API. flush() is wrong. Because >write specifies "The general contract for write is that one byte >is written to the output stream." but not "a byte may be written >or buffered". > >Actually, an application would need to call flush() after each >write (or bunch of write calls) to ensure that write really did >something otherwise I think. OutputStreams don't _have_ to be synchronous or asynchronous, but the OutputStream API was be arranged so that subclasses _can_ be synchronous or asynchronous. Such generality is the hardest part of getting an API right. Hence, if at some point a program using an OutputStream wants to be sure that the data has been pushed all the way out, flush() is available. For some subclasses, e.g. the buffered ones, this has important behavior. Others write the data from each call, and flush() doesn't do anything. You _can_ omit it in programs that are known to use this second type, but there's no requirement that you do so; the interface is general in that way. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From Steffen.DETTMER at ingenico.com Mon Jun 11 12:32:39 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Mon, 11 Jun 2007 20:32:39 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> Message-ID: <20070611183239.GT10821@elberon.bln.de.ingenico.com> * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: > >Actually, an application would need to call flush() after each > >write (or bunch of write calls) to ensure that write really did > >something otherwise I think. > OutputStreams don't _have_ to be synchronous or asynchronous, > but the OutputStream API was be arranged so that subclasses > _can_ be synchronous or asynchronous. Ahh, oki. Thanks for the clarificaion. So in short, flush() MUST be called on OutputStream, this is just not documented correctly or so clearly (right?). So the overall usage semantics would be: 1. call write (multiple times if desired) 2. call flush only if both succeeded, write was successful. If flush fails it remains unknown if a part of the data was written and/or will be repeated. So the spec (API doc) is wrong. Correct would be to tell that write behaves as told as long as it is followed by a call to flush, otherwise data may or may not get lost (depending wheter close() is called and calls flush(), which seems not to be guaranteed/required). BTW, I think it is a little bit... erm... interesting to find the specification (java API doc reference) wrong, having a need to conclude it from the presence of some methods with "it would make no sense if they behave exactly as specified, so specification must be wrong (incomplete)". > Such generality is the hardest part of getting an API right. Yes, seems to be proven ;) > Hence, if at some point a program using an OutputStream wants > to be sure that the data has been pushed all the way out, > flush() is available. For some subclasses, e.g. the buffered > ones, this has important behavior. Others write the data from > each call, and flush() doesn't do anything. > You _can_ omit it in programs that are known to use this second > type, but there's no requirement that you do so; the interface > is general in that way. I think, it still it must be called always, otherwise the application could break if passing a different runtime type as OutputStream. I think, if the application/method needs a special "type of OutputStream" then the parameter type must be a subclass but not OutputStream, maybe a PrintStream or so - otherwise the compiler could not detect this error (passing wrong type). Is this correct? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From Bob_Jacobsen at lbl.gov Mon Jun 11 13:00:52 2007 From: Bob_Jacobsen at lbl.gov (Bob Jacobsen) Date: Mon, 11 Jun 2007 12:00:52 -0700 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611183239.GT10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> Message-ID: At 8:32 PM +0200 6/11/07, Steffen DETTMER wrote: >So the spec (API doc) is wrong. Correct would be to tell that >write behaves as told as long as it is followed by a call to >flush, otherwise data may or may not get lost (depending wheter >close() is called and calls flush(), which seems not to be >guaranteed/required). I'm not entirely sure that the spec is wrong, but reasonable people can differ on this. In the 1.5 JavaDocs, all that the docs say for the write methods is that they write to the _output_ _stream_; there is no guarantee of anything beyond that. Only the flush method has any guarantee about the data, which is >Flushes this output stream and forces any buffered output bytes to >be written out. The general contract of flush is that calling it is >an indication that, if any bytes previously written have been >buffered by the implementation of the output stream, such bytes >should immediately be written to their intended destination. People commonly use various OutputStreams without using flush(), and it often works, but it's a bad practice and will eventually bite them. Bob -- Bob Jacobsen, UC Berkeley jacobsen at berkeley.edu +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG From netbeans at gatworks.com Mon Jun 11 13:31:57 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 15:31:57 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070611183239.GT10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> Message-ID: <466DA32D.1010602@gatworks.com> Steffen DETTMER wrote: > * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: >>> Actually, an application would need to call flush() after each >>> write (or bunch of write calls) to ensure that write really did >>> something otherwise I think. > >> OutputStreams don't _have_ to be synchronous or asynchronous, >> but the OutputStream API was be arranged so that subclasses >> _can_ be synchronous or asynchronous. > > Ahh, oki. Thanks for the clarificaion. > > So in short, flush() MUST be called on OutputStream, this is just > not documented correctly or so clearly (right?). No. Flush can be called to force all current data in java buffer's to be written to the kernel - NOW. A flush() can also *imply* that, besides writing out the buffer's that java employs, may also imply/ask the kernel to write all data thusfar written to the kernel, to be physically placed on the destination device - NOW. For some OS's there is no need to do a kernel flush(), as the I/O is synchronized already. Since this is java, you never know what OS your on. From tjarvi at qbang.org Mon Jun 11 19:28:27 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Jun 2007 19:28:27 -0600 (MDT) Subject: [Rxtx] [OT] select :-) In-Reply-To: <466DA32D.1010602@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: On Mon, 11 Jun 2007, Uncle George wrote: > Steffen DETTMER wrote: >> * Bob Jacobsen wrote on Mon, Jun 11, 2007 at 08:32 -0700: >>>> Actually, an application would need to call flush() after each >>>> write (or bunch of write calls) to ensure that write really did >>>> something otherwise I think. >> >>> OutputStreams don't _have_ to be synchronous or asynchronous, >>> but the OutputStream API was be arranged so that subclasses >>> _can_ be synchronous or asynchronous. >> >> Ahh, oki. Thanks for the clarificaion. >> >> So in short, flush() MUST be called on OutputStream, this is just >> not documented correctly or so clearly (right?). > No. > Flush can be called to force all current data in java buffer's to be > written to the kernel - NOW. > > A flush() can also *imply* that, besides writing out the buffer's that > java employs, may also imply/ask the kernel to write all data thusfar > written to the kernel, to be physically placed on the destination device > - NOW. > For some OS's there is no need to do a kernel flush(), as the I/O is > synchronized already. Since this is java, you never know what OS your on. To add to the confusion, flush on the C side throws away data. drain makes sure it is written. Looking at the ParallelImp.c we can probably do better. /* we set a timeout because all calls are sequentiell (also with asynchron) this means that the default timeout of unlimited blocks all calls (also close and status request) if the device is down */ GetCommTimeouts( (HANDLE)fd, &timeouts ); timeouts.WriteTotalTimeoutMultiplier = 0; timeouts.WriteTotalTimeoutConstant = 2000; /* 2000 is the min value for the default Windows NT and Windows 2000 driver */ SetCommTimeouts( (HANDLE)fd, &timeouts ); while( count > 0 ){ if(!WriteFile( (HANDLE)fd, bytes, count, &countWritten, NULL ) && countWritten == 0){ /* this are 20 * 2 seconds, in this time a printer (or other parallel device) should solv all problems like buffer full, etc */ if(errorCount++ < 20){ Sleep( 20 ); /* make a small pause to execute all other requests in all other threads */ continue; } throw_java_exception_system_msg( env, IO_EXCEPTION, "writeArray" ); break; } errorCount = 0; bytes += countWritten; count -= countWritten; } LPRPort has some timeout code that appears to be doing nothing but flipping bits back and forth right now. The commapi rxtx follows allows for timeout control from javax.comm.CommPort. The above is a solution that worked in one specific use case. With timeouts in place, the original 'old printer going offline' problem could be solved. That printer code isn't written in stone. In fact it was ajusted from being able to print 'asdf' to a daisy wheel printer to working for one person. BTW, I've finished teaching after hours tonight and will be moving forward with a new rxtx release in my free time. -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Jun 11 21:28:04 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 11 Jun 2007 23:28:04 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: <466E12C4.1010305@gatworks.com> > Looking at the ParallelImp.c we can probably do better. > The problem stemmed from the possibility that the writev routine could have written some of the buffer, in chunks, printer pauses, refuses any more chunks, and a timeout occurs. Do you or do you not cause an exception to be thrown? Is there a way to set timeout for a ParallelPort data output stream? I cant find it. From tjarvi at qbang.org Mon Jun 11 22:17:23 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 11 Jun 2007 22:17:23 -0600 (MDT) Subject: [Rxtx] [OT] select :-) In-Reply-To: <466E12C4.1010305@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> <466E12C4.1010305@gatworks.com> Message-ID: On Mon, 11 Jun 2007, Uncle George wrote: >> Looking at the ParallelImp.c we can probably do better. >> > The problem stemmed from the possibility that the writev routine could > have written some of the buffer, in chunks, printer pauses, refuses any > more chunks, and a timeout occurs. Do you or do you not cause an > exception to be thrown? > > Is there a way to set timeout for a ParallelPort data output stream? I > cant find it. hmm I looked again after you asked. The timeouts are only controllable on the receive side. This comes from CommPort; the parent. So what we are talking about is some bytes in memory that rxtx has and is supposed to write. A buffer perhaps? The approach with rxtx in the past has been to ignore output buffer sizes. The assumption is that the library does not know how to best handle buffers. There are buffered output streams that can do buffering on top of rxtx for instance. There is also a question regarding what was actually ment when the API was put together. My suspicion is that it was put together while looking at one OS API and was never ment to be anything more than a hook into that API. The comments are fairly telling combined with reading the w32 API. So looking at the problem again.. The current timeout behavior appears fairly arbitrary. Presumably this is to prevent a program from hanging instead of using a helper thread to write - heavy handed for new programmers. Even so, I don't think the write should timeout at all if it is not configurable. >From the API perspective, "What Timeout?" -- Trent Jarvi tjarvi at qbang.org From Steffen.DETTMER at ingenico.com Tue Jun 12 02:14:48 2007 From: Steffen.DETTMER at ingenico.com (Steffen DETTMER) Date: Tue, 12 Jun 2007 10:14:48 +0200 Subject: [Rxtx] [OT] select :-) In-Reply-To: <466DA32D.1010602@gatworks.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> Message-ID: <20070612081447.GU10821@elberon.bln.de.ingenico.com> * Uncle George wrote on Mon, Jun 11, 2007 at 15:31 -0400: > Steffen DETTMER wrote: > > Ahh, oki. Thanks for the clarificaion. > > > > So in short, flush() MUST be called on OutputStream, this is just > > not documented correctly or so clearly (right?). > No. hum (though now I got it, but...). > Flush can be called to force all current data in java buffer's to be > written to the kernel - NOW. > > A flush() can also *imply* that, besides writing out the > buffer's that java employs, may also imply/ask the kernel to > write all data thusfar written to the kernel, to be physically > placed on the destination device - NOW. > > For some OS's there is no need to do a kernel flush(), as the I/O is > synchronized already. Since this is java, you never know what OS your on. (well, but if you're going to kernel level, even flush cannot guarantee that data will "be physically placed". Maybe you're flushing to a file via NFS (and the client "thinks" that it was written, but maybe it was just buffered by the NFS server) or so... but of course such exceptions of the rules are constructable always.) Well, you tell that depending on the OS it can be that flush is needed or it can be that flush is not needed (beacuse the I/O is synchronized already), right? Also, applications should work on any OS, which includes the OSes that do need flush. Since the application cannot know whether flush is needed or not because it doesn't know what the OS is doing, it has to call flush, hasn't it? I mean, if it would not call flush then it would not work on such OSes (except the written data would not be needed at all, but in this would be an artificial example :)). Since applications are supposed to work this would be wrong, wouldn't it? So would it be correct to say: "Applications, that should work under all OSes (including the OSes where the I/O is not synchronised already), have to call flush on OutputStream to ensure the data is transfered to the kernel." or is this wrong? If so, then I'm afraid I missed the point again :( oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. 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. From netbeans at gatworks.com Tue Jun 12 04:46:52 2007 From: netbeans at gatworks.com (Uncle George) Date: Tue, 12 Jun 2007 06:46:52 -0400 Subject: [Rxtx] [OT] select :-) In-Reply-To: <20070612081447.GU10821@elberon.bln.de.ingenico.com> References: <20070611142116.GN10821@elberon.bln.de.ingenico.com> <20070611183239.GT10821@elberon.bln.de.ingenico.com> <466DA32D.1010602@gatworks.com> <20070612081447.GU10821@elberon.bln.de.ingenico.com> Message-ID: <466E799C.7060700@gatworks.com> S > (well, but if you're going to kernel level, even flush cannot > guarantee that data will "be physically placed". Thats true now-a-days because ( from "man 2 sync" ) : > According to the standard specification (e.g., SVID), sync() schedules > the writes, but may return before the actual writing is done. However, > since version 1.3.20 Linux does actually wait. (This still does not > guarantee data integrity: modern disks have large caches.) My disk drive has 8mb cache. Maybe you're > flushing to a file via NFS (and the client "thinks" that it was > written, but maybe it was just buffered by the NFS server) or > so... but of course such exceptions of the rules are > constructable always.) > > Well, you tell that depending on the OS it can be that flush is > needed or it can be that flush is not needed (beacuse the I/O is > synchronized already), right? Also, applications should work on > any OS, which includes the OSes that do need flush. Its not OS's that need flush, its applications that want to have some assurance that data is written to the device that really needs to use flush. If your program ( or thread ) dies then it is in your best interest to write out the critical data as soon as possible, as economical as possible. These are trade-off's that the application programmer makes. A big buffer may mean big loss of data, a small buffer may mean spending too much time writing out data. > > > So would it be correct to say: > > "Applications, that should work under all OSes (including the > OSes where the I/O is not synchronised already), have to call > flush on OutputStream to ensure the data is transfered to the > kernel." > > or is this wrong? If so, then I'm afraid I missed the point again > :( > No that is not wrong. Ensuring that data is transfered to the OS is just about what any application can do. From tjarvi at qbang.org Thu Jun 14 08:16:47 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Thu, 14 Jun 2007 08:16:47 -0600 (MDT) Subject: [Rxtx] rxtx and usb-serial solution In-Reply-To: References: Message-ID: On Thu, 14 Jun 2007, Vladimir Kirtchev wrote: > Hi Trent, > > I develop a Java application which communicates with devices which have > USB-to-Serial bridge in them. The target OS is Linux. So for this purpose I > use RXTX. > > But I encountered a strange problem - when reading from the InputStream, I > receive series of zeros. I have this problem under Linux only. Under Windows > it is fine. > Actually this problem is the same as the one described here: > http://marc.info/?l=rxtx&m=109703190731748&w=2. > > > So I searched for the problem in the native code. And found that the root of > the problem is in SerialImp.c, > int configure_port( int fd ) > { > ... > ttyset.c_iflag = INPCK; > ... > } > > This line enables input parity checking, and the data sent from the device > is processed by the OS driver before being read with read(). > In this case the driver detects some problem and sets the received bytes to > zero. > > On the other hand in the Java part a set the serial port parameters with > SerialPort.PARITY_NONE. According to me, except all other things, this > should also disable INPCK in c_iflag. > > So I refactored the method translate_parity(...) to the following: > > int translate_parity( JNIEnv *env, struct termios *ttyset, jint parity ) > { > ENTER( "translate_parity" ); > #ifdef CMSPAR > ttyset->c_cflag &= ~(PARENB | PARODD | CMSPAR ); > #endif /* CMSPAR */ > switch( parity ) { > case JPARITY_NONE: > ttyset->c_iflag &= ~INPCK; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_EVEN: > ttyset->c_cflag |= PARENB; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_ODD: > ttyset->c_cflag |= PARENB | PARODD; > LEAVE( "translate_parity" ); > return 0; > #ifdef CMSPAR > case JPARITY_MARK: > ttyset->c_cflag |= PARENB | PARODD | CMSPAR; > LEAVE( "translate_parity" ); > return 0; > case JPARITY_SPACE: > ttyset->c_cflag |= PARENB | CMSPAR; > LEAVE( "translate_parity" ); > return 0; > #endif /* CMSPAR */ > default: > printf("Parity missed %i\n", (int) parity ); > } > > LEAVE( "translate_parity" ); > /* > For some reason the native exceptions are not being caught. Moving this > to the Java side fixed the issue. taj. > throw_java_exception( env, UNSUPPORTED_COMM_OPERATION, > "", "parity value not supported" ); > */ > return 1; > } > > This modification solved the problem and now it works correctly under Linux. > > I think I will be a nice if this is idea is included in a future release of > RXTX. > > Thanks Vadim, I'll try that out. Forwarding to the rxtx mail-list too. This is probably not going to help USB drivers on windows which I'm sure some are looking for. As far as I can tell, windows USB bluetooth and serial dongles are limited by driver functionality. Some are good and others lack key features. -- Trent Jarvi tjarvi at qbang.org From dan.sandberg.lists at gmail.com Mon Jun 18 14:43:39 2007 From: dan.sandberg.lists at gmail.com (Dan Sandberg) Date: Mon, 18 Jun 2007 13:43:39 -0700 Subject: [Rxtx] Fix for JNI Get/Set Field Errors Message-ID: <4676EE7B.7060800@gmail.com> Hi, I've fixed the problems that cause the following JNI error when extra JNI checking ( -Xjni:check ) is turned on. FATAL ERROR in native method: Field type (instance) mismatch in JNI get/set field operations at gnu.io.RXTXPort.eventLoop(Native Method) at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:1531) The problem was basically that GetLong was being used to get ints, and SetInt was used for longs. The patch below fixes this. Please let me know if there are any questions / problems. Cheers, -Dan diff -aur old/SerialImp.c src/SerialImp.c --- old/SerialImp.c 2007-06-18 13:24:33.000000000 -0700 +++ src/SerialImp.c 2007-06-18 06:26:26.000000000 -0700 @@ -1337,7 +1337,7 @@ report("init_threads: get eis\n"); jeis = (*eis->env)->GetFieldID( eis->env, eis->jclazz, "eis", "J" ); report("init_threads: set eis\n"); - (*eis->env)->SetIntField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); + (*eis->env)->SetLongField(eis->env, *eis->jobj, jeis, ( size_t ) eis ); report("init_threads: stop\n"); report_time_end( ); return( 1 ); @@ -1530,7 +1530,7 @@ jobject jobj, jboolean interrupted ) { int fd = get_java_var( env, jobj,"fd","I" ); - struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var( env, jobj, "eis", "J" ); + struct event_info_struct *eis = ( struct event_info_struct * ) get_java_var_long( env, jobj, "eis", "J" ); int result, count=0; char message[80]; @@ -2939,7 +2939,7 @@ /* TRENT */ int flag, count = 0; struct event_info_struct *eis = ( struct event_info_struct * ) - get_java_var( env, *jobj,"eis","J" ); + get_java_var_long( env, *jobj,"eis","J" ); report_time_start(); flag = eis->eventflags[SPE_DATA_AVAILABLE]; @@ -4873,9 +4873,9 @@ exceptions: none comments: ----------------------------------------------------------*/ -size_t get_java_var( JNIEnv *env, jobject jobj, char *id, char *type ) +long get_java_var_long( JNIEnv *env, jobject jobj, char *id, char *type ) { - int result = 0; + long result = 0; jclass jclazz = (*env)->GetObjectClass( env, jobj ); jfieldID jfd = (*env)->GetFieldID( env, jclazz, id, type ); @@ -4889,7 +4889,11 @@ LEAVE( "get_java_var" ); return result; } - result = (int)( (*env)->GetIntField( env, jobj, jfd ) ); + if ( !strcmp( type, "J" ) ) { + result = (long)( (*env)->GetLongField( env, jobj, jfd ) ); + } else { + result = (int) ( (*env)->GetIntField( env, jobj, jfd ) ); + } /* ct7 & gel * Added DeleteLocalRef */ (*env)->DeleteLocalRef( env, jclazz ); if(!strncmp( "fd",id,2) && result == 0) @@ -4900,6 +4904,10 @@ return result; } +int get_java_var( JNIEnv *env, jobject jobj, char *id, char *type ) { + return (int) get_java_var_long( env, jobj, id, type ); +} + /*---------------------------------------------------------- throw_java_exception diff -aur old/SerialImp.h src/SerialImp.h --- old/SerialImp.h 2007-06-18 13:24:39.000000000 -0700 +++ src/SerialImp.h 2007-06-18 06:23:43.000000000 -0700 @@ -413,7 +413,8 @@ void system_wait(); void finalize_event_info_struct( struct event_info_struct * ); int read_byte_array( JNIEnv *, jobject *, int, unsigned char *, int, int ); -size_t get_java_var( JNIEnv *, jobject, char *, char * ); +int get_java_var( JNIEnv *, jobject, char *, char * ); +long get_java_var_long( JNIEnv *, jobject, char *, char * ); jboolean is_interrupted( struct event_info_struct * ); int send_event(struct event_info_struct *, jint, int ); void dump_termios(char *,struct termios *); From yvespielusenet at free.fr Tue Jun 26 03:41:58 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 11:41:58 +0200 Subject: [Rxtx] [PARALLEL] resource in use Message-ID: <1182850918.3483.10.camel@localhost.localdomain> Hello, So now I want to modify the timeout of the library for parallel port. I have downloaded source code. There is a makefile for migw. SO I have installed mingw on ubuntu and modified the makefile.mingw32 to set it for my system. I have no error but some warnings. The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But When I want to use it the jvm crash :( How can I know what is wrong ? How rxtx windows release has been done ? thanks -- yves piel From yvespielusenet at free.fr Tue Jun 26 07:17:02 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 15:17:02 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182850918.3483.10.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> Message-ID: <1182863822.3483.17.camel@localhost.localdomain> Here is the Makefile I use, the output of the 'make' and the log of the jvm when it crashed : - The Makefile : http://yvespiel.free.fr/rxtx/Makefile - The make output : http://yvespiel.free.fr/rxtx/compile.txt - The crash log : http://yvespiel.free.fr/rxtx/hs_err_pid2100.log I have compiled rxtx under Debian testing with mingw : narma at linimi:/tmp/err$ dpkg -l | grep mingw ii mingw32 3.4.5.20060117.1.dfsg-3 ii mingw32-binutils 2.17.50-20070129.1-1 ii mingw32-runtime 3.12-1 thanks fort help :) Le mardi 26 juin 2007 ? 11:41 +0200, yves pielusenet a ?crit : > Hello, > So now I want to modify the timeout of the library for parallel port. I > have downloaded source code. There is a makefile for migw. SO I have > installed mingw on ubuntu and modified the makefile.mingw32 to set it > for my system. > I have no error but some warnings. > The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But > When I want to use it the jvm crash :( > > How can I know what is wrong ? > > How rxtx windows release has been done ? > > thanks > From yvespielusenet at free.fr Tue Jun 26 07:40:11 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 15:40:11 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182863822.3483.17.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> <1182863822.3483.17.camel@localhost.localdomain> Message-ID: <1182865211.3483.21.camel@localhost.localdomain> I have add the options '--enable-stdcall-fixup' to the 'i586-mingw32msvc-ld' commande. Now I have no warning. But the JVM always crashes :( The output seems more detailled, but I don't understand anything... Here is files : http://yvespiel.free.fr/rxtx/2/ -- yves piel Le mardi 26 juin 2007 ? 15:17 +0200, yves pielusenet a ?crit : > Here is the Makefile I use, the output of the 'make' and the log of the > jvm when it crashed : > > - The Makefile : http://yvespiel.free.fr/rxtx/Makefile > - The make output : http://yvespiel.free.fr/rxtx/compile.txt > - The crash log : http://yvespiel.free.fr/rxtx/hs_err_pid2100.log > > I have compiled rxtx under Debian testing with mingw : > narma at linimi:/tmp/err$ dpkg -l | grep mingw > ii mingw32 3.4.5.20060117.1.dfsg-3 > ii mingw32-binutils 2.17.50-20070129.1-1 > ii mingw32-runtime 3.12-1 > > thanks fort help :) > > > Le mardi 26 juin 2007 ? 11:41 +0200, yves pielusenet a ?crit : > > Hello, > > So now I want to modify the timeout of the library for parallel port. I > > have downloaded source code. There is a makefile for migw. SO I have > > installed mingw on ubuntu and modified the makefile.mingw32 to set it > > for my system. > > I have no error but some warnings. > > The RXTXcomm.jar, rxtxSerial.dll and rxtxParallel.dll are created. But > > When I want to use it the jvm crash :( > > > > How can I know what is wrong ? > > > > How rxtx windows release has been done ? > > > > thanks > > > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > From yvespielusenet at free.fr Tue Jun 26 08:27:42 2007 From: yvespielusenet at free.fr (yves pielusenet) Date: Tue, 26 Jun 2007 16:27:42 +0200 Subject: [Rxtx] [PARALLEL] resource in use In-Reply-To: <1182865211.3483.21.camel@localhost.localdomain> References: <1182850918.3483.10.camel@localhost.localdomain> <1182863822.3483.17.camel@localhost.localdomain> <1182865211.3483.21.camel@localhost.localdomain> Message-ID: <1182868062.3483.24.camel@localhost.localdomain> I think thant the include files of jdk were not for windows but for linux. So I have copied include/ folder from windows to linux and I modified the Makefile to use those file. It compile fine but the JVM always crash :( http://yvespiel.free.fr/rxtx/3/ Le mardi 26 juin 2007 ? 15:40 +0200, yves pielusenet a ?crit : > I have add the options '--enable-stdcall-fixup' to the > 'i586-mingw32msvc-ld' commande. Now I have no warning. But the JVM > always crashes :( The output seems more detailled, but I don't > understand anything... > Here is files : > http://yvespiel.free.fr/rxtx/2/ > From netbeans at gatworks.com Fri Jun 1 05:38:50 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 07:38:50 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <465F7ADD.1010501@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> Message-ID: <4660054A.2040202@gatworks.com> Manuel Naranjo wrote: In the case of my module, you can > unplug the device but it will not delete the symlink until those apps > that had opened the port has closed it. This is done this way to avoid > kernel panics. What does this mean to user code ? I have tried the alternate route ( other than closing ) which is sleep inbetween the I/O errors ( an unplugged USB device). When the device is plugged back in, The writes to the device still get an I/O error. This would seem to be a lost cause for the application. From netbeans at gatworks.com Fri Jun 1 06:35:48 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 08:35:48 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <465F7ADD.1010501@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> Message-ID: <466012A4.90608@gatworks.com> Manuel Naranjo wrote: In the case of my module, you can > unplug the device but it will not delete the symlink until those apps > that had opened the port has closed it. T Did u also mean for this to happen? USB0 was not closed by application. Apparently USB1 got created when USB device was plugged back in. There is only one USB device on a 4 port USB hub. This also seems to suggest that application recovery to be impossible. > Jun 1 07:10:08 mylaptop kernel: garmin_gps 1-1.4:1.0: Garmin GPS usb/tty converter detected > Jun 1 07:10:08 mylaptop kernel: usb 1-1.4: Garmin GPS usb/tty converter now attached to ttyUSB0 > Jun 1 07:15:17 mylaptop kernel: usb 1-1: USB disconnect, address 4 > Jun 1 07:15:17 mylaptop kernel: usb 1-1.4: USB disconnect, address 5 > Jun 1 07:15:17 mylaptop kernel: garmin_gps 1-1.4:1.0: device disconnected > Jun 1 07:15:26 mylaptop kernel: usb 1-1: new full speed USB device using uhci_hcd and address 6 > Jun 1 07:15:26 mylaptop kernel: hub 1-1:1.0: USB hub found > Jun 1 07:15:26 mylaptop kernel: hub 1-1:1.0: 4 ports detected > Jun 1 07:15:27 mylaptop kernel: usb 1-1.4: new full speed USB device using uhci_hcd and address 7 > Jun 1 07:15:27 mylaptop kernel: garmin_gps 1-1.4:1.0: Garmin GPS usb/tty converter detected > Jun 1 07:15:27 mylaptop kernel: usb 1-1.4: Garmin GPS usb/tty converter now attached to ttyUSB1 From naranjo.manuel at gmail.com Fri Jun 1 09:17:22 2007 From: naranjo.manuel at gmail.com (Manuel Naranjo) Date: Fri, 01 Jun 2007 12:17:22 -0300 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <466012A4.90608@gatworks.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> <466012A4.90608@gatworks.com> Message-ID: <46603882.5050701@gmail.com> Uncle George escribi?: > Manuel Naranjo wrote: > In the case of my module, you can > >> unplug the device but it will not delete the symlink until those apps >> that had opened the port has closed it. T >> > > Did u also mean for this to happen? USB0 was not closed by application. > > Apparently USB1 got created when USB device was plugged back in. There > is only one USB device on a 4 port USB hub. > > This also seems to suggest that application recovery to be impossible. > Exactly there's a dead symlink (you can read and write to it and nothing will happen) and a new port will be created when a new device is connencted. From netbeans at gatworks.com Fri Jun 1 10:20:46 2007 From: netbeans at gatworks.com (Uncle George) Date: Fri, 01 Jun 2007 12:20:46 -0400 Subject: [Rxtx] The SELECT() that never stops giving! In-Reply-To: <46603882.5050701@gmail.com> References: <465F421A.2070005@gatworks.com> <465F6733.4030404@gatworks.com> <465F7ADD.1010501@gmail.com> <466012A4.90608@gatworks.com> <46603882.5050701@gmail.com> Message-ID: <4660475E.5090202@gatworks.com> Not sure what u mean by "symlink". U cant read/write to it anymore. U get I/O error. In this scenario the device effectively went dead, and only solution is to close the channel. reconnecting the USB device, although dead, but not closed, will create a second device. This does not seem to be a desirable side-effect. The user will now have ttyUSB1, wondering where did ttyUSB0 go to. The application will also be in a confused state, as well as RXTX, because RXTX wont know about ttyUSB1. Manuel Naranjo wrote: > Uncle George escribi?: >> Manuel Naranjo wrote: >> In the case of my module, you can >> >>> unplug the device but it will not delete the symlink until those apps >>> that had opened the port has closed it. T >>> >> Did u also mean for this to happen? USB0 was not closed by application. >> >> Apparently USB1 got created when USB device was plugged back in. There >> is only one USB device on a 4 port USB hub. >> >> This also seems to suggest that application recovery to be impossible. >> > Exactly there's a dead symlink (you can read and write to it and nothing > will happen) and a new port will be created when a new device is connencted. > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From arnab.bhaumik at gmail.com Mon Jun 4 01:40:16 2007 From: arnab.bhaumik at gmail.com (arnab bhaumik) Date: Mon, 4 Jun 2007 13:10:16 +0530 Subject: [Rxtx] full duplex com port with rxtx Message-ID: hi , till now i did half duplex communication with rxtx package on com package. my question is : is it possible to use com port with full duplex mode with rxtx package . ther is example of SimpleRead class and SimpleWrite class. it is clear that if i can use both the class simultaneously then full duplex is possible......... arnab/vu2bpw -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20070604/6edb0453/attachment.html From lists at iDIAcomputing.com Mon Jun 4 07:53:17 2007 From: lists at iDIAcomputing.com (George Dinwiddie) Date: Mon, 04 Jun 2007 09:53:17 -0400 Subject: [Rxtx] full duplex com port with rxtx In-Reply-To: References: Message-ID: <4664194D.90301@iDIAcomputing.com> arnab bhaumik wrote: > hi , > > till now i did half duplex communication with rxtx package on com > package. > > my question is : is it possible to use com port with full duplex mode > with rxtx package . > > > ther is example of SimpleRead class and SimpleWrite class. it is > clear that if i can use both the class simultaneously then full duplex > is possible......... I haven't looked at the SimpleRead and SimpleWrite classes (I originally wrote my code for the javax.comm api), but full duplex is certainly possible. My CommReader class requires an object analogous to a OutputStream or Writer. When started, it spawns a thread that reads the comm port and writes to that output device. In this way the input is asynchronous and dependent on the actual input data. For full duplex, I extend that class with CommReaderWriter, which adds synchronous output methods. Hope that helps, George -- ---------------------------------------------------------------------- * George Dinwiddie * http://blog.gdinwiddie.com Software Development http://www.idiacomputing.com Consultant and Coach http://www.agilemaryland.org ---------------------------------------------------------------------- From supsoop at hotmail.com Mon Jun 4 15:21:06 2007 From: supsoop at hotmail.com (soop soop) Date: Mon, 04 Jun 2007 21:21:06 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- Message-ID: Hi Guys, Looked through the archives but still cannot figure this out. I have a Motorola G24 GPRS/GSM modem that I am connecting to my server running Ubuntu. I can see my modem as is shows up as ttyACM0, but RXTX is not detecting the port, CommPortIdentifier.getPortIdentifiers(). I have added the line to RXTXCommDriver: "ttyACM" // for USB Modems Rxtx still does not seem to find the port. Is there something I am missing to make this port visable? [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control Model driver for USB modems and ISDN adapters I really need your help as I have moved my server from windows to Linux and have been down for a few days because of this .. Thanks so much! _________________________________________________________________ PC Magazine’s 2007 editors’ choice for best Web mail—award-winning Windows Live Hotmail. http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507 From tjarvi at qbang.org Mon Jun 4 16:17:35 2007 From: tjarvi at qbang.org (Trent Jarvi) Date: Mon, 4 Jun 2007 16:17:35 -0600 (MDT) Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: On Mon, 4 Jun 2007, soop soop wrote: > Hi Guys, > > Looked through the archives but still cannot figure this out. I have a > Motorola G24 GPRS/GSM modem that I am connecting to my server running Ubuntu. > I can see my modem as is shows up as ttyACM0, but RXTX is not detecting the > port, CommPortIdentifier.getPortIdentifiers(). > > I have added the line to RXTXCommDriver: > > "ttyACM" // for USB Modems > > Rxtx still does not seem to find the port. Is there something I am missing to > make this port visable? > > [ 74.709723] drivers/usb/input/hid-core.c: v2.6:USB HID core driver > [ 108.642903] cdc_acm 2-1:1.0: ttyACM0: USB ACM device > [ 108.647128] drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control Model > driver for USB modems and ISDN adapters > > I really need your help as I have moved my server from windows to Linux and > have been down for a few days because of this .. Thanks so much! > You could try the INSTALL documentation that comes with the source for possible solutions. Those usually involve lockfile creation, permissions on the device file or the device is in use by another application (even another session of your application). The usual commands: ls -l /dev/ttyACM0 fuser /dev/ttyACM0 touch /var/lock/LCK.testfile && rm -f /var/lock/LCK.testfile whoami To disable lockfiles: ../configure --disable-lockfiles && make install -- Trent Jarvi tjarvi at qbang.org From netbeans at gatworks.com Mon Jun 4 16:22:52 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 04 Jun 2007 18:22:52 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <466490BC.3090801@gatworks.com> soop soop wrote: > I really need your help as I have moved my server from windows to Linux > and have been down for a few days because of this .. Thanks so much! can u open the device ? ie is the file protection/permissions keeping you out? From supsoop at hotmail.com Mon Jun 4 16:44:40 2007 From: supsoop at hotmail.com (soop soop) Date: Mon, 04 Jun 2007 22:44:40 +0000 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: <466490BC.3090801@gatworks.com> Message-ID: Thanks for the reply, I see no exceptions being thrown, just no detection of the port whats so ever. I will run rxtx in debug mode and log. If this were a permissions issue would I not see some exceptions being thrown? >From: Uncle George >Reply-To: RXTX Developers and Users >To: RXTX Developers and Users >Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >Date: Mon, 04 Jun 2007 18:22:52 -0400 > >soop soop wrote: > > > I really need your help as I have moved my server from windows to Linux > > and have been down for a few days because of this .. Thanks so much! > >can u open the device ? ie is the file protection/permissions keeping >you out? >_______________________________________________ >Rxtx mailing list >Rxtx at qbang.org >http://mailman.qbang.org/mailman/listinfo/rxtx _________________________________________________________________ Get a preview of Live Earth, the hottest event this summer - only on MSN http://liveearth.msn.com?source=msntaglineliveearthhm From netbeans at gatworks.com Mon Jun 4 17:06:15 2007 From: netbeans at gatworks.com (Uncle George) Date: Mon, 04 Jun 2007 19:06:15 -0400 Subject: [Rxtx] RXTX not detecting ttyACM* -- In-Reply-To: References: Message-ID: <46649AE7.10405@gatworks.com> Exceptions on what? On startup it wants to lookup all devices in /dev that it is capable of opening ( within the list of specific 'comm' devices ). If it cannot open, then does not get onto list. Part of this process, if configured, will also test if the "LOCK" schema can also be opened for the device. then it gets on the list of avail comm port. soop soop wrote: > Thanks for the reply, > > I see no exceptions being thrown, just no detection of the port whats so > ever. I will run rxtx in debug mode and log. If this were a permissions > issue would I not see some exceptions being thrown? > > >> From: Uncle George >> Reply-To: RXTX Developers and Users >> To: RXTX Developers and Users >> Subject: Re: [Rxtx] RXTX not detecting ttyACM* -- >> Date: Mon, 04 Jun 2007 18:22:52 -0400 >> >> soop soop wrote: >> >>> I really need your help as I have moved my server from windows to Linux >>> and have been down for a few days because of this .. Thanks so much! >> can u open the device ? ie is the file protection/permissions keeping >> you out? >> _______________________________________________ >> Rxtx mailing list >> Rxtx at qbang.org >> http://mailman.qbang.org/mailman/listinfo/rxtx > > _________________________________________________________________ > Get a preview of Live Earth, the hottest event this summer - only on MSN > http://liveearth.msn.com?source=msntaglineliveearthhm > > _______________________________________________ > Rxtx mailing list > Rxtx at qbang.org > http://mailman.qbang.org/mailman/listinfo/rxtx > > From alex.flint at gmail.com Mon Jun 4 21:31:49 2007 From: alex.flint at gmail.com (Alex Flint) Date: Tue, 5 Jun 2007 13:01:49 +0930 Subject: [Rxtx] random EXCEPTION_ACCESS_VIOLATION errors Message-ID: Hi All, I'm running winXP and RXTX 2.1-7r2 (the latest from the webpage as of June 2007). I'm sending sequences of 64 lines (each line has about 15 chars) at various intervals. The strings are sent fine, until I get the following error (from hs_err_pid3316.log, at the end of this email). What can I do to avoid the error? Obviously this is a low-level memory exception, but is there any way I can keep the JVM running after such an error? I noticed the exact same problem here: http://mailman.qbang.org/pipermail/rxtx/Week-of-Mon-20070129/1180520.html Cheers, Alex # # An unexpected error has been detected by Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x100034fb, pid=3316, tid=2400 # # Java VM: Java HotSpot(TM) Client VM (1.6.0_01-b06 mixed mode, sharing) # Problematic frame: # C [rxtxSerial.dll+0x34fb] # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # --------------- T H R E A D --------------- Current thread (0x00386400): JavaThread "main" [_thread_in_native, id=2400] siginfo: ExceptionCode=0xc0000005, reading address 0x20726f78 Registers: EAX=0x20726f20, EBX=0x6d8922c0, ECX=0x00000005, EDX=0x20726f20 ESP=0x003efa30, EBP=0x003efb68, ESI=0x269728a0, EDI=0x00386400 EIP=0x100034fb, EFLAGS=0x00010212 Top of Stack: (sp=0x003efa30) 0x003efa30: 003efa3c 003efa64 0000000f ffffffff 0x003efa40: 003efa40 2a97f808 003efa6c 2b190ca8 0x003efa50: 00000000 2b190ec0 003efa90 008e2dd7 0x003efa60: 003efa90 008e2dd7 26977f88 6d815e72 0x003efa70: 00000004 2696eae0 0000008a 003efb0c 0x003efa80: 6d852b4a 2696eae0 00000003 26970930 0x003efa90: 000000cb 2696eae0 6d86b264 00385d40 0x003efaa0: 0000003f 003efb0c 26977f90 2ace65d8 Instructions: (pc=0x100034fb) 0x100034eb: ff ff 8d 76 00 eb 02 89 f6 90 8b 45 f8 8b 55 f8 0x100034fb: 8b 4a 58 83 c9 04 89 48 58 83 c4 f8 8b 45 f8 8b Stack: [0x003a0000,0x003f0000), sp=0x003efa30, free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rxtxSerial.dll+0x34fb] Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j gnu.io.RXTXPort.writeArray([BIIZ)V+0 j gnu.io.RXTXPort$SerialOutputStream.write([B)V+76 j com.bjt.media.server.CommLink.send(Ljava/lang/String;)V+48 j com.bjt.media.server.DigitoolConnection.select(I)V+73 j com.bjt.media.server.DigitoolConnection.main([Ljava/lang/String;)V+74 v ~StubRoutines::call_stub --------------- P R O C E S S --------------- Java Threads: ( => current thread ) 0x02a69400 JavaThread "Thread-0" [_thread_in_native, id=3052] 0x02a4d000 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=3920] 0x02a48400 JavaThread "CompilerThread0" daemon [_thread_blocked, id=1968] 0x02a47400 JavaThread "Attach Listener" daemon [_thread_blocked, id=2984] 0x02a46400 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=2660] 0x02a41c00 JavaThread "Finalizer" daemon [_thread_blocked, id=3924] 0x02a3d800 JavaThread "Reference Handler" daemon [_thread_blocked, id=4008] =>0x00386400 JavaThread "main" [_thread_in_native, id=2400] Other Threads: 0x02a34400 VMThread [id=3708] 0x02a4e800 WatcherThread [id=3964] VM state:not at safepoint (normal execution) VM Mutex/Monitor currently owned by a thread: None Heap def new generation total 960K, used 131K [0x22960000, 0x22a60000, 0x22e40000) eden space 896K, 7% used [0x22960000, 0x22970ea8, 0x22a40000) from space 64K, 99% used [0x22a50000, 0x22a5fff8, 0x22a60000) to space 64K, 0% used [0x22a40000, 0x22a40000, 0x22a50000) tenured generation total 4096K, used 76K [0x22e40000, 0x23240000, 0x26960000) the space 4096K, 1% used [0x22e40000, 0x22e53060, 0x22e53200, 0x23240000) compacting perm gen total 12288K, used 137K [0x26960000, 0x27560000, 0x2a960000) the space 12288K, 1% used [0x26960000, 0x26982518, 0x26982600, 0x27560000) ro space 8192K, 62% used [0x2a960000, 0x2ae5e4e8, 0x2ae5e600, 0x2b160000) rw space 12288K, 52% used [0x2b160000, 0x2b7a0e78, 0x2b7a1000, 0x2bd60000) Dynamic libraries: 0x00400000 - 0x00423000 C:\Program Files\Java\jre1.6.0_01\bin\javaw.exe 0x7c900000 - 0x7c9b0000 C:\WINDOWS\system32\ntdll.dll 0x7c800000 - 0x7c8f4000 C:\WINDOWS\system32\kernel32.dll 0x77dd0000 - 0x77e6b000 C:\WINDOWS\system32\ADVAPI32.dll 0x77e70000 - 0x77f01000 C:\WINDOWS\system32\RPCRT4.dll 0x7e410000 - 0x7e4a0000 C:\WINDOWS\system32\USER32.dll 0x77f10000 - 0x77f57000 C:\WINDOWS\system32\GDI32.dll 0x76390000 - 0x763ad000 C:\WINDOWS\system32\IMM32.DLL 0x7c340000 - 0x7c396000 C:\Program Files\Java\jre1.6.0_01\bin\msvcr71.dll 0x6d7c0000 - 0x6da07000 C:\Program Files\Java\jre1.6.0_01\bin\client\jvm.dll 0x76b40000 - 0x76b6d000 C:\WINDOWS\system32\WINMM.dll 0x5cd70000 - 0x5cd77000 C:\WINDOWS\system32\serwvdrv.dll 0x5b0a0000 - 0x5b0a7000 C:\WINDOWS\system32\umdmxfrm.dll 0x6d310000 - 0x6d318000 C:\Program Files\Java\jre1.6.0_01\bin\hpi.dll 0x76bf0000 - 0x76bfb000 C:\WINDOWS\system32\PSAPI.DLL 0x6d770000 - 0x6d77c000 C:\Program Files\Java\jre1.6.0_01\bin\verify.dll 0x6d3b0000 - 0x6d3cf000 C:\Program Files\Java\jre1.6.0_01\bin\java.dll 0x6d7b0000 - 0x6