Forum OpenACS Q&A: Is this tDOM related?

Collapse
Posted by Oscar Bonilla on
On a brand new OpenACS installation from HEAD I get:

[09/Jun/2003:17:11:52][28728.5][-sched-] Notice: lang::catalog::import_from_files - Starting import of message catalogs: /web/dotlrn/p\
ackages/acs-kernel/catalog/acs-kernel.ast_ES.ISO-8859-1.xml /web/dotlrn/packages/acs-kernel/catalog/acs-kernel.de_DE.ISO-8859-1.xml /w\
eb/dotlrn/packages/acs-kernel/catalog/acs-kernel.en_US.ISO-8859-1.xml /web/dotlrn/packages/acs-kernel/catalog/acs-kernel.es_ES.ISO-885\
9-1.xml /web/dotlrn/packages/acs-kernel/catalog/acs-kernel.fi_FI.ISO-8859-15.xml /web/dotlrn/packages/acs-kernel/catalog/acs-kernel.fr\
_FR.ISO-8859-1.xml /web/dotlrn/packages/acs-kernel/catalog/acs-kernel.gl_ES.ISO-8859-1.xml /web/dotlrn/packages/acs-kernel/catalog/acs\
-kernel.ja_JP.Shift_JIS.xml /web/dotlrn/packages/acs-kernel/catalog/acs-kernel.nl_NL.ISO-8859-1.xml /web/dotlrn/packages/acs-kernel/ca\
talog/acs-kernel.no_NO.ISO-8859-1.xml /web/dotlrn/packages/acs-kernel/catalog/acs-kernel.pl_PL.ISO-8859-2.xml /web/dotlrn/packages/acs\
-kernel/catalog/acs-kernel.pt_BR.ISO-8859-1.xml /web/dotlrn/packages/acs-kernel/catalog/acs-kernel.ru_RU.windows-1251.xml /web/dotlrn/\
packages/acs-kernel/catalog/acs-kernel.sv_SE.ISO-8859-1.xml
[09/Jun/2003:17:11:52][28728.5][-sched-] Notice: lang::catalog::read_file reading /web/dotlrn/packages/acs-kernel/catalog/acs-kernel.a\
st_ES.ISO-8859-1.xml in ISO-8859-1
[09/Jun/2003:17:11:52][28728.5][-sched-] Error: lang::catalog::import_from_files - The import of file /web/dotlrn/packages/acs-kernel/\
catalog/acs-kernel.ast_ES.ISO-8859-1.xml failed, error message is:

can't read "xml_data": no such variable

stack trace:

can't read "xml_data": no such variable
    while executing
"xml_parse $xml_data"
    (procedure "parse" line 20)
    invoked from within
"parse [read_file $file_path"
    (procedure "import_messages_from_file" line 6)
    invoked from within
"import_messages_from_file $file_path"

I've grepped for xml_data in acs-lang/tcl/* and found no other reference but the one in the parse function:

  set tree [xml_parse $xml_data]

I have tDOM instead of ns_xml in my aolserver config file. Any ideas?

Regards,

-Oscar

Collapse
2: Re: Is this tDOM related? (response to 1)
Posted by Don Baccus on
It's defined in acs-tcl/tcl/30-xml-utils-procs.tcl so you must not have a clean update of HEAD for some reason ...
Collapse
Posted by Oscar Bonilla on
socrates ...tcl > cvs status 30-xml-utils-procs.tcl
===================================================================
File: 30-xml-utils-procs.tcl    Status: Up-to-date

  Working revision:    1.7
  Repository revision: 1.7    /cvsroot/openacs-4/packages/acs-tcl/tcl/30-xml-utils-procs.tcl,v
  Sticky Tag:          (none)
  Sticky Date:        (none)
  Sticky Options:      (none)

socrates ...tcl > grep xml_data 30-xml-utils-procs.tcl
socrates ...tcl > grep xml_data *
apm-xml-procs.tcl:    set xml_data [read $file]
apm-xml-procs.tcl:    set tree [xml_parse -persist $xml_data]
socrates ...tcl>

I checked on cvs.openacs.org and 1.7 is the latest version.

I tried putting an ns_log when xml_data is set and later when it's used in the parse function in acs-lang. The code only goes through the usage of xml_data. What could be wrong?

Regards,

-Oscar

Collapse
4: Re: Is this tDOM related? (response to 1)
Posted by Don Baccus on
OK I misread I thought you said that xml_parse was missing, not the xml_data variable.

This appears to be a typo introduced when Bart switched to tDOM, I've made what should be the necessary change but haven't tested it, can you grab the latest version and try again?

Collapse
5: Re: Is this tDOM related? (response to 4)
Posted by Bart Teeuwisse on
Oscar and Don,

I'm not quite sure why it would report the xml_data variable missing. This variable is set a few lines before tDOM has to parse it. Before and after I committed the changes to the HEAD I've tested installation of the core.

I'm inclined to think that the error is caused in part by the language files you are trying to parse. Oscar, I suggest that you uncomment the ns_log statements in 30-xml-utils-procs.tcl to find out which file is being parsed when you observe the error.

I'm visiting New York at the moment and might not be able to assist till I return to Santa Cruz next week.

/Bart

Collapse
6: Re: Is this tDOM related? (response to 1)
Posted by Bjorn Thor Jonsson on

Now when I install from an updated cvs head checkout there are complaints in the error log about invalid command name "xml_doc_get_first_node_by_name". Checking packages/acs-tcl/tcl/30-xml-utils-procs.tcl I see the proc doesn't exist, as it does in a previous checkout. That proc might be implemented using tDOM like this:

# Get first node with a given name
proc xml_doc_get_first_node_by_name {doc_id name} {
    set root [$doc_id documentElement]
    return [$root child 1 $name]
}
Assuming that the first child of the root element with the given name is what you want. But the previous nsxml implementation seems to assume that you might also be searching for the root element by name, which just seems weird to me. Either you explicitly ask for the root element or search for one of it's decendants. But I guess that behaviour might be implemented by using domDoc's getElementsByTagName method.

It is lang::catalog::parse that is missing xml_doc_get_first_node_by_name. Since it is using it to get the message_catalog root element, I just changed it to use xml_doc_get_first_node instead.

But still there where errors. Changing the xml_parse proc in packages/acs-tcl/tcl/30-xml-utils-procs.tcl from

proc xml_parse args {
#   ns_log notice "xml_parse $args"
    if {[lindex $args 0] == "-persist"} {
        return [dom parse -simple [lindex $args 1]]
    } else {
        dom parse -simple [lindex $args 0] doc
        return $doc
    }
}
to
proc xml_parse args {
#   ns_log notice "xml_parse $args"
    if {[lindex $args 0] == "-persist"} {
        return [dom parse -simple [lindex $args 1]]
    } else {
        return [dom parse -simple [lindex $args 0]]
    }
}
fixed those. The DOM tree and the associated Tcl command object was probably being freed automatically: http://tdom.org/dom.html

Collapse
7: Re: Is this tDOM related? (response to 1)
Posted by Oscar Bonilla on
Thanks Don and Bjorn. Your suggestions fixed the problem. Could this be commited?

Thanks,

-Oscar

Collapse
8: Re: Is this tDOM related? (response to 1)
Posted by Don Baccus on
Bart ... when I looked at my copy of HEAD xml_data definitely wasn't being set (which matches the error message, of course)

Could you checkout a fresh copy and make sure of this?

Collapse
9: Re: Is this tDOM related? (response to 6)
Posted by Bart Teeuwisse on
Bjorn,

what appeared as a bug is actually intentional. You'll have to include the --persist flag in your call to xml_parse if you intend to avoid the automatic freeing of the DOM tree.

When I made the change, all of the package in OpenACS core used the --persist flag. I suggest changing the calling script. Or remove the --persist flag from xml_parse all together and always return a persistent DOM tree. Please note that persistent trees require explicit deletion.

I'll comment on the xml_doc_get_first_node_by_name after my return from NY.

/Bart

Collapse
10: Re: Is this tDOM related? (response to 1)
Posted by Bart Teeuwisse on
Oscar,

I just installed OpenACS and dotLRN from CVS HEAD without any problems. Are you still seeing this error? If so, do you have any additions/modifications to a stock install?

/Bart

Collapse
11: Re: Is this tDOM related? (response to 1)
Posted by Bjorn Thor Jonsson on
Bart,
in CVS I see Don has commited changes like you describe in this thread June 15.; added the -persist flag to the xml_parse call in acs-lang and dropped the use of xml_doc_get_first_node_by_name:
http://xarg.net/tools/cvs/change-set-details?key=B2BCE9FBF7DA6F3AA28EC932C7F7B9A5E38E7D19

Since then I've also installed OpenACS from CVS HEAD with error free success.