After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 789399 - Reverse score ordering
Reverse score ordering
Status: RESOLVED FIXED
Product: libgnome-games-support
Classification: Other
Component: general
1.2.x
Other Linux
: Normal normal
: ---
Assigned To: Michael Catanzaro
libgames-scores maintainer(s)
: 793262 793387 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2017-10-24 11:46 UTC by Serge Matveenko
Modified: 2018-02-18 02:15 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
Gnome mines screenshot illustrating reverse score order. (159.01 KB, image/png)
2017-10-24 11:46 UTC, Serge Matveenko 		  Details
scores 8-8-10 (240 bytes, text/plain)
2017-10-24 23:43 UTC, Serge Matveenko 		  Details
scores 16-16-40 (90 bytes, text/plain)
2017-10-24 23:43 UTC, Serge Matveenko 		  Details
scores 30-16-99 (589 bytes, text/plain)
2017-10-24 23:44 UTC, Serge Matveenko 		  Details
scores: Use List instead of PriorityQueue to store scores (5.89 KB, patch)
2018-02-18 02:12 UTC, Michael Catanzaro 		committed Details | Review

Description Serge Matveenko 2017-10-24 11:46:30 UTC 
Created attachment 362174 [details]
Gnome mines screenshot illustrating reverse score order.

Top scores display in a reversed manner.

Also beating the score when score table is full doesn't alter the score table.

See screenshot. Notice score ordering and 2:44 is the last time which should get a place in the score table.

gnome-mines 3.24.0
gnome-mines-3.24.0-1.fc26
Fedora release 26 (Twenty Six)
Comment 1 Michael Catanzaro 2017-10-24 14:59:01 UTC 
Weird, I tested just now and it's working fine for me. I can't even begin to guess what's causing this.
Comment 2 Serge Matveenko 2017-10-24 23:42:01 UTC 
Just noticed that 16x16 has no ordering and 8x8 looks good.
Attaching score files.
Comment 3 Serge Matveenko 2017-10-24 23:43:20 UTC 
Created attachment 362229 [details]
scores 8-8-10
Comment 4 Serge Matveenko 2017-10-24 23:43:53 UTC 
Created attachment 362230 [details]
scores 16-16-40
Comment 5 Serge Matveenko 2017-10-24 23:44:17 UTC 
Created attachment 362231 [details]
scores 30-16-99
Comment 6 Michael Catanzaro 2017-10-25 00:11:16 UTC 
Wow, I can reproduce now. But my results are different than yours.

For 8x8 I'm seeing the scores in exactly the same order they are in the file (unsorted).

16x16 is also sorted in the same order the scores appear in the file (sorted in reverse order) for me.

I see 30x16 sorted properly, lowest time to highest time, even though the file is unsorted.

This is not likely to be a Mines bug, we need to debug libgnome-games-support.
Comment 7 Robert Roth 2018-02-07 16:30:54 UTC 
*** Bug 793262 has been marked as a duplicate of this bug. ***
Comment 8 Jeremie Tamburini 2018-02-10 00:09:29 UTC 
Mines 3.26.0 - Ubuntu 17.10

In my case the scores in (8x8) and (16x16) look unsorted.
Everything fine in (30x16).
Comment 9 Robert Roth 2018-02-12 14:33:08 UTC 
*** Bug 793387 has been marked as a duplicate of this bug. ***
Comment 10 Michael Catanzaro 2018-02-18 02:12:01 UTC 
The following fix has been pushed:
2869410 scores: Use List instead of PriorityQueue to store scores
Comment 11 Michael Catanzaro 2018-02-18 02:12:11 UTC 
Created attachment 368509 [details] [review]
scores: Use List instead of PriorityQueue to store scores

Instead, sort the scores right before they're needed. This should be
less efficient in theory, but our use of PriorityQueue is not working
properly and it's not clear why. Sorting on demand simplifies several
functions, and should be just fine.

This fixes scores appearing out of order on the scores dialog.
Comment 12 Michael Catanzaro 2018-02-18 02:15:57 UTC 
Sorry about this issue. I'm going to be overly-cautious and not backport this to 1.2, so it will be fixed only in libgnome-games-support 1.4. Will do a preview release for that soon.