[naviserver-devel] NS Initialization (Was: ::xotcl::unknown)

[Zoran Vasiljevic]

Am 16.02.2007 um 18:05 schrieb Bernd Eidenschink:

Hm, looks like with the 4.99.1 Sourceforge release there is no problem loading

xotcl files and working with it.


current bin/init.tcl and/or nstrace.tcl.

The same seems to fail, no matter what lazyloader setting is used, with the

I have looked into that part... (LONG!)

The trouble is the way how NS or AS are initialized.

Both (yes, we do still use that old arcane init stuff) are doing pretty
much complicated and error-prone stuff to get all the Tcl files sourced
and all the modules loaded.

The way how it works is (roughly):

  o. all tcl files are sourced
  o. introspective script is run to gather the state of the interp
  o. the script applied to every new Tcl interp

This is of course sub-optimal for any complex interp initialization.
Tcl (still) does not offer a capability to replicate a loaded interp.
There are several attempts to do so, but most of them are/were limited
in scope. Over the lifetime of AS project (including our own NS fork)
there have been several attempts to address this problem but no one was
really successful.

As of V4, there is a vehicle to do this right and that is: ns_ictl

which are to be executed at interpreter creation, deletion, etc. This is


Therefore I suggest we take complete different way for hanling XOTcl at

This will simplify the things greatly.

The idea is to issue something like

    ns_ictl oninit {package require XOTcl}
    foreach file $xotcl_files {
        ns_ictl oninit {source $file)
    }

during server startup. The "xotcl_files" would hold list of
all *.xotcl files found in various places (in [ns_library shared]
and/or [ns_library private]).

I have written a trivial XOTcl loader (attached). Please note that
the nstrace.tcl (attached) is slightly modified to *exclude* processing
of xotcl namespace (I will have to check this into CVS but for the
meantime, please just put both files under /usr/local/ns/tcl or under
/usr/local/ns/modules/tcl directory).

How it works now is:

    xotcl.tcl issues ns_itcl oninit {package req XOTcl}
    then it collects all shared/private *.xotcl files
    for every file it does: ns_ictl "source $file"

This is MUCH simpler, works always and everybody can understand it.
It might be that this will introduce a small speed penalty when
creating an interpreter, but most modern computers are so fast that
you will not notice that in real life.

A word on lazy loading... this is MUCH more complicated stuff as it
requires special support from XOTcl in addition to the nstrace.tcl
code. Fortunately, there is a way to do that and we are using this
in our product. Unfortunately, I have no time at this moment to get
it done "right" for everybody to use. So, for the time being please
refrain from using lazy-loading of XOTcl.

If the attachments are filtered by the list handler please tell
me so I can put them somewhere for download.

Cheers,
Zoran

(stands for "interpreter control"). You can use this to register callbacks the most flexible way how one could/should tangle that (complex) problem. the interp start than we do now. Over the time we can rewrite the existing code to use ns_ictl only, w/o fiddling with that home-brewn script synthesis.

nstrace.tcl
Description: Binary data

xotcl.tcl
Description: Binary data