| Age | Commit message (Collapse) | Author |
|---|
|
log_mf_h are given
The sasl application starts and adds log_mf_h handler if all three
environment variables are given and valid. If any of the variables are
invalid, sasl startup will crash.
Earlier, if one or two of the variables were missing sasl would
successfully start but silently skip adding log_mf_h. This commit
changes this behaviour so that sasl startup will crash if some
variables are given and some are not.
|
|
* siri/sasl/rb-help-error/OTP-9166:
rb help error
|
|
Add new option <c>src_tests</c> to systools:make_script and
systools:make_tar. The old option <c>no_module_tests</c> is now
ignored as this is the default behaviour.
|
|
Start and end date for rb:filter/2 was specified as {{Y-M-D},...} in
the help text instead of {{Y,M,D},...}. This has been corrected.
|
|
* sg/fix-diskless-booted-relup:
Remove traces of release_handler reading from filesystem when it has
Masters list
OTP-9142
|
|
list
There are a couple of places in release_handler and release_handler_1
that assumed it has a disk to read from, which in the case of an
erl_prim_loader Loader other than efile is not necessarily true
Add check_paths/2 to do the equivalent of check_path/1 for when there
is a Masters list
Change get_vsn to no longer get sent File paths but instead use the
Bin since beam_lib:version being sent a file path causes it to read
the local file system
Add get_current_vsn/1 as an equivalent to
beam_lib:version(code:which(Mod)), but using erl_prim_loader:get_file
instead of reading from local file system
|
|
|
|
Previously, relup file always included an
application:start(Application, permanent) apply instruction for every
application that appear in the UpTo/DowFrom release file, whatever
their start type in the release file.
The new implementation fixes this bug by honoring the start type
according to the rel(5) format. If the start type is none, no apply
line is included in the relup. If the start type is load, the relup
includes instruction to only load the application. Otherwise, the
relup includes an instruction to start the application to the
according type.
The fix is implemented by adding a new parameter to the
add_application high level appup instruction. This new parameter is
documented in appup(5).
|
|
* sv/sasl-fix-get_status:
Prepare patch release
fix sys:get_status backward compatibility for sasl release_handler_1
OTP-8619 sv/sasl-fix-get_status
In R13B04 sys:get_status was modified to invoke format_status/2 in the
callback module if the module exports that function. This resulted in a
change to the term returned from calling sys:get_status on the supervisor
module, since supervisor is a gen_server and gen_server exports
format_status. The sasl release_handler_1 module had a dependency on the
pre-R13B04 term returned by sys:get_status when invoked on a supervisor, so
the R13B04 change broke that dependency.
This problem has been fixed by change release_handler_1 to handle both the
pre-R13B04 and R13B04 terms that sys:get_status can return from a
supervisor.
|
|
In R13B04 sys:get_status was modified to invoke format_status/2 in the
callback module if the module exports that function. This resulted in
a change to the term returned from calling sys:get_status on the
supervisor module, since supervisor is a gen_server and gen_server
exports format_status. The sasl release_handler_1 module had a
dependency on the pre-R13B04 term returned by sys:get_status when
invoked on a supervisor, so the R13B04 change broke that dependency.
Change release_handler_1 to handle both the pre-R13B04 and R13B04
terms that sys:get_status can return from a supervisor.
|
|
* bg/sasl-infinity:
Prepare patch release
sasl: Use gen_server:call/3 with infinity timeout
OTP-8506 bg/sasl-infinity
Use an infinity timeout in all calls to gen_server:call() in the sasl
application.
|
|
gen_server:call/2,3 now sets up a monitor to make sure that
it will be noticed if the called process dies. Therefore,
there is almost never a good reason to use gen_server:call/2
with its default 5 seconds timeout. Use gen_server:call/3
with the 'infinity' timeout instead.
To make sure we use the 'infinity' timeout every time,
wrap the to call gen_server:call/3 in a local call/1 function
in each module.
|
|
* ks/cleanups:
percept: Clean up as suggested by tidier
percept: Modernize types and specs
parsetools: Don't use 'try...of' when 'try' will do
parsetools: Use %% for comments at the beginning of a line
parsetools: Replace lists:keysearch/3 with lists:keyfind/3
parsetools: Modernize types and specs
parsetools: Replace TABs with spaces
runtime_tools: Modernize specs
sasl: Eliminate tuple used as fun
sasl: Add missing modules to app file
asn1: Clean up as suggested by tidier
os_mon: Modernize types and specs
wx: Clean up as suggested by tidier
OTP-8455 ks/cleanups
|
|
|
|
|
|
* jn/sasl-format_report:
Added sasl_report:format_report/3 to return a string rather than send an io
OTP-8445 There is new function sasl_report:format_report/3 that works like
the existing sasl_report:write_report/3 function except that it
returns a formatted string. Note that there is currently no
documentation for the sasl_report module. (Thanks to Jay Nelson.)
|
|
* va/rb-improvements:
New rb:filter/2 to filter reports by date
New rb:filter/1 function to ease report filtering
Modify rb:grep/1 to grep reports using the re module
Fix minor typo in read_report/1
OTP-8443 The re:grep/1 function now uses the 're' module instead of the
deprecated 'regexp' module. There are new functions rb:filter/1
and rb:filter/2 for easier filtering of reports. (Thanks to
Alvaro Videla.)
|
|
sasl_report:write_report/3 calls io:format to output the report
message, but does not provide an option to generate a formatted string
rather than sending the message. sasl_report:format_report/3 is added
to allow the replacement of sasl_report with a different handler but
still generate reports in the same format. It returns the string
generated by io_lib:format. sasl_report:write_report/3 retains its
original behavior.
This patch was submitted in 2008 (see
http://www.erlang.org/cgi-bin/ezmlm-cgi/4/35061) but was never
incorporated into the source.
|
|
The function filter/2 expects a second parameter
Dates that can be used to return reports that
occurred between the provided dates.
Usage:
Dec22 = {{2009,12,22},{0,0,0}}.
Dec24 = {{2009,12,24},{0,0,0}}.
rb:filter(Filters, {Dec22, from}).
%will return reports that occurred from Dec22.
rb:filter(Filters, {Dec22, to}).
%will return reports that occurred before Dec22.
rb:filter(Filters, {Dec22, Dec24}).
%will return reports that occurred between Dec22
% and Dec24
|
|
Currently in the rb module the only way to filter
reports is by using the grep/1 or re/1 functions
that use Regular Expressions.
This new function allow us to specify detailed
filters that will match against our reports.
Since the reports are proplists the filters are
tuples of the form {Key, Value}. If the report
contains that tuple, it will be displayed.
Usage:
1> rb:filter([{"foo", "bar"}, {"abc", "value"}]).
2> rb:filter([{"foo", "bar", no}]).
% excludes reports containing {"foo", "bar"}
3> rb:filter([{"foo", RegExp, re}]).
% the report must contain an element with Key = "foo"
% and Value must match RegExp
|
|
|
|
|
|
|
