client.cfg

Caporegime
Joined
18 Oct 2002
Posts
25,287
Location
Lake District
Just noticed a new line in my cfg that I didn't put there, local=1, what's this setting for?
 
It was used to help stop clients getting confused with files from another client on a dual core machine when running two clients simultaneously

I don't think the new clients have a problem with this anymore.

How many times do you think I can get away with using the word client in this post.

Client
 
Actually, you're both wrong ;)

The local value inside client.cfg simply tallies the number of WUs submitted by that particular client since you installed it.

I think you're getting confused with the -local flag that gets passed to the client which forces it not to use the registry for certain settings.
This flag is still required (on Windows) to run multiple clients on one machine.
 
How spectacularly stupid.

You would have thought a meaningful name would have been used. Like WUCount or something. Local means **** all to beginners and is misleading to us veterans :p
 
How spectacularly stupid.

You would have thought a meaningful name would have been used. Like WUCount or something. Local means **** all to beginners and is misleading to us veterans :p

It makes sense it you think of it as "local WU count", which is in fact what it is ;) Plus, it's largely irrelevant to end users.
 
I'm with Sirius on this one, you shouldn't have two different things called the same thing lol :P

If it means Local WU Count then why not bloody write that, lazy so-and-so's
 
Reminds me of the time we were clearing some space on the filer and found a random file called DELETEME.ORA :eek:
 
You would think the basics of having understandable code would tell them to make everything absolutely clear :p

As said "local" is not a good variable name. localcount is better. localwucount better still. Naughty lazy programmers! :D

Who cares? They know what it means, and it makes no difference to the rest of us, it's not OSS :p
 
I'm not that bothered. Still, I am not surprised. Every time stanford releases a new BETA they usually manage to break the log output again :p
 
I'm not that bothered. Still, I am not surprised. Every time stanford releases a new BETA they usually manage to break the log output again :p

Don't I know it, however, as a side note, I'm porting the important bits of qd into FahMon which will alleviate some of the annoying monitoring related bugs, since queue.dat is the only reliable source for some data.
 
Back
Top Bottom