Problems on Windows 10

[kristiank]

Web version

When I start the web application (using start.bat), the terminal eventually launches a web browser but it shows only the black background and nothing more. Inspecting the terminal window I couldn't see anything that indicates any errors.

Stand-alone version

When I start the application it shows the jumping robot and loads the IDE nicely. But in the IDE the connect button is not clickable, it seems if it was deactivated (the button maybe has a darker shade of green than in another Linux computer's IDE). This happens for both the 32 and 64 bit version.

Is this related to the issue mentioned in #40, or does it indicate that Java is missing? I can't find any error messages indicating that, but I don't really know for sure whether Java is installed or not (it's not my computer). Any thoughts?

[RichoM]

That's weird. I don't think it is related to #40 because in that case the connect button was enabled, it just didn't work.

I also don't think it's missing java because if that were the case it wouldn't even open the IDE (I think, I'm not sure).
Just to be sure, could you test with this version? It should work even if you don't have java installed on your computer:
https://drive.google.com/file/d/1lkd2goKKpaUwiqJ9Ul8GuJSA_wXPA_Ol/view?usp=sharing

Also, we might find more info in the application logs. I keep them in the "log" folder for the web version and in "resources/app/log" for the standalone version. You should also find them if you search for "uzi.log".

[RichoM]

Please dismiss the link I sent you in the previous comment. I've published a new release anyway so if you can please test with the latest release. Thanks!

[kristiank]

I now tried with the latest release from the download page. This version allowed to press the Connect-button, but for the three available entries reported on the port list, the COM9 and 127.0.0.1:4242 did not connect and COM3 never reported back and we had to restart the program again. I was quite sure making the connection uses some kind of timer, because of the translations includes "Connection timeout", but this never seemed to happen when we tried. I was able to connect the board to my GNU/Linux computers with no problems.

I attach the log file uzi.log, hopefully it reveals the problem.

[RichoM]

I really have no idea what is going on. And I don't have a Windows 10 computer to test at the moment. I think I'll be able to get one this weekend, though. Hopefully I'll be able to reproduce the error.

[RichoM]

I have good news and bad news.

The good news is that I was able to reproduce the bug without a Windows 10 computer. I mistakenly tried to open the COM6, which in my computer is paired to a bluetooth device that is turned off, and the behavior was almost exactly as you described. It seems that when trying to open this port the control in never returned to the program so the thread is stuck.

I first tried open the port on a new thread so that I could forcefully terminate it if gets stuck. However, if I did that I could regain control but the serial library would get stuck in a loop and wouldn't connect to any port anymore, leaving the application in an invalid state. I believe the problem (and potential solution) is explained here: nyholku/purejavacomm#106. It seems we would have to change the timeout argument to 0 to avoid getting stuck in the loop.

Unfortunately, an these are the bad news, the library we're using (which is effectively a wrapper of purejavacomm) doesn't allow to specify the timeout parameter. I don't know why the author made this decision, but it seems we're not alone with this problem because the only open pull request in the library's repository is exactly what we need: the ability to specify the timeout parameter (peterschwarz/clj-serial#15). However the pull request is still not merged after two years.

So, one alternative would be to fork the clj-serial library and merge the pull request myself, which I don't want to do. Another idea would be to use purejavacomm directly and avoid clj-serial altogether, which I also don't want to do. A third option would be to make our own version of the serial.core/open function and use that instead of the original one. Then we can change it to accept the timeout as parameter. It would be an ugly hack but I think it would work, at least until the clj-serial maintainer merges the pull request.

I have tested this and it doesn't leave the application in an irrecoverable state after attempting to open a non-responsive blueetooh serial port. However, I'm a little worried about just changing the timeout to 0 so I'll probably make it configurable.

There seems to be a problem with the close function as well, but in my computer it manifests with COM7 (another bluetooth port). This problem seems to be related but I haven't figured it out yet. I'll see if I can fix it after the holidays.

Merry Christmas!