#456: Ensure functions are not defined twice
-------------------------+--------------------------------------------------
Reporter: hinder | Owner:
Type: enhancement | Status: new
Priority: major | Milestone:
Component: Cactus | Version:
Keywords: |
-------------------------+--------------------------------------------------
When multiple source files define non-static functions with the same name,
these are all compiled together into the resulting executable. Which one
gets called is not predictable by the user.
This can happen if a user copies a thorn, modifies it slightly, and
compiles both thorns into the same configuration. This can lead to *very*
difficult-to-find bugs, and it would be helpful if Cactus was able to
prevent this, or at least to mitigate the problem.
At the CST level, Cactus should be able to tell that there are two thorns
which schedule functions with the same name. At the moment, this is not
caught. I propose that this should be a fatal error, as there is no way
to predict which function will be called eventually.
This will solve the problem in some cases, but not in the case where there
are instances of duplicate function names which are not scheduled. It
should be possible to scan the object/library files using standard tools
(nm etc) to determine if there are multiple globally visible symbols with
the same name. There might even be standard tools for this purpose.
Doing this in a portable way might not be straightforward, but having an
implementation for Linux, for example, would catch the majority of cases.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/456>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#447: simfactory 1.0 always uses -L 3
----------------------------------------------+-----------------------------
Reporter: alexander.beck-ratzka@… | Owner: eschnett
Type: defect | Status: new
Priority: major | Milestone:
Component: SimFactory | Version:
Keywords: |
----------------------------------------------+-----------------------------
The perl version of simfactory always uses the debugging loglevel for
simulations. The loglevel of a cactus simulation can be specified by
setting -L to a value between 0 (none) and 3 (debug). While the cactus
default is 0, simfactory sets it to 3. The debug loglevel could lead to
huge output files.
I would suggest to set it to the cactus default, and allow a user to
increase it.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/447>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#107: Update released einsteintoolkit.bib once we have a more final version
-----------------------+----------------------------------------------------
Reporter: anonymous | Type: task
Status: new | Priority: major
Milestone: | Component: EinsteinToolkit website
Version: | Keywords:
-----------------------+----------------------------------------------------
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/107>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#346: Detect when --reconfig is necessary
----------------------+-----------------------------------------------------
Reporter: eschnett | Owner:
Type: defect | Status: new
Priority: minor | Milestone:
Component: Other | Version:
Keywords: |
----------------------+-----------------------------------------------------
Cactus sometimes outputs an error message that a configuration needs to be
reconfigured. Simfactory should notice this, and then automatically build
with --reconfig.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/346>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#450: Output elapsed times for test cases
-------------------------+--------------------------------------------------
Reporter: eschnett | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: Cactus | Version:
Keywords: |
-------------------------+--------------------------------------------------
To ensure that Cactus test cases don't run for too long, and to identify
those that do, we should output the run time for all test cases together
with their results.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/450>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#229: Using a nonexistent header file should lead to an error message
--------------------+-------------------------------------------------------
Reporter: hinder | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: Cactus | Version:
Keywords: |
--------------------+-------------------------------------------------------
If I have the following in my interface.ccl,
USES INCLUDE: vectors.h
but no thorn in my thornlist provides this header file, there is no error
at compile time. Further, if I #include this file in my source file, an
empty file is included, which means that again I don't get an error. The
first indication that something is wrong is that the contents of the
header file are not available, which makes debugging the problem with the
thornlist very confusing.
I propose that the CST should emit a fatal error if one of the thorns
tries to use a header file which does not exist.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/229>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#526: Reorder ticket states
----------------------------------+-----------------------------------------
Reporter: eschnett | Owner:
Type: defect | Status: new
Priority: minor | Milestone:
Component: EinsteinToolkit trac | Version:
Keywords: |
----------------------------------+-----------------------------------------
The order in which the ticket states is displayed (in the form where one
modifies the ticket state) should be the natural order in which a ticket
progresses. The current order is somewhat random.
I suggest this order:
new
confirmed
accept
reassign
review
resolve
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/526>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#519: Add all ET repositories to TRAC
----------------------------------+-----------------------------------------
Reporter: hinder | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: EinsteinToolkit trac | Version:
Keywords: |
----------------------------------+-----------------------------------------
TRAC provides integration with version control systems. It has a list of
repositories, and specific changesets and files can be referred to in
ticket comments and wiki pages using a convenient syntax. Several ET
repositories have been added already. I think this feature is useful, and
that the remaining repositories should be added.
It would be nice if the links were easier to type. I propose omitting the
arrangement name from the repositories, as all thorn names are probably
unique, and avoiding spaces which require extra quoting. We have several
repositories in Git and Mercurial. It would be nice to include those as
well. I believe that there are TRAC plugins to accomplish this in the
same way as for SVN.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/519>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#650: User is not asked for Mercurial authentication information initially
---------------------------+------------------------------------------------
Reporter: hinder | Owner: eric9
Type: defect | Status: new
Priority: major | Milestone:
Component: GetComponents | Version:
Keywords: |
---------------------------+------------------------------------------------
When running GetComponents without the "-a" (anonymous) option, the user
is asked initially for authentication information for any authenticated
repositories. However, the Carpet repository is not included in this
list. This leads to the authentication prompt much later when Carpet is
actually being checked out, and here it is not possible to say
"anonymous". I believe the problem occurs on line 846 of GetComponents:
{{{
# if AUTH_URL is defined we want to find the username:
if (
defined( $component->{AUTH_URL} )
and ( $component->{TYPE} eq 'cvs'
or $component->{TYPE} eq 'svn'
or $component->{TYPE} eq 'darcs'
or $component->{TYPE} eq 'git' )
)
{
}}}
where Mercurial (hg) is not included in that list. The attached
(untested) patch adds hg to that list, but I don't know if this is
sufficient to fix the problem.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/650>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit