OK, this is ready for testing and review. I have updated the top comment with info on the changes.

Has anyone else had a chance to look at this yet? @scztt and I walked through the logic together and found small issues with GC and state that I've taken care of in the last few commits. It would be nice if someone could try hooking it up to a pre-existing system (Arduino, etc.) to do some real-world sanity testing.

have verified the tests pass on Linux. going to get a Windows build up this week and test out with an arduino.

okay i am STILL getting set up on windows because i am a dumb ass of life, but i have gotten a chance to test reading and writing bytes on linux with an actual arduino uno.

serialtest.ino:

void setup() {
  Serial.begin(9600);
}

int incomingByte = 0;
void loop() {
  if (Serial.available() <= 0) {
    return;
  }
  incomingByte = Serial.read();
  Serial.print("I received: ");
  Serial.println(incomingByte, DEC);
}

supercollider code:

(
var port;
port = SerialPort("/dev/ttyACM0", baudrate: 9600);

Routine.run {
    var character, line;
    loop {
        character = port.read.asAscii;
        (character == $\n).if {
            line.notNil.if { line.join("").postln };
            line = List[];
        } {
            line.add(character);
        };
    };
};

Routine.run {
    var i = 0;
    loop {
        port.put(i);
        i = i + 1;
        1.wait;
    };
};
)

i haven't tested every implemented feature, but this is good news -- seems to be working great.

update: got it working on windows!

one bug is that we don't have SerialPort.devices on windows. i am digging into how the arduino IDE discovers serial ports. here is the arduino IDE serial port discoverer, and here is the windows-specific code it uses in the JSSC library.

EDIT: the latter link tells us that we can get a list of devices, identical to that of the arduino IDE, by running

reg query HKLM\HARDWARE\DEVICEMAP\SERIALCOMM\

so all we have to do is parse this.

latest commit has a minor API change -- i improved the matching rules for SerialPort.devices for macOS and linux so they're (as far as i can tell) identical to the rules used in arduino. i marked SerialPort.devicePattern as legacy for reasons explained in the docs and my commit messages. i also deprecated passing an integer to the port argument of SerialPort.new, which is a really brittle and unnecessary convenience.

in the interest of pushing this along, i have commented out a nonfunctioning unit test and have used guard clauses to skip the tests if we're on Windows or if the "socat" utility is not installed.

Updated the tests, I believe based on the discussion at the dev meeting that this should be good to go now.

Just saw that this is going on, great work!

Some remarks (without having tested things yet; I'm quite out of sync with the latest SC developments):

• devicePattern: this is quite useful, as e.g. on Linux you can also look at /dev/serial/by-id/* instead of /dev/ttyUSB* with the advantage that the first uses fixed names based on the actual device, and the ttyUSB ones are in order of plugging in. (For installations that need to run unattended, I usually use the first one).
• was a test done where the device gets unplugged? This is what I originally implemented the doneAction for, for accidental device removal or similar, so that you can assign an action to catch that issue (like starting a task that will look for the device to come back).

Just saw that this is going on, great work!

Some remarks (without having tested things yet; I'm quite out of sync with the latest SC developments):

• devicePattern: this is quite useful, as e.g. on Linux you can also look at /dev/serial/by-id/* instead of /dev/ttyUSB* with the advantage that the first uses fixed names based on the actual device, and the ttyUSB ones are in order of plugging in. (For installations that need to run unattended, I usually use the first one).

I'm not sure if there is a question here?

• was a test done where the device gets unplugged? This is what I originally implemented the doneAction for, for accidental device removal or similar, so that you can assign an action to catch that issue (like starting a task that will look for the device to come back).

Yes, that is what test_connectionLost does.

devicePattern: this is quite useful, as e.g. on Linux you can also look at /dev/serial/by-id/* instead of /dev/ttyUSB* with the advantage that the first uses fixed names based on the actual device, and the ttyUSB ones are in order of plugging in. (For installations that need to run unattended, I usually use the first one).

thanks for looking at the PR. i changed the device matching behavior, so i should be the one to justify it.

SerialPort.devices was just a thin wrapper around pathMatch. a minor problem is that this thin wrapper isn't necessary: you can just use pathMatch if you want a custom path matching operation.

a major problem is that pathMatch isn't adequate to actually match all the devices we want on all platforms. for macOS and linux, a full-on regexp is needed (pathMatch isn't a regexp, it's a file glob, so there is no way to match e.g.(ttyS|ttyUSB|ttyACM|ttyAMA|rfcomm|ttyO)[0-9]{1,3}). for Windows, we need to make a system call and read the windows registry to figure out what serial ports we have, which is definitely out of the file globbing league.

the serial port primitives aren't coupled to the device matching behavior. SerialPort.new doesn't care if the device you pass in wouldn't be matched by one of the built-in heuristics. so if you need a special file glob, you can just run "/dev/serial/by-id/*".pathMatch, pick a device name, and pass it into SerialPort.new.

due to the complete decoupling of device matching and serialport creation, there really isn't any need for a user to customize SerialPort.devices -- the user should just swap it out for their own path matching and SerialPort.new will be fine with it. hope that makes sense.

ok. that makes sense.
Thanks for the explanation!