V5.11.0

[5.11.0] - 2024-04-16

Added

• Enhancement Per internal tester request, I've added an option for the STDIO access method to provide an amount of time for
  SAS to terminate before killing the process, in the endsas() method. I've always waited up to 5 seconds from the subprocess
  to terminate after requesting SAS shutdown, which is normally fine. If it takes longer, I kill the process. In this case,
  SAS runs with some internal testing options which causes processing at termination, and takes longer than 5 seconds. So I've
  added an option to allow me to wait longer before terminating the process which will allow this extra termination processing
  to complete. This isn't a usual option customers would set, but it's there either way. The option is termwait and it takes an
  integer number of seconds. In this case, the config def required: 'termwait': 60, to get it to work as expected.

Changed

• None Nothing changed

Fixed

• None Nothing fixed

Removed

• None Nothing removed

V5.10.0

[5.10.0] - 2024-04-09

Added

• None Nothing added

Changed

• None Nothing changed

Fixed

• None Nothing fixed

Removed

• Enhancement Per user request, I've added the ability to request a keepalive thread in the IOM access method.
  I added this in V5.9.0, but then found that this could deadlock the IOM access method if the keepalive thread executed while in the middle
  of one of my SASPy methods; which I didn't think would be the case, but I didn't happen to have it happen. When it
  does, it can deadlock everything. So, I'm removing this feature with this release. It just doesn't work as expected.

V5.9.0

[5.9.0] - 2024-04-08

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

V5.7.0

[5.7.0] - 2024-03-19

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

V5.6.0

[5.6.0] - 2024-02-05

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

V5.5.0

[5.5.0] - 2024-01-09

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

New Contributors

• @bagerard made their first contribution in #569
• @Sleemanmunk made their first contribution in #573

V5.4.4

[5.4.4] - 2023-11-02

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

V5.4.3

[5.4.3] - 2023-10-27

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

V5.4.2

[5.4.2] - 2023-10-18

Added

• None Nothing added

Changed

• None Nothing changed

Fixed

• Fixed Found a SAS code gen syntax error in the HTTP access method causing an error in the log
  for sd2df. Needed to quote the fileref in a function. So, fixed that syntax error in that method.

Removed

• None Nothing removed

V5.4.1

[5.4.1] - 2023-10-06

Added

• None Nothing added

Changed

• Tweak Added to the doc for the HTTP access method, adding the 'refreshtoken' keyword which goes along with the
  'authtoken' keyword if you did your own authentication to SASLogon. Refreshtoken was added when authtoken was, I just
  didn't get it in the doc then.

Fixed

• Fixed Based upon Issue 562, I enhanced sd2df() to allow you to provide 'errors=' as a keyword parameter which is
  used in the decode() method when converting the bytes being streamed across to characters. The errors keyword determines
  how transcoding failures are handled; the default being failure. See bytes.decode() in the Python doc for valid values.

Removed

• None Nothing removed