*** empty log message ***

svn path=/trunk/boinc/; revision=4690

checkin_notes

@@ -20372,3 +20372,24 @@ Bruce 30 Nov 2004
         db_ops.inc
     sched/
         db_purge.C
+
+David  30 Nov 2004
+    - fixed a bug in DB_VALIDATOR_ITEM_SET::update_result(): the lines
+            "server_state=%d, outcome=%d, opaque=%lf"
+            "where id=%d",
+        produce a bad SQL query (e.g. opaque=0.0000where id=4)
+    - fixed a bug in the transitioner:
+        TRANSITIONER_ITEM::enumerate() and query()
+        weren't reading "need_validate".
+        In some (rare) cases this would cause the flag
+        to get incorrectly cleared by the transitioner
+                     
+    NOTES:
+    - ALL VALIDATORS SHOULD BE RECOMPILED
+    - RECOMPILE THE TRANSITIONER
+
+    db/
+        boinc_db.C
+    client/
+        cs_account.C
+        main.C

client/cs_account.C

@@ -238,7 +238,7 @@ int CLIENT_STATE::add_project(const char* master_url, const char* _auth) {
     safe_strcpy(auth, _auth);
     strip_whitespace(auth);
     if (!strlen(auth)) {
-        msg_printf(0, MSG_ERROR, "Invalid account ID: %s", auth);
+        msg_printf(0, MSG_ERROR, "Invalid account key: %s", auth);
         return ERR_AUTHENTICATOR;
     }
 

client/main.C

@@ -60,7 +60,7 @@ void project_add_failed(PROJECT* project) {
     if (project->scheduler_urls.size()) {
         printf(
             "BOINC failed to log in to %s.\n "
-            "Please check your account ID and try again.\n",
+            "Please check your account key and try again.\n",
             project->master_url
         );
     } else {

db/boinc_db.C

@@ -643,6 +643,7 @@ void TRANSITIONER_ITEM::parse(MYSQL_ROW& r) {
     strcpy2(name, r[i++]);
     appid = atoi(r[i++]);
     min_quorum = atoi(r[i++]);
+    need_validate = atoi(r[i++]);
     canonical_resultid = atoi(r[i++]);
     transition_time = atoi(r[i++]);
     delay_bound = atoi(r[i++]);
@@ -684,6 +685,7 @@ int DB_TRANSITIONER_ITEM_SET::enumerate(
             "   wu.name, "
             "   wu.appid, "
             "   wu.min_quorum, "
+            "   wu.need_validate, "
             "   wu.canonical_resultid, "
             "   wu.transition_time, "
             "   wu.delay_bound, "
@@ -924,7 +926,7 @@ int DB_VALIDATOR_ITEM_SET::update_result(RESULT& res) {
 
     sprintf(query,
         "update result set validate_state=%d, granted_credit=%.15e, "
-        "server_state=%d, outcome=%d, opaque=%lf"
+        "server_state=%d, outcome=%d, opaque=%lf "
         "where id=%d",
         res.validate_state,
         res.granted_credit,

doc/boinc_dev.php

@@ -4,7 +4,24 @@
 
    echo "
 <p>
-The BOINC source code is <a href=source/>here</a>.
+<h2>Source code</h2>
+You can get the BOINC source code in several ways:
+<ul>
+<li>
+<a href=source/>Download</a> a tarball or .zip file
+(generated nightly).
+<li>
+Browse the CVS repository via a
+<a href=http://boinc.berkeley.edu/cgi-bin/cvsweb.cgi/>web-based interface</a>.
+<li>
+Access the CVS repository directly, e.g. with a command like
+<pre>
+cvs -d :pserver:anonymous@alien.ssl.berkeley.edu:/home/cvs/cvsroot checkout boinc
+<pre>
+</ul>
+<p>
+Source code for a typical BOINC application,
+SETI@home, is <a href=http://boinc.berkeley.edu/seti_source/>here</a>.
 <p>
 If you are an experienced C++ system programmer you may be able
 to help us maintain and enhance BOINC.
@@ -15,6 +32,8 @@ You should understand exactly how BOINC is supposed to work
 (for both <a href=participate.php>participants</a>
 and <a href=create_project.php>developers</a>)
 before getting into the source code.
+
+<h2>Bug database</h2>
 <p>
 <a href=http://setiathome.berkeley.edu/taskbase>View database of bugs and feature requests</a>
 <p>

doc/project_cookbook.php

@@ -9,7 +9,8 @@ Make sure MySQL is configured and running.
 <li> Run HOME/boinc/tools/<a href=make_project.php>make_project</a>
 <li> Append the contents of projects/PROJECT/PROJECT.httpd.conf
 to httpd.conf and restart Apache.
-<li> Insert a cron job to run the project's periodic tasks, e.g.
+<li> Use 'crontab' to insert a cron job to run the project's
+periodic tasks, e.g.
     <br> 0,5,10,15,20,25,30,35,40,45,50,55 * * * * HOME/projects/PROJECT/bin/start --cron
     <br> (if cron cannot run 'start', try using a helper script
     to set PATH and PYTHONPATH)
@@ -19,8 +20,8 @@ edit it to taste,
 and run <a href=tool_xadd.php>bin/xadd</a>.
 <li> Edit html/project/project.inc, changing the
 master URL and copyright holder.
-<li> Using <a href=http://httpd.apache.org/docs/programs/htpasswd.html>htpasswd</a>,
-add .htaccess and .htpasswd files to html/ops.
+<li> Protect the html/ops directory
+(e.g. by putting .htaccess and .htpasswd files there).
 </ul>
 
 Visible result: the project web site is up.

doc/tool_update_versions.php

@@ -1,10 +1,8 @@
 <?php
 require_once("docutil.php");
-page_head("update_versions");
+page_head("Releasing application versions");
 echo "
 
-<h2>Releasing application versions</h2>
-
 The <code>update_versions</code> script
 releases new application versions.
 It makes the needed database entries and copies files
@@ -20,6 +18,7 @@ with the same name as the application.
 Put new application versions here.
 <code>update_versions</code>
 scans these directories for new application versions.
+<li> Run bin/update_versions
 </ul>
 <p>
 
@@ -49,22 +48,23 @@ Recommended code-signing practices are described
 <a href=code_signing.php>here</a>.
 
 
-<h3>Minimum core version</h3>
-Application versions have a field <code>min_core_version</code> which,
-if nonzero, indicates the minimum core client version number
+<h3>Min/max core version</h3>
+Application versions have fields <code>min_core_version</code>
+and <code>max_core_version</code> which, if nonzero,
+indicates the range of core client version numbers
 to which the application version should be sent.
 Update_versions, by default, sets this to the largest
 core client version number in the database.
-You can disable this by editing update_versions,
-or by manually changing the app_version record.
+To change this, you can manually edit the app_version record.
 
 <h3>Multiple-file application versions</h3>
 
-Application versions can consist of multiple files.
-Follow the above procedure, but create a directory
-with the given name, and put the files in that directory.
-The executable file with the lexicographically first name
-will be treated as the main program.
+Application versions can consist of multiple files,
+one of which is the main program.
+To create a multiple-file application version,
+create a directory with the same name as the main program
+(of the form NAME_VERSION_PLATFORM[.ext]).
+and put the files in that directory.
 
 
 <h2>Releasing core client versions</h2>

doc/tools_work.php

@@ -87,7 +87,7 @@ The result file template is macro-substituted as follows:
 'wuname_resultnum_n' where wuname is the workunit name and resultnum is
 the ordinal number of the result (0, 1, ...).
 <li>
-&lt;UPLOAD_URL> is replaced with the upload URL.
+&lt;UPLOAD_URL/> is replaced with the upload URL.
 </ul>
 <p>
 <a name=cmdline>

doc/validate.php

@@ -27,7 +27,8 @@ be granted for correct results for this workunit.
 
 <li>
 If, when an output file for a result has a nonrecoverable error
-(i.e. the directory is there but the file isn't),
+(e.g. the directory is there but the file isn't,
+ or the file is present but has invalid contents),
 then it must set the result's outcome (in memory, not database)
 to VALIDATE_ERROR.
 Note: the function try_fopen() (in lib/util.C) can be used
@@ -59,6 +60,7 @@ In the absence of errors,
 it sets the new result's validate_state to either VALID or INVALID.
 <li>
 If it has a nonrecoverable error reading an output file of either result,
+or if the new result's output file is invalid,
 it must set the new result's outcome (in memory, not database)
 to VALIDATE_ERROR.
 <li>