GC command line options

[Paul J]

I've looked in the Wiki and still none the wiser....

So I have two versions of GC (and separate athlete data) on my machine, a stable release for every day use, and a development version, so what I want to enter two separate command lines that open the different versions and their associated athlete date, but it just doesn't seem to work...

The last open directory or athlete seems to be problematic, and GC just opens an empty select Athlete dialog, so the commands I'd like to include in my desktop icons:

Stable
C:\Program Files\Golden Cheetah\GoldenCheetah.exe D:\Quick Access\Golden Cheetah Paul

Dev:
D:\Coding\GoldenCheetah\src\release\GoldenCheetah.exe D:\Coding\GoldenCheetah\Library Paul_test

[Mark Liversedge]

$ GoldenCheetah --help

GoldenCheetah V3.6-DEV2009 (4002)
usage: GoldenCheetah [[directory] athlete]

--help or --usage   to print this message and exit
--version           to print detailed version information and exit
--server            to run as an API server
--debug             to direct diagnostic messages to the terminal instead of goldencheetah.log
--clouddbcurator    to add CloudDB curator specific functions to the menus
--no-python         to disable Python startup
--no-r              to disable R startup

Specify the folder and/or athlete to open on startup
If no parameters are passed it will reopen the last athlete.

$

Mark

[ptj...@gmail.com]

Hi Mark,

   I've just tried using "D:/Coding/GoldenCheetah/src/release/GoldenCheetah.exe D:/Coding/GoldenCheetah/Library Paul_Test" 

   and get:

[Ale Martinez]

El domingo, 3 de enero de 2021 a la(s) 10:06:03 UTC-3, ptj...@gmail.com escribió:

I've looked in the Wiki and still none the wiser....

So I have two versions of GC (and separate athlete data) on my machine, a stable release for every day use, and a development version

https://github.com/GoldenCheetah/GoldenCheetah/wiki/FAQ-DATA#how-can-i-have-a-separated-data-or-portable-goldencheetah-install 

[ptj...@gmail.com]

Mark & Ale,

Thank you for your help, I did read the link you sent earlier and moving my test data now it now works.

But I thought from the --usage option that the path & athlete [[directory] Athlete] parameters could specified, then it would override the default location or last opened location functionality. 

The reason why this would be useful is I like to keep my data (D drive) and applications (C Drive aka Win10 drive) separate for backup purposes, I'm not a fan of Windows storing data in AppData as this complicates my backups, I can recover my C drive from downloads from the internet, whilst my D drive holds primary state data/original files.

My Stable setup is

C:\Program Files\Golden Cheetah\GoldenCheetah.exe

GC Data path : D:\Quick Access\Golden_Cheetah_Data  

Athlete : Paul (stored in D:\Quick Access\Golden_Cheetah_Data) 

 

My development setup is

GC : D:\Coding\GoldenCheetah\src\release\GoldenCheetah.exe

GC Data path : D:\Quick Access\Golden_Cheetah_Data

Athlete : Paul_Test (stored in D:\Quick Access\Golden_Cheetah_Data)

so it would be nice to be able to execute GC passing the path & athlete

Stable --> C:\Program Files\Golden Cheetah\GoldenCheetah.exe D:\Quick Access\Golden_Cheetah_Data Paul

Dev  --> D:\Coding\GoldenCheetah\src\release\GoldenCheetah.exe D:\Quick Access\Golden_Cheetah_Data Paul_Test

or even better as a single parameter

Stable --> C:\Program Files\Golden Cheetah\GoldenCheetah.exe D:\Quick Access\Golden_Cheetah_Data\Paul  

Dev --> D:\Coding\GoldenCheetah\src\release\GoldenCheetah.exe D:\Quick Access\Golden_Cheetah_Data\Paul_Test

Sorry if I'm missing the point somewhere....

Regards,

Paul

[Ale Martinez]

El domingo, 3 de enero de 2021 a la(s) 12:53:57 UTC-3, ptj...@gmail.com escribió:

Mark & Ale,

Thank you for your help, I did read the link you sent earlier and moving my test data now it now works.

But I thought from the --usage option that the path & athlete [[directory] Athlete] parameters could specified, then it would override the default location or last opened location functionality. 

The reason why this would be useful is I like to keep my data (D drive) and applications (C Drive aka Win10 drive) separate for backup purposes, I'm not a fan of Windows storing data in AppData as this complicates my backups, I can recover my C drive from downloads from the internet, whilst my D drive holds primary state data/original files.

My Stable setup is

C:\Program Files\Golden Cheetah\GoldenCheetah.exe

GC Data path : D:\Quick Access\Golden_Cheetah_Data  

Athlete : Paul (stored in D:\Quick Access\Golden_Cheetah_Data) 

 

My development setup is

GC : D:\Coding\GoldenCheetah\src\release\GoldenCheetah.exe

GC Data path : D:\Quick Access\Golden_Cheetah_Data

Athlete : Paul_Test (stored in D:\Quick Access\Golden_Cheetah_Data)

so it would be nice to be able to execute GC passing the path & athlete

Stable --> C:\Program Files\Golden Cheetah\GoldenCheetah.exe D:\Quick Access\Golden_Cheetah_Data Paul

Dev  --> D:\Coding\GoldenCheetah\src\release\GoldenCheetah.exe D:\Quick Access\Golden_Cheetah_Data Paul_Test

or even better as a single parameter

Stable --> C:\Program Files\Golden Cheetah\GoldenCheetah.exe D:\Quick Access\Golden_Cheetah_Data\Paul  

Dev --> D:\Coding\GoldenCheetah\src\release\GoldenCheetah.exe D:\Quick Access\Golden_Cheetah_Data\Paul_Test

Sorry if I'm missing the point somewhere....

For that configuration you can set the athlete library to D:\Quick Access\Golden_Cheetah_Data, as explained in https://github.com/GoldenCheetah/GoldenCheetah/wiki/UG_Special-Topics_Setting-the-athlete-library and pass athlete name only in the command line.

[ptj...@gmail.com]

Please ignore my earlier post, I have it working in my batch file:

set stable="C:\Program Files\Golden Cheetah\GoldenCheetah.exe"

set data_home="D:\Quick Access\GoldenCheetah"

set Alth=Paul

CALL %stable% %data_home% %Alth%

On Sunday, 3 January 2021 at 13:59:53 UTC Ale Martinez wrote:

[ptj...@gmail.com]

ok, so there does appear to be a problem of having two separate executables and two separate data sets, and passing them on the command line as per

set DEVELOPMENT="D:\Coding\GoldenCheetah\src\release\GoldenCheetah.exe"

set DATAHOME="D:\Coding\athlete_test_data\GoldenCheetah"

set ATHLETE=PaulDev

CALL %DEVELOPMENT% %DATAHOME% %ATHLETE%

and 

set STABLE="C:\Program Files\Golden Cheetah\GoldenCheetah.exe"

set DATAHOME="D:\Quick Access\GoldenCheetah"

set ATHLETE=Paul

CALL %STABLE% %DATAHOME% %ATHLETE%

as both instances share the file in AppData\Roaming\goldencheetah.org and seem to fight over the homedir, which is the first test in determining the path to the athlete

main.cpp - line 499

        // or did we override in settings?

        QString sh;

        if ((sh=appsettings->value(NULL, GC_HOMEDIR, "").toString()) != QString("")) localLibraryPath = sh;

if this directory doesn't exist, which it always does for me as its either stable or the test path, then it goes on to try

       QString oldLibraryPath=QDir::home().canonicalPath()+"/Library/GoldenCheetah";

all before looking at the passed in parameters on the command line.

So everytime switch between stable & test versions, it causes problems trying load the most recently used data set, which is the wrong one.

Can you tell me what functionality homedir is trying to provide?

Regards,

Paul

[ptj...@gmail.com]

Looking at   https://github.com/GoldenCheetah/GoldenCheetah/wiki/UG_Special-Topics_Setting-the-athlete-library  would require me to edit this value each time I switched between stable and development builds, what I'm after is being able to define this on the command line, so I can have a batch file to launch stable and another for Dev. Please see my later comment, as it would appear to me that the homedir functionality has precedence over the command line parameters, when I would have expected it to be the other way. 

[Ale Martinez]

El domingo, 3 de enero de 2021 a la(s) 15:42:04 UTC-3, ptj...@gmail.com escribió:

Looking at   https://github.com/GoldenCheetah/GoldenCheetah/wiki/UG_Special-Topics_Setting-the-athlete-library  would require me to edit this value each time I switched between stable and development builds, what I'm after is being able to define this on the command line, so I can have a batch file to launch stable and another for Dev.

In the scenario you described in detail both stable and dev point to D:\Quick Access\Golden_Cheetah_Data, no need to change anything.

[ptj...@gmail.com]

Hi Ale,

   Yes you are right, but I was intending to move the GC Althlete test data to another location so the example I gave had a cut and paste error, which wasn't helpful.

   Also if I move PaulDev to my GC data directory that contains my Athlete Paul directory, then both the stable and Dev executables will share the files at the GC directory level shown below, and I was aiming for complete independence between the executables and datasets in case I mess up whilst editing/coding, or there is a difference between versions in these files.

I was thinking that the precedence for processing the startup would be:

1) Command line parameters

2) GoldenCheetah/Library (default) and last open Athlete

3) homedir and last opened Athlete

But it appears to me that it is the opposite.

Regards,

Paul.

[Ale Martinez]

I will take a look at the code, the 2 parameters command line is not something I use and I am not sure it works. Default location for stable and local Library for testing is what I use, that is what I recommended in my first answer.

[ptj...@gmail.com]

Hi Ale,

    The number of paths and their use in main.cpp is somewhat convoluted, so I'm going to refactor the code and make a proposal for simplification, although once complete, I'll need a MAC & Linux user to check it works for them. We appear to have the following paths & Athletes, I would have expected an absolute path to the executable, a path absolute to the Athlete data, and a relative path to the Athlete, but we have more than three.....

• gcroot
• oldLibraryPath
• localLibraryPath (usually setup from GC_HOMEDIR)
• libraryPath
• home
• lastOpened566
• and GC_OPENLASTATHLETE

I'm also wondering why the processing for the command line parameters (lines 569 - 602)  isn't combined with the defining of the library paths (lines 500-527), as the translator processing (541-566) could go after the existing command line processing steps. This would improve the clarity of the precedence of the path handling IMHO, so I'd have thought the processing steps would be:

1. Process command line parameters
2. Process USB path
   
3. Process old style GoldenCheetah/Library location
   
4. and lastly process lastopened path & althlete
5. At this point all the relevant paths and which athlete to open would be clearly defined
   
6. Complete the rest of the processing, settting up translators, TrainDB, etc
   

Some help on understanding the required processing would be helpful, and what purpose of GC_HOMEDIR is for, given this is held in a AppData, and is a single value for GC executables, is it really necessary ?

Regards,

Paul. 

[Ale Martinez]

I did some test to confirm the local library option (https://github.com/GoldenCheetah/GoldenCheetah/wiki/FAQ-DATA#how-can-i-have-a-separated-data-or-portable-goldencheetah-install) allows to have a separate development data set even when you change the location of athlete’s library to your taste (https://github.com/GoldenCheetah/GoldenCheetah/wiki/UG_Special-Topics_Setting-the-athlete-library), that’s is what I would recommend.

Off course you can do whatever you want in your fork, but for contributions in my experience, if you are new to the project, identify a bug or a feature of general use (it is working, but not in the way I would like, tends not to be the case) and develop specific code for that (without simultaneously reformatting and refactoring just because you think it would be better), then it is more likely to be merged than refactorings and changes to better suit your way to do things.

Anyway, this is just my opinion and what I see was approved and not along these years, final decision is from Mark.

[ptj...@gmail.com]

Please see main.cpp in pull request #3752, hopefully it provides greater clarity to the precedence for the various possible paths & athletes, the main.cpp can be taken independently of the other changes, and removes some error cases, like providing too many cmd line parameters.

[ptj...@gmail.com]

Hi Ale,

  Yes I understand and appreciate that re-factorings and changes without prior discussion aren't always going to well received, so maybe I'm I missing another discussion group that covers future changes and/or direction of the project? As I have some time on my hands due to Covid, and keen to get involved to help improve/maintain GC, as I switched from SportsTracks a year or so back and use GC exclusively now as its great.

   So my proposed changes to main.cpp aren't about style, just hopefully making the processing easier to understand whilst fixing a problem with the parsing of the command line parameters.   

   Mark has already told me to use K&R brackets... I'll eventually get with the programme  :)

Regards,

Paul.

[Ale Martinez]

El lunes, 4 de enero de 2021 a la(s) 12:47:19 UTC-3, ptj...@gmail.com escribió:

Hi Ale,

  Yes I understand and appreciate that re-factorings and changes without prior discussion aren't always going to well received, so maybe I'm I missing another discussion group that covers future changes and/or direction of the project?

There is a developers forum to avoid bothering end users with code issues: https://groups.google.com/g/golden-cheetah-developers, github also recently added discussions to avoid the need to create issues to discuss topics, but they are not enabled in our repo yet.

 

As I have some time on my hands due to Covid, and keen to get involved to help improve/maintain GC, as I switched from SportsTracks a year or so back and use GC exclusively now as its great.

   So my proposed changes to main.cpp aren't about style, just hopefully making the processing easier to understand whilst fixing a problem with the parsing of the command line parameters.   

   Mark has already told me to use K&R brackets... I'll eventually get with the programme  :)

I would have prefered a separate PR for clarity sake, since they are unrelated issues, but commits can be cherry picked eventually, thanks.

[ptj...@gmail.com]

Hi Ale,

  Thank you for assistance, and patience with my joining the project, trying to understand the processes, and my proposed changes.

  I see in the project backlog there are two functions to develop/fix regarding overwriting files on import (#1706 & #621), I'm wondering how I go about taking on those changes, how do I know someone else isn't working on them?

I would have prefered a separate PR for clarity sake, since they are unrelated issues, but commits can be cherry picked eventually, thanks 

 

  I totally agree and that was my aim, but I'm getting to grips with GitHub, I was using GitHub desktop until yesterday, and I couldn't seem to create a separate pull request from my fork. I have now installed SourceTree which is much more powerful, and so I can get on with creating separate branches, and I guess from that separate pull requests.

Regards,

Paul

[Ale Martinez]

El martes, 5 de enero de 2021 a la(s) 05:49:52 UTC-3, ptj...@gmail.com escribió:

Hi Ale,

  Thank you for assistance, and patience with my joining the project, trying to understand the processes, and my proposed changes.

Welcome, feel free to ask, I will try to answer if I can. Here are some guidelines for contributing: https://github.com/GoldenCheetah/GoldenCheetah/wiki/Guidelines-for-submitting-a-patch

 

  I see in the project backlog there are two functions to develop/fix regarding overwriting files on import (#1706 & #621), I'm wondering how I go about taking on those changes, how do I know someone else isn't working on them?

Both are long standing issues and were added to v3.6 backlog in batch, it is very likely nobody is working on them, we can assign a issue to you after you comment the issue, so feel free to propose yourself there.