| Age | Commit message (Collapse) | Author |
|---|
|
|
|
* henrik/doc-fixes:
Fix typo in INSTALL.md
Update README.md
Fix typo in 'app' documentation
s/is/are
|
|
|
|
* sverk/bad_printable_range:
stdlib: Fix io_SUITE:bad_printable_range for windows
|
|
Since Windows 8 we are not allowed (in non elevated mode) to
write to hklm.
|
|
avoid os:cmd as it treats stderr different on windows.
|
|
* bjorn/compiler/binary-comprehensions/OTP-13289:
Generalize bit string comprehensions
|
|
|
|
|
|
|
|
The expression in a bit string comprehension is limited to a
literal bit string expression. That is, the following code
is legal:
<< <<X>> || X <- List >>
but not this code:
<< foo(X) || X <- List >>
The limitation is annoying. For one thing, tools that transform
the abstract format must be careful not to produce code such as:
<< begin
%% Some instrumentation code.
<<X>>
end || X <- List >>
One reason for the limitation could be that we'll get
reduce/reduce conflicts if we try to allow an arbitrary
expression in a bit string comprehension:
binary_comprehension -> '<<' expr '||' lc_exprs '>>' :
{bc,?anno('$1'),'$2','$4'}.
Unfortunately, there does not seem to be an easy way to work
around that problem. The best we can do is to allow 'expr_max'
expressions (as in the binary syntax):
binary_comprehension -> '<<' expr_max '||' lc_exprs '>>' :
{bc,?anno('$1'),'$2','$4'}.
That will work, but functions calls must be enclosed in
parentheses:
<< (foo(X)) || X <- List >>
|
|
|
|
|
|
* siri/remove-overload/OTP-13184:
Remove module 'overload' from SASL
|
|
|
|
|
|
* benwilson512/better-maps-with:
Improved maps:with/2 and maps:without/2 algorithm
OTP-13376
|
|
|
|
The reason is that the module is not used, and that we se no obvious
use case for it.
|
|
Forms with record field types created before OTP 19.0 are replaced by
well-formed record forms holding the type information.
Tools reading the 'abstract_code' chunk can rely on the returned forms
being well-formed, that is, there are no badly formed 'type' attribute
forms.
|
|
* bjorn/stdlib/function-macro/OTP-13059:
Implement ?FUNCTION_NAME and ?FUNCTION_ARITY macros
epp: Refactor expand_macros()
|
|
* bjorn/remove-test_server/OTP-12705:
Remove test_server as a standalone application
Erlang mode for Emacs: Include ct.hrl instead test_server.hrl
Remove out-commented references to the test_server applications
Makefiles: Remove test_server from include path and code path
Eliminate use of test_server.hrl and test_server_line.hrl
|
|
For a long time, users have asked for one or more macros that would
return the name and arity of the current function.
We could define a single ?FUNCTION macro that would return
a {Name,Arity} tuple. However, to access just the name or
just the arity for the function, element/2 must be used.
That would limit its usefulness, because element/2 is not
allowed in all contexts.
Therefore, it seems that we will need two macros.
?FUNCTION_NAME that expands to the name of the current function
and ?FUNCTION_ARITY that expands to arity of the current
function.
Converting the function name to a string can be done like this:
f() ->
atom_to_list(?FUNCTION_NAME) ++ "/" ++
integer_to_list(?FUNCTION_ARITY).
f/0 will return "f/0". The BEAM compiler will evaluate the
entire expression at compile-time, so there will not be
any run-time penalty for the function calls.
The implementation is non-trivial because the preprocessor is
run before the parser.
One way to implement the macros would be to replace them with some
placeholder and then let the parser or possibly a later pass replace
the placeholder with correct value. That could potentially slow
down the compiler and cause incompatibilities for parse transforms.
Another way is to let the preprocessor do the whole job. That means
that the preprocessor will have to scan the function head to find
out the name and arity. The scanning of the function head can be
delayed until the first occurrence of a ?FUNCTION_NAME or
?FUNCTION_ARITY.
I have chosen the second way because it seems less likely to cause
weird compatibility problems.
|
|
As a preparation for implementing a ?FUNCTION macro, pass the
entire state record to expand_macros/2 and its helpers. That will
allow us to have more information available when expanding
?FUNCTION.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Problem: The types of record fields have since R12B been put in a
separate form by epp:parse_file(), leaving the record declaration form
untyped. The separate form, however, does not follow the syntax of
type declarations, and parse transforms inspecting -type() attributes
need to know about the special syntax. Since the compiler stores the
return value of epp:parse_file() as debug information in the abstract
code chunk ("Abst" or 'abstract_code'), tools too need to know about
the special syntax, if they inspect -type() attributes in abstract
code.
Solution: As of this commit no separate form is created by
epp:parse_file(), but the type information kept in the record fields.
This means that all parse transforms and all tools inspecting
-record() declarations need to recognize {typed_record_field, Field,
Type}.
We recommend that all parse transforms and tools be updated as to
recognize typed record fields.
Discussion: As of OTP 19.0, the abstract form of type declarations and
function specifications is documented. An (unsatisfactory) alternative
to the above solution is to document two formats of the abstract form
of typed record fields: one if returned by epp:parse_file(); and one
if returned by, for example, epp:parse_erl_form(). Yet another (bad)
alternative is to not document the format returned by epp:erl_parse(),
but instead document the idempotent function
epp:restore_typed_record_fields/1, and urge authors of parse transform
and tools to always call this function.
|
|
Since no test suites includede test_server.hrl, there is no need
to have test_server in the include path or code path.
|
|
As a first step to removing the test_server application as
as its own separate application, change the inclusion of
test_server.hrl to an inclusion of ct.hrl and remove the
inclusion of test_server_line.hrl.
|
|
* maint:
xmerl: Remove 'no_return' Dialyzer warnings
xmerl: Add suppression of Dialyzer warnings
eunit: Add suppression of Dialyzer warnings
debugger: Add suppression of Dialyzer warnings
kernel: Add suppression of Dialyzer warnings
mnesia: Add suppression of Dialyzer warnings
observer: Add suppression of Dialyzer warnings
runtime_tools: Add suppression of Dialyzer warnings
stdlib: Add suppression of Dialyzer warnings
test_server: Add suppression of Dialyzer warnings
tools: Add suppression of Dialyzer warnings
Conflicts:
lib/stdlib/src/erl_lint.erl
lib/stdlib/src/otp_internal.erl
|
|
|
|
* bjorn/cuddle-with-tests:
erl_prim_loader_SUITE: Refactor helper functions
Move record compilation errors to erl_lint_SUITE
compile_SUITE: Use get_files/3 in more places
compile_SUITE: Replace confusing files/2 with get_files/3
|
|
Conflicts:
lib/stdlib/src/supervisor.erl
|
|
* nybek/speed_up_supervisor_count_children:
Speed up supervisor:count_children/1; simple_one_for_one
Add supervisor:get_callback_module/1
OTP-13290
|
|
The current implementation is roughly O(N*M) where N is the number of items to be removed, and M is the number of items in the map. This does not include the cost of `maps:from_list` or `maps:to_list`. This leads to pretty horrifying execution times on large maps regardless of how many or few keys are to be removed.
The new implementation is O(N) where N is the number of items to be removed. For each N there's the cost of removing a key from a map, and but in practice that turns out to be a vast improvement for all map sizes I tested
The new maps:take/2 implementation similarly builds a list of keys and values by iterating only the list of desired keys, and then hands it off to maps:from_list. This turned out to be faster than N maps:put calls.
|
|
The two bad record usage test cases in compile_SUITE do not
belong there, as the errors are detected in erl_lint. Move the
test to the erl_lint_SUITE.
|
|
Speed up supervisor:count_children/1 for simple_one_for_one
supervisors. This is achieved by avoiding looping through all the
child process and verifying that each one is alive.
For a supervisor with 100,000 'temporary' children the count-time will
drop from approx 25ms to about 0.005ms.
For a supervisor with 100,000 'permanent' or 'transient' children the
count-time will drop from approx 30ms to about 0.005ms.
This avoids having the supervisor block for an extended period while
the count takes place. Under normal circumstances the accuracy of the
result should also improve since the duration is too short for many
processes to die during the count.
|
|
This function is used by release_handler during upgrade. This was
earlier implemented in the release_handler, but it required a copy og
the definition of the supervisor's internal state, which caused
problems when this state was updated.
|
|
* maint:
Introduce time management in native APIs
Introduce time warp safe replacement for safe_fixed option
Introduce time warp safe trace timestamp formats
Conflicts:
erts/emulator/beam/erl_bif_trace.c
erts/emulator/beam/erl_driver.h
erts/emulator/beam/erl_nif.h
erts/emulator/beam/erl_trace.c
erts/preloaded/ebin/erlang.beam
|
|
* rickard/monotonic-time-improvements/OTP-13222:
Introduce time management in native APIs
Introduce time warp safe replacement for safe_fixed option
Introduce time warp safe trace timestamp formats
|
|
* bjorn/stdlib/remove-tuple-fun-vestiges:
Eliminate redundant double is_function test
|
|
* maint:
Check for already started beam_lib crypto server
|
|
* lrascao/stdlib/beam_lib-race-condition/OTP-13278:
Check for already started beam_lib crypto server
|
|
When tuple funs were still supported, the idiom for allowing
real funs with a certain arity but not tuple funs was:
is_function(Fun) andalso is_function(Fun, Arity)
The reason that both tests were needed is because:
is_function({M,F}) would return 'false'
is_function({M,F}, Arity) would return 'true'
In 53ec991d19, is_function/2 was updated to only return 'false'
for tuples, so the call to is_function/1 can be removed.
|
|
* maint:
Use file read buffering in dbg:trace_client
Do not consider "." part of names in edlin
|
