absolute_file_name/2
has changed slightly.
It no longer looks for an existing file with a `.pl' extension
if the given relative file name has no extension. The old behavior
can be achieved with:
old_absolute_file_name(RelFileSpec, AbsFileName) :- Options = [ file_type(source), access(exist), file_errors(fail) ], ( absolute_file_name(RelFileSpec, AbsFileName, Options) -> true ; absolute_file_name(RelFileSpec, AbsFileName, []) ).
debugger_command_hook/2
takes a different first
argument.
print_message/2
does not take a force/1
severity.
stream_interrupt/3
and stream_select/3
were unsafe, and have been removed. The latter can be replaced
by the following equivalent definition, which
works for file descriptor streams under UNIX and, for socket streams, under
Windows as well:
:- use_module(library(sockets)). stream_select(Streams, TimeOut, ReadStream) :- socket_select([], _, TimeOut, Streams, ReadStream).
link_foreign_resource/6
,
are prepare_resource_table/2
, and
prepare_foreign_resource/3
. See The Foreign Resource Linker, for
details on using splfr.
reinitialise/0
is gone.
apply_bound/1
API for branch & bound search has been
replaced by predicates called first_bound/2
and
later_bound/2
.
all_different/[1,2]
and
all_distinct/[1,2]
require bounded domains.
serialized/[2,3]
and
cumulative/[4,5]
only prune the bounds of domains,
not inside them, unless the bounds_only(false)
option is given.
library(db)
has been removed.
library(xref)
has been replaced.
library(flinkage)
is no longer supported. It is still present to
help porting really old code.
jasper_call/4
introduced in
SICStus 3.8.5 so you should migrate your code even if you are still
using SICStus 3.8.
se.sics.jasper
that operate on a SICStus
object will now throw an error if called from a thread other
than the one that created the SICStus object. This is similar to the
behavior in early versions of 3.8.
SICStus 3.9 introduces a new thread safe Jasper API, which is not backwards compatible with the Jasper API of 3.8. However, the old API has been amended to be compatible with the thread safe API, making it possible to write Java programs that can run in both modes.
SP_signal()
are now deferred until
Prolog can call them safely. This makes SP_signal()
unsuitable for
handling synchronous signals such as `SIGSEGV'. See Signal Handling.