I never even noticed. Querying my submitted results is lightning fast.

One little note on the My Account > Results page: When filtering for a specific result type (I just wanted a list of my LL residues), there is a confusing statement.

For me, for example, it says "234,000 (can't remember the exact number) results for The_Mawn (only 100 are shown)" which is a bit misleading because I would want to know how many LL results I have, specifically, as opposed to total, if I'm filtering for a specific result type.

EDIT: I should mention that this isn't a New Server specific bug, just something I noticed.

[QUOTE=kracker;382148]Going to team results...[/QUOTE]I can replicate, taking a look...

[QUOTE=kracker;382148]Going to team results...[/QUOTE]

Fixed, thanks.

FAST!!!!!
 

!!!!!

Thanks

I'm happy to report that (finally!) the new manual_results submission form is in place for all to use. That should mean that factors falsely recorded as P-1 or ECM when they should be TF are finally behind us.

Let me know if you find some result lines that are not processed as expected.

[QUOTE=James Heinrich;382254]I'm happy to report that (finally!) the new manual_results submission form is in place for all to use. That should mean that factors falsely recorded as P-1 or ECM when they should be TF are finally behind us.

Let me know if you find some result lines that are not processed as expected.[/QUOTE]

I just submitted a few TF results, which included 2 factors found. I moved one to the top of the list. Everything was detected correctly. :smile:

Heads up to primetools/mfloop.py users: the way the script detected that the results were successfully submitted broke with the changes, but I've fixed it in my fork: [url]http://github.com/MarkRose/primetools[/url]

I've submitted a pull request to teknohog.

[QUOTE=Mark Rose;382267]Heads up to primetools/mfloop.py users[/QUOTE]Two minor issues I found in your patch:
a) The "B1" parameter is not needed when submitting results (but not harmful either, so doesn't matter if it remains).
b) You changed the login page from /default.php to /account/default.php which again isn't harmful, but not necessary (unless there was a reason for it that I missed?)

[QUOTE=James Heinrich;382293]Two minor issues I found in your patch:
a) The "B1" parameter is not needed when submitting results (but not harmful either, so doesn't matter if it remains).
b) You changed the login page from /default.php to /account/default.php which again isn't harmful, but not necessary (unless there was a reason for it that I missed?)[/QUOTE]

I had changed the login page to account/default.php when the homepage log in was no longer working. I've updated my fork and I've submitted another pull request to teknohog with these changes. He merged my previous pull request already.

[QUOTE=James Heinrich;382254]I'm happy to report that (finally!) the new manual_results submission form is in place for all to use. That should mean that factors falsely recorded as P-1 or ECM when they should be TF are finally behind us.

Let me know if you find some result lines that are not processed as expected.[/QUOTE]

The old page told you the exponents it checked in, you could then verify against your results file.

the new page doesn't ...

Found 4 lines to process.
CPU credit is 27.3345 GHz-days.
CPU credit is 27.3344 GHz-days.
CPU credit is 27.3344 GHz-days.
Done processing:
* Parsed 3 lines.
* Found 0 datestamps.
GHz-days
Qty Work Submitted Accepted Average
3 Trial Factoring: no factor 82.003 82.003 27.334
3 - all - 82.003

Did not understand 0 lines.
Recognized, but ignored 0/3 of the remaining lines.
Skipped 0 lines already in the database.
Accepted 3 lines.

**

Also,any chance at all, this side of the heat death of the universe of getting GPU recognised as a processor type :-)

[QUOTE=Gordon;382310]the new page doesn't ...[/QUOTE]... does now :smile:

[QUOTE=Gordon;382310]Also, any chance at all, this side of the heat death of the universe of getting GPU recognised as a processor type :-)[/QUOTE]Where?