Erlang/OTP 21.0-rc1 (Release Candidate)

Erlang/OTP 21.0-rc1 (Release Candidate)

OTP 21 Release Candidate 1

This is the first of two planned release candidates before the OTP 21
release. The intention whit this release is that you as users try it
and give us feedback if something does not work as expected. Could be a
bug,an unexpected incompatibility, a significant change of
characteristics in a negative direction, etc.

Erlang/OTP 21 is a new major release with new features, improvements as
well as incompatibilities.

Potential Incompatibilities

* All Corba applications are now moved from the OTP repository
* A new Corba repository will be created https://github.com/erlang * New applications ftp and tftp, moved from inets
* ssl no longer supports 3_DES cipher suites or RSA-key exchange
cipher suites by default
* erlang:monitor on a primitive node (erl_interface, jinterface, etc)
will no longer fail with badarg exception. Instead a monitor will be
created, but it will only supervise the connection to the node.

Compiler:
* Misc compiler optimizations including contributions from the
Elixir team resulting in 10% improvements in benchmarks
* "Tuple calls" have been removed from the run-time system.
* Code such as f({ok, Val}) -> {ok, Val} is now automatically
rewritten to f({ok, Val} = Tuple) -> Tuple. this reduces code
size, execution time, and removed GC pressure.
* More information in stacktrace from a number of operators
* erlang:get_stacktrace/0 deprecated to be replaced with try ...
catch C:R:Stacktrace -> ...
* Creation of small maps with literal keys optimized.

Security:
* DTLS support in SSL
* Enhanced support for distribution over TLS
* "unsecure" ciphers removed from defaults in SSL and SSH.
* A new option value defined to facilitate implementing exec
servers. Old option kept for compatibility, but now gives errors
on stderror.

For languages that support currying and partial-application easily, there is one compelling series of arguments, originally from Chris Okasaki:

Put the data structure as the last argument

Why? You can thencompose operations on the datanicely. E.g.insert 1 $ insert 2 $ insert 3 $ s. This also helps forfunctions on state.Standard libraries such as "containers"follow this convention.Alternate arguments are sometimes given to put the data structure first, so it can be closed over, yielding functions on a static structure (e.g. lookup) that are a bit more concise. However, the broad consensus seems to be that this is less of a win, especially since it pushes you towards heavily parenthesized code.

Put the most varying argument last

For recursive functions, it is common to put the argument that varies the most (e.g. an accumulator) as the last argument, while the argument that varies the least (e.g. a function argument) at the start. This composes well with the data structure last style.

For languages that support currying and partial-application easily, there is one compelling series of arguments, originally from Chris Okasaki:

Put the data structure as the last argument

Why? You can thencompose operations on the datanicely. E.g.insert 1 $ insert 2 $ insert 3 $ s. This also helps forfunctions on state.Standard libraries such as "containers"follow this convention.Alternate arguments are sometimes given to put the data structure first, so it can be closed over, yielding functions on a static structure (e.g. lookup) that are a bit more concise. However, the broad consensus seems to be that this is less of a win, especially since it pushes you towards heavily parenthesized code.

Put the most varying argument last

For recursive functions, it is common to put the argument that varies the most (e.g. an accumulator) as the last argument, while the argument that varies the least (e.g. a function argument) at the start. This composes well with the data structure last style.

Re: Erlang/OTP 21.0-rc1 (Release Candidate)

In Kernel User's Guide new logger API chapter
"2.6 Example: implement a handler"
callback function 'removing_handler' is documented to accept single
parameter logger:handler_id(),
but in the example for handler that prints to file it takes two
parameters (Id and Config).

The current implementation seems to call this function with single
parameter HandlerId, but that makes not possible to cleanly close the
file descriptor as shown in the example.

> OTP 21 Release Candidate 1
>
> This is the first of two planned release candidates before the OTP 21
> release. The intention whit this release is that you as users try it
> and give us feedback if something does not work as expected. Could be a
> bug,an unexpected incompatibility, a significant change of
> characteristics in a negative direction, etc.
>
> Erlang/OTP 21 is a new major release with new features, improvements as
> well as incompatibilities.
>
> Potential Incompatibilities
>
> * All Corba applications are now moved from the OTP repository
> * A new Corba repository will be created https://github.com/erlang> * New applications ftp and tftp, moved from inets
> * ssl no longer supports 3_DES cipher suites or RSA-key exchange
> cipher suites by default
> * erlang:monitor on a primitive node (erl_interface, jinterface, etc)
> will no longer fail with badarg exception. Instead a monitor will be
> created, but it will only supervise the connection to the node.
>
> Highlights
>
> Erts:
>
> * Enhanced IO scalability
> * Support for usage of distribution controller processes for
> alternative transports, routing etc
> * compact instructions on 64bit systems for code below 4GB 20% less
> memory for loaded code
> * Rewrite of the efile-driver with NIFs and "Dirty schedulers"
> resulting in faster file operations
> * non-smp VM removed
> * link and monitor optimized for scalability
> * os:getenv/putenv now work on thread-safe emulation. No longer in
> sync with libc getenv(3). Manual synchronization will be needed.
>
> Compiler:
> * Misc compiler optimizations including contributions from the
> Elixir team resulting in 10% improvements in benchmarks
> * "Tuple calls" have been removed from the run-time system.
> * Code such as f({ok, Val}) -> {ok, Val} is now automatically
> rewritten to f({ok, Val} = Tuple) -> Tuple. this reduces code
> size, execution time, and removed GC pressure.
> * More information in stacktrace from a number of operators
> * erlang:get_stacktrace/0 deprecated to be replaced with try ...
> catch C:R:Stacktrace -> ...
> * Creation of small maps with literal keys optimized.
>
> Security:
> * DTLS support in SSL
> * Enhanced support for distribution over TLS
> * "unsecure" ciphers removed from defaults in SSL and SSH.
> * A new option value defined to facilitate implementing exec
> servers. Old option kept for compatibility, but now gives errors
> on stderror.
>
> Standard libraries:
> * New API for logging, logger
> * New uri_string module for parsing URIs according to "The
> standard"
> * New function lists:search(list,fun/1) -> {ok, Value} | false
> * Changed default behaviour of .erlang loading. escript, erlc,
> dialyzer and typer no longer load an .erlang at all.
>
> For more details see
> http://erlang.org/download/otp_src_21.0-rc1.readme>
> Pre built versions for Windows can be fetched here:
> http://erlang.org/download/otp_win32_21.0-rc1.exe> http://erlang.org/download/otp_win64_21.0-rc1.exe>
> Online documentation can be browsed here:
> http://erlang.org/documentation/doc-10.0-rc1/doc/>
> The Erlang/OTP source can also be found at GitHub on the official
> Erlang repository,
> https://github.com/erlang/otp with tag OTP-21.0-rc1
>
>
> Thank you for all your contributions!
> _______________________________________________
> erlang-questions mailing list
> [hidden email]> http://erlang.org/mailman/listinfo/erlang-questions>

Re: Erlang/OTP 21.0-rc1 (Release Candidate)

On 05/03/2018 01:54 PM, Loïc Hoguin wrote:

> Hello!
>
> Just a quick heads up, having a couple issues:
>
> * It doesn't compile on FreeBSD. I can get you more details later but
> "kerl build git https://github.com/erlang/otp OTP-21.0-rc1 OTP-21.0-rc1"
> might be a quicker alternative.
>
> * SSL is broken. See [1] for example. I can see the same thing happening
> on 5 different Linux distributions (with different OpenSSL versions) and
> on OSX. A quick try in the shell is not much better:
>
> 1> ssl:start().
> ok
> 2> ssl:connect("google.com", 80, []).
> {error,{tls_alert,"bad record mac"}}

That one was a brain fart. This works when the port is correct.

> Keep up the good work!
>
> [1]
> https://builds.ninenines.eu/logs/ranch/78/ubuntu/ct_run.ct_ranch@ubuntu0.2018-05-03_11.12.51/ninenines.ranch.acceptor_SUITE.logs/run.2018-05-03_11.12.52/acceptor_suite.ssl_echo.html>
>
> On 05/02/2018 01:37 PM, Henrik Nord X wrote:
>> OTP 21 Release Candidate 1
>>
>> This is the first of two planned release candidates before the OTP 21
>> release. The intention whit this release is that you as users try it
>> and give us feedback if something does not work as expected. Could be a
>> bug,an unexpected incompatibility, a significant change of
>> characteristics in a negative direction, etc.
>>
>> Erlang/OTP 21 is a new major release with new features, improvements as
>> well as incompatibilities.
>>
>> Potential Incompatibilities
>>
>> * All Corba applications are now moved from the OTP repository
>> * A new Corba repository will be created https://github.com/erlang>> * New applications ftp and tftp, moved from inets
>> * ssl no longer supports 3_DES cipher suites or RSA-key exchange
>> cipher suites by default
>> * erlang:monitor on a primitive node (erl_interface, jinterface, etc)
>> will no longer fail with badarg exception. Instead a monitor will be
>> created, but it will only supervise the connection to the node.
>>
>> Highlights
>>
>> Erts:
>>
>> * Enhanced IO scalability
>> * Support for usage of distribution controller processes for
>> alternative transports, routing etc
>> * compact instructions on 64bit systems for code below 4GB 20% less
>> memory for loaded code
>> * Rewrite of the efile-driver with NIFs and "Dirty schedulers"
>> resulting in faster file operations
>> * non-smp VM removed
>> * link and monitor optimized for scalability
>> * os:getenv/putenv now work on thread-safe emulation. No longer in
>> sync with libc getenv(3). Manual synchronization will be needed.
>>
>> Compiler:
>> * Misc compiler optimizations including contributions from the
>> Elixir team resulting in 10% improvements in benchmarks
>> * "Tuple calls" have been removed from the run-time system.
>> * Code such as f({ok, Val}) -> {ok, Val} is now automatically
>> rewritten to f({ok, Val} = Tuple) -> Tuple. this reduces code
>> size, execution time, and removed GC pressure.
>> * More information in stacktrace from a number of operators
>> * erlang:get_stacktrace/0 deprecated to be replaced with try ...
>> catch C:R:Stacktrace -> ...
>> * Creation of small maps with literal keys optimized.
>>
>> Security:
>> * DTLS support in SSL
>> * Enhanced support for distribution over TLS
>> * "unsecure" ciphers removed from defaults in SSL and SSH.
>> * A new option value defined to facilitate implementing exec
>> servers. Old option kept for compatibility, but now gives errors
>> on stderror.
>>
>> Standard libraries:
>> * New API for logging, logger
>> * New uri_string module for parsing URIs according to "The
>> standard"
>> * New function lists:search(list,fun/1) -> {ok, Value} | false
>> * Changed default behaviour of .erlang loading. escript, erlc,
>> dialyzer and typer no longer load an .erlang at all.
>>
>> For more details see
>> http://erlang.org/download/otp_src_21.0-rc1.readme>>
>> Pre built versions for Windows can be fetched here:
>> http://erlang.org/download/otp_win32_21.0-rc1.exe>> http://erlang.org/download/otp_win64_21.0-rc1.exe>>
>> Online documentation can be browsed here:
>> http://erlang.org/documentation/doc-10.0-rc1/doc/>>
>> The Erlang/OTP source can also be found at GitHub on the official
>> Erlang repository,
>> https://github.com/erlang/otp with tag OTP-21.0-rc1
>>
>>
>> Thank you for all your contributions!
>> _______________________________________________
>> erlang-questions mailing list
>> [hidden email]>> http://erlang.org/mailman/listinfo/erlang-questions>>
>

The error_logger event handler is started lazily when the first error_logger:add_report_handler call is done. So the new logging framework does not use the error_logger process, but it is started if legacy code uses it. All calls to error_logger:*_report/msg are redirected to logger which then decides what to do with them.

=WARNING REPORT==== 3-May-2018::15:38:51.663313 ===
Process <0.2680.0> on node 'ct@MACHINE' enabled access to the
emulator internal state.
NOTE: This is an erts internal test feature and should *only* be used
by OTP test-suites.

The error_logger event handler is started lazily when the first error_logger:add_report_handler call is done. So the new logging framework does not use the error_logger process, but it is started if legacy code uses it. All calls to error_logger:*_report/msg are redirected to logger which then decides what to do with them.

Something has clearly changed in the behaviour of the error logger in ways that I am not sure I completely understand.

I have a simple script to run the HiPE tests which looks as follows:
=====================================
#! /bin/sh

=WARNING REPORT==== 3-May-2018::15:38:51.663313 ===
Process <0.2680.0> on node 'ct@MACHINE' enabled access to the emulator internal state.
NOTE: This is an erts internal test feature and should *only* be used by OTP test-suites.

How does one suppress these?

There seems to be some bug in the cth_log_redirect. You should be able to do "ct_run -kernel logger_dest silent -dir hipe_test" to work around it for now. We'll fix the bug.

Re: Erlang/OTP 21.0-rc1 (Release Candidate)

On 05/03/2018 03:53 PM, Lukas Larsson wrote:

>
>
> On Thu, May 3, 2018 at 3:41 PM, Kostis Sagonas <[hidden email]> <mailto:[hidden email]>> wrote:
>
> Something has clearly changed in the behaviour of the error logger
> in ways that I am not sure I completely understand.
>
> I have a simple script to run the HiPE tests which looks as follows:
> ... <SNIP>
>
>
> How does one suppress these?
>
>
> There seems to be some bug in the cth_log_redirect. You should be able
> to do "ct_run -kernel logger_dest silent -dir hipe_test" to work around
> it for now. We'll fix the bug.

The error_logger event handler is started lazily when the first error_logger:add_report_handler call is done. So the new logging framework does not use the error_logger process, but it is started if legacy code uses it. All calls to error_logger:*_report/msg are redirected to logger which then decides what to do with them.

Re: Erlang/OTP 21.0-rc1 (Release Candidate)

On 05/03/2018 01:54 PM, Loïc Hoguin wrote:
> * SSL is broken. See [1] for example. I can see the same thing happening
> on 5 different Linux distributions (with different OpenSSL versions) and
> on OSX. A quick try in the shell is not much better:

OK it's just a very misleading error message I think.

Switching my server's test keys from RSA to DSA fixes it so I think this
issue is caused by:

OTP-14769 Application(s): ssl

For security reasons RSA-key exchange cipher suites are
no longer supported by default

Still, it probably should provide a more helpful error message than this:

"malformed_handshake_data" sounds like the client would have sent a
malformed handshake, ie bad data, when the actual issue seems to be that
the certificate configured is no longer supported. The server generating
an alert about its own certificate doesn't sound quite right either.

That being said I do not really know the intent so I'm guessing a bit.
All I know for sure is that it's confusing.

"malformed_handshake_data" sounds like the client would have sent a malformed handshake, ie bad data, when the actual issue seems to be that the certificate configured is no longer supported. The server generating an alert about its own certificate doesn't sound quite right either.

That being said I do not really know the intent so I'm guessing a bit. All I know for sure is that it's confusing.

This error is consistent with one of the errors I am seeing in the nightly builds when running OpenSSL with only default parameters so I suspect something is off in combination

version negotiation and cipher suite selection checks. I am looking in to it!

"malformed_handshake_data" sounds like the client would have sent a malformed handshake, ie bad data, when the actual issue seems to be that the certificate configured is no longer supported. The server generating an alert about its own certificate doesn't sound quite right either.

That being said I do not really know the intent so I'm guessing a bit. All I know for sure is that it's confusing.

This error is consistent with one of the errors I am seeing in the nightly builds when running OpenSSL with only default parameters so I suspect something is off in combination

version negotiation and cipher suite selection checks. I am looking in to it!

Re: Erlang/OTP 21.0-rc1 (Release Candidate)

On 4 May 2018 at 08:32, Ingela Andin <[hidden email]> wrote:
> This error is consistent with one of the errors I am seeing in the nightly
> builds when running OpenSSL with only default parameters so I suspect
> something is off in combination
> version negotiation and cipher suite selection checks. I am looking in to
> it!

I'm seeing the same, if it helps to reproduce. I generated my certificates with:

"malformed_handshake_data" sounds like the client would have sent a malformed handshake, ie bad data, when the actual issue seems to be that the certificate configured is no longer supported. The server generating an alert about its own certificate doesn't sound quite right either.

That being said I do not really know the intent so I'm guessing a bit. All I know for sure is that it's confusing.

This error is consistent with one of the errors I am seeing in the nightly builds when running OpenSSL with only default parameters so I suspect something is off in combination

version negotiation and cipher suite selection checks. I am looking in to it!