I guess if your Server crashes and is restarted by supervisor, size_limit will be reset.
In such situations I usually either read application:get_env(my_app, size_limit) in init callback or just on-spot, instead of storign the value in supervisor’s arguments.
Online Erlang customize builder - Imagine, you go to the official Erlang website, indicate in an online form under which OS and OS category to make the assembly, indicate which components you want to be in this assembly, press the assemble button and after a few seconds you will receive your own assembly without additional components that you do not use at all in your project . And something tells me that it is very closely related to Configuration of Erlang system
Integration bootstrap into EDoc - for rebar3 projects already implemented few great plugins for build beautiful and convenient Erlang documentation
and
I believe will be provided also other similar plugins but what about Erlang.mk projects? The developers and team who use Erlang.mk instead of rebar3 will still experience inconvenience with the old style of documentation … At the same time @garazdawi already did an amazing job with the integration of Bootstrap into official Erlang web site and we already know how positively the Erlang community reacted to this. I believe that it would be great if EDoc also will have Bootstrap HTML/CSS/JavaScript stuff for build cross-browser documentation for any existing project
I think edoc styles and so forth should be definitely be updated, but I don’t think it obviates the need for using ex_doc when publishing docs to hex. The docs generated by ex_doc are more than just pretty It’s a standard format. One important aspect is a standardized way of generating links such that packages can link to each other (e.g., type links) on hexdocs.pm.
It’s possible you could have that all in edoc, but that requires edoc not only being hex aware but keeping up with ex_doc, moving target style.
Users of erlang.mk could use ex_doc right now, if they wanted to FWIW. The instructions in ex_doc reference rebar3 but could be applied to erlang.mk.
Agreed. Almost all languages that are considered batteries included end-up with unmaintained or outdated modules, which later are deprecated and removed anyway. Less is more!
The community will always be larger than the Erlang/OTP team and it should be on us to provide the missing pieces we find necessary.
This is a really cool idea. Compared to most other ideas in this thread this doesn’t need changes in OTP itself (though OTP xcomp improvements would greatly help) so it’s a great candidate for a community project that maybe would become official one day.
I find the idea of adding javascript to edoc egregious. The new erlang.org looks comparatively worse on browsers like netsurf. If we’ll need spidermonkey or V8 to “properly” view the docs, I’d ask for a reevaluation.
Agree with essen.
We should better remove things or at least move high level applications out of Erlang (megaco, jinterface etc…).
But some things need to be added to Erlang MHO :
missing compression algorithms, in particular lzma
exec command for os with exit code
namespace concept to allow use of modules with same name but from two (or more) different sources.
+1 for having a proper “os:cmd” that returns exit code, stdin/stdout/stderr separately, and has somewhat more control. I have a dozen of those spread over various places in code.