| Age | Commit message (Collapse) | Author |
|---|
|
OTP-9792
The colum listing modules that uses the current application or module
did earlier have the title "Modules used by others". This is now
changed to "Modules using this".
|
|
OTP-9792
For some configuration changes and during generation of target system,
there was no indication in the status bar that reltool was
working. This has been corrected - it now says "Processing
libraries...".
|
|
The new warning list did not work on Windows. It could not display
tooltips for each warning and the popup window would always disappear
behind the main system window.
Also, column width did not occur well initially in list controls.
|
|
The stdlib error has been corrected in a previous commit so the
failing test (reltool_server_SUITE:create_script_sort) can be
un-skipped.
|
|
OTP-9984
Applications that are listed in {applications,Apps} in the app file
were not sorted correctly in the script file. They were loaded/started
in the reverse order of how they were listed in the .app file.
This is corrected so they are now sorted (internally between each
other) in the same way as they are listed in the .rel file.
|
|
OTP-9980
Sasl documentation earlier said that the InclApps parameters in a .rel
file defaults to the empty list. This is not correct. It defaults to
the same value as specified in the .app file.
|
|
OTP-9792
The following problems have been solved:
* reltool_target:do_merge_apps - in recursive calls to this function,
the accumulator was reverted each time causing the order of
applications listed after kernel and stdlib in the rel specification
in the configuration to sometimes be messed up.
* There are several ways to specify wich applications to include in an
application:
1) in the .app file for the including applications
2a) in the .rel file, when listing applications
2b) in the rel specification in the reltool configuration
2a (systools) and 2b (reltool) should have the same effect and
overwrite 1.
According to the documentation of systools (sasl), the default value
in 2a is an empty list. This should mean that if included
applications are not mentioned in the .rel file, then any included
application listed in the .app file will be disregarded. This is NOT
the way systools actually works. The implementation sets the default
for the .rel file to the same list as in the .app file.
Reltool earlier implemented 2b as described in the systools
documentation. However, after some discussion we decided to change
this so that reltool handles 2b in the same way as systools handles
2a since this seems more intuitive. The sasl documentation will be
altered accordingly (internal ref OTP-9980).
* If the rel specification in the reltool configuration explicitly
specified included applications to be an empty list, and the .app
file had a non-empty list, then the empty list from the rel
specification was discarded. This has been corrected so the rel
specification now, if set, always overwrites the value of
included_applications in the .app file.
* reltool would earlier add load instructions in the script/boot files
for ALL modules in the ebin directory of an application even if
mod_cond was set to app (include only modules listed in the .app
file). This has been corrected - now only modules with
#mod.is_included==true are loaded.
* reltool would earlier add start instructions in the script/boot file
for included applications. This has been corrected - included
applications shall only be loaded since the including application is
responsible for starting them.
|
|
OTP-9792
Earlier this would cause an error with reason
"Module xxx potentially included by two different applications: yyy and yyy."
This is now changed so it will only be a warning saying that the
module is duplicated in the .app file.
|
|
OTP-9794
|
|
OTP-9792
Also correct documentation of reltool:install/2: first argument is
RelName, not Server.
|
|
OTP-9794
This is a minor change, in order to keep tables private to
reltool_server.
|
|
OTP-9967
All active warnings are now displayed in a specific warning list at
the bottom of the sys windows. Warnings do no longer cause popup
dialogs during configuration.
The reason for this is to avoid the same warning to pop up many
times. This would happen since each configuration change now causes a
fresh reading of the file system - and thus each warning would be
detected each time the configuration was changed.
reltool_manual_gui_SUITE is updated to test the new functionality.
|
|
OTP-9794
Remove some unused code from reltool test.
|
|
OTP-9794
Some escript tests in reltool_server_SUITE failed if ERL_FLAGS was set
to enable smp. The reason is that the test expected smp_support to be
false, since the argument "-smp disable" is stated in the %%!-line of
the escript. However, ERL_FLAGS will override the arguments in the
escript so the result could not be truested.
|
|
OTP-9794
Stopping configuration (throw/catch) at first error instead of
continuing through all steps and then returning the error at the
end.
Start of reltool_server will no longer succeed if the configuration
causes an error.
reltool:get_status can only return {error,Reason} in the case where
the reltool_server has terminated. In all other cases it will return
{ok,Warnings}.
Bug fix in this commit:
* warnings are no longer duplicated in pop-up or return from reltool_server
|
|
OTP-9794
Backup old configuration before starting re-configuration so rollback
is possible if configuration fails.
Store last configuration including derivates so undo does no longer
need to refresh and analyse everything from disk.
|
|
OTP-9968
Make sure that inlined applications in an escript is included/excluded
as the escript itself, and forbid explicit configuration of the
inlined application.
|
|
OTP-9792
Start of reltool GUI sometimes crashes with a badmatch in
reltool_sys_win:do_init/1 because the #sys record fetched with
reltool_server:get_sys/1 differs from the #sys record returned from
reltool_server:start_link/1. This has been
corrected. reltool_server:start_link/1 no longer retuns the #sys
record.
|
|
OTP-9794
OTP-9968
The main idea behind the data structure in reltool_server is that the
state shall reflect what is explicitly configured, and the tables
shall contain this configuration plus everything that is derived. In
some cases, however, this was not the complete truth:
* the application table was never read
* the module table was never updated on undo
* the state contained a lot more than what was explicitly configured
This commit re-writes major parts of the reltool_server for the sake
of unifying the way the state and tables are updated:
* The list of applications in the state now only contains those
applications and modules for which there are explicit settings in
the configuration (given at startup or changed from the GUI)
* When changing any bit of the configuration, the tables are always
emptied and every part is derived again from the configuration found
in the state
* All configuration changes now cause a re-read of the file system,
meaning that if something has changed in the file system it will be
reflected in the result of the configuration change. This is the
case even if no file system related configuration is changed
(e.g. root dir or lib dirs)
(*POSSIBLE INCOMPATIBILITY*)
* Requests for applications and modules from the GUI now always read
the tables, not the state
* When loading a new configuration file via the GUI, the old
configuration is completly scratched, and only the new is valid
(*POSSIBLE INCOMPATIBILITY*)
* The handling of escripts which include archives of applications is
changed to always produce one #app record for the escript in
addition to one for each inlined application. All modules are listed
as parts of the inlined application where it belongs and not as part
of the escript's #app record. This is a temporary solution which
will be modified and improved.
The following bugs are corrected by this commit:
* Loading a config which contains an escript via the GUI menu did not
produce the same #app record as when loading the same configuration
at reltool start. Paths, version and label could differ.
* Loading config with same escript (source) twice caused reltool to
add same module twice in #app.mods
* Loading config with same escript (inlined beam) twice caused reltool
to fail saying module is included by two different applications
* Loading config which in addition to an existing escript also adds
another escript for which the name sorts before the existing one
would cause reltool to fail saying "Application name clash"
|
|
OTP-9794
OTP-9968
The following test cases are added:
* create_standalone_beam
* create_standalone_app
* create_multiple_standalone
* load_config_escript_path
* load_config_same_escript_source
* load_config_same_escript_beam
* load_config_add_escript
Most of them are temporarily skipped since they re-produce known
problems that will be corrected in a later commit.
|
|
OTP-9794
Test cases create_release_sort and create_script_sort are added. The
test are temporarily skipped since they detected quite a few bugs that
will be corrected with OTP-9792.
The following bug is corrected in this commit:'
reltool_server did not recognize {App,InclApps} inside a 'rel'
specification in the reltool config, e.g.
{rel, "myrel", "1.0", [{myapp,[app2]}]}.
|
|
OTP-9794
This commit adds a test suite for manual testing of the reltool
GUI. By use of test_server:break/1 function, it guides the user
through a set of tests in the GUI.
Some minor checks are also added to the automatic GUI test,
reltool_wx_SUITE.
|
|
OTP-9794
Test cases are added for the following functions:
* reltool_server:get_sys
* reltool_server:set_sys
* reltool_server:get_status
* reltool_server:gen_rel_files
* reltool:eval_target_spec
* reltool:get_server
|
|
OTP-9794
This test case revealed a bug that occurs when calling
reltool_server:get_mod after reltool_server:undo_config. get_mod reads
from the module table (ets) and not from the reltool_server state,
while undo_config only changes the state. This bug has been corrected,
so undo_config now updates both state and tables (it does the same as
set_sys).
|
|
OTP-9794
Some test cases in reltool_server_SUITE tried to create a target
system and then start a node running this system. If creation of the
target system failed, an attempt would still be made to start the
node. This has been corrected so the test is immediately terminated if
the target system could not be created.
|
|
OTP-9794
This is a test of the mechanism with which reltool_server decides
which applications to include and not, based on function calls between
applications. This is also the mechanism which forms the base for the
application- and module dependency graphs.
|
|
OTP-9794
The following test cases are added for the inteface from GUI to
reltool_server:
* get_config
* get_apps
* set_app_and_undo
* set_apps_and_undo
* load_config_and_undo
* reset_config_and_undo
* save_config
The following bugs were found and corrected:
* If set_apps failed, then the state of reltool_server would not
be reset to how it was before the failing operation - and every
operation done afterwards would also (seem to) fail.
* undo_config did not work after reset_config - since faulty #sys
record was stored as old_sys.
* undo_config did not work after set_app (used when changing the
content of an application from the GUI) - since old_sys was not
set. Also old_status was not set causing possible warnings to
disappear.
* undo_config did not work after set_apps (used e.g. when
excluding or including an application from the GUI) - since
old_sys was not set. Also old_status was not set causing
possible warnings to disappear.
|
|
* rj/fix-supervisor-shutdown-doc:
Fix small typo in kernel app doc
Cosmetic: split very long lines from supervisor doc
Fix supervisor doc: Shutdown, MaxR and MaxT type specs
Add the type restrictions in the code comments
Remove trailing spaces
OTP-9987
|
|
* rj/fix-misc-doc-typos:
Fix a code snippet and two typos in the doc
|
|
* rj/minor-doc-improvements:
Remove dashes from error_logger doc
Add start/0,1 and help/0 to etop's doc
Remove/add extra/missing white spaces
|
|
* rj/fix-global-spec:
Improve global:re_register_name/2,3 spec
Fix global:{random_exit_name,random_notify_name}/3 spec
|
|
* origin/peppe/common_test/otp-9666:
Set correct group leader for end_per_testcase process after tc timeout
OTP-9666
|
|
* origin/peppe/common_test/otp-9634_9659:
Change the option name 'unique_priv_dir' to 'create_priv_dir'
Add test suite for the unique_priv_dir feature
Make it possible to use unique priv_dir names
Create entry for every repeated test in index.html
OTP-9634
OTP-9659
|
|
|
|
|
|
* bjorn/compiler/coverage-and-minor-fixes/OTP-9982:
v3_life: Use common code for guards and bodies
v3_core: Don't put negative line numbers in annotations
v3_kernel: Dig out the line number only when generating a warning
v3_kernel: Clean up handling of guards
v3_kernel: Introduce is_in_guard/1
v3_kernel: Removed unreached clause for #k_bin_int{} in sub_size_var/1
v3_kernel: Remove unreached handling of #k_bin_int{} in arg_con/1
v3_codegen: Eliminate the special case of 'put' without destination
v3_kernel: Don't attempt to share identical literals
v3_kernel: Handle sequences in guards
v3_kernel: Remove clauses that are never executed in arg_val/1
v3_kernel.hrl: Remove unused record #k_string{}
v3_kernel.erl: Remove unused define of EXPENSIVE_BINARY_LIMIT
sys_core_fold: Refactor previous_ctx_to_binary/2 to cover it completely
sys_core_fold: Fix opt_guard_try/1
sys_core_fold: Simplify opt_bool_not() to cover it completely
sys_core_fold: Remove duplicate optimization
|
|
* origin/peppe/common_test/otp-9899:
Fix broken repeat functionality
OTP-9899
|
|
* origin/peppe/common_test/otp-9964_9975_9595:
Have ct_run clean up the code path after each test run
Fix problems with ct_run's code path manipulation
OTP-9964
OTP-9975
OTP-9595
|
|
|
|
In Core Erlang and later passes, compiler-generated code can be
indicated in two different ways: by negative line numbers and by
a 'compiler_generated' annotation.
Simplify the code and improve coverage by turning negative line
numbers positive and adding a 'compiler_generated' annotation in
the v3_core pass. That means that Core Erlang and latter passes
do not have deal with negative line numbers.
|
|
|
|
Handling of guards become a mess when andalso/orelse in guards
were introduced. Clean it up by using common code for most
constructs, regardless of where they occur, and when needed use
is_in_guard/1 to handle guard constructs differently.
|
|
Also make sure that warnings about failure or timeout of end_per_testcase
(after a test case timeout) get printed in the test case log file.
OTP-9666
|
|
The new values for create_priv_dir are:
auto_per_run, auto_per_tc, manual_per_tc
|
|
|
|
Introduce the optional feature to have Test Server generate
priv_dir directory names that are unique for each test case
or config function. The name of the option/flag is
'unique_priv_dir' and it can be set to value 'auto' or
'manual'. If auto, Test Server creates each priv_dir
automatically (can be expensive in case of many and/or repeated
cases). If manual, the user needs to create the priv_dir
explicitly by calling ct:make_priv_dir/0.
|
|
For each repeated test during a test run, an entry is created
in the index.html file (i.e. the overview file for the test run).
In the top level (logdir) index file, only the last test result is
listed.
E.g, given the test spec:
[{merge_tests,false},{dirs,testobj1},{dirs,testobj1}]
In the index file for the test run (under Logdir/ct_run.Node.Date.Time),
both dir tests are listed. In the top level index file (under Logdir),
only the last test is listed (one has to find all results through the
all_runs.html file).
|
|
* origin/peppe/common_test/otp-9730:
Add column for group name in suite overview log file
OTP-9730
|
|
* origin/peppe/common_test/otp-9904_9900:
Introduce error notification printout in the tc log
OTP-9904
OTP-9900
|
|
* origin/peppe/common_test/otp-9830:
Fix problem with buffered DOWN messages
OTP-9830
|
