Eliminate local.txt. Bad idea?

[axn]

Originally Posted by S485122

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.

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.

[petrw1]

[Andrew Usher]

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

[Prime95]

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.

[Uncwilly]

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.

[Mark Rose]

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

[Andrew Usher]

Originally Posted by Prime95

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.

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

[henryzz]

Originally Posted by Prime95

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.

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.

[Prime95]

Originally Posted by henryzz

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.

We think alike

[kriesel]

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.

[chalsall]

Originally Posted by kriesel

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

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

Originally Posted by kriesel

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

Not to mention the fundemental code-base.

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