#261: GetComponents misleading warning message
------------------------------+---------------------------------------------
Reporter: bmundim | Owner: eric9
Type: defect | Status: new
Priority: minor | Milestone:
Component: GetComponents | Version:
Keywords: warning messages |
------------------------------+---------------------------------------------
I receive the following kind of warning quite often when updating my tree:
-----------------------------------------------------------------
Updating module: Carpet/doc
from repository: git://carpetcode.dyndns.org/carpet
located in: Cactus/arrangements
Executing: git stash
In: /work/01157/bcmundim/einstein_dev_chandra/Cactus/repos/carpet
No local changes to save
Executing: git pull --rebase
In: /work/01157/bcmundim/einstein_dev_chandra/Cactus/repos/carpet
Current branch master is up to date.
Executing: git stash pop
In: /work/01157/bcmundim/einstein_dev_chandra/Cactus/repos/carpet
fatal: Needed a single revision
: no valid stashed state found
Warning: Could not update carpet. Could not pop stashed changes.
-----------------------------------------------------------------
I am not sure what 'fatal: Needed a single revision' means, but if the
current branch is already up to date, why do I receive a warning message
saying that
GetComponents couldn't update the repository?
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/261>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#248: Enhance GetComponents functionality when dealing with git branches
---------------------------+------------------------------------------------
Reporter: bmundim | Owner: eric9
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: GetComponents | Version:
Keywords: git branches |
---------------------------+------------------------------------------------
When using git it is very common to develop new code or functionality in
separate branches. Sometimes these branches are maintained in a central
repository too (besides in the user local repo). It would be nice if
GetComponents could handle the checkout and update of *all* these branches
in the *same* Cactus tree. Currently we have to either checkout these
branches manually (a bit inconvenient) or to have several Cactus trees,
each containing the branch that we want to work with (quite impractical
and expensive). I suggest that GetComponents understands the following
lines written in the same thorn list file and checkout all the appropriate
branches:
!CRL_VERSION = 1.0
!DEFINE ROOT = Cactus
!DEFINE ARR = $ROOT/arrangements
# Checkout the master branch:
!TARGET = $ARR
!TYPE = git
!URL = ssh://path/to/repo
!CHECKOUT =
arrangement1/thorn1
arrangement1/thorn2
#Checkout the development branch:
!TARGET = $ARR
!TYPE = git
!URL = ssh://path/to/repo
!REPO_BRANCH = development
!CHECKOUT =
arrangement1/thorn1
arrangement1/thorn2
#Checkout the experimental branch:
!TARGET = $ARR
!TYPE = git
!URL = ssh://path/to/repo
!REPO_BRANCH = experimental
!CHECKOUT =
arrangement1/thorn1
arrangement1/thorn2
#Checkout the test branch:
!TARGET = $ARR
!TYPE = git
!URL = ssh://path/to/repo
!REPO_BRANCH = test
!CHECKOUT =
arrangement1/thorn1
arrangement1/thorn2
As far as I understand this workflow is not usual for either cvs or svn.
So the "feature" proposed here would be limited to git repositories (I
know nothing about darcs and very little about hg. So someone may want to
comment for these repo types.).
Thanks,
Bruno.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/248>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#264: Reference Manual gives wrong include file for CCTK_TerminateNext
--------------------------------------------+-------------------------------
Reporter: roland.haas@… | Type: defect
Status: new | Priority: minor
Milestone: | Component: Cactus
Version: | Keywords: documentation
--------------------------------------------+-------------------------------
CCTK_TerminateNext is declared in cctk_Termination.h not in cctk.h anymore
(2001). Also there is not Fortran prototype anymore.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/264>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#213: "cleanup" is implemented twice
------------------------+---------------------------------------------------
Reporter: eschnett | Owner: mthomas
Type: defect | Status: new
Priority: minor | Milestone:
Component: SimFactory | Version:
Keywords: |
------------------------+---------------------------------------------------
The functions command_cleanup and CleanupRestarts are very similar. One of
them should probably call the other.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/213>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#220: "sim stop" should be able to stop multiple simulations
-------------------------+--------------------------------------------------
Reporter: eschnett | Owner: mthomas
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: SimFactory | Version:
Keywords: |
-------------------------+--------------------------------------------------
If multiple simulations are given as argument to "sim stop", all should be
stopped
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/220>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#258: Add support for Datura to the Python version
-------------------------+--------------------------------------------------
Reporter: eschnett | Owner: mthomas
Type: enhancement | Status: new
Priority: critical | Milestone:
Component: SimFactory | Version:
Keywords: |
-------------------------+--------------------------------------------------
The Perl version already supports Datura.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/258>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#153: docs.einsteintoolkit.org login does not require https
----------------------+-----------------------------------------------------
Reporter: hinder | Owner:
Type: defect | Status: new
Priority: critical | Milestone:
Component: Other | Version:
Keywords: |
----------------------+-----------------------------------------------------
If I go to http://docs.einsteintoolkit.org and click on "log in/create
account" in the top right hand corner, it gives a login page which is
served via http not https. As I understand it, the passwords used here
are CCT accounts, and so they should not be transmitted in plain.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/153>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#146: Update GRHydro examples for EOS_Omni
----------------------+-----------------------------------------------------
Reporter: eschnett | Owner:
Type: defect | Status: new
Priority: major | Milestone:
Component: Cactus | Version:
Keywords: |
----------------------+-----------------------------------------------------
Please update the GRHydro examples to use EOS_Omni; this would help me
update my parameter files.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/146>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit
#187: Cannot disable optimisation with Intel compiler using OPTIMISE=no
-------------------------+--------------------------------------------------
Reporter: hinder | Owner:
Type: enhancement | Status: new
Priority: minor | Milestone:
Component: Cactus | Version:
Keywords: |
-------------------------+--------------------------------------------------
Cactus supports a variable OPTIMISE=yes/no to control whether optimisation
is performed during compilation. Setting this variable to "yes" (for
example, make sim-config OPTIMISE=yes) adds the flags in C_OPTIMISE_FLAGS
to CFLAGS so that optimisation is performed. This is the default.
Setting OPTIMISE=no does not add the flags. For gcc, this results in an
unoptimised configuration as gcc assumes -O0 as the default. The Intel
compiler, however, uses -O2 as the default. Hence, setting OPTIMISE=no
has no effect on Intel, and -O2 is still used.
The attached patch adds new configuration options C_NO_OPTIMISE_FLAGS,
CXX_NO_OPTIMISE_FLAGS, F77_NO_OPTIMISE_FLAGS and F90_NO_OPTIMISE_FLAGS to
complement the *_OPTIMISE_FLAGS options. These are added to the flags
when OPTIMISE=no is used, and they default to -O0, which for the commonly
used gcc and Intel compilers will lead to an unoptimised configuration. I
have also included a patch to the documentation.
I have not included the automatically generated configure script; to avoid
confusion the committer should probably generate this.
--
Ticket URL: <https://trac.einsteintoolkit.org/ticket/187>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit