- use form-control class for text inputs and selects.
This makes them all full-width, but I guess that's OK.
- use success class (green) for action buttons
- right-align table headings where appropriate
- use <small> instead of text-muted.
- tweak custom CSS to fix link and navbar visited colors
- int2hex() now uppercases the actual value to make it easier to compare.
- Decode large negative values as Windows error codes. Right now assumes everything smaller than -400 to be a Windows error code. Unfortunately there are also positive codes that overlap with Linux and BOINC ones.
Exit codes (32 bits) with the high order bit set (e.g. 0xc0000005) were being displayed as 0xffffffffc0000005.
This seems to be a problem with php's printf("%x") where negative values are shown as 64 bit integers in the hex representation (dechex() has the same problem).
Exit codes (32 bits) with the high order bit set (e.g. 0xc0000005)
were being displayed as 0xffffffffc0000005.
Also: fix some confusion between exit codes and error numbers.
BOINC doesn't use error numbers as exit codes.
* Added still required code that was removed without apparent reason
* If in doubt about a code's purpose, please check the history first
* Original commit: 8be519a
The latest client reports the peak working set size, swap size,
and disk usage for completed jobs.
Add fields to the results table to store these.
Parse them in scheduler request messages, and write to the DB.
Display them in the result web page.
This data can be used to improve (or even automate)
the job estimates for memory and disk usage.
for when the job completed successfully but
one or more output files had permanent upload failures.
Show this state in web interfaces.
- sample_work_generator: check return value of count_unsent_results(),
so that we don't generate infinite work if there's a DB problem
- web: RSS feed shows news items from last 90 days, rather than 14
svn path=/trunk/boinc/; revision=24377
and other operations.
You can now designate a user as "manager" for a particular app.
They can then:
- control job-submit permissions for that app
- deprecate/undeprecate versions of the app.
- abort jobs for that app
You can also designate a user a manage for the project.
They can then edit permissions and quotas,
as well as performing the app-specific functions for all apps.
This is described here:
http://boinc.berkeley.edu/trac/wiki/MultiUser#Accesscontrol
This required some changes to the DB schema.
svn path=/trunk/boinc/; revision=24250
- add fields to batch table, extend APIs accordingly
- require that example web interface run on BOINC server
(this makes many things easier;
an actual remote interface would require a bit more work)
svn path=/trunk/boinc/; revision=23881
Michael Kulabuhov