#1188: GetComponents should output the total number of components to be downloaded
Reporter: Ian Hinder
Status: wontfix
Milestone:
Version:
Type: enhancement
Priority: minor
Component: GetComponents
Changes (by Roland Haas):
status: wontfix (was new)
If GetComponents outputs the total number of components it is about to download, then Mohave will be able to give a better progress report. This would also be helpful for users as they can see how far through the process they are.
**Keyword:**
Comment (by Roland Haas):
Eclipse (and its Cactus integration) seems no longer in use for the ET. Progress updates with parallel checkouts are tricky, GetComponent does not always know which components it will update vs. download freshly.
This seems lots of work for little gain just to get at Windows like progress bar that gets stuck on the last % value.
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/1188/getcomponents-sho…
#2719: GetCompnents does not handle symbolic links correctly when checking repository inter-dependencies
Reporter: Roland Haas
Status: new
Milestone:
Version:
Type: bug
Priority: minor
Component: GetComponents
GIven two stanzas:
```
# FUKA initial data thorns
# the crazy path works around a bug in GetComponents that does not handly
# symbolic links and ".." correctly
!TARGET = $ARR/Fuka/KadathThorn/src/fuka
!TYPE = git
!URL = https://bitbucket.org/fukaws/fuka
!CHECKOUT = Cmake build_debug build_release codes eos include install_par.sh install_seq.sh src src_par src_seq
!TARGET = $ARR
!TYPE = git
!URL = https://bitbucket.org/fukaws/$2
!REPO_PATH=../$2
!CHECKOUT = Fuka/KadathImporter Fuka/KadathThorn
#DISABLED Fuka/KadathImporter
#DISABLED Fuka/KadathThorn
```
GetComponents detects that the `Cmake`, `build_debug` etc files checked out of `fuka` depend on `KadathThorn` having been checked out by running `$TARGET/$CHECKOUT` for both through `canonpath` then doing a _string_ comparison to check if the path obtained for `fuka` starts with that of `KadathThorn`.
However when creating symbolic links it uses `abs2rel` which walks the directory tree and produces possibly incorrect symbolic links. Namely I get:
```
$ ls repos/KadathThorn/src/fuka/ -l total 44
lrwxrwxrwx 1 rhaas rhaas 31 Apr 25 13:28 Cmake -> ../../../../../repos/fuka/Cmake
lrwxrwxrwx 1 rhaas rhaas 37 Apr 25 13:28 build_debug -> ../../../../../repos/fuka/build_debug
lrwxrwxrwx 1 rhaas rhaas 39 Apr 25 13:28 build_release -> ../../../../../repos/fuka/build_release
lrwxrwxrwx 1 rhaas rhaas 31 Apr 25 13:28 codes -> ../../../../../repos/fuka/codes
lrwxrwxrwx 1 rhaas rhaas 29 Apr 25 13:28 eos -> ../../../../../repos/fuka/eos
lrwxrwxrwx 1 rhaas rhaas 33 Apr 25 13:28 include -> ../../../../../repos/fuka/include
lrwxrwxrwx 1 rhaas rhaas 40 Apr 25 13:28 install_par.sh -> ../../../../../repos/fuka/install_par.sh
lrwxrwxrwx 1 rhaas rhaas 40 Apr 25 13:28 install_seq.sh -> ../../../../../repos/fuka/install_seq.sh
lrwxrwxrwx 1 rhaas rhaas 29 Apr 25 13:28 src -> ../../../../../repos/fuka/src
lrwxrwxrwx 1 rhaas rhaas 33 Apr 25 13:28 src_par -> ../../../../../repos/fuka/src_par
lrwxrwxrwx 1 rhaas rhaas 33 Apr 25 13:28 src_seq -> ../../../../../repos/fuka/src_seq
```
which have an extra `../`
Instead one must use:
```
# FUKA initial data thorns
# the crazy path works around a bug in GetComponents that does not handly
# symbolic links and ".." correctly
!TARGET = $ARR/Fuka/KadathThorn/src/fuka/../../../../../repos/KadathThorn/src/fuka
!TYPE = git
!URL = https://bitbucket.org/fukaws/fuka
!CHECKOUT = Cmake build_debug build_release codes eos include install_par.sh install_seq.sh src src_par src_seq
```
for the first stanza to make sure it does not end up in a symbolic link. Which produces the correct:
```
$ ls repos/KadathThorn/src/fuka/ -l
total 44
lrwxrwxrwx 1 rhaas rhaas 28 Apr 25 13:29 Cmake -> ../../../../repos/fuka/Cmake
lrwxrwxrwx 1 rhaas rhaas 34 Apr 25 13:29 build_debug -> ../../../../repos/fuka/build_debug
lrwxrwxrwx 1 rhaas rhaas 36 Apr 25 13:29 build_release -> ../../../../repos/fuka/build_release
lrwxrwxrwx 1 rhaas rhaas 28 Apr 25 13:29 codes -> ../../../../repos/fuka/codes
lrwxrwxrwx 1 rhaas rhaas 26 Apr 25 13:29 eos -> ../../../../repos/fuka/eos
lrwxrwxrwx 1 rhaas rhaas 30 Apr 25 13:29 include -> ../../../../repos/fuka/include
lrwxrwxrwx 1 rhaas rhaas 37 Apr 25 13:29 install_par.sh -> ../../../../repos/fuka/install_par.sh
lrwxrwxrwx 1 rhaas rhaas 37 Apr 25 13:29 install_seq.sh -> ../../../../repos/fuka/install_seq.sh
lrwxrwxrwx 1 rhaas rhaas 26 Apr 25 13:29 src -> ../../../../repos/fuka/src
lrwxrwxrwx 1 rhaas rhaas 30 Apr 25 13:29 src_par -> ../../../../repos/fuka/src_par
lrwxrwxrwx 1 rhaas rhaas 30 Apr 25 13:29 src_seq -> ../../../../repos/fuka/src_seq
```
The “obvious” solution would be to use `realpath` instead of `canonpath` however that requires that the path actually exists which is not yet the case when dependencies are checked for.
This was triggered by Fuka in #2711
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2719/getcompnents-does…
#206: Add --xml option to GetComponents
Reporter: Eric Seidel
Status: wontfix
Milestone:
Version:
Type: enhancement
Priority: minor
Component: GetComponents
Changes (by Roland Haas):
status: wontfix (was open)
GetComponents should support machine readable output using XML.
**Keyword:**
Comment (by Roland Haas):
This has not been needed in 13 years. We are unlikely to ever need it.
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/206/add-xml-option-to-…
#1425: git repositories checkout into main tree
Reporter: Frank Löffler
Status: duplicate
Milestone:
Version: development version
Type: enhancement
Priority: minor
Component: GetComponents
Changes (by Roland Haas):
status: duplicate (was new)
Comment (by Roland Haas):
Duplicate of #1047.
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/1425/git-repositories-…
#1130: Cactus tutorial on cactus website
Reporter: Jian Tao
Status: resolved
Milestone:
Version:
Type: bug
Priority: minor
Component: Other
Changes (by Roland Haas):
status: resolved (was new)
Following the instructions on the Cactus website will not lead
to a successful run due to the introduction to ash. This frustrates
new Cactus users.
I would suggest to add
!BRANCH = Cactus_4.0.0
to the thorn list to make it work at least.
**Keyword:**
Comment (by Roland Haas):
Fixed by more explicit instructions in the tutorial jupyter notebook.
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/1130/cactus-tutorial-o…
#2580: GetComponents assumes that default branch name is "master"
Reporter: Roland Haas
Status: new
Milestone:
Version: development version
Type: bug
Priority: minor
Component: GetComponents
Comment (by Roland Haas):
hmm, this would seem to likely cause failures also when we have the release branches set and this be \(much\) more severe than “minor”. Needs testing.
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2580/getcomponents-ass…
#2711: attempting to build KadathThorn assumes a git repository
Reporter: Roland Haas
Status: new
Milestone:
Version:
Type: bug
Priority: major
Component:
Comment (by Roland Haas):
Ok, there is definitely \(at least\) one bug in GetComponent’s. Basically it does not handle symbolic links in paths correctly. I do not want to touch GetComponents this close to the release, so here’s a workaround using a crazy path:
```
# FUKA initial data thorns
# the crazy path works round a bug in GetComponents that does not handly
# symbolic links and ".." correctly
!TARGET = $ARR/Fuka/KadathThorn/src/fuka/../../../../../repos/KadathThorn/src/fuka
!TYPE = git
!URL = https://bitbucket.org/fukaws/fuka
!CHECKOUT = Cmake build_debug build_release codes eos include install_par.sh install_seq.sh src src_par src_seq
```
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2711/attempting-to-bui…
#2711: attempting to build KadathThorn assumes a git repository
Reporter: Roland Haas
Status: new
Milestone:
Version:
Type: bug
Priority: major
Component:
Comment (by Roland Haas):
Alright, something is wrong. I will need to see what it actually uses to check dependency. Likely the CHECKOUT and not the TARGET/NAME data.
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2711/attempting-to-bui…
#2619: include Ellipitca (reader) in Einstein Toolkit
Reporter: Roland Haas
Status: open
Milestone: ET_2023_05
Version:
Type: enhancement
Priority: major
Component:
Comment (by Alireza R.):
Additionally, the resolutions and grid structures of these testing runs between ETK and BAM are different, so we expect some variation at a later time. We plan to perform some gauge-independent tests after completing an entire evolution.
--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2619/include-ellipitca…