Forum OpenACS Development: Rename OpenACS Administration to Site-Wide Admin?

Not from me!

It is indeed a trivial change ... and yes, I'd forgotten about that thread, too. I'm glad that you are willing to serve as my extended memory :)

/Lars

I just updated from CVS and now I get this error when trying to access /acs-admin/

Can this possibly be related to something you just did?

Request Error

       unknown command "instance_name":  should be authpassword, authuser, close, content, contentlength, driver, flags, form, headers, host, isconnected, location, method, outputheaders, peeraddr, peerport, port, protocol, url, query, server, sock, start, status, urlc, urlv, or version
           while executing
       "ns_conn $var"
           ("-get" arm line 5)
           invoked from within
       "switch -- $flag {
           -connected_p {
             return [info exists ad_conn(request)]
           }

           -set {
             set ad_conn($var) [lindex $args 2]
           }

          ..."
           (procedure "ad_conn" line 12)
           invoked from within
       "ad_conn instance_name"
           invoked from within
       "set title "[ad_conn instance_name] for [ad_system_name]""
           ("uplevel" body line 9)
           invoked from within
       "uplevel {
                 ad_page_contract {
           @author Bryan Quinn (bquinn@arsdigita.com)

           @creation-date August 15, 2000
           @cvs-id $Id: index.tcl,v 1...."
           (procedure "code::tcl::/var/web/epimetrics-dev/packages/acs-admin/www/in..." line 2)
           invoked from within
       "code::tcl::$__adp_stub"
           invoked from within
       "if { [file exists $__adp_stub.tcl] } {

             # ensure that data source preparation procedure exists and is up-to-date
             adp_init tcl $__adp_stub
       ..."
           ("uplevel" body line 3)
           invoked from within
       "uplevel {

           if { [file exists $__adp_stub.tcl] } {

             # ensure that data source preparation procedure exists and is up-to-date
             adp_init t..."
           (procedure "adp_prepare" line 2)
           invoked from within
       "adp_prepare "
           (procedure "template::adp_parse" line 30)
           invoked from within
       "template::adp_parse [file root [ad_conn file]] {}"
           (procedure "adp_parse_ad_conn_file" line 7)
           invoked from within
       "$handler"
           ("uplevel" body line 2)
           invoked from within
       "uplevel $code"
           invoked from within
       "ad_try {
               $handler
             } ad_script_abort val {
               # do nothing
             }"
           invoked from within
       "rp_serve_concrete_file [ad_conn file]"
           (procedure "rp_serve_abstract_file" line 60)
           invoked from within
       "rp_serve_abstract_file "$root/$path""
           ("uplevel" body line 2)
           invoked from within
       "uplevel $code"
           invoked from within
       "ad_try {
               rp_serve_abstract_file "$root/$path"
               set tcl_url2file([ad_conn url]) [ad_conn file]
               set tcl_url2path_info([ad_conn url]) [ad_conn path_inf..."

Hmmm...do you mean I need to drop the database and reinstall? Restarting the server with the current CVS checkout completely hoses the site -- all I get now is an error in the browser: "The document contained no data." from any url.

Here is the error I presume is the clue:

debug: RP (9.866 ms): rp_filter: setting up request: GET / 
[16/Sep/2002:14:26:44][26713.5126][-conn2-] Error: tclop: invalid return code from filter proc 'can't read "node(instance_name)": no such element in array': must be filter_ok, filter_return, or filter_break

Nope, something's badly amiss; a fresh reinstall proceeds fine -- the kernel installs OK, the core services/packages also without error, likewise the site-wide admin and the system information.

Once I reach the "OpenACS Installation Complete" page, we're right back to where we began: "The document contained no data" and the same problem with 'can't read "node(instance_name)"' in the error logs.

Hi Stan,

I just cvs updated my copy.  And did a fresh install my plain vanilla OpenACS runs fine.  Its using PG.

Perhaps you need to do a cvs up -PAd to unset a date tag (-D) if you reverted to prior revisions?

Glad it's working now :)

/Lars

Interesting. Misery loves company I guess.

But this raises in my mind the question of tracking CVS closely. How often have mysterious problems like this happened? Theoretically CVS should make it possible to roll backwards and forwards to different versions to get around problems like this (as well as to make it easy or at least possible to merge the canonical fixes by those with commit powers with one's own custom modifications).

But in reality, how well does this work? I've seen posts elsewhere about the hassles of reconciling one's own code with the moving target of the cvs code base. How do people make this work?

One thing to keep in mind when talking about tracking CVS is that
you should not be surprised when things break on the head.
I think everything said about the nightly tarballs
( https://openacs.org/sdm/nightly-tarballs.tcl?package_id=9 )
goes double for life on the head (the it might not work, waste
of time if you don't know what you are doing, etc).

Obviously these postings about problems with the cvs checkout
go counter to what's stated on the tarball page, but I for one
find it helpful to hear if something is broken and can usually tell
right away if I am the one to blame.

You should also realize we are trying to get things in for the
code freeze on monday for the 4.6 release so things are
appreciably less stable than is typical.