Fix imexam on NumPy 2

[jehturner]

A one-line fix for #181, issue 2 (the same as in the copy of numdisplay bundled with DRAGONS) -- because NumPy 2 no longer allows implicit downcasting when creating an array.

I notice that you have int16 here, whereas the same code in numdisplay had uint16. IRAF's implementation of the IIS prtocol appears to munge both 18-bit(!) control codes >32767 (or even >65535) and also negative values into 16 bits, so I don't think either is obviously correct, nor that it really matters, as long as we send the expected sequence of 16 bits to the display tool, so I've kept the type as you had it... Should you wish to balk at that, you're welcome to refer to the following, but I think we'll have to concede that it does the same as before and works again :wink::

https://noirlab.edu/science/sites/default/files/media/archives/documents/scidoc3024.pdf

Thanks!

James.

[olebole]

Hi James, sorry that I didn't answer earlier; I was too busy.

Thank you for your patch! On the first view, it seems to work. Checking the surrounding code, I think however that np.int16 isn't correct (and never was), it should really be np.uint16 as in numdisplay. https://github.com/iraf-community/pyraf/blob/93d93bf2e5554726857b14b9fd51fc4c7ac262e2/pyraf/irafdisplay.py#L147-L156

The calculated checksum sum may cover the the range 0…65535. If a is np.int16, then any value above 32767 will raise an OverflowError when it is assigned to a[3]. Also, the last line makes clear that it is to be interpreted just as bytes at the end. I'd think that np.uint16 would be the naturally correct choice here; the checksum doesn't change with either.

I took the opportunity and checked the older changes of dragon's numdisplay. One that is not in PyRAF yet is https://github.com/GeminiDRSoftware/DRAGONS/commit/2b572bca67fa33843b5da1c2f90b4485c4d44a22 from @KathleenLabrie:

--- a/gempy/numdisplay/displaydev.py
+++ b/gempy/numdisplay/displaydev.py
@@ -299,7 +299,12 @@ def readCursor(self,sample=0):
         s = self._read(self._SZ_IMCURVAL)
         self._inCursorMode = 0
         # only part up to newline is real data
-        return s.split("\n")[0]
+        try:
+            coo = s.split("\n")[0]  # works in Py2
+        except TypeError:
+            coo = s.decode("utf-8", "ignore").split("\n")[0]  # works in Py3
+        return coo
+        #return s.split("\n")[0]

Would you think this should be applied as well (without the Python-2-compability)? This could resolve the first problem, whoever I would then expect that there was an exception visible.

[olebole]

I took the opportunity and checked the older changes of dragon's numdisplay. One that is not in PyRAF yet is https://github.com/GeminiDRSoftware/DRAGONS/commit/2b572bca67fa33843b5da1c2f90b4485c4d44a22 from @KathleenLabrie

I just checked this: in PyRAF, the cursor is readout by a function that came from stsci.tools https://github.com/iraf-community/pyraf/blob/032e6081fecb776f0c7548fe19b8bd4078c04c3a/pyraf/tools/irafutils.py#L431-L470 At the time when this function was moved to PyRAF, STScI already added Python-3 compability by changing the output to a str, so the code in irafutils.py doesn't need to decode.

So, I would just ask @jehturner to change the array type to numpy.uint16.