Eliminate local.txt. Bad idea?

[Prime95]

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?

[Mark Rose]

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.

[chalsall]

Originally Posted by Prime95

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

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

Tech debt is a thing. So is refactoring.

[Batalov]

Thirded!

[techn1ciaN]

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?

[Prime95]

Originally Posted by techn1ciaN

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?

Yes, handled automatically.

[axn]

Originally Posted by Prime95

Could this break any scripts users have?

1172

But seriously, this one is long overdue

[preda]

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.

[Mark Rose]

Originally Posted by preda

- 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.

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.

[bur]

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.

[S485122]

Originally Posted by preda

...
- 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.

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.