Forum .LRN Q&A: .lrn issues, believe I have done something wrong,

any help appreciated;

Hope all had a good holiday.

I dug through the bug tracker and believe these are not
bugs, but misconfigurations.

I finally managed to get .lrn installed and running.
I did indeed pay careful attention to the installation
instructions for postgresql. Am using AOLserver/3.3.1+ad13, postgresql 7.2.3, OpenACS 4.6beta1 from the tarball and .lrn from head CVS. Please note that I am a non-CVS grokking person.

So, all installed, no errors anywhere in sight, all seems
well.

Some "issues";

So, I log in, go to "My Space" click on "Control Panel"
and under Personal Options I see "Create a Weblog" and
I think, "Hey, that's cool" so I click on it and

----------------include error----------------------------
Request Error

Database operation "0or1row" failed (exception NSDB, "Query was not a statement returning rows.")
    while executing
"ns_pg_bind 0or1row nsdb0 {

    select forums_forum__new(:forum_id,'forums_forum',:name,:charter,:presentation_type,:posting_policy,:package_id,NULL,:cre..."
    ("uplevel" body line 1)
    invoked from within
"uplevel $ulevel [list ns_pg_bind $type $db $sql"
    invoked from within
"db_exec 0or1row $db $full_statement_name $sql"
    invoked from within
"if {[regexp -nocase -- {^\s*select} $test_sql match]} {
            db_qd_log QDDebug "PLPGSQL: bypassed anon function"
            set selection [db_..."
    ("uplevel" body line 6)
    invoked from within
"uplevel 1 $code_block "
    invoked from within
"db_with_handle db {
        # plsql calls that are simple selects bypass the plpgsql
        # mechanism for creating anonymous functions (OpenACS - ..."
    (procedure "db_exec_plsql" line 13)
    invoked from within
"db_exec_plsql create_object "
    BEGIN
      :1 := ${package_name}.new([plsql_utility::generate_attribute_parameter_call  -prepend ":"  -indent [expr..."
    (procedure "package_instantiate_object" line 106)
    invoked from within
"package_instantiate_object -extra_vars $extra_vars forums_forum"
    (procedure "forum::new" line 8)
    invoked from within
"forum::new -name $name  -charter $charter  -presentation_type $presentation_type  -posting_policy $posting_policy  -package_id $weblog_package_id  "
    invoked from within
"set forum_id [forum::new -name $name  -charter $charter  -presentation_type $presentation_type  -posting_policy $posting_policy  -package_id $weblog_p..."
    ("uplevel" body line 2)
    invoked from within
"uplevel 1 $transaction_code "
    (procedure "db_transaction" line 1)
    invoked from within
"db_transaction {
    set forum_id [forum::new -name $name  -charter $charter  -presentation_type $presentation_type  -posting_policy $posting_policy  -pa..."
    invoked from within
"if {![llength $existing_forum_ids]} {
    #No existing weblog lets make them one.

    set user_name [dotlrn::get_user_name $user_id]
    set name "[_..."
    ("uplevel" body line 35)
    invoked from within
"uplevel {
          #
#  Copyright (C) 2001, 2002 MIT
#
#  This file is part of dotLRN.
#
#  dotLRN is free software; you can redistribute it and/or modi..."
    (procedure "code::tcl::/web/dotlrn2/packages/dotlrn/www/weblog-new" 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..."

------------------end include--------------------------

So, I'm like, "Umm, okay, that doesn't work" and move
along.

Back in "My Space" I take a peek at what is around,
check out the "Full Calendar" and click on the week
view and am presented with (In the Full Calendar block)

--------------include error---------------------------
Full Calendar      shade  hide

You have found a bug in our code.

Please notify the webmaster and include the following text. Thank You.

*** portal::render_element show callback Error! ***

undefined variable `sunday_of_the_week'
----------------end include---------------------------

Month view and day view work.

Anyway, there are others. In fact, my installation is
replete with things like this. A lot of stuff works
just fine, but a lot of stuff fails in manners consistant
with those I posted.

Can anyone point out an obvious misconfiguration that
I have missed? or something I have done wrong?

Thanks in advance for any help at all,

keep up the good work. This software is wonderful.

Collapse
Posted by Samir Joshi on
Hi Chip,

I agree with you, the cause of problems most likely is mismatch between dotLRN and OpenACS versions. I would use both dotlrn and openacs from their respective cvs HEAD, though  that may have some problem still as the distributed development team members update their changes.

Collapse
Posted by Caroline Meeks on
The weblog problem is some sloan specific code that got merged into CVS by mistake.

In /dotlrn/www/control-panel.adp remove the line:

<li><include src="weblog-control-panel">

Thanks for catching this.

Caroline

Collapse
Posted by Jarkko Laine on
The problem with calendar is discussed here.

I don't know if it's really solved, but Peter Marklund made a quick solution for it. I think it's not solved in 1.0 nor head versions. The quick workaround is also in bug tracker. (link)

Collapse
Posted by Roger Metcalf on
I'm posting this here instead of a new topic because it seems closely related. I've installed 4.6. On an ETP page I click "Create a new subtopic", give it a name and title, click Submit, and get:

Database operation "0or1row" failed (exception NSDB, "Query was not a statement returning rows.")
    while executing
"ns_pg_bind 0or1row nsdb0 {

	select site_node__new(NULL,:parent_id,:name,NULL,:directory_p,:pattern_p,:creation_user,:creation_ip)

      }"
    ("uplevel" body line 1)
    invoked from within
"uplevel $ulevel [list ns_pg_bind $type $db $sql"
    invoked from within
"db_exec 0or1row $db $full_statement_name $sql"
    invoked from within
"if {[regexp -nocase -- {^\s*select} $test_sql match]} {
            db_qd_log QDDebug "PLPGSQL: bypassed anon function"
            set selection [db_..."
    ("uplevel" body line 6)
    invoked from within
"uplevel 1 $code_block "
    invoked from within
"db_with_handle db {
        # plsql calls that are simple selects bypass the plpgsql 
        # mechanism for creating anonymous functions (OpenACS - ..."
    (procedure "db_exec_plsql" line 13)
    invoked from within
"db_exec_plsql create_object "
    BEGIN
      :1 := ${package_name}.new([plsql_utility::generate_attribute_parameter_call  -prepend ":"  -indent [expr..."
    (procedure "package_instantiate_object" line 113)
    invoked from within
"package_instantiate_object -extra_vars $extra_vars site_node"
    (procedure "site_node::new" line 10)
    invoked from within
"site_node::new -name $name -parent_id $parent_id"
    invoked from within
"set node_id [site_node::new -name $name -parent_id $parent_id]"
    ("uplevel" body line 3)
    invoked from within
"uplevel 1 $transaction_code "
    (procedure "db_transaction" line 1)
    invoked from within
"db_transaction {
            set node_id [site_node::new -name $name -pare..."
    (procedure "site_node_apm_integration::new_site_node_and_package" line 3)
    invoked from within
"site_node_apm_integration::new_site_node_and_package  -name $url_path_component  -parent_id $parent_node_id  -package_key $package_key  -instance_name..."
    (procedure "site_node_mount_application" line 12)
    invoked from within
"site_node_mount_application -return package_id $node_id $instance_name $package_key $pretty_name"
    (procedure "subsite::auto_mount_application" line 34)
    invoked from within
"subsite::auto_mount_application  -instance_name $subtopic_name  -pretty_name $subtopic_title "edit-this-page""
    invoked from within
"if { $confirmed == "t" } {
    if { [empty_string_p $subtopic_name] ||
         [regexp {[^a-zA-Z0-9\-_]} $subtopic_name] } {
	ad_return_complaint 1 "..."
    ("uplevel" body line 21)
...

In tracking this down a bit I find that package_instantiate_object seems to be calling site_node.new with a parameter string (generated by plsql_utility::generate_attribute_parameter_call) that looks like this:

(creation_user => :creation_user, creation_ip => :creation_ip, 
name => :name, parent_id => :parent_id, directory_p => :directory_p, pattern_p => :pattern_p)

That sure doesn't match the signature for function site_node__new:

create function site_node__new (integer,integer,varchar,integer,boolean,boolean,integer,varchar)
returns integer as '
declare
  new__node_id                alias for $1;  -- default null  
  new__parent_id              alias for $2;  -- default null    
  new__name                   alias for $3;  
  new__object_id              alias for $4;   -- default null   
  new__directory_p            alias for $5;  
  new__pattern_p              alias for $6;   -- default ''f'' 
  new__creation_user          alias for $7;   -- default null   
  new__creation_ip            alias for $8;   -- default null   
  v_node_id                   site_nodes.node_id%TYPE;
  v_directory_p               site_nodes.directory_p%TYPE;
begin
...

I don't know postgresql well yet but aren't parameters passed positionally, and doesn't that look like an Oracle argument list? What am I missing here?