naviserver-devel

[naviserver-devel] XOTcl and ttrace

[Stephen D. <sd...@gm...>]

Shouldn't the support for XOTcl and ttrace be in the XOTcl package
itself?  They already ship generic/aol-xotcl.tcl which overrides
_ns_savenamespaces etc.

The dependency seems slightly backwards -- that naviserver should have
to understand the guts of XOTcl, a non-required package.  And keeping
the support updated as new XOTcl packages are released...

Re: [naviserver-devel] XOTcl and ttrace

[Zoran V. <zv...@ar...>]

Am 25.02.2006 um 21:29 schrieb Stephen Deasey:

> Shouldn't the support for XOTcl and ttrace be in the XOTcl package
> itself?  They already ship generic/aol-xotcl.tcl which overrides
> _ns_savenamespaces etc.
>
> The dependency seems slightly backwards -- that naviserver should have
> to understand the guts of XOTcl, a non-required package.  And keeping
> the support updated as new XOTcl packages are released...

Hm... actually I should make a plugin interface for this in ttrace  
and let
xotcl users register the plugin. That would make it cleaner. Yes.

Cheers,
Zoran

Re: [naviserver-devel] XOTcl and ttrace

[Stephen D. <sd...@gm...>]

On 2/25/06, Zoran Vasiljevic <zv...@ar...> wrote:
>
> Am 25.02.2006 um 21:29 schrieb Stephen Deasey:
>
> > Shouldn't the support for XOTcl and ttrace be in the XOTcl package
> > itself?  They already ship generic/aol-xotcl.tcl which overrides
> > _ns_savenamespaces etc.
> >
> > The dependency seems slightly backwards -- that naviserver should have
> > to understand the guts of XOTcl, a non-required package.  And keeping
> > the support updated as new XOTcl packages are released...
>
> Hm... actually I should make a plugin interface for this in ttrace
> and let
> xotcl users register the plugin. That would make it cleaner. Yes.


I thought ttrace::addscript, ttrace::atdisable etc. were the interface?

What would really make me happy is if ns_eval wasn't redefined in
nsd/init.tcl :-)

Re: [naviserver-devel] XOTcl and ttrace

[Zoran V. <zv...@ar...>]

Am 27.02.2006 um 09:40 schrieb Stephen Deasey:

>
> I thought ttrace::addscript, ttrace::atdisable etc. were the  
> interface?
>
Yes but I have to make it somehow usable in this particular
place load-wise because ttrace needs to be loaded before anyting
else.

> What would really make me happy is if ns_eval wasn't redefined in
> nsd/init.tcl :-)

???????? (deep confusion...)

The "ns_eval", as implemented in stock AS or NS is the MOST UGLY JUNK  
CODE
I ever saw. OTOH, the "new" redefined ns_eval is just:

    ttrace::enable
    eval $code
    ttrace::disable

TRIVIAL. Also, if you disable lazy-loader, ns_eval is the same old
ugly piece of crap as it was before.

What is wrong in redefining that ugly ns_eval thing?

Cheers
Zoran