In 'general' a bit ago I had a problem where Emplode finds my serial port but Jemplode wont (here)

Well, some digging later it turns out that javax.comm enumerates the serial ports on my XP box as COM3, COM4, COM1, COM2
COM3 and COM4 are USB ports.
For whatever reason the java.io.InputStream.read() returns 0 bytes (documented behaviour)
This is bad because the read() in LittleEndianInputStream loops by incrementing pos by bytesRead
Result: infinite loop and jemplode doesn't see my serial port.

Patch below fixes this and I can now see my Empeg on COM2 (from eclipse - yep it's CVS is pretty good isn't it )

Index: src/com/inzyme/typeconv/LittleEndianInputStream.java

===================================================================

RCS file: /share/mirror/cvsstore/Jemplode/inzyme-core/src/com/inzyme/typeconv/LittleEndianInputStream.java,v

retrieving revision 1.1.1.1

diff -u -r1.1.1.1 LittleEndianInputStream.java

--- src/com/inzyme/typeconv/LittleEndianInputStream.java	28 Oct 2003 17:16:04 -0000	1.1.1.1

+++ src/com/inzyme/typeconv/LittleEndianInputStream.java	30 Oct 2003 20:53:29 -0000

@@ -70,6 +70,8 @@

 			int bytesRead = read(_buffer, pos, _buffer.length - pos);

 			if (bytesRead == -1) {

 				throw new IOException("The connection to the device dropped while attemping to read data from it.");

+			} else	if (bytesRead == 0) {

+				throw new IOException("The connection had no data to read");

 			} else {

 				pos += bytesRead;

 			}

  

So this is a little weird, but I want to keep this on the up-and-up, but while jEmplode is GPL'd, I actually use the library that this class is part of for the Karma as well. Which means that I release it under both a closed source license and a GPL license. This is not a problem in general since nobody has ever submitted a patch for anything in this project so I'm the copyright holder. So my question to you is this -- if I import this fix, it will be available in the GPL version, but I also need your permission to basically own it too, since I have to release this project as part of Rio Music Manager Lite. Does this bother you?

Also -- did I mention that it's terribly evil of javax.comm to be returning 0 bytes read? End of stream is supposed to be -1. Oh well.

ms

I'm happy for you to 'basically own it' - consider copyright assigned or whatever.

It takes quite a while to find the empeg too.
This is because this read blocks for 5 secs or so.
A check for myIS.available() >0 speeds up discovery a lot (30s->5s for me) -- *but* I guess this may be a problem if the serial port is slow?

	public int read(byte[] _buffer) throws IOException {

		int pos = 0;

		while (pos < _buffer.length) {

			if (myIS.available() >0) {

				int bytesRead = read(_buffer, pos, _buffer.length - pos);

				if (bytesRead == -1) {

					throw new IOException("The connection to the device dropped while attemping to read data from it.");

				} else {

					pos += bytesRead;

				}

			} else	{

				throw new IOException("The connection had no data to read");

			}	

		}

		return pos;

	}

mmmm - I'm not sure I like it

Yeah -- in general you can't really trust .available() for breaking out of a read loop ... It's very possible that you have an active connection that just doesn't have anything in the queue yet ... Note that this class is used on all connection types -- serial, usb, and ethernet, all of have pretty different performance characteristics (I would guess ethernet especially would be guilty of failing this test).