Primenet web design

[Madpoo]

I just updated the exponent report page (the one that shows status for an exponent or range of exponents).

I've been working on that for a while but let it sit a bit during the holidays... it seems good so I'm letting it rip.

It's basically the same, but ECM details are hidden by default (some exponents have a LOT and will take a long time to show), plus I fiddled with spacing on the data to make it more compact, and the history shown if you select full details are sorted by most recent at the top.

Otherwise there's not a whole lot different. There was some work done to make the text of the full details get "prettified" in SQL itself rather than doing some parsing in PHP, so it may be a little quicker on average, but not enough to notice. The details themselves may appear different, with different text. Usually related to the "factor found" messages reported from clients, with some attempt made to remove extraneous stuff from showing up (the mfaktc stuff).

If you have something that auto parses that info, I think it would all be okay, but changes were made and I can't guarantee anything.

I do have an XML version of that page in test... I might add a link on the report page that takes you to the XML version of the same page.

If anyone is curious about the XML, try this out (this may not be the final URL, but for testing it'll give you an idea):
Exponent XML Report

[Madpoo]

Originally Posted by Madpoo

I just updated the exponent report page (the one that shows status for an exponent or range of exponents).

Thanks to user "ugonabuj" for pointing out that on some exponents (thanks, CUDAPm1 v0.20 clients) include the assignment ID in a weird way in their result text. I added a workaround to hide those from the history of an exponent (like http://www.mersenne.org/M38053991 )

AID's in the exponent history aren't a big deal... by the time its in there, the assignment is checked in and nothing can be done with it, but it's still messy. Good news is I only saw 74 entries total out of millions that have that strange form in the result text. :)

If anyone sees anything else weird in the history section, let me know. Since I rewrote the message parsing stuff directly in SQL, there's a good chance there are some edge cases where some client or another adds it's own weird text in the message that was parsed okay previously, but my new code isn't handling it as well. SQL doesn't really do regex so I had to come up with other ways to do it... not exactly a one-to-one thing.

[tha]

On the "exponent status" page, can there be a destinction made between "expired on" and "checked in on". Currently assignments are said to have expired as they were checked in, which can create confusion.

[snme2pm1]

Originally Posted by Madpoo

Otherwise there's not a whole lot different. ... The details themselves may appear different, with different text. Usually related to the "factor found" messages reported from clients, with some attempt made to remove extraneous stuff from showing up (the mfaktc stuff).

I see that partial 2 power band exploration remains indicated with an asterisk, with the agent portion hidden.
I suppose for most current purposes that is adequate, though knowing the agent and thereby the algorithm, completion of a range might be achievable.
I also note that the ordering of results has shifted.
However I found the results attributed to user TJAOI especially hard to believe.
The styling suggests that recently entire 2 power bands have been explored, but that isn't that those particular explorers are up to at all.
e.g.

Exponent	Status	Data
5474411	Factored	10948823;660285933207007;36419415765584759
5474411	History	2014-12-31;TJAOI;F;Factor: 36419415765584759 / TF: 55-56
5474411	History	2014-04-25;TJAOI;F;Factor: 660285933207007

[VictordeHolland]

My team (Dutch Power Cows) is ranked Lifetime:
ECMF 46 out of 29
Percentile: -61

[TheMawn]

Originally Posted by VictordeHolland

My team (Dutch Power Cows) is ranked Lifetime:
ECMF 46 out of 29
Percentile: -61

You're gonna have to put in a bit more effort then.

[snme2pm1]

By the way, I noticed that the login expiration cookie has apparently changed to now 7 days.
Probably that is helpful.
That might diminish instances of manual submissions becoming accidentally attributed to Anomymous, though perhaps the hazard is merely time shifted for folk making regular manual lodgements.

[Madpoo]

Originally Posted by snme2pm1

I see that partial 2 power band exploration remains indicated with an asterisk, with the agent portion hidden.
I suppose for most current purposes that is adequate, though knowing the agent and thereby the algorithm, completion of a range might be achievable.
I also note that the ordering of results has shifted.
However I found the results attributed to user TJAOI especially hard to believe.
The styling suggests that recently entire 2 power bands have been explored, but that isn't that those particular explorers are up to at all.
e.g.

Exponent	Status	Data
5474411	Factored	10948823;660285933207007;36419415765584759
5474411	History	2014-12-31;TJAOI;F;Factor: 36419415765584759 / TF: 55-56
5474411	History	2014-04-25;TJAOI;F;Factor: 660285933207007

Yeah... in the old display it was just showing the factor found, but any additional info like the range it was found in and the magic asterisk (which indicated whether or not the entire range was factored completely, or if it stopped after finding one) wasn't included. I was unaware of what that asterisk actually meant but James filled me in.

If you're ever curious to see how the old report would have looked, visit the "old.php" page, e.g.
http://www.mersenne.org/report_expon...5474411&full=1

I won't guarantee the old page will be there forever, but I put it there so I could do my own before/after testing.

Anyway, in theory at least, any extra info from the client side like the range tested, whether it was complete or not, etc. should be reflected in that output.

Here's an example of one with the asterisk showing the range was completely factored (if I understand it correctly):
http://www.mersenne.org/report_expon...exp_hi=&full=1

Note the asterisk in TF: 69-70*

That same entry on the "old.php" page looks like this:
1024766831515799780753;[TF:69:70*:mfaktc 0.20 barrett76_mul32_gs]

So the only info missing really is the mfaktc stuff, which I considered irrelevant. If you think including that adds any real benefit, I could look into that some more. I didn't really think it mattered though.

[Madpoo]

Originally Posted by snme2pm1

By the way, I noticed that the login expiration cookie has apparently changed to now 7 days.
Probably that is helpful.
That might diminish instances of manual submissions becoming accidentally attributed to Anomymous, though perhaps the hazard is merely time shifted for folk making regular manual lodgements.

Yeah, that was me. It was set to 3 days on the old server and I was recently looking into some cookie session file issues on the new server (they're not being auto cleaned by PHP's garbage collection), and figured it was time to extend that.

Setting it to a longer period should reduce by quite a bit all of those session files the server has to keep track of. I should really look at making PHP store those in SQL...

[James Heinrich]

Originally Posted by Madpoo

Here's an example of one with the asterisk showing the range was completely factored (if I understand it correctly):
http://www.mersenne.org/report_expon...exp_hi=&full=1
Note the asterisk in TF: 69-70*

Actually it's backwards -- the asterisk means that the assignment was started with the target bitlevel but the range was not completed.

Unfortunately that means that an absence of asterisk either means that the range was definitely completed (newer versions of mfakt*), or that it's an older version of the software that didn't differentiate. You'd have to parse for version number to differentiate between those two cases.

[tha]

The "Manual Testing | Assignments" page serves a new set of assignments during a reload of the page. That means if someone leaves the page open on one of the tabs, every restart of the browser may lead to new assignments being requested. Can a safeguard be build in to prevent that?