Saspy

Added

- `None` Nothing Added

Changed

- `Tweak` The analytic methods all take a SASdata object, or the name of a SAS dataset (str). The method signatures used
['SASdata', str] to represent either/or, not a list. The current Spinx doc build no longer allows that and doesn't generate
signatures, so I hade to replace the [] with (). No programming changes, just a tweak to get the doc to build right with the
newer version of Spinx.

Fixed

- `Fix` Fix for issue 480. No programming changes required.

Removed

- `None` Nothing removed

Added

- `Enhanced` Added another configuration key in the SAS_config_options dictionary for providing an override for the ODS type.
This was already available tochenge as an attribute on the SASSession object, but in a SAS_Kernel notebook, there was no
way to do that. So I added `style` to the config so it could be set when using SAS_Kernel in Jupyter.

Changed

- `Tweak` There are a number of methods which require querying SAS for information which is returned in the LOG and then
parsed out by SASPy. If there's something wrong on the SAS side and somehow the information isn't in the LOG, it can cause
exceptions in the method. I've added code to catch these exceptions and just handle them like an error so processing can
continue. The methods will now just fail and you can look at the log to see what the problem was.

Fixed

- `Fix` There were a couple methods on the SASdata object which, when returning Pandas results, didn't specify the
work library explicitly on the retrieval step. So if there was a user libref assigned, it would look there instead of
work for the data and not find it. All better now.

- `Fix` In the IOM Access Method, the Java IOM Client code does some of the transcoding between Unicode and whatever the
SAS Session Encoding is. If there is a transcode failure, it throws an exception which terminates the Java process and the
SAS server process. I added code to catch this trye of failure, in my Java code, and return the failure, keeping the Java
and SAS processes (and SASPy) going. I don't have a way to change the behavior of the client code, so catching this and
keeping things running are what I can do, which is better than it all terminating out from under SASPy.

- `Fix` And the big fix for this release is for df2sd() and sd2df(), fixing problems when the record length is larger
than the max (32767) for the _infile_ statement, which is used in the SAS code for these methods. This caused problems in
df2sd() if the row length was larger than 32767. There was also an issue that could be hit w/ regards to this in sd2df()
also, so that's addressed with this fix to. This is for all 3 access methods; STDIO, IOM and HTTP.

Removed

- `None` Nothing removed

Added

- `Tweak` Thanks to our graphics design dept for creating a cool logo for SASPy! I added the graphic to the main repo
page (in the readme), and to the saspy-examples repo and to the documentation page. This has nothing to do with the code
or functionality; just a cool logo for SASPy!

Changed

- `Tweak` Changed the prompt in the IOM access method which asks for userid/pw to use 'OMR' instead of 'IOM' since the
configuration keys for user/pw are omruser/omrpw not iomuser/iompw. This has no effect on the code or processing, just
changing the text of the message to better correlate with the right acronym.

- `Tweak` Made a change in the java IOM client code for upload/download to propagate and return the error if there was
a failure during the data transfer phase. Never seen this case happen before, but if it does it should be more clear.

Fixed

- `Fix` Added a check in the HTTP access method in upload and download to see if the status for the HTTP call was an error
and return the failure. Previously it didn't check and just returned success.

- `Fix` Made a change in the HTTP access method's download method to read/write chunks of the data instead of the whole
file to keep from running out of, or using excess, memory in the Python process.

Removed

- `None` Nothing removed

Added

- `New` Per a user request, I added the ability to use sshpass with the STDIO over SSH access method.
This allows you to authenticate with user/pw instead of having to use rsa keys (passwordless shh). There
are now two new keys (see the doc) for providing the path to the sshpass executable and the parameters to use.
The ssh key and other keys for this configuration stay the same.

Changed

- `Enhanced` The sd2df methods require multiple interactions (code submissions) to the SAS server and if any of these
intermediate steps fail or have some issue, then the method invocation fails. But, I wasn't catching these intermediate
problems which could cause non-obvious exceptions and tracebacks which were confusing. I've added code to catch failures
for these intermediate steps and throw a more clear exception if that happens. Nothing about how the methods works has
changed, just better error handling.

- `Enhanced` The code that checks for an 'ERROR:' in the log and issues a warning to alert you to look to see what the
error was, wasn't only looking for it to start in column 1 of the log. So, it could pick up 'ERROR:' in a comment in the
code or anywhere in the log. I've enhanced this to limit false positives by only flagging 'ERROR:' starting in the first
column of the LOG.

- `Tweak` Fixed a typo in an error message.

Fixed

- `Fix` The COM Access Method had a bug where the `encoding` was being used to transcode HTML results returned to
SASPy when it shouldn't, since the HTML results are already utf-8. Other code paths retrieving data from SAS did need to
use the provided encoding for transcoding from SAS Session encoding to utf-8. So, this one path was changed to not try to
transcode the HTML results. This was a fix for issue 454.

Removed

- `None` Nothing removed

Added

- `None` Nothing Added

Changed

- `Tweak` If the initial connection to SAS (a SASsession) fails then there will be a failure error provided, but there
is also an exception thrown in subsequent code, trying to submit some of the initial code to gather info about the
session. This was subordinate and inconsequential, yet was confusing and needed to be addressed. So, in this release, there
is a specific exception being thrown instead of the one that happened to be thrown, which makes the problem more clear.

Fixed

- `Fix` There was an issue opened for the STDIO Access Method where if the code being submitted was longer than 128K,
SASPy would deadlock with SAS due to both being single threaded and the way Pipes work; trying to flush STDIN would block
in SASPy because SAS was blocked on writing to STDOUT/ERR, so they would both deadlock, not being able to read off of the
other Pipes. I reworked how submit works in STDIO, so that there's a blocked amount of STDIN sent before trying to pull off
of both STDOUT and STDERR, iterating till done, to circumvent this behavior. That works great, but it caused issues with
ATTN handling that I support in that Access Method. I needed to rework that to compensate and it's handling it much better.

Removed

- `None` Nothing removed

Added

- `New` I added a new method, lib_path(), off the SASsession object which returns a list of the path(s) for
the libref. Depending upon the engine, 'path' may mean different things. For BASE engines (Linux/PC), it's a directory
or multiple directories if a concatenated libref. For database engines, it varies; may be the database name that you're
connected to. On MVS, it could be then name of a bound library file, or a linux directory path.

Changed

- `Tweak` In the submit method of the HTTP access method, for results='text', I removed extraneous empty lines before
and after the code. These resulted in extra 'return's being submitted. Removing these allows correct behavior when using
saspy to interactively debug (w/ pdb) PROC PYTHON code. With the extra 'return' before and after the command you tried
to submit, pdb executed extra commands. Now it's 1:1 with clean debugging using submit().

Fixed

- `None` No changes

Removed

- `None` Nothing removed