Saspy

Added

- `None` Nothing added

Changed

- `Enhancement` Per user request, I've added the ability to request a keepalive thread in the IOM access method.
The workspace server has a timeout option (defined in metadata), which usually defaults to 60 minutes. If no interaction
happens in that amount of time since the last interaction, the Workspace server will terminate itself. I've added an
option `keepalive` for the IOM access method that can be defined in the Configuration Definition or on SASsession(keepalive=50) to
specify you want this thread created and how many minutes in between interactions. So, if you're Workspace server has
a timeout of 60 min, you can specify `'keepalive' : 50,` in your config def to have saspy send a request every 50 min
so the timeout doesn't happen, and keep your session connected until you terminate it. The default is, of course, the
current behavior which is no keepalive thread.


Fixed

- `None` Nothing fixed

Removed

- `None` Nothing removed

Added

- `None` Nothing added

Changed

- `Enhancement` Per user request, I've added the ability to CANCEL submit()'ed code in both the IOM and HTTP
access methods. Until now you would see a message like the following if you tried to interrupt a submit:
`SAS attention handling is not yet supported over IOM. Please enter (T) to terminate SAS or (C) to continue.`
But now, with the ability to cancel long running code, you will see something like this instead:
`Please enter (T) to Terminate SAS or (C) to Cancel submitted code or (W) continue to Wait.`
If you choose 'C' then I can now use the API to tell the server to terminate whatever was being executed and
come back immediately, so you can then run other code. Also, for IOM, I cancel any code in endsas() so that the
workspace server terminates immediately instead of only after whatever is running finishes.


Fixed

- `None` Nothing fixed

Removed

- `None` Nothing removed

Added

- `None` Nothing added

Changed

- `Enhancement` Per user request, I've added the ability to have the SASLOG returned from the submit methods
be HTML with ERROR:, WARNING: and NOTE: lines colorized like in other SAS UI's. This is how the SAS_Kernel for
Jupyter colors it's LOG and how the log returned in the SAS_Results object in SASPy colors that log too. This
feature requires the Pygments package, so it is only available if that package in installed, else you get the
current behavior. The new `colorLOG` configuration key is how to set this. It's a boolean and defaults to False;
existing behavior. It can be specified in the Configuration Definition or on SASsession, like any other key.

Fixed

- `None` Nothing fixed

Removed

- `None` Nothing removed

Added

- `None` Nothing added

Changed

- `Tweak` A user contribution enhanced an error case where parsing an empty log due to the SAS session
being terminated returned a less than helpful error in the exception. This now would return a clear error
as to the problem.


- `Enhancement` Regarding a SAS process unexpectedly terminating out from under SASPy, you may have seen this or a similar
error message before: "No SAS process attached. SAS process has terminated unexpectedly." along with an arbitrary exception.
I've enhanced this case, like many other situations to now throw a new exception, SASIOConnectionTerminated, and to log the
message(s) previously returned (logger.fatal()). This should really have always been an exception as it is a fatal case where
the SAS session is no longer functional, since there's no SAS process connected anymore.


Fixed

- `None` Nothing fixed

Removed

- `None` Nothing removed

Added

- `None` Nothing added

Changed

- `Tweak` Databricks finally enabled IPython support which allows for HTML rendering from w/in SASPy,
like in both Jupyter and Zeppelin (Zeppelin has its own rendering, but SASPy supports it). So now
display='databricks' will just use the same code as display='jupyter' so HTML can finally be rendered
for you by SASPy instead of having to run batch mode to get the HTML returned to you and then you having
to pass it to their displayHTML() method.

Fixed

- `None` Nothing fixed

Removed

- `None` Nothing removed

Added

- `None` Nothing added

Changed

- `None` Nothing changed

Fixed

- `Fixed` The upload method wasn't validating that the file was uploaded successfully after the fact.
It has a number of checks up front, and if there's a failure, it could return Success=False, but each
access method is different and they didn't each get a failure the same way. So I added a more explicit
validation after the upload is completed, to prove the file really made it or not. For the HTTP access
method, I also mitigated a situation where the Compute server process could be killed for trying to
access a restricted path. Now that just gets a clean failure with a message about the problem.

Removed

- `None` Nothing removed