Forum OpenACS Development: Re: OpenACS: the core and the packages/plugins
my replies here below.
I have answered on the bug-tracker about tsearch.
[MM] More on this later, where you talk about "rules of tumb".
Regarding the "Contacts" package, this and some of its many dependencies are not among the packages we actually maintain. I am courious on whether you just tried this one package randomly or if you need it in your project.
[MM] Carl, my customer, already answered. We're looking for a Contacts package, and it seemed to me that "contacts" was the best available option,
However, this commit https://cvs.openacs.org/changelog/OpenACS?cs=MAIN%3Aantoniop%3A20210103153317 should improve the situation. There is still a lot of deprecated api in there and I am not really sure about the many "US-oriented" packages it requires, but better than just breaking at install time.
[MM] These are exactly the very same fixes I applied to the package, to make it work.
As a rule of thumb, is always better to provide detailed information about the problem at hand, rather than just dropping the "It's broken!" bomb. All the packages currently in the oacs-5-10 branch are maintained and do work to their capacity (save the occasional bug), so I suspect there to be an explanation for your issues that has something to do with the specifics of a Windows setup.
[MM] Well... well...
Given this piece of code
if {[callback::impl_exists -impl $driver -callback search::driver_info]} {
array set info [lindex [callback -impl $driver search::driver_info] 0]
# array set info [list package_key intermedia-driver version 1 automatic_and_queries_p 1 stopwords_p 1]
} else {
array set info [acs_sc::invoke -contract FtsEngineDriver -operation info -call_args [list] -impl $driver]
}
if { [array get info] eq "" } {
ns_return 200 text/html [_ search.lt_FtsEngineDriver_not_a]
ad_script_abort
}
The initial if passed OK, but then the following statement did not work, so I got the error displayed by
ns_return 200 text/html [_ search.lt_FtsEngineDriver_not_a]
If you check my fix, I forced the execution of
array set info [acs_sc::invoke -contract FtsEngineDriver -operation info -call_args [list] -impl $driver]
and then that piece of code "worked".
Exactly the same behaviour and consequent reasoning for the following piece of code:
if {[callback::impl_exists -impl $driver -callback search::search]} {
# DAVEB TODO Add subsite to the callback def?
# FIXME do this in the intermedia driver!
# set final_query_string [db_string final_query_select "select site_wide_search.im_convert(:q) from dual"]
array set result [lindex [callback -impl $driver search::search -query $q -offset $offset -limit $limit \
-user_id $user_id -df $df \
-extra_args [list package_ids $search_package_id object_type $object_type]] 0]
} else {
array set result [acs_sc::invoke -contract FtsEngineDriver -operation search \
-call_args $params -impl $driver]
}
When "search" got fixed this way, the system was looking for a tsearch2::search implementation
which as you saw I provided into "tsearch2-driver"
I'm not sure this is a specific Windows problem, it looks to me as code that needs some restructuring.
Frank and Malte stumbled on the very same problems and they are not working on Windows
https://openacs.org/forums/message-view?message_id=5465077
So it seems that the callback implementation is detected as existing, but then returns null when it is actually invoked.
If one looks at: https://openacs.org/api-doc/proc-view?proc=callback&source_p=1
There are basically two ways this can happen: no command is found in the prefix ::callback::${callback}::impl, or the command returns the empty string.
There is little chance that the empty string is returned, as this particular callback implementation returns a constant:
https://openacs.org/api-doc/proc-view?proc=tsearch2::driver_info&source_p=1
hence I suspect that for some reason we do not enter the foreach that says: "foreach procname [lsort [info commands ${base}::$impl]] {" in the call to "callback".
Would you be so kind to check whether this is actually happening? Just insert a debug in the loop and see if the tsearch-driver callback implementation of the search::driver_info contract is found.
If this happens to be the issue you have much more than a broken search on your hands, basically the whole callback machinery would be broken. Let's just see if this is really the case and we can work from there.
Thanks in advance
Antonio
