On 2/20/07, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote:
>
> 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.
> >
> > The same seems to fail, no matter what lazyloader setting is used,
> > with the
> > current bin/init.tcl and/or nstrace.tcl.
>
> 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
> (stands for "interpreter control"). You can use this to register
> callbacks
> which are to be executed at interpreter creation, deletion, etc. This is
> the most flexible way how one could/should tangle that (complex)
> problem.
>
> Therefore I suggest we take complete different way for hanling XOTcl at
> 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.
> 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.
How does the lazy loader compare to Tcl's -lazy switch to pkg_mkIndex?
http://www.tcl.tk/man/tcl8.4/TclCmd/pkgMkIndex.htm
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
naviserver-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/naviserver-devel
