Forum OpenACS Development: Bug in xowiki page includelets resolution when viewing live revision

If you go to an xowiki page that has an include of another xowiki page like
{{ page_title }}
and you click "Revisions" then click on the magnifying glass icon next to the lastest/live revision you will get an infinite loop.

Here is what happens.

When the include tag is encountered by the parser resolve_request is called. Then this bit of code runs

if {$item_id != 0} {
set revision_id [my query_parameter revision_id 0]
set [expr {$revision_id ? "item_id" : "revision_id"}] 0
#my log "--instantiate item_id $item_id revision_id $revision_id"
set r [::Generic::CrItem instantiate -item_id $item_id -revision_id $revision_id]
$r destroy_on_cleanup
#my log "--instantiate done CONTENT\n[$r serialize]"
$r set package_id [namespace tail [self]]
return $r
} else {
return ""
}

This gets the revision_id from the URL query parameters and passes it to the instantiate which uses the revision_id. This instantiates the revision of the parent page and it parses it again, gets to the include etc.

I noticed in a later version of xowiki the code is changed to use

set r [::xo::db::CrClass get_instance_from_db -item_id $item_id -revision_id $revision_id]

which might fix it. I am not sure of all the implications of this the xo::db::CrClass call is no available in my version.

Any advice?

Hi Gustaf,

The code from HEAD (i have version 1.39 of context-procs.tcl for example) exhibits the same behavior. It appears the code has been totally rewritten and the patches do not help.

I am using xotcl-core 0.89 released 2008-08-25.

Any ideas?

I fixed this problem by increasing the stacksize to 1mb from 512kb.

Not sure why it was only 512kb, i think at leaast 1mb is a minimum with the code we are using these days.

Gustaf, what stacksize do you use?

512KB are clearly to small. We use 2mb on all our systems (including production, were we have about 100 connection threads configured). However, i don't see, were the document size has an influence on the stack size diff. As long there is no recursion, the document size should not require a larger stack. Are you using already the version with ::util::diff? If you see a recursion, where does it happen?

Difference on time depending on size is ok, different stack consumption would be bad. The Tcl-based diffs load the document in two versions in memory and build from this tcl lists, for which the longest common subsequences are computed.

It well established that scripted solutions are slow on large input files (see e.g. the comments on http://esw.w3.org/topic/HtmlDiff). The best free alternative seems to be currently daisydiff from Google code (gsoc project in 2007) and maybe the php implementation for mediawiki based on the same algorithm (gsoc project in 2008) http://code.google.com/p/daisydiff/ . If someone has time, interest and skills, it sounds like a nice little project to compare this in detail with the tcl based html diff and maybe port it to Tcl.

-gustaf neumann