[erlang-questions] OTP R16A has been released

[Kenneth Lundin]

 

Erlang/OTP R16A has been released. This is a beta release before the R16B product release on February 27:th.

 

OTP R16 i a new major release with a number of new features, characteristics and also some minor incompatibilities.

We encourage you to build and test your applications using this release and report unexpected problems to us.
See the readme file and the documentation for more details.

Some of the highlights are:

• Optimized handling of processes in the VM
• New internal process table allowing for parallel reads and writes
• optimized run queue management
• optimized process state changes
• "Non-blocking" code loading
• New internal port table, and rewrite of scheduling of port tasks.
• Dynamic allocation of port structures, allowing the default for maximum ports to be raised to 65536 (from 1024)
• Support for UTF-8 encoded Unicode characters in source files.
• Inets application: The http client now support HTTPS through a proxy
• Asn1 application: Major cleanup of back ends and optimizations of mainly decode for PER and UPER.
• The experimental features parameterized modules and packages are removed. An alternative compatible solution
  for parameterized modules is provided here https://github.com/erlang/pmod_transform.
• All built in functions BIF's (even if they are implemented in C as part of the VM) are now visible in the
  source code of the module they belong to, including their type specs.
• The Wx application now compiles and is usable with the unstable development branch of wxWidgets-2.9.
  This means that wx can now be built on 64 bit MacOsX as well. 

 

You can find the README file with more detailed info at

http://www.erlang.org/download/otp_src_R16A_RELEASE_CANDIDATE.readme

You can download the full source distribution from

http://www.erlang.org/download/otp_src_R16A_RELEASE_CANDIDATE.tar.gz

http://www.erlang.org/download/otp_src_R16A_RELEASE_CANDIDATE.readme (this file)

Note: To unpack the TAR archive you need a GNU TAR compatible program.

For installation instructions please read the README that is part of

the distribution.

You can also find this release at the official Erlang/OTP Git-repository at Github here:

https://github.com/erlang/otp tagged OTP_R16A_RELEASE_CANDIDATE

 

The Windows binary distribution can be downloaded from

http://www.erlang.org/download/otp_win32_R16A_RELEASE_CANDIDATE.exe

http://www.erlang.org/download/otp_win64_R16A_RELEASE_CANDIDATE.exe

On-line documentation can be found at http://www.erlang.org/doc/.

You can also download the complete HTML documentation or the Unix manual files

http://www.erlang.org/download/otp_doc_html_R16A_RELEASE_CANDIDATE.tar.gz

http://www.erlang.org/download/otp_doc_man_R16A_RELEASE_CANDIDATE.tar.gz

We also want to thank those that sent us patches, suggestions and bug reports,

The Erlang/OTP Team at Ericsson

[Fred Hebert]

Been reading the README and I'm pretty excited for a lot of the changes
there. Especially anything related to contention and better parallel
behaviour for ETS tables, processes, ports, and module loading. I'll be
interested to see how well a stable version does for us in production.

Unicode support is nice. There is no mention of Unicode support
libraries. Anything regarding that? Did you get the libraries to add
unicode support through some random detection, purely switching on the
comment and using the right io functions?

Also:

OTP-10739 Add search to Erlang shell's history. Thanks to Fred
Herbert.

My name is Hebert :)

Here's a question regarding reltool updates:

-- The rel specification now dictates the order in which
included and used applications (specified in the .app file as
included_applications and applications respectively) are
loaded/started by the boot file. If the applications are not
specified in the rel spec, then the order from the .app file
is used. This was a bug earlier reported on systools, and is
now also implemented in reltool.

Does this let people put in orders that break the load/boot sequence
(say starting my app before stdlib/kernel, or other ones), or does it
only allow to specify ambiguous cases (where it doesn't contradict the
.app file)?

Thanks for all the work!
Fred.

On 01/30, Kenneth Lundin wrote:
> Erlang/OTP R16A has been released. This is a beta release before the R16B
> product release on February 27:th.
>
> OTP R16 i a new major release with a number of new features,
> characteristics and also some minor incompatibilities.
> We encourage you to build and test your applications using this release and
> report unexpected problems to us.
> See the readme file and the documentation for more details.
>
> Some of the highlights are:
>

> - Optimized handling of processes in the VM
> - New internal process table allowing for parallel reads and writes
> - optimized run queue management
> - optimized process state changes
> - "Non-blocking" code loading
> - New internal port table, and rewrite of scheduling of port tasks.
> - Dynamic allocation of port structures, allowing the default for

> maximum ports to be raised to 65536 (from 1024)

> - Support for UTF-8 encoded Unicode characters in source files.
> - Inets application: The http client now support HTTPS through a proxy
> - Asn1 application: Major cleanup of back ends and optimizations of

> mainly decode for PER and UPER.

> - The experimental features parameterized modules and packages are

> removed. An alternative compatible solution
> for parameterized modules is provided here
> https://github.com/erlang/pmod_transform.

> - All built in functions BIF's (even if they are implemented in C as

> part of the VM) are now visible in the
> source code of the module they belong to, including their type specs.

> - The Wx application now compiles and is usable with the

> unstable development branch of wxWidgets-2.9.
> This means that wx can now be built on 64 bit MacOsX as well.
>
>
>
> You can find the README file with more detailed info at
> http://www.erlang.org/download/otp_src_R16A_RELEASE_CANDIDATE.readme
>
> You can download the full source distribution from
> http://www.erlang.org/download/otp_src_R16A_RELEASE_CANDIDATE.tar.gz
> http://www.erlang.org/download/otp_src_R16A_RELEASE_CANDIDATE.readme (this
> file)
>
> Note: To unpack the TAR archive you need a GNU TAR compatible program.
>
> For installation instructions please read the README that is part of
> the distribution.
>
> You can also find this release at the official Erlang/OTP Git-repository at
> Github here:

> https://github.com/erlang/otp tagged *OTP_R16A_RELEASE_CANDIDATE*

>
>
> The Windows binary distribution can be downloaded from
>
> http://www.erlang.org/download/otp_win32_R16A_RELEASE_CANDIDATE.exe
> http://www.erlang.org/download/otp_win64_R16A_RELEASE_CANDIDATE.exe
>
>
> On-line documentation can be found at http://www.erlang.org/doc/.
> You can also download the complete HTML documentation or the Unix manual
> files
>
> http://www.erlang.org/download/otp_doc_html_R16A_RELEASE_CANDIDATE.tar.gz
> http://www.erlang.org/download/otp_doc_man_R16A_RELEASE_CANDIDATE.tar.gz
>
> We also want to thank those that sent us patches, suggestions and bug
> reports,
>
> The Erlang/OTP Team at Ericsson

> _______________________________________________
> erlang-questions mailing list
> erlang-q...@erlang.org
> http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
erlang-q...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions

[Max Lapshin]

Great news!

Can you tell, what means "optimized process state changes"?

[Max Bourinov]

Great news!

Congradulations to all Erlangers!

Best regards,

Max

On Wed, Jan 30, 2013 at 4:54 PM, Max Lapshin <max.l...@gmail.com> wrote:

Great news!

Can you tell, what means "optimized process state changes"?

[Kenneth Lundin]

On Wed, Jan 30, 2013 at 4:40 PM, Fred Hebert <mono...@ferd.ca> wrote:

Been reading the README and I'm pretty excited for a lot of the changes
there. Especially anything related to contention and better parallel
behaviour for ETS tables, processes, ports, and module loading. I'll be
interested to see how well a stable version does for us in production.

I encourage you to test that as soon as possible. We don't regard this release as particularly unstable.

We only expect minor corrections until R16B and of course we will have even better confidence regarding

the quality after some weeks of community testing on top of our own.

 

/Kenneth Erlang7OTP Ericsson

[Max Lapshin]

"The rewrite was also necessary in order to make it possible to schedule signals from processes to ports."

Can I intercept sighup now in driver? I can write proper fork/execve driver now?

[Loïc Hoguin]

On 01/30/2013 04:26 PM, Kenneth Lundin wrote:
> We encourage you to build and test your applications using this release
> and report unexpected problems to us.

Works for me!

Great release, can't wait for R16B! Thanks!

--
Loïc Hoguin
Erlang Cowboy
Nine Nines
http://ninenines.eu

[Lukas Larsson]

Signals is referring to Erlang signals[1], not OS signals. 

[1]: http://www.erlang.org/doc/apps/erts/communication.html

On Wed, Jan 30, 2013 at 6:32 PM, Max Lapshin <max.l...@gmail.com> wrote:

"The rewrite was also necessary in order to make it possible to schedule signals from processes to ports."

Can I intercept sighup now in driver? I can write proper fork/execve driver now?

[Rickard Green]

On Jan 30, 2013, at 4:54 PM, Max Lapshin <max.l...@gmail.com> wrote:

> Great news!
>
> Can you tell, what means "optimized process state changes"?

> _______________________________________________
> erlang-questions mailing list
> erlang-q...@erlang.org
> http://erlang.org/mailman/listinfo/erlang-questions

It should have said "optimized process internal state changes". For details see: https://github.com/erlang/otp/commit/4bcffe41e193bfa03f54f77e2158b3d989a001d0

Regards,
Rickard Green, Erlang/OTP, Ericsson AB

[Wes James]

> On Wed, Jan 30, 2013 at 8:26 AM, Kenneth Lundin <kenneth...@gmail.com> wrote:
>
>    
>Erlang/OTP R16A has been released. This is a beta release before the R16B product release on February 27:th.
     

<snip>

For what it's worth:

I git cloned my "database search web ui" from:

https://github.com/comptekki/dbswui.git

I ran make and this pulls cowboy (master), ranch (0.6.1), epgsql (master) and  compiles all those and dbswui.  I ran dbswui and I could search, add, edit and delete postgres records so all looks well for these.

Thanks!

Wes

[Motiejus Jakštys]

On Wed, Jan 30, 2013 at 3:40 PM, Fred Hebert <mono...@ferd.ca> wrote:
> Also:
>
> OTP-10739 Add search to Erlang shell's history. Thanks to Fred
> Herbert.

History between sessions is not implemented (I get readline-style
ctrl-r in same session fine which is super cool)?

/home/motiejus$ erl -config hist.config -name labas
Erlang R16A (erts-5.10) [source] [smp:2:2] [async-threads:10] [hipe]
[kernel-poll:false]

Eshell V5.10 (abort with ^G)
(la...@precise.local)1> application:get_all_env(kernel).
[{hist_file,"erlang-history"},
{included_applications,[]},
{error_logger,tty},
{hist_size,120},
{hist_drop,["q().","init:stop()."]}]
(la...@precise.local)2> q().
ok
(la...@precise.local)3> %
/home/motiejus$ ls -lA | grep erlang
-r-------- 1 motiejus motiejus 20 Rgp 23 23:00 .erlang.cookie

--
Motiejus Jakštys

[Fred Hebert]

That's what it is. It searches the line stack. It's a *history-search*
patch, not a general history-saving patch.

I have https://github.com/ferd/erlang-history that implements a search
that can be saved, but there's still work to do in it before it can be
good enough for OTP:

1. it relies on DETS, and DETS seems to corrupt files from time to time
either when too many shells write to it, or when it's interrupted
while dumping. I want to get rid of DETS at some point for some other
line utility, maybe disk_log.
2. I'll need to make it use a .erlang/ directory in $HOME rather than
plenty of .erlang.$NAME files. There's a truckload of .erlang.*
config files around, and one per named shell is problematic.
3. Multiple shells are implemented in an okay way, but there may be a
need to correct codes when many shells write to the same file
(usually multiple non-distributed shells).
4. The usual OTP cleanup and formatting is required.
5. I haven't considered the issue of multiple encodings used in the same
shell history file yet.
6. I haven't asked the OTP team what they think should be done at that
point, but I'd be fine forking this thread to start discussing it.

Lately I haven't had the time/motivation to do that heavy lifting,
but with the book and university done, I'll probably find time here and
there to try and make a better implementation.

In the mean time, I'll keep the repository above up to date. It's not
yet ready for R16A support -- I use the compiler versions to deal with
things and the new code can't be the same to make it there. It should
work fine with the new ^R support feature.

Shell history is a tiny bit about injecting history in a shell and is
*mostly* about handling files on disk. Shell history search is pretty
much handling the line stack in the shell and edlin, so that one was
much simpler to deal with than history to make it part of OTP :)

Regards,
Fred.

[Pierre Fenoll]

Hi Fred!  and sorry to diverge this thread…

Why do you want a history file per erlshell? bash only uses one: ~/.bash_history

You only need one ~/.erlang.history, don't you?

[Richard O'Keefe]

On 31/01/2013, at 4:26 AM, Kenneth Lundin wrote:
[Lots of goodies in R16A]
> • All built in functions BIF's (even if they are implemented in C as part of the VM) are now visible in the

> source code of the module they belong to, including their type specs.

This one I _love_.

[Fred Hebert]

On 01/31, Pierre Fenoll wrote:
> Hi Fred! and sorry to diverge this thread…
> Why do you want a history file per erlshell? bash only uses one:
> ~/.bash_history
> You only need one ~/.erlang.history, don't you?
>

Because from one computer you can be using remote shells to many
different Erlang VMs running with different names.

I always figured that the history for test@mycomputer would be something
you would like a different history from something like pr...@other.host,
especially considering histories disappearing over time and whatnot.
That way, different projects or nodes get isolated histories.

So far I've enjoyed it and the fact I can get a clean shell history for
projects I haven't touched in months whereas the shell I use to test
everything locally (nonode@nohost) is chuck full of unrelated garbage
and experiments.

If people tell me they don't give a crap, I'm open to consider getting
rid of that, but there's really no complexity attached to any of this. I
simply add a call atom_to_list(node()) when opening the table/file and
that's it.

Regards,
Fred.

[Dan Gudmundsson]

That work list addresses the concerns we had with original implementation,
looks good to me for a starter.

I don't have a preference about multiple or single history files
either, right now.

/Dan

On Thu, Jan 31, 2013 at 12:41 AM, Fred Hebert <mono...@ferd.ca> wrote:
> On 01/31, Pierre Fenoll wrote:

>> Hi Fred! and sorry to diverge this thread...

[Siri Hansen]

Hi Fred!

Kernel and stdlib will always be started first. Other applications you can sort as you want.

Regards

/siri

2013/1/30 Fred Hebert <mono...@ferd.ca>

[Ulf Wiger]

On 31 Jan 2013, at 09:54, Siri Hansen wrote:

Hi Fred!

Kernel and stdlib will always be started first. Other applications you can sort as you want.

Siri,

Isn't it so that reltool_target:sort_apps/1 is still called, and that it retains the specified order *unless* it violates application dependencies? That is, if application dependencies require a change to the order, sort_apps/1 will change the order to fulfill these requirements, but it will not change an order that is legal.

I interpreted that as the essence Fred's question (otherwise, it is just mine). 

BR,

Ulf W

Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc.

http://feuerlabs.com

[Siri Hansen]

2013/1/31 Ulf Wiger <u...@feuerlabs.com>

Ulf, Fred - 

that is correct. The fix allows the rel specification to modify the order of things as long as it does not contradict the .app files. E.g. the rel file may change the order internally between included applications, but it may not change the fact that included applications are started before the application which includes them.

/siri

[Vlad Dumitrescu]

Hi,

It looks like R16 works nicely with erlide too. We have support for the new coding comment in source files and have fixed some issues with the console too (the latter is only available in the current nightly builds).

best regards,

Vlad

[Erik Reitsma]

Hi Kenneth,

Could you update the config.sub and config.guess to include
arm-linux-androideabi, unless there is a reason to keep the 2007 version
in favor of the one from 2012-12-30? The fewer files I need to update to
cross-compile for Android, the better!

Regards,
*Erik.

[Anthony Ramine]

IMHO these two files shouldn't even be versioned. There are some stuff in
the OTP build process that makes me cry, like how there are 4 identical
aclocal.m4 files in 4 different directories when there could be only one
either at the repository root or in erts/automake/ so that erts can be
built standalone.

--
Anthony Ramine

[Kostis Sagonas]

On 02/01/2013 01:05 PM, Anthony Ramine wrote:
> IMHO these two files shouldn't even be versioned. There are some stuff in
> the OTP build process that makes me cry, like how there are 4 identical
> aclocal.m4 files in 4 different directories when there could be only one
> either at the repository root or in erts/automake/ so that erts can be
> built standalone.

You are very kind in your words... ;)

There are actually 6 of them, not just 4, all identical!

kostis@some_machine:~/HiPE/otp$ wc `find . -name aclocal.m4`
1905 5931 61331 ./lib/megaco/aclocal.m4
1905 5931 61331 ./lib/wx/aclocal.m4
1905 5931 61331 ./lib/erl_interface/aclocal.m4
1905 5931 61331 ./lib/odbc/aclocal.m4
1905 5931 61331 ./aclocal.m4
1905 5931 61331 ./erts/aclocal.m4

For what's worth, I second your suggestions.

Cheers,
Kostis

[Fred Hebert]

Hi, just to let you (and other readers) know, I've just updated the
current erlang-history repository to work with R16A.
(https://github.com/ferd/erlang-history)

I've tested it locally on my machines and it still works fine here.

Regards,
Fred.

On 01/30, Motiejus Jakštys wrote:

[Björn-Egil Dahlberg]

"stand alone" apps with there own configure.

These used to be links, but cannot be links anymore.

We didn't want their macros to deviate.

I utterly hate this too.

2013/2/1 Kostis Sagonas <kos...@cs.ntua.gr>

[Edwin Fine]

Although it does not seem to be in the release notes, it appears that
R16 does support epmd using IPv6 addresses, but it is not enabled by
default. To enable it, it seems that you need to export CPPFLAGS=-DEPMD6
before running configure, assuming that the building system provides
inet_pton.

After building R16A, to assign some IPv6 and IPv4-on-IPv6 addresses, I
got this to work:

$ epmd -daemon -address ::FFFF:0.0.0.0,fded:1486:2e44::1:2:1
$ netstat -tnl|grep 4369
tcp6 0 0 ::1:4369 :::* LISTEN
tcp6 0 0 fded:1486:2e44::1::4369 :::* LISTEN
tcp6 0 0 0.0.0.0:4369 :::* LISTEN

It does not look as if the Erlang Solutions build of R16A has the IPv6
epmd support enabled on the Ubuntu 11.04 64-bit package I installed.

My questions are:

1. Did I understand this correctly?
2. Why is EPMD IPv6 support not enabled by default using autoconfig?
3. Is the EPMD IPv6 support intended to be used in this release, or is
it disabled for some reason?

Ed

[Lukas Larsson]

Hello!

I've updated config.sub and config.guess to the latest version. They should be visible on github tomorrow and will be part of the R16B release.

Do you have to change many things within the vm to get it to run on android? If the changes are not too big and are #ifdef'ed nicely it would be neat to have them in the official release.

Lukas