My next request is to do a corresponding cleanup of the 'detailed' RESULT
page. In particular, it should show ALL the fields at the bottom of this
page: ops/db_form.php?table=result&detail=low which are:
Some specific things that would be helpful:
(1) again, decode meaning, AND numeric value:
Server state: Over [X]
Outcome: Client error [X]
File Delete state: Initial [0]
where possible.
(2) It would be extremely useful to decode the exit status
values into text, according to: lib/error_numbers.h:
so if the error is one of these values, a human-readable string
is also displayed. If not one of these values, just the number.
(3) This might be too hard -- could you search in stderr out
for things like <error_code>-108</error_code> and if found
add a separate row with the human-readable decoding of this?
(4) If easy, link App version back to the app version table.
If hard, don't bother.
(5) Fix bug on User Id line (currently has host_name_by_id(...))
svn path=/trunk/boinc/; revision=4974
more recent than the 'md5info', then ignore md5info. If md5info
has *exactly* the right format (no extra or missing characters) then
remove it in this case (only). Don't write an md5info file if
another file is found with the same name. Thus if someone has two
data files called X and X.md5, unless X.md5 has the exact correct
syntax for an md5-info cache file, it won't be removed or used.
Still disabled by default. Use -DBOINC_CACHE_MD5 to enable it.
svn path=/trunk/boinc/; revision=4973
results in some range of MOD time rather than some range of received
time, and display all fields associated with Workunits.
svn path=/trunk/boinc/; revision=4969
the cost of computing the md5 sums becomes expensive. Inserted
a simple caching mechanism into the utility function
process_wu_template(). For a given filename FILENAME, this looks
for a file called FILENAME.md5, which contains the md5sum and
length. If the file exists, these values are used. If not, such
a file is created. Since (I think) David is planning to have a
database for files, this mechanism will eventually be obsolete.
Right now it disabled by default. Use -DBOINC_CACHE_MD5 to
enable it.
svn path=/trunk/boinc/; revision=4965
generated a SIGARBT. We now catch this signal. In the
graphics thread, this just restarts the graphics init process
(with some sleep(2)ing if needed to prevent a busy fail loop).
If the signal is caught in the main thread, we restore the old
signal handler then raise(SIGABRT).
David, note that when run standalone, killing the graphics
window does NOT kill the process. I think this is fine, but
it doesn't correspond to what the documentation says.
svn path=/trunk/boinc/; revision=4958
Darwin/Unix. It's only needed under Windows. Also warn user if
GLUT libraries missing, and then build only non-graphical client
side code.
svn path=/trunk/boinc/; revision=4954
When glutInit fails it prints a line (~100 chars) to stdout. If it does
this 60 times per hour, that's 6kB/hour. After ten hours it will overflow
the blob for stderr.
svn path=/trunk/boinc/; revision=4953
David Anderson