Eliminate local.txt. Bad idea?
 

I've long regretted the decision to have both a prime.txt and local.txt file to store prime95 settings. I often have no idea which .txt file is supposed to have a particular setting. The original idea was one could set up a new computer by copying a prime95 install from one computer to the new computer and delete the local.txt file. a) I doubt anyone uses that "feature". b) I doubt it works.

I could fix this in 30.10 by moving every local.txt option to prime.txt and deleting local.txt. From then on, all options are read from prime.txt.

Bad idea? Could this break any scripts users have? Thoughts?

I think it's a fantastic idea. I never know where settings are supposed to go.

I often copy my mprime install from computer to computer and all I do is remove the ComputerID and ComputerGUID lines (as well as worktodo.txt and results.txt). I'll tweak the CoresPerTest and Memory lines if necessary.

[QUOTE=Prime95;624112]Bad idea? Could this break any scripts users have? Thoughts?[/QUOTE]

Good idea. And this would break no scripts I have, nor any I know of.

Tech debt is a thing. So is refactoring.

Thirded!

Sounds like a great idea. My only question is, will there be some kind of automatic handler for anyone upgrading an existing installation (is this what you mean by "moving every local.txt option to prime.txt and deleting local.txt"?), or will recovering any custom local.txt values be incumbent upon the user?

[QUOTE=techn1ciaN;624119]Sounds like a great idea. My only question is, will there be some kind of automatic handler for anyone upgrading an existing installation (is this what you mean by "moving every local.txt option to prime.txt and deleting local.txt"?), or will recovering any custom local.txt values be incumbent upon the user?[/QUOTE]

Yes, handled automatically.

[QUOTE=Prime95;624112]Could this break any scripts users have?[/QUOTE]
[XKCD]1172[/XKCD]

But seriously, this one is long overdue

No problem with removing local.txt

I would also like to mention:
- when mprime runs out of work (empties worktodo.txt), it sets UsePrimenet=0 and NoMoreWork=0 (which wore set to UsePrimenet=1 and NoMoreWork=1 initially). This looks like a bug.
- it would be great if prime.txt would never be written by mprime. The user writes prime.txt, mprime *only* reads it.

If for some reason some options in prime.txt need to be written by the software, thouse are the ones that should be extracted from prime.txt to a separate file, such that prime.txt becomes read-only.

[QUOTE=preda;624125]- when mprime runs out of work (empties worktodo.txt), it sets UsePrimenet=0 and NoMoreWork=0 (which wore set to UsePrimenet=1 and NoMoreWork=1 initially). This looks like a bug.[/QUOTE]

This has been the behaviour for many years. It's a little annoying, but I mostly keep a buffer of work personally, so I don't run into it often.

For what it's worth, I'd also be happy with getting rid of local.txt

If you absolutely want to retain compatability, you could allow both files to be used interchangeably. That doesn't sound like a good idea though.

[QUOTE=preda;624125]...
- it would be great if prime.txt would never be written by mprime. The user writes prime.txt, mprime *only* reads it.

If for some reason some options in prime.txt need to be written by the software, those are the ones that should be extracted from prime.txt to a separate file, such that prime.txt becomes read-only.[/QUOTE]
I suppose some you mean something like :
"The values that the software generates should be in another file than prime.txt which should only contain user settable settings."
Most users set at least some of their preferences and work settings through the menu, which implies the software must be able to change them in prime.txt.

[QUOTE=S485122;624135]Most users set at least some of their preferences and work settings through the menu, which implies the software must be able to change them in prime.txt.[/QUOTE]
I took it to mean, the program mustn't change any settings on its own. Doing so at the behest of user should be perfectly cromulent.

:tu:

In the absence of any other considerations, I would vote against. The difference between the two is logical and easily understood, and in at least one case I have moved an installation to a different system by deleting local.txt and letting prime95 re-make it; the behavior of the program in automatically updating only local.txt is also a useful thing to remember.

So I can't see why it needs to be done from the user standpoint; if it's a matter of simplifying things for you as programmer it would be different.

Moving all [I]user-set[/I] options to prime.txt (possibly still allowing them in local.txt for compatibility), while retaining local.txt for the stuff normally written by the program, though, seems a reasonable solution from all perspectives.

Since Preda also mentioned it, I'll add that I also agree to his second point: the behavior of prime95 after running out of work is annoying and appears like a bug. Letting this happen is useful as there seems to be no other way to get it to stop exactly after the completion of a certain list of jobs.

I could also neaten prime.txt by grouping "like-minded" settings together in their own section. For example, put all the values one shouldn't touch such as maintaining the rolling average or counting the CERT MB downloaded in a section marked [internal settings]. Benchmark settings could go in the [bench] section, etc.

A section that covers the "delete these values when copying to a new machine" would be useful.

And while we are at it:
Is/can there be a way to set-up Prime95 such that rather specifying a specific number of cores per worker, one could do something like this (in the Prime.txt)
[Workers]
WorkerDivisionMethod=1 {where 0 would be the current system and 1 would be new way}
WorkerDivision1=25 {the approximate percentage of the cores attributed to Worker1, Prime95 would round workers up or down as needed}
WorkerDivision2=25
WorkerDivision3=50 {if the total is less than 100%, then a test is performed to see if the sum of the percentages (when rounded) will leave 1 or more cores idle}

So if a person copies their setup from a 4 four machine to an 8 core machine, the number of workers would remain the same, but each would get a second core. If going from a 6 core to 8 core some workers might get more, others not.

And a way to make one worker per chiplet or numa node may be helpful (not something I would use at the moment though).

[QUOTE=Prime95;624215]I could also neaten prime.txt by grouping "like-minded" settings together in their own section. For example, put all the values one shouldn't touch such as maintaining the rolling average or counting the CERT MB downloaded in a section marked [internal settings]. Benchmark settings could go in the [bench] section, etc.[/QUOTE]

Now this would be a good idea in any case, but even more so if you've decided to merge the two files.

[QUOTE=Prime95;624215]I could also neaten prime.txt by grouping "like-minded" settings together in their own section. For example, put all the values one shouldn't touch such as maintaining the rolling average or counting the CERT MB downloaded in a section marked [internal settings]. Benchmark settings could go in the [bench] section, etc.[/QUOTE]

If this is done please make it a cosmetic feature i.e. if someone puts something in the wrong location it is moved to the correct location rather than ignored. Otherwise it just makes life more difficult.

[QUOTE=henryzz;624314]If this is done please make it a cosmetic feature i.e. if someone puts something in the wrong location it is moved to the correct location rather than ignored. Otherwise it just makes life more difficult.[/QUOTE]

We think alike :smile:

Use as many section headings as you like, with one that is
[User modifiable]

(Everything else is user keep out or beware and possibly harmful or fatal to program execution)
That said, I've seen the screen coordinates for the GUI get trashed and need to be manually edited.
Editing program-generated lines would require user knowledge, or coaching by the author.

Some NUMA awareness would be great. Not sure how that changes the file content or structure.

[QUOTE=kriesel;624353]Use as many section headings as you like, with one that is [User modifiable].[/QUOTE]

A developer always enjoys receiving advice and feedback from users. Also eating your own dog food is useful.

[QUOTE=kriesel;624353]Some NUMA awareness would be great. Not sure how that changes the file content or structure.[/QUOTE]

Not to mention the fundemental code-base.

Thanks everyone. This is where I come to calm down.

[QUOTE=preda;624125]
- when mprime runs out of work (empties worktodo.txt), it sets UsePrimenet=0 and NoMoreWork=0 (which wore set to UsePrimenet=1 and NoMoreWork=1 initially). This looks like a bug.
- it would be great if prime.txt would never be written by mprime. The user writes prime.txt, mprime *only* reads it.

If for some reason some options in prime.txt need to be written by the software, thouse are the ones that should be extracted from prime.txt to a separate file, such that prime.txt becomes read-only.[/QUOTE]

The best way to do this is "DaysOfWork=0"

NoMoreWork=1 really means "Quit GIMPS after current assignments complete"

[QUOTE=Prime95;626012]NoMoreWork=1 really means "Quit GIMPS after current assignments complete"[/QUOTE]

In 30.11, NoMoreWork will be renamed QuitGIMPS.
The mprime menus will allow setting "Days of work to queue up" to zero. The Windows dialog box already allowed this.

What about:
MaxExponents=0

that seems to work ok as well.

[QUOTE=ATH;626014]What about:
MaxExponents=0

that seems to work ok as well.[/QUOTE]

I suppose that would work as well.

So you will just merge two files into one? And all content of one file copy to another. No more no less? :)

[QUOTE=pepi37;626017]So you will just merge two files into one? And all content of one file copy to another. No more no less? :)[/QUOTE]

When you first run 30.11, the two files will be merged into one and local.txt deleted.
A few options are renamed for clarity. Some options are moved to sections like [Internals] or [PrimeNet], also for clarity.

Again, all automatic.

[QUOTE=Prime95;626019]When you first run 30.11, the two files will be merged into one and local.txt deleted.
A few options are renamed for clarity. Some options are moved to sections like [Internals] or [PrimeNet], also for clarity.

Again, all automatic.[/QUOTE]

Only downside I see here is that it's a one-way trip; downgrades won't know what to do with the combined file. I don't plan on downgrading, but it's worth considering if there's some reason that someone might be inclined to try.

Bugs motivating version revert are one foreseeable reason. User preference is another.
So:

copy prime.txt was.prime.txt
copy local.txt was.local.txt
merge files

There seems to be something I didn't get here: what are you trying to accomplish using DaysOfWork=0 or MaxExponents=0 ? What is the intended behavior when exhausting worktodo? I think it should just be a normal stop (and automatic restart if new work is received through Primenet).

This might not be the right place to ask, but is there an option to not receive work from the server, but still submit results automatically? I ask because my current setup racks up several (unwanted) assignments when the work I queue gets low, but I have found in the past that setting days of work to queue lower sometimes removes work that I add manually.

[QUOTE=Denial140;626066]This might not be the right place to ask, but is there an option to not receive work from the server, but still submit results automatically? I ask because my current setup racks up several (unwanted) assignments when the work I queue gets low, but I have found in the past that setting days of work to queue lower sometimes removes work that I add manually.[/QUOTE]

Set DaysOfWork=0 and UnreserveDays=999999, both in prime.txt.

The first tells the client to not fetch more work from PrimeNet. The second prevents it from unreserving assignments. Sometimes the computer will be busy doing something else when mprime/Prime95 calculates the system throughput which causes it to unreserve exponents.

I would go one step further and do not use prime.txt and local.txt anymore at all, and instead rename the new file settings.txt (or settings.ini).
It will break my CoreCycler script, but it's an easy enough fix.

Prime95 changing settings files from .ini to .txt was requested by and / or welcomed by Windows users, because then we didn't need to adjust file associations on every system installation to our favorite text editor for .ini.

Typically the GIMPS apps use a file name for their settings initialization/configuration corresponding to (matching) the program's name;

prime95 & mprime: prime.txt & local.txt
Mlucas: mlucas.ini
Gpuowl: config.txt
Mfaktc: mfaktc.ini
Mfakto: mfakto.ini
CUDAPm1 CUDAPm1.ini
CUDALucas: CUDALucas.ini
clLucas: clLucas.ini
mmff: mmff.ini

Most use .txt for worktodo; Mlucas is an outlier there, using .ini
Some support work to be added as worktodo.add (prime95, mfakt[co])

Benchmark data is saved differently among applications, if at all.
Mlucas: mlucas.cfg
prime95/mprime: results.benchmark.txt
Gpuowl: N/A
Mfaktc: N/A
Mfakto: N/A
mmff: N/A
...