Saspy

Added

- `Enhanced` rayewright added a half dozen more ML procs to the sasViyaML package for Viya.


Changed

- `Enhanced` Added documentation specifically identifying datatype conversions between SAS data Sets
and Pandas dataframes; both directions. This was added in the AdvancedTopics section of the doc and the other
couple parts of that section also about data movement were moved to all be contiguous and thus make all more
clear. No code changes, just documentation.

- `Enhanced` Added documentation for the IOM access method regarding authentication. The Configurations
section already specifies how to authenticate with different means, but now there's a part of the doc explicitly
identifying which methods are supported and the one method that is not supported; SAS Token Authentication.

- `Enhanced` andyjessen cleaned up some links in the doc that were still referring to master instead of main
for the branch they linked to.

- `Enhanced` The HTTP access method, to Viya, requires a valid authentication token be passes to every request.
This token is acquired when calling SASsession(). This token had been set to expire after 10 hours. Viya has been changed
to have these tokens expire after 1 hour, so to keep this from causing problems for SASPy sessions, which can be
interactive and last much longer than one hour, I've added support to reauthenticate and get a new authtoken prior
to the current one expiring. This happens as long as the SASsession object is valid and connected. There are no coding
changes required in user code. This should all just happen under the covers with no requirements on the user or program.
I did add a method for explicitly refreshing the authtoken, but that should not be required at any time. But, it may
be of use as a diagnostic in the field if there are ever issues reauthenticating. So, again, no code changes required.


Fixed

- `None` Nothing fixed


Removed

- `None` Nothing removed

Added

- `None` Nothing Added


Changed

- `Tweak` Had a PR with fixes to Doc; mostly typos and consistent use of terms. Also fixed a broken link.


Fixed

- `Fix` Fix for leaked resources. The pipes that are created between subprocess and Python were not being
released prior to subtask termination. This results in a resource leak that is identified when running with
settings that report these issues. I clean this up in both the IOM and STDIO access methods, they each had
similar concerns. No programming changes required.


- `Fix` Fix for issue 487 where, in the df2sd() method, there was data that contained the data step
termination string which resulted in the data step, which was retrieving the data and writing it to the SAS
data step, terminating prior to processing all of the data and then SAS would take the rest of the stream
as SAS code, which fails miserably and consumes memory with all of the errors going to the log. It also
terminates the connection to the client. I've also added code in the java client to catch this kind of
failure so it wouldn't hang, like it was. So this is addressed and fixed in this release, and requires no
programming changes.


Removed

- `None` Nothing removed

Added

- `None` Nothing Added


Changed

- `Tweak` I'm moving to a newer dev environment; newer OS version, newer Python version, and all the newer modules, ...
Using Sphinx to build the doc fails with this newer version, so I've had to tweak and reworks things to get the doc to build
with this newer version of evrerything. So, there were a lot of minor adjustments pushed to accomodate this. It's all working
and, of course, requires no programming changes due to any of this. A plus is that now the index, shown on the left side of the
page, finally has links to the individual methods, in the API section of the doc! This is a welcome enhancement.


Fixed

- `Fix` Fix for issue 480 was in the last version. That issue was a discrepency with how Python on MacOS works compared to
any other operating system. I've had to implement workarounds for Mac Python for a number of issues in the past. This release
has a couple more workarouds for problems with the Mac version of Python too. These are in the IOM access method, whereas the
last versions fix was in the STDIO access method. Again, no programming changes required.

- `Fix` All of the analytic methods correspond to some SAS Procedure. Each method is one analytic PROC. The code that generates
the PROC syntax for all of tese methods is a bit convoluted. While fixing the method signatures for the doc building issues,
last release, I noticed that if the USER librfer is assigned, then none of the analytic method work. I've worked through that code
to resolve this, so in this release, that problem is fixed and they all work as they should have regardless of is USER is assigned
or not.


Removed

- `None` Nothing removed

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