Migrate from score file version 5 to version 6

[firmart]

Suddenly, I cannot use elfeed-score anymore after an update. I got weird error like

Debugger entered--Lisp error: (file-already-exists "File already exists" "~/.emacs.d/elfeed.score.~5~")

By inspecting the source code, I realized that we move to a version 6 which uses plist. But currently, for older score files, the code do nothing more than copying it to elfeed.score.~VERSION~. It would be nice to have a message/error announcing the version change and even nicer to have a function to migrate from old versions.

BTW, it's excellent to have plist. It was a little pain to know which parameter has what purpose without checking the source code or the README.

[sp1ff]

Hey @firmart -- sorry for the trouble! Just pushed a change that will:

1. Announce the fact that your score file will be upgraded
2. Not error-out on failure to make a backup copy

Can I ask how you ended-up with a file named elfeed-score.el.~5~?

Yeah... the flat list format was getting tougher & tougher to work with, so I finally bit the bullet. I tried to make the upgrade seamless, but it seems I missed at least one corner case.

[firmart]

Michael <notifications@github.com> writes:

Hey @firmart -- sorry for the trouble! Just pushed a change that will: 1. Announce the fact that your score file will be upgraded 2. *Not* error-out on failure to make a backup copy

Thanks! I just tested and read the code and realized that it does backup but doesn't write the upgraded score file. I had to manually call elfeed-score-serde-write-score-file to upgrade. Anyway, happy that the score reappears again!

Can I ask how you ended-up with a file named "elfeed-score.el.~5~"?

It's due to the following line, as the version mismatches: (copy-file score-file (format "%s.~%d~" score-file version)))

Yeah... the flat list format was getting tougher & tougher to work with, so I finally bit the bullet. I tried to make the upgrade seamless, but it seems I missed at least one corner case.

It's okay, I'm a faithful user!

…

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #12 (comment)

[sp1ff]

It's due to the following line, as the version mismatches:

No, no... what I meant to ask was: why was there already a file present on disk named elfeed-score.el.~5~ in the first place? Did you load it twice without writing it out (so that the package thought it had to upgrade twice)?

Right now, the score file will be written out when:

1. you unload the package
2. you explicitly request a score operation (elfeed-score-score-search, e.g.)
3. you ask it to (i.e. when you call elfeed-score-serde-write-score-file)

IOW, if you just read your RSS feeds, updating & reading, the state accumulates in memory without being written to disk. I suppose I could write it periodically, or watch the job queue (and when it drops to zero, write).

I'll definitely change the update logic to write the new file immediately.

[firmart]

Michael <notifications@github.com> writes:

> It's due to the following line, as the version mismatches: No, no... what I meant to ask was: why was there already a file present on disk named `elfeed-score.el.~5~` in the first place? Did you load it twice without writing it out (so that the package thought it had to upgrade twice)?

Ah ok... That's because I have (elfeed-score-enable) in my config and I probably relaunched emacs few times meanwhile (ignoring warnings at startup). The calling sequence being: elfeed-score-enable elfeed-score-load-score-file elfeed-score-serde-load-score-file elfeed-score-serde--parse-score-file

Right now, the score file will be written out when: 1. you unload the package 2. you explicitly request a score operation (`elfeed-score-score-search`, e.g.) 3. you ask it to (i.e. when you call `elfeed-score-serde-write-score-file`)

Only the third point was realistic to me, because I saw straight away that the scores disappeared. The first reaction was looking for a function that writes the score file directly.

IOW, if you just read your RSS feeds, updating & reading, the state accumulates in memory without being written to disk. I suppose I could write it periodically, or watch the job queue (and when it drops to zero, write). I'll definitely change the update logic to write the new file immediately.

Nice!

…

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #12 (comment)

[sp1ff]

Alright, the latest release will just write the new file straightaway. I'm going to close this issue & start a new one to track the issue of in-memory rules getting written out, since that's a bigger topic.