Forum OpenACS Development: Using "info procs" after upgrade to OpenACS 5.9.1b3 (nsf proc reform)

Request notifications

Dear community,

I have recently upgraded one of our production systems to OpenACS 5.9.1b3. In some places in the system "weak dependencies" are implemented in a coding style like this:

if {[info procs ::mypackage::myproc] ne ""} {
  do something if this is available
}

I have just realized that now after the upgrade these snippets don't fire because these procs cannot be found. I have immediately figured out that in most situations this can be fixed by using "info commands". After some digging, I have found that these procs now live under ::nsf::procs, so that [info procs ::nsf::procs::mypackage::myproc] does work as well.

However, not all procs seem to be affected. A colleague found that (ad_)procs with empty parameters or without non-positional parameters are not affected.

So how should we tackle this? info procs is used in many places. Do we have to double check every occurrence or is there a simple solution?

All the best! Michael

Hi Michael!

Gustaf Neumann will probably comment on that as the authority, but whether an nsf::proc shows up in [info procs] or [info commands] depends on the way it becomes implemented internally. nsf::proc falls back to ordinary Tcl proc (and the corresponding cmd type) when the formal arguments do not require NSF arg processing (optional or nonpos arguments). This matches your observation:

% ::nsf::proc foo {} {;}
% info proc foo
foo
% info commands foo
foo
% ::nsf::proc foo {b:optional} {;}
% info proc foo
% info commands foo
foo

Whether this should (can?) be dealt with, requires a dive. But symmetry in introspection would be good ... Pls. feel free to submit a ticket at https://sourceforge.net/p/next-scripting/tickets/.

As for the "feature checks" in OpenACS: These spots should uniformly use [info commands] anyways, simply because [info commands] does not discriminate between scripted (procs) and C-implemented commands. Using [info procs] at these places is not robust in light of switching between a scripted or C implementation or nsf::proc implementation of sth. named "::mypackage::myproc", which is typically orthogonal to the feature check as such, right?

Cheers,
Stefan

To be clear: [info commands] should not be substituted for each and every occurrence of [info procs], just for those feature checks you mentioned.
please refer to https://github.com/openacs/openacs-core/commit/d4a4abade442fcc39d00b493b3c6b880b75a4268 for the related changes, which happened a few years ago. Using nsf::proc improves the performance of ad_procs by a factor for 2 or three and reduces memory consumption as well (see commit message above). By using nsf::proc, the ad_procs are appearing to Tcl as commands. There is no way to make them look exactly as procs without modifying Tcl itself (or introducing a significant speed penalty). Tcl find every "proc" via "info commands"; therefore every code, that does not want explicitly to distinguish between a "proc" and a "command" should use the more general "info commands". In the case above, i would recommend to implement the "weak dependencies" via "info commads", since it probably does not matter to you, whether the function is implemented via Tcl proc or Tcl command.

In general, all code in acs-core and in the 90 supported packages is supposed to be working out of the box with and without nsf::proc (this is running since several years on openacs.org). If there are missed cases, please report via bug tracker.

The usage of nsf::proc for ad_procs depends primarily on the availability of nsf/xotcl 2.0 on your system. If a site has no xotcl 2.0 installed, ad_procs are always implemented by default as plain Tcl procs. If xotcl 2.0 (or newer) is installed nsf::procs are used when these are beneficial (e.g. when argument parsing is needed). If for some reason a site has xotcl 2.0 installed, and does not wish to use nsf::procs, please add a line "set ::acs::useNsfProc 0" to the end of your "0-acs-init.tcl" file (this could be as well made configurable via the config file).

Hope, this helps.

Thank you both for the extensive clarifications!