[QUOTE=snme2pm1;384562]That has bothered me from early days here.
Apparently it is a measure of production versus deemed capability of registered equipment.
It's usefulness is entirely voided once an unspecified GPU with even a little grunt is deployed.
I don't know enough history as to who loves that baby.
A broader question might be whether any perhaps alternative representation of anything useful from readily available production statistics would work better.[/QUOTE]

To be honest I wasn't sure what that represented either.

According to the source of those graphs, it's a measure of the GHz-hours for the past 24-hours and 90-days.

I guess if you haven't checked in any results in 24 hours it's at zero, which is how it usually looks for me (just one machine running).

It should probably be labeled on there... I guess now that I know, it makes sense. Speedometer displays work better though when they're updated more frequently.

I wonder what it would take to replace that with some kind of individual plot of account or team GHz-days over a period of days/months, similar to the overall graph on the "Work Distribution Map" page.

I can look into that, but don't get your hopes up... it may be too intensive on the database side to generate that dynamically every time someone views it... I don't know... and maybe there's already somewhere that it gets generated statically on a daily/hourly basis and I just haven't sussed that.

[QUOTE=Mark Rose;384565]Hopefully the string "[I]username[/I]<br>logged in" won't change. mfloop.py was looking for "[i]username[/i] logged-in" and it broke with the change today/yesterday. I've modify the script and TeknoHog has a pull request waiting :)[/QUOTE]

I'll leave that <br> in there.

Those are the kinds of things I suspected were probably going to break some automations out there... scripts that look for certain placeholder text on the page that ended up changing.

I honestly did try to keep some things as-is, especially in the manual result/manual assignment pages, if I had a good reason to think GPU72 in particular might be keying off certain things, but even then, it was just a guess on my part. For GPU72 at least, I figured it was using URLs to get work and read the output which I didn't change at all, and for checking things in, the submit button is moved now but it shouldn't care if it's just submitting the form through a script.

If you know of any other things where a script like mfloop is looking for certain items, could you PM me so I know to either leave those things alone or coordinate any change?

[QUOTE=James Heinrich;384575]Not true, the original legacy manual result form not only had two submit buttons, but was two separate forms, one POST method for file upload, one GET for the copy-paste textarea, which limited copy-paste manual submissions to around 4kB.
As you guessed: when the form is submitted, if you uploaded a file that is processed, otherwise whatever's in the textarea is processed; it's mutually exclusive.[/QUOTE]

Really? I pulled up the "legacy" page and only see the one button. You know how to view the old page so maybe you can double-check, in case I'm just seeing things. LOL :smile:

[QUOTE=Gordon;384582]Pie charts, what be they? See nothing at all...[/QUOTE]

The current design requires clicking on a link to view the chargs/graphs/etc. I think the decision around that was the SQL work involved in pulling the data, but that was on the old server.

Maybe like you, I didn't even know they were there because my brain just skipped right over that link to "click here for more details"

It just adds a ?details=1 to the URL

And yeah, I know the hovering over the tables is still futzed up. It's a neat effect when it works, how the tooltip follows your pointer over that particular cell, but it's ignoring the div margins or something, or overcorrecting...whatever. :) When I have more free time I'll fix it.

FYI, I did add some explanatory text to the speedometers so it's clear what those actually represent.

[QUOTE=James Heinrich;384575]when the form is submitted, if you uploaded a file that is processed, otherwise whatever's in the textarea is processed; it's mutually exclusive.[/QUOTE]And there's now a simple Javascript in place to warn/prevent you from doing that.

[QUOTE=Madpoo;384589]Really? I pulled up the "legacy" page and only see the one button. You know how to view the old page so maybe you can double-check, in case I'm just seeing things. LOL :smile:[/QUOTE]The current "legacy" code is after I reworked the manual_results page. You need to [url=https://web.archive.org/web/20101106063549/http://www.mersenne.org/manual_result/]go back further than that[/url] (date picked at random).

[QUOTE=blip;384563]Overall, looking quite good :smile:

Some (minor) remarks:

I don't think we need mourning borders all over the place (e.g. Summary Details, Stats for the last 365 Days, etc.) Just leave them away...[/QUOTE]

I *think* that's the only page where I added the full-width borders to each sub-section... I don't know why exactly, but I think it helps the sections stand out better... they act as kind of a proxy for a table title, for example, since the tables are full width as well.

[QUOTE=blip;384563]Remove all borders in tables. (Or draw them in white...) This is not a spread sheet. Reduce font size in table headers to "normal"[/QUOTE]

Eww... I'll have to disagree with you there. :) I like tables with borders unless the table is just being used as a layout shortcut. Am I just old skool on that? Maybe?

[QUOTE=blip;384563]Remove 3d effect from "CPU time by stats type". The third dimension carries no added value/information.[/QUOTE]

It doesn't *add* anything, but it's kind of cool and, no pun intended, it does make the graph pop out, visually. Now I"m thinking the bar chart for work types should also be 3D. LOL

[QUOTE=blip;384563]Put reading instruction and comments atop of tables ("All timings are in milliseconds - lower is better", "blip has xxx results in the last 365 days (only 100 are shown).
To keep the database size down,...")
[/QUOTE]

That's a good idea... I considered that (I assume you mean on the benchmark table, for example) and thought it made more sense to specify just what all those #'s are, up top, for the uninitiated. I'll have to play with some placements and see what looks good. I think some of those tables are going to need some other changes anyway to their overall layout.

The early mocks I did on those benchmark tables with rotated headers was cool and certainly, to me anyway, improved readability, but not all browsers (Retina and his Firefox 3.6!) support skew/transform and it would look even worse, plus it was manually "weird" to do the skews and offset things because the CSS rotate works around the *middle* of an object, not any particular corner, so rotating an object means doing a little math + experimenting to get it actually looking good.

I'm hoping to just find some jquery to do that for me, because why reinvent the wheel if so.

To see what I mean, consider the examples here:
[URL="http://jimmybonney.com/articles/column_header_rotation_css/"]CSS header rotation[/URL]

[QUOTE=Madpoo;384588]I'll leave that <br> in there.

Those are the kinds of things I suspected were probably going to break some automations out there... scripts that look for certain placeholder text on the page that ended up changing.

I honestly did try to keep some things as-is, especially in the manual result/manual assignment pages, if I had a good reason to think GPU72 in particular might be keying off certain things, but even then, it was just a guess on my part. For GPU72 at least, I figured it was using URLs to get work and read the output which I didn't change at all, and for checking things in, the submit button is moved now but it shouldn't care if it's just submitting the form through a script.

If you know of any other things where a script like mfloop is looking for certain items, could you PM me so I know to either leave those things alone or coordinate any change?[/QUOTE]

It also, by default, will get trial factoring assignments from PrimeNet if GPU72 fails for some reason. I made that feature optional and I don't use it and haven't tested it.

What we really need are pages that return XML or JSON. Parsing HTML will always be a hacky approach. I know you're doing your best to keep things consistent :)

At work, I get the joy filled task of rewriting two older API's to work with our new infrastructure. Needless to say, the output must be identical. I know the position you're in too well.

[QUOTE=Mark Rose;384596]It also, by default, will get trial factoring assignments from PrimeNet if GPU72 fails for some reason. I made that feature optional and I don't use it and haven't tested it.

What we really need are pages that return XML or JSON. Parsing HTML will always be a hacky approach. I know you're doing your best to keep things consistent :)

At work, I get the joy filled task of rewriting two older API's to work with our new infrastructure. Needless to say, the output must be identical. I know the position you're in too well.[/QUOTE]

I'd be happy to at least take a look at some way to return well-formed data. XML wouldn't be too hard to generate, and JSON should be (I think?) easier to parse on the client side.

Maybe Primenet v6 (Prime95 v29+) should switch it's client/server communication to a more standard RESTful API too... then these other bots out there could jabber on that instead of the manual check in/out pages in a more consistent way.

Ultimately that would require a lot more work, and I wouldn't be doing much, if any of that, so it's easy for me to throw that idea out there. :)

If it were done in steps, I'd say creating a restful API to start with and let these other projects like GPU72 start using it, then once any kinks are worked out, the Prime95 clients could start using it too...

In the end, it's just a different way to skin that cat, but one that has better library support. Every language out there has something to deserialize XML so it should be simple enough to define the schema and let 'er rip.

Found another issue: the "follow these instructions" image link is messed up. I'm using Firefox ESR 31.1.1.

[QUOTE=ixfd64;384600]Found another issue: the "follow these instructions" image link is messed up. I'm using Firefox ESR 31.1.1.[/QUOTE]

Hmm... it's a "button" with styling to give it a gradient (and different gradient when hovered), plus rounded corners using the radius option. There's also a shadow applied.

It seems particularly broken where the shadow overlaps to give it the shaded look.

FF 31.x should render those CSS3 stylings just fine, so that's strange. I'm tempted to chalk that up to a rendering issue specific to that version of Firefox. It looks normal in 32.x at any rate. It's probably a bug in how it handles shadows + radius. It looks like it squared those corners where the shadows alternate. :(

When you hover over it, does it "break" in a different way or does it look better (when hovered, the shadow color is the same on all 4 sides).

Any problems with any of the other styled buttons, like the top-right one when you're logged in that says "username logged in" ? That's styled in a very similar fashion, but it has a consistent, somewhat translucent shadow applied.