The ragged SPW bonanza

[o-smirnov]

Still some testing and verification to be done, but I wanted @JSKenyon's review to start at his earliest convenience (this being the holidays, this could understandably be delayed...)

[o-smirnov]

retest this please

[o-smirnov]

@Athanaseus try this branch to see if it works around (what we assume is) casacore/python-casacore#130

[JSKenyon]

This looks good to me. Can you confirm that you are happy @o-smirnov? I think this will likely need to wait until all the other tiny PRs in limbo are merged, so there may be a couple of conflicts to resolve.

[o-smirnov]

I'm happy. @Jordatious, does this branch solve your ragged-SPW issues?

[Jordatious]

It's hard to say. I'm just finishing inspecting the results (hence this issue) and then will report on it. It at least ran end-to-end, and peeled the source, but with a lot of junk left over. I'm finding zeros in the data for some reason, so I think perhaps something was funky from before CubiCal ran.

[IanHeywood]

I'm finding zeros in the data

Off-topic, but were there zeros in the data as well as the model?

[Jordatious]

Hard to say from the plots here (data and corrected). Also not sure about DIR1_DATA, only MODEL_DATA at this point. I'll check.

[JSKenyon]

@o-smirnov tests seem to be failing with:

Traceback (most recent call last):
  File "/usr/local/bin/gocubical", line 5, in <module>
    from cubical.main import main
  File "/usr/local/lib/python3.6/dist-packages/cubical/main.py", line 102, in <module>
    from cubical.data_handler.ms_data_handler import MSDataHandler
  File "/usr/local/lib/python3.6/dist-packages/cubical/data_handler/ms_data_handler.py", line 0
SyntaxError: unknown encoding: future_fstrings

I suspect that future_fstrings could be added to setup.py, but I actually think that this is unnecessary. As we are dropping support for Python<3.6 (and soon we may need to consider dropping support for 3.6), there is no need for the backporting. Could you please remove the encodings?

[o-smirnov]

I thought it was in setup.py already? We've been using f-strings all over for quite a while.

I would add it to setup.py and leave it like this for one more release cycle. Once we're fully settled on >3.6, we can sanitize the unnecessary cookies.

[bennahugo]

Please do not drop python3.6 support until we have not switched our production systems to 20.04. I also plan to only support up to 3.6 for the next release of kms and ddfacet so let's keep synergy between the tools.

…

On Wed, 17 Mar 2021, 10:41 JSKenyon, ***@***.***> wrote: @o-smirnov <https://github.com/o-smirnov> tests seem to be failing with: Traceback (most recent call last): File "/usr/local/bin/gocubical", line 5, in <module> from cubical.main import main File "/usr/local/lib/python3.6/dist-packages/cubical/main.py", line 102, in <module> from cubical.data_handler.ms_data_handler import MSDataHandler File "/usr/local/lib/python3.6/dist-packages/cubical/data_handler/ms_data_handler.py", line 0 SyntaxError: unknown encoding: future_fstrings I suspect that future_fstrings could be added to setup.py, but I actually think that this is unnecessary. As we are dropping support for Python<3.6 (and soon we may need to consider dropping support for 3.6), there is no need for the backporting. Could you please remove the encodings? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#424 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB4RE6QGO5DPTKHHJC42TR3TEBTM7ANCNFSM4VBQTC5Q> .

[JSKenyon]

I have not done anything to 3.6 functionality, I was just saying that we will likely be forced to drop it in the near future due to upstream pressure. future-fstrings is only necessary for <3.6. Given that those versions are not supported, we don't need it. I have removed the two -*- coding: future_fstrings -*- that crept in with this PR and will see if the tests run through.

[o-smirnov]

Ah. Well if it's only <=3.5 that's being affected, then let it burn indeed!

[JSKenyon]

Wehey! It worked.

[JSKenyon]

I will leave pushing the button to you @o-smirnov, once you are happy that the issues @Jordatious is still seeing are not in some way related to these changes.