| Age | Commit message (Collapse) | Author |
|---|
|
* sverker/erts/system_monitor-doc:
erts: Add some erl_nif doc clarifications
erts: Clarify erlang:system_monitor/2 semantics
|
|
|
|
Update erlang.xml / map_get in guard tests
|
|
|
|
|
|
This reverts commit 425889ba69b69a9b6fb14bfbef121d51b78e853a.
|
|
|
|
A multitude of broken links were found when a bug was fixed
in the link checker.
|
|
This reverts commit 0118046f9bda8dcf3594184fa439b79267db8017.
|
|
|
|
|
|
* maint:
Fix typo in erlang.xml
inets: Ignore bracket option in format_address
Change-Id: I8a215d3872ae74e08d7a17b70ba53535947c032f
|
|
|
|
|
|
done on unknown ports.
|
|
Document that current_function can be undefined
OTP-15543
|
|
|
|
This is the result of going through all .xml files
with "clause_i" attributes and make sure
their "since" versions are correct.
|
|
Conflicts:
erts/emulator/beam/bif.c
erts/preloaded/ebin/erlang.beam
erts/preloaded/ebin/erts_internal.beam
erts/preloaded/ebin/prim_file.beam
|
|
If a process is executing in native-compiled code, process_info(Pid,
current_function) may return the atom undefined instead of an MFA.
|
|
This flag allows logger and other components to set the
process which log messages from ERTS are to be sent.
|
|
|
|
The ones marked since="?" are unknown (but newer than R13B03)
monitor/2
port_info/2
process_flag/2
statistics/1
system_flag/2
system_info/1
trace_pattern/3
|
|
|
|
introduced after OTP_R13B03.
|
|
Optimise creation of anonymous functions
|
|
This introduces a similar optimisation for normal funs
to what was introduced for external funs in #1725.
It is possible to allocate the fun as a literal, if it does not capture
the environment (i.e. it does not close over any variables).
Unfortunately it's not possible to do this in the compiler due to
problems with representation of such functions in the `.beam` files.
Fortunately, we can do this in the loader.
Simple evaluation shows that functions that don't capture the
enviornment consistute over 60% of all funs in the source code of
Erlang/OTP itself.
The only downside is that we lose a meningful value in the `pid` field
of the fun. The goal of this field, beyond debugging, was to be
able to identify the original node of a function. To be able to still do
this, the functions that are created in the loader are assigned the init
pid as the creator.
To solve issues with staryp, initially set the `erts_init_process_id`
to `ERTS_INVALID_PID` and skip the described optimisation if the value
is still uninitialised.
|
|
to include ports and NIF resources.
Added new opaque type 'nif_resource'.
|
|
from erlang:open_port/2 docs.
|
|
Use erlang:system_info(ets_count) and improve docs
|
|
|
|
|
|
|
|
|
|
|
|
* sverker/ets-count/OTP-14987:
erts,stdlib: Improve docs about obsolete ets_limit
erts: Reduce test log noise from ets_SUITE
erts: Increase scalability of ets name lookup
erts: Rename one of delete_trap to select_delete_trap
erts: Refactor usage of am_atom_put to ERTS_MAKE_AM
erts: Add system_info(ets_count)
erts: Fix narrow race between ets:new and ets:delete
|
|
|
|
|
|
Fix typos in erlang.xml
|
|
|
|
|
|
This complements the `map_get/2` guard BIF introduced in #1784.
Rationale.
`map_get/2` allows accessing map fields in guards, but it might be
problematic in more complex guard expressions, for example:
foo(X) when map_get(a, X) =:= 1 or is_list(X) -> ...
The `is_list/1` part of the guard could never succeed since the
`map_get/2` guard would fail the whole guard expression. In this
situation, this could be solved by using `;` instead of `or` to separate
the guards, but it is not possible in every case.
To solve this situation, this PR proposes a `is_map_key/2` guard that
allows to check if a map has key inside a guard before trying to access
that key. When combined with `is_map/1` this allows to construct a
purely boolean guard expression testing a value of a key in a map.
Implementation.
Given the use case motivating the introduction of this function, the PR
contains compiler optimisations that produce optimial code for the
following guard expression:
foo(X) when is_map(X) and is_map_key(a, X) and map_get(a, X) =:= 1 -> ok;
foo(_) -> error.
Given all three tests share the failure label, the `is_map_key/2` and
`is_map/2` tests are optimised away.
As with `map_get/2` the `is_map_key/2` BIF is allowed in match specs.
|
|
* 'map-get-bif' of git://github.com/michalmuskala/otp:
Introduce map_get guard-safe function
OTP-15037
|
|
Rationale
Today all compound data types except for maps can be deconstructed in guards.
For tuples we have `element/2` and for lists `hd/1` and `tl/1`. Maps are
completely opaque to guards. This means matching on maps can't be
abstracted into macros, which is often done with repetitive guards. It
also means that maps have to be always selected whole from ETS tables,
even when only one field would be enough, which creates a potential
efficiency issue.
This PR introduces an `erlang:map_get/2` guard-safe function that allows
extracting a map field in guard. An alternative to this function would be
to introduce the syntax for extracting a value from a map that was planned
in the original EEP: `Map#{Key}`.
Even outside of guards, since this function is a guard-BIF it is more
efficient than using `maps:get/2` (since it does not need to set up the
stack), and more convenient from pattern matching on the map (compare:
`#{key := Value} = Map, Value` to `map_get(key, Map)`).
Performance considerations
A common concern against adding this function is the notion that "guards
have to be fast" and ideally execute in constant time. While there are
some counterexamples (`length/1`), what is more important is the fact
that adding those functions does not change in any way the time
complexity of pattern matching - it's already possible to match on map
fields today directly in patterns - adding this ability to guards will
niether slow down or speed up the execution, it will only make certain
programs more convenient to write.
This first version is very naive and does not perform any optimizations.
|
|
All functions, datatype and h3 headings have gotten a hover
attribute that shows a link directly to the edit page on
github for easy editing of documentation.
The github link links to the maint branch. An early attempt
was done to use the SHA of the current branch, but that did
not work well as github can only take pull requests from
branches.
|
|
|
|
make erlang:process_info/1 not retrieve messages
|
|
|
|
|
|
with link to ! operator
and clarify ugly badarg for unregistered atom argument.
|
