| Age | Commit message (Collapse) | Author |
|---|
|
Add missing list wrapper.
|
|
`af_function_type()` already contains the `{'type', anno(), 'fun', ...}`
tuple so it does not have to be wrapped again.
|
|
This is allowed since 19.3 (commit 6d238032) and documented since commit
744fb920.
|
|
|
|
Before OTP 22, the option `{nowarn_deprecated_function,MFAs}` was only
recognized when given in the file with the attribute
`-compile()`. (The option `{nowarn_unused_function,FAs}`
was incorrectly documented to only work in a file, but it also
worked when given in the option list.) Starting from OTP 22, all
options that can be given in the file can also be given in the option
list.
|
|
* raimo/stdlib/sys-log-of-gen-in-terminate-report/OTP-15381:
sys:log timeout 0 events
Filter gen_server State in crash sys:log
Fix statement duplication
Document system_events better
Adjust sys:log(N, get) to documentation
Unify system_events in gen_*
Log code change
Use from/1 type check
Limit more error_logger terms
Add client stacktrace
Print sys:log in error report
Optimize sys:handle_debug/4
Optimize sys:log
Fix sys:log functionality
Conflicts:
lib/stdlib/doc/src/sys.xml
|
|
Currently, a user of gen_statem cannot use gen_statem types
related to naming & starting in their behaviour implementations
As an example, we cannot do:
-spec start_link(Options) -> gen_statem:start_ret() when
Options :: some_complex_thing().
start_link(Options) ->
gen_statem:start_link(?MODULE, [Opts], []).
As dialyzer, if configured to complain about unknown types, will
warn that the type gen_statem:start_ret() is unknown.
Likewise, for the same reason, we cannot do:
-spec do_call_to_gen_statem(ServerRef) -> Reply when
ServerRef :: gen_statem:server_ref(),
Reply :: term().
do_call_to_gen_statem(ServerRef) ->
gen_statem:call(ServerRef, do_thing).
This fixes that by exporting the appropriate types
|
|
* maint:
Updated OTP version
Prepare release
|
|
|
|
* maint:
stdlib: Let calendar:system_time_to_rfc3339() keep fractions
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
RFC3339 mentions in paragraph 5.1 that if certain conditions are
fulfilled, then sorting date and time strings results in a
time-ordered sequence. One of the conditions is that the strings must
have the same number of fractional second digits. This commits makes
sure this is indeed the case.
|
|
|
|
* maint:
Fix inadvertently suppressed warning for unused variable
|
|
An external fun could inadvertently suppress warnings for
unused variables, such as in this example:
bug() ->
BugVar = foo(),
if true ->
fun m:f/1
end.
There would be no warning that `BugVar` was unused.
The bug was introduced in ff432e262e652, which was the commit
that extended external funs to allow variables.
https://bugs.erlang.org/browse/ERL-762
|
|
Before this patch the following call resulted in the below error
```
1> dbg:fun2ms(fun(_) -> m:f() end).
Error: Unknown error code {122,m,f}
```
Now it is properly formatted as
```
1> dbg:fun2ms(fun(_) -> m:f() end).
Error: fun containing the remote function call 'm:f/0' (called in body) cannot be translated into match_spec
```
|
|
|
|
|
|
|
|
|
|
|
|
Abstract out Latest-N-Log functions to this to nlog_*.
Fix sys:log(Name, get) to strip the internal formatting funs.
|
|
|
|
Even more scalable ETS ordered_set with write_concurrency
|
|
* maint:
beam_lib: Remove obsolete module() from the beam() type
hipe: Don't use beam_lib:info/1 with an atom as filename
Honor the max heap size when copying literals after purging
|
|
|
|
The type `beam()` in the `beam_lib` module is confusing:
-type beam() :: module() | file:filename() | binary().
It says that the module name can be used to identify the BEAM module
to be accessed, but passing in the module name only works if the BEAM
file is located in the current working directory because the module
is not searched for in the code path.
The reason that it is allowed to pass in the module name as an atom is
for backward compatibility. A long time ago, atoms instead of strings
were used as filenames. For that reason, `filename` and `file` still
accept atoms as filenames (although the practice is frown
upon). `beam_lib` accepts an atom as the filename for the same reason.
To remove the confusion, remove `module()` from the type and the
mention of it in the documentation. Code that uses an atom as a
filename will still work, but Dialyzer will issue a warning.
https://bugs.erlang.org/browse/ERL-696
|
|
OTP-14731 Implement 'exsss' (Xorshift116**) as new default 'rand' algorithm
The new algorithm is a combination of the Xorshift116 ('exsp') state update and a new scrambler "StarStar" from the 2018 paper "Scrambled Linear Pseudorandom Number Generators" by David Blackman and Sebastiano Vigna. This combination should not have the caveat of weak low bits that the previous default algorithm(s) have had, with the cost of about 10% lower speed.
|
|
* maint:
compiler: Forward +source flag to epp and fix bug in +deterministic
epp: Allow user to set source name independently of input file name
|
|
* john/compiler/deterministic-paths/OTP-15245/ERL-706:
compiler: Forward +source flag to epp and fix bug in +deterministic
epp: Allow user to set source name independently of input file name
|
|
Note that this does *not* affect -include()'d files or the -file()
directive.
|
|
|
|
|
|
|
|
Document bit_size in match-specs and allow in fun2ms
|
|
|
|
The otp_mibs application is to be removed so we
also remove the os_mon usage of that application.
|
|
|
|
It is already allowed in match-specs.
|
|
OTP-14737
* raimo/stdlib/gen_statem-cleanup:
Improve user's guide on time-outs
Clean up and optimize code and doc
|
|
OTP-14461 - New 'rand' algorithm: Xoroshiro928** also for 'crypto'
Implement a new 'rand' algorithm named 'exro928ss' and a new 'crypto' plugin for 'rand' named 'crypto_aes'.
Both are based on Xoroshiro928** which is derived from Xoroshiro1024** modified to use 58-bit words for performance reasons in the Erlang VM. Xoroshiro1024** has got the Xoroshiro1024 generator and the StarStar scrambler from the 2018 paper "Scrambled Linear Pseudorandom Number Generators" by David Blackman and Sebastiano Vigna.
This generator and scrambler combination shows no systematic weaknesses in standard statistical tests as TestU01(BigCrush) and PractRand, unlike the previously used * and + scramblers in the 'rand' module that exhibit statistical weaknesses for the lowest bits.
The 'crypto' plugin uses AES-256 as scrambler and the Xoroshiro928 as generator, which gives the same very long period and jump functions as for Xoroshiro928**, but a cryptographically secure scrambler gives absolutely no detectable statistical weaknesses regardless of how the generated numbers are used.
The speed of 'exro928ss' is only about 30-50% slower than the default fast 'rand' algorithm, but the state is roughly the double and it produces about 8 times the garbage per iteration.
The speed of 'crypto_aes' is about half (amortized) that of the default fast 'rand' algorithm which is fast and thanks to doing encryption in batches caching the result. Hence the state is much larger.
|
|
The old net module (in kernel) (deprecated) was removed and its
function(s) has been moved into the new module.
Also a minor updated to the info function.
OTP-14831
|
|
* maint:
stdlib: Allow lists with binaries in the Format argument
|
