PyChess sets (pin, gin, availinfo) FICS vars to values that don't work well with other clients or telnet

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Create a FICS account and play with your favorite telnet client
2. Download and start pychess, login to FICS using pychess with your previously 
created FICS account
3. Login again into your FICS account using telnet: pychess scrambled all your 
settings without asking your permission.

Settings changed includes also formula.

What is the expected output? What do you see instead?

I was expecting pychess to ASK me the permission to change my FICS settings, or 
even better, to adapt to them without making any change.

Does it happen every time?
Yes.

What version of the product are you using?
Lastest mercurial.

Did you use an installed version of PyChess or did you run in from a
tarball/svn?
I run it from source.

Original issue reported on code.google.com by dbo...@gmail.com on 30 Oct 2010 at 12:20

[GoogleCodeExporter]

Thanks for the bug report. It's not practical for pychess to "ask you 
permission" to change each and every setting pychess needs for it to function 
correctly (there's alot of them), as pychess' goal is to be usable by people 
who don't care about var settings, in addition to people that do, like us. But 
it is supposed to save your var and formula settings settings (upon login) and 
restore them upon logout (ListAndVarManager.py), right Thomas?

I just tested tip, and gin and availinfo are the two most noticeable FICS var's 
that are not restored. I'm not sure about formulas since I haven't used a 
custom one for a long time.

Original comment by mattgatto on 30 Oct 2010 at 12:43

• Changed state: Accepted
• Added labels: Type-Defect

[GoogleCodeExporter]

Thank you Matt for your explanation on how pychess works.

I can see the bug on this workflow: it assumes that there will be a logout soon 
or later to restore the variables. But that's not true: what if pychess crashes 
or link gets broken?
The variables will not get restored, and, I guess, that was my case :)

General speaking, IMHO you can't assume that after a login there will certainly 
be a logout.
A possible workaround would be to save the vars into a static location (i.e. a 
file) _only_ the first time user logs in to FICS, then always restore variables 
from that file: even in case of a crash, the restored variables will be correct 
and a login/logout will fix the "telnet" environment.

It would be even nicer if FICS guys could introduce support to profiles, so I 
could have my telnet, eboard, pyches, etc... separate profiles and switch them 
with a "profile" command, but stop wandering.

Also, this file should be human-readable for a manual restore if the case 
something goes really wrong.

Just my 2c.

Original comment by dbo...@gmail.com on 30 Oct 2010 at 1:01

[GoogleCodeExporter]

Good point about not assuming there will always be a clean logout. The idea 
about saving vars the first login with a certain userid, and always using that 
to restore variables makes sense. So does the idea about FICS guys creating 
profiles for differe clients. The former idea's logic could look something like 
this:

# login
if config_get('FICS_vars') is None:
    config_set('FICS_vars', get_FICS_vars())

...

# logout
set_FICS_vars(config_get('FICS_vars'))

Note that the state of one's FICS vars are logged before they're changed in the 
pychess logs which are stored at ~/.local/share/pychess. So if they get screwed 
up you could always go in there to find out what they were before pychess 
changed them.

Original comment by mattgatto on 31 Oct 2010 at 2:55

[GoogleCodeExporter]

The FICS guys said this about PyChess not being included in the GUI list:
"Hi,

PyChess has been unlisted because it is known to alter some server variables
on the user profile (gin, pin and availinfo) that cause a lot of confusion
whenever the user switches to a different interface. After many complaints
from several users about this behavior, we have unlisted it.

-- FICS Support"

Original comment by miasid.n...@gmail.com on 1 Nov 2010 at 2:38

[GoogleCodeExporter]

Matt, Thomas, I know too few about these variables, but are these var settings 
really necessary for PyChess to function correctly? How other GUI-s handle this 
problem?
I feel the save/restore method is not a real solution. As bdobom described 
PyChess or the connection can crash, so nothing can guarantee the restore. 
Saving the vars into a static location (i.e. a file) _only_ the first time user 
logs in to FICS is not a solution, because if he will make a different setting 
later in another client program, that will be scrambled by PyChess again.
The solution should be some kind of advanced FICS setting panel in preferences, 
reading vars from the server when logged in, and using that (modifiable) 
settings by PyChess. What do you think, is this possible?

Original comment by gbtami on 2 Nov 2010 at 8:43

[GoogleCodeExporter]

@comment 4, miasid.neofelis: Thanks for the info. AFAIK, it was never listed at 
the http://www.freechess.org/cgi-bin/Download/FICS_Download_Interface.cgi -> 
Linux webpage in the first place, so I'm not sure what they mean by  PyChess 
being "unlisted".

Tamás: These variables turn on server output of information about game 
starts/ends and player logins/status-changes which the pychess Players and 
Games tabs need in order to be updated automatically. The only way the player 
and game lists could function without changing the variables, would be to add a 
"Refresh" button to each tab which manually issued the games/players commands 
which provide the info, or to gobject.timeout_add the games/players commands 
(and maybe under the condition that the respective tab is being shown/focused). 
I think that the ideal fix for this would be, for the FICS server software to 
automatically set these particular variables (gin, pin and availinfo) to 0 upon 
login, and then individual clients can change them as needed after connecting 
to the server. There is simply no other full-proof way to handle this. Even if 
we forked a separate process which waited for pychess to exit, then logged in 
and reset their variables to what they were before pychess changed them, it 
wouldn't cover the case where the user's computer crashed while pychess was 
running and then they logged in on a separate computer with a different client 
like telnet. Also, even if Eboard/Jin/Xboard were patched to set these 
variables to values appropriate to their client (i.e. 0), it wouldn't help with 
the case where pychess crashed and the user logged in afterwards via telnet.

I think it's unfair of whoever wrote this FICS Support reply to blame this 
issue on PyChess. Eboard/Jin/Xboard don't use or need these variables  (AFAIK) 
because they don't have player or game lists that are automatically updated. 
But why would the coders of the server software have created these variables if 
they weren't supposed to be changed or used? I don't see anything on any of the 
help pages on any of these variables that says that client software shouldn't 
change them, or that the client needs to change them back to their original 
value before exiting:
http://www.freechess.org/Help/HelpFiles/v_pin.html
http://www.freechess.org/Help/HelpFiles/v_gin.html
http://www.freechess.org/Help/HelpFiles/v_availinfo.html

However, since pychess is the only client currently in use that needs different 
values for these variables (AFAIK), and we don't want to make unneccessary work 
for the FICS helpers and admins, I guess we need to fix it as best we can until 
the server is fixed, which may never happen. I think the best and easiest 
immediate workaround would be to A) hard set (gin, pin, availinfo) back to 0 
upon logout, B) work on making sure that the logout handler is called whenever 
possible (i.e. whenever we exit from a situation where a signal or exception 
handler could have run cleanup routines like logout before exiting), and maybe 
C) warn the user, the first time they login as a registered user, something 
like:

"Warning: If you use PyChess with other FICS clients, and PyChess or your 
computer crashes while you're logged in with PyChess, you'll need to login and 
logout with PyChess once before logging in with a different client so that your 
FICS user variables are set to a state that make sense for a telnet session and 
Eboard/Jin/Xboard."

Original comment by mattgatto on 4 Nov 2010 at 2:26

[GoogleCodeExporter]

Original comment by mattgatto on 4 Nov 2010 at 4:31

• Changed title: PyChess sets (pin, gin, availinfo) FICS vars to values that don't work well with other clients or telnet

[GoogleCodeExporter]

I can imagine another solution. No automatic update on players/games tab, just 
after the user selects the "Enable PyChess to set FICS user variables for auto 
refresh user/game lists" checkbox in preferences. Maybe in this case we can 
provide a refresh button on these tabs, and an info text about the existence of 
auto mode. All other solutions can be incorrect in certain cases.
But this is just my personal opinion of course.

Original comment by gbtami on 4 Nov 2010 at 5:10

[GoogleCodeExporter]

I think we should hard reset of gin, pin and availinfo.
This is based on the simple observation:
 - You can only disable then once on, if you can do fics blind typing. Any help messages will disappear in the fast stream of data.
 - If you have enabled them once, you should be able to do so again easily.

No solutions seam perfect though. We could do some more checking to call the 
logout handler, and perhaps we could save some variables in a file. Backing up 
variables are however already a major time consumer for login (I remember 50% 
of the login time is spent waiting for variables to be read, just so the new 
values can be set), and as stated by people before me, it will never work 
perfectly.

The next best suboptimal solution is to have a refresh bar, with optional 'auto 
update' from preferences. The thing is though, that auto update is the kind of 
thing, that makes things feel like 'they just work'. This effect disappears if 
you have to enable it manually, in fact I think very few people would.

A final note is, that all the above only manages changes to gin, pin and 
availinfo. If a PyChess fics mamanger chooses to change something else - like 
joined groups - we'll still have a problem.
I figure though, that most users will be more willing to accept variable 
changes, that they remember actively doing (even though indirectly) in the 
interface, and changes that don't make the terminal unusable.

Original comment by lobais on 5 Nov 2010 at 1:41

[GoogleCodeExporter]

Issue 645 has been merged into this issue.

Original comment by gbtami on 2 Feb 2011 at 8:25

[GoogleCodeExporter]

While reading this issue again today, I thought adding the "Enable PyChess to 
set FICS user variables for auto refresh user/game lists" checkbox in 
preferences with checked _on_ by default can save the current behavior. Am i 
right?

Original comment by gbtami on 6 Aug 2012 at 1:13

[GoogleCodeExporter]

@comment 6, Matt:The warning you suggested in last doesn't work, koz if PyChess 
crash, it leaves the variables in a bad state, and when PyChess starts again, 
our new FICS session starts with reading the bad variables and on qoutting it 
saves them again.

Btw. I coded some speed up on FICS login in gbtami-fics-console clone. Can 
anyone review revision #b7257cbe81b0 , please?

Original comment by gbtami on 18 Aug 2012 at 9:09

[GoogleCodeExporter]

In my gbtami-fics-console clone I'v implemented a solution. Decoupled the game 
and player list management code to a different (helper) connection. It's acting 
like some kind of bot, listening only for pin/gin/show/games notifications. 
This way the user variables will never be scrambled by pychess, koz it sets 
them only in a helper guest connection. Another benefit is that the "show" and 
"games" commands doesn't block the seek tab updating.

Original comment by gbtami on 23 Aug 2012 at 12:35

[GoogleCodeExporter]

interesting idea, i'll check it out. i haven't had much time for pychess 
lately, but
that was a solution i'd been thinking of as well.

Original comment by mattgatto on 24 Aug 2012 at 9:58

[GoogleCodeExporter]

Merged it to the main repo. Test please!

Original comment by gbtami on 17 Sep 2012 at 9:18

• Changed state: Started

[GoogleCodeExporter]

Original comment by gbtami on 12 Feb 2014 at 3:45

• Changed state: Fixed