Closed o-smirnov closed 3 years ago
Yeah for sure. I'm starting a 1.2.pre branch to add some new stuff, so the timing will be good. I can make it use JS9 master for now.
In the meantime, I want to push 1.1.2 out as a housekeeping release (somehow a bunch of bugfixes didn't make it in...) very quickly, i.e. this week, so I guess that should stay with 3.2?
Yeah 3.2 should be fine ... it's better to use a version that you yourself trust! But check help/changelog.html for the 2 regressions fixed in 3.3 ... though I doubt you're using either one (drag/drop a FITS file onto the display, then upload it to the server for further analysis). Otherwise 3.3 was just the start of the effort to upgrade underlying socket.io to v3, and 3.4 will be the completion, along with some nice but esoteric region features (grouping regions using boolean expressions).
Cool, let me try 3.3 for the 1.1.2 release, and switch to master for the dev branch.
Sure, but use 3.3.1 in that case ...
Hmm, with 3.3.1 I'm getting an error message that it's failed to connect to the helper. No further info in the console, but I can tell the helper is running, and I can telnet to its port.
So I think I'll stick to 3.2 for the 1.1.2 release (given that there's no pressing bugs that 3.3+ fixes for our use cases), and work with later versions in 1.2.x.
Well ... js9 v3.3.x is the upgrade of socket.io from v2 to v3, so I'm not completely surprised. The nuance with js9 v3.3.x is that I had to maintain both socket.io v2 and socket.io v3, so there is some fiddling to make sure the right one is called, and, though it seemed straight-forward at the time, perhaps that is tripping us up.
The code in the js9 working repository (waiting to be 3.4) only has socket.io v3 (because at some point socket.io v3 was able to support v2 as well), so my first recommendation is to try out the js9 working version and see if that just works. Otherwise or alternatively, if you start the helper with this command:
env DEBUG='*' node js9Helper.js ...
you'll get a pile of debug into from the helper, which we can use to debug things. I'm happy to wait until you are happy before releasing v3.4 ... currently buried in adding an html driver to cfitsio that does not download the whole file at the start ...
btw ... is it possible that when you updated js9 to 3.3.1, you did not restart the helper? Cause then the helper would be listening for v2 connections and and the client would (by default) be connecting using v3 and that will never work ...
No, absolutely not. The helper is started "fresh" in every session (not to mention the many rebuilds in between).
Anyway, no stress, the current bugfix release (1.1.2) is perfectly fine going out with JS9 3.2. I'll do some debugging with 3.4+ on the 1.2.x branch as per your suggestion above. Let's move the discussion to https://github.com/ratt-ru/radiopadre-client/issues/38, as this thread is a bit hard to find.
@o-smirnov Would you care to coordinate the imminent JS9 release 3.4 with your current work? I see you are trying 3.2, but if you want to test out the current JS9 master branch, I would fix any problems and then release 3.4 so that you could just upgrade to that. Alternatively (but less enthusiastically), I could release 3.4 and fix problems for a 3.4.1 patch ...
I'm not adding new stuff to the current JS9 working repository, just fixing problems, in preparation for v3.4 release. In fact, at the moment I've embarked on a quest to make it possible for cfitsio to open and access a FITS file through a web server without having to download the whole thing first. For memory-limited, browser-based analysis, this is becoming increasingly necessary ... no way we'll ever get the 5Gb of Chandra calibration files into the browser ... let alone the 100x larger Lynx files (fingers crossed that the latter will become a real problem!)