[erlang-questions] [erlang-announce] Erlang OTP 22.0-rc2 is available for testing!

Tue Apr 9 16:04:56 CEST 2019

On mån, 2019-04-08 at 12:54 -0700, Michael Truog wrote:
> On 3/26/19 8:47 AM, Kenneth Lundin wrote:
> > OTP 22 Release Candidate 2
> > This is the second of three planned release candidates before the OTP 22
> > release.
> > The intention with this release is to get feedback from our users. All
> > feedback is welcome, even if it is only to say that it works for you, as it
> > lets us know that the release candidate got some testing.
> > Erlang/OTP 22 is a new major release with new features and improvements as
> > well as incompatibilities.
> > Potential Incompatibilities
> > gen_* behaviours: If logging of the last N messages through sys:log/2,3 is
> > active for the server, this log is included in the terminate report.
> > reltool: A new element, Opts, can now be included in a rel tuple in the
> > reltool release specific configuration format: {rel, Name, Vsn, RelApps,
> > Opts}.
> > All external pids/ports/refs created by erlang:list_to_pid and similar
> > functions now compare equal to any other pid/port/ref with same number from
> > that node.
> > The old legacy erl_interface library is deprecated as of OTP 22, and will be
> > removed in OTP 23. This does not apply to the ei library.
> > VxWorks is deprecated as of OTP 22 and will be removed in OTP 23.
> > Additional highlights in release candidate 2
> > A simple socket API is provided through the socket module. This is a low
> > level API that does *not* replace gen_[tcp|udp|sctp]. It is intended to
> > *eventually* replace the inet driver. It also provides a basic API that
> > facilitates the implementation of other protocols than TCP, UDP and SCTP.
> > Known issues are; No support for the Windows OS (currently), a small term
> > leakage. This feature will be classed as experimental in OTP 22.
> > ssl: Basic support for TLS 1.3 Server for experimental use.
> > In OTP 22, HiPE (the native code compiler) is not fully functional. The
> > reasons for this are new BEAM instructions for binary matching that the HiPE
> > native code compiler does not support. If erlc is invoked with the +native
> > option, and if any of the new binary matching instructions are used, the
> > compiler will issue a warning and produce a BEAM file without native code.
> > erts: Added the NIF function enif_term_type, which helps avoid long
> > sequences of enif_is_xyz by returning the type of the given term. This is
> > especially helpful for NIFs that serialize terms, such as JSON encoders,
> > where it can improve both performance and               readability.
> > crypto: The new hash_info/1 and cipher_info/1 functions returns maps with
> > information about the hash or cipher in the argument.
> > Highlights in release candidate 1
> > Erts:
> > Support for Erlang Distribution protocol to split the payload of large
> > signals into several fragments.
> > ETS option write_concurrency now also effects and improves scalability of
> > ordered_set tables.
> > The length/1 BIF used to calculate the length of the list in one go without
> > yielding, even if the list was very long. Now it yields when called with
> > long lists.
> > A new (still experimental) module socket is introduced. It is implemented as
> > a NIF and the idea is that it shall be as "close as possible" to the OS
> > level socket interface.
> > Compiler:
> > The compiler has been rewritten to internally use an intermediate
> > representation based on Static Single Assignment (SSA). The new intermediate
> > representation makes more optimizations possible.
> > The binary matching optimizations are now applicable in many more
> > circumstances than before.
> > Type optimizations are now applied across local function calls, and will
> > remove a lot more redundant type tests than before.
> > All compiler options that can be given in the source file can now be given
> > in the option list on the command line for erlc.
> > Standard libraries:
> > Cover now uses the counters module instead of ets for updating counters. The
> > new function cover:local_only/0 allows running Cover in a restricted but
> > faster local-only mode. The increase in speed will vary depending on the
> > type of code being cover-compiled, as an example the compiler test suite
> > runs more than twice as fast with the new Cover.
> > SSL now uses the new logger API, including log levels and verbose debug
> > logging.
> > For more details see
> > http://erlang.org/download/otp_src_22.0-rc2.readme
> > Pre built versions for Windows can be fetched here:
> > http://erlang.org/download/otp_win32_22.0-rc2.exe
> > http://erlang.org/download/otp_win64_22.0-rc2.exe
> > Online documentation can be browsed here:
> > http://erlang.org/documentation/doc-11.0-rc2/doc
> > The Erlang/OTP source can also be found at GitHub on the official Erlang
> > repository:
> > https://github.com/erlang/otp
> > OTP-22.0-rc2
> >   Thank you for all your contributions!
> > 
> > 
> > _______________________________________________
> > erlang-announce mailing list
> > erlang-announce@REDACTED
> > http://erlang.org/mailman/listinfo/erlang-announce> >  id="-x-evo-selection-
> > start-marker">
>  Hi Kenneth,
> It looks like the Erlang Binary Term Format change previously added in 19.0rc-
> 1 was never documented (to cause the creation integer to be 32bits for pids,
> ports and refs) though the new format is being forced with a recent commit for
> 22.0rc-2 (https://github.com/erlang/otp/commit/78ea501bcc84bd8bd49da97e514c1c3
> b20682d86).  The change wasn't announced in your email, nor the necessity of
> the switch to NEW_PID_EXT/NEW_PORT_EXT/NEWER_REFERENCE_EXT for all future
> Erlang integration.
> 
The missing documentation was clearly a mistake. Thanks for pointing that out,
Michael.
The revised plan now is to
1. Revert the removal of encoding the old pid/port/ref tags for OTP 22.
2. Document NEW_PID_EXT/NEW_PORT_EXT/NEWER_REFERENCE_EXT which have existed
since OTP 19.
3. Mark the old as deprecated and announce for upcoming removal of old encoding
in OTP 23.
 
/Sverker
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20190409/c8d615f6/attachment.htm>