Weblog Page

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Sat, 24 Jun 2006 15:59:56 +0200

-------- Original-Nachricht --------
Betreff: Re: [Xotcl] Debugging in Expect with XOTCL
Datum: Sat, 24 Jun 2006 15:59:11 +0200
Von: Gustaf Neumann <neumann_at_wu-wien.ac.at>
An: Jegan Kumar Somi Ramasamy Subramanian -X (jsomiram - HCL at Cisco)
<jsomiram_at_cisco.com>
Referenzen:
<AAC329F11B438F43BBA91F50013A69B6013FA62F_at_xmb-blr-413.apac.cisco.com>



Dear Jegan,

i know close to nothing about how expect works and what procs it
defines. but maybe i can point you to
the right direction, and someone else can help you more specific.

Jegan Kumar Somi Ramasamy Subramanian -X (jsomiram - HCL at Cisco) schrieb:
> Hi all,
>
> I have few questions in debugging of XoTcl with expect/tclsh.
>
> 1) How can we do debugging from expect? I am not able to use edprocs
> in xoTcl. I usually do "edprocs <proc name>" from expect and I will do
> necessary changes without changing the actual file. Do we have any
> such option in xoTcl?
i am pretty sure, edproc is defined in exect in tcl. i would recommend
to define methods
  Object instproc edproc ...
  Class instproc edinstproc ...
where you get the methods arguments and body in the same way as in
edproc via introspection and
redefined the proc/instproc after editing.

>
> 2) Also, is there any direct way to print or get the variables defined
> in a class in expect? As of now, I am creating a simple procedure in
> the expect under the required class and I am retrieving the values
> using that procedure by calling them with the corresponding object.
similar as (1). in plain tcl , you have ...[info vars]..., in xotcl you
have ...[obj info vars]...It should be possible
with little work to provide a generic xotcl layer for this as well.
>
> 3) In case of TCL, while doing debugging we do some changes in the
> .tcl file and we just source it in the expect prompt to get the
> changes. But in case of xoTcl, I am now coming out of expect and again
> opening a new one and giving a "package require <package name>" to get
> the updated information. Is there any simple way to do this as I need
> to reset many of my environment while doing this process?
i don't understand the problem here, esp. with the "package reqire" and
"environment variables". if you have a running
script, and you have xotcl already loaded, there is no need to do e.g. a
package require again before sourcing the script.
We do this all the time e.g. in the openacs environment (openacs.org).

-gustaf
>
>
> Thanks,
> Jegan.
> ------------------------------------------------------------------------
>
> _______________________________________________
> Xotcl mailing list
> Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
>

From: Scott Gargash <scottg_at_atc.creative.com>
Date: Tue, 5 Sep 2006 08:43:30 -0700

Gustaf Neumann <neumann_at_wu-wien.ac.at> wrote on 09/04/2006 03:50:42 AM:

> Scott,
>
> you can achieve the precedence you are wanting by adding multiple
> superclasses to Derived.
> In the forthcoming version (which will be named 1.5), you can even use
> "superclass add" like
> in the following example.

Thanks, but in my particular case I don't have knowledge of Derived, only
Base. By that, I mean I'm actually adding BaseMixin (the HW simulator) to
Base (the HW) before Derived has even been created. I'd like for Derived
to remain ignorant of BaseMixin because BaseMixin only exists for testing
purposes. I prefer to avoid having code paths that exist only for testing
purposes. (Which mixins are particualrly well-suited for).

My current solution is to make Derived a mixin as well. This then forces
it to the head of the precedence order regardless of the existence of
BaseMixin so I don't have different code paths for BaseMixin vs. Base. It
works, but it's not really correct from a design standpoint. Derived
should be a derived class (it's a unique type), not a mixin.

This is what I meant about the current precedence order breaking
encapsulation. I wish to modify a single class, but the precedence order
makes it be global. In order to get things to work, I have to distribute
knowledge of BaseMixin to places in the hierarchy that (I believe)
shouldn't have to know or care.

What's the scenario where it's desireable for BaseMixin to be ahead of
Derived?

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Tue, 28 Apr 2009 08:44:44 +0200

Ross, Colin schrieb:
> Hi Gustaf - thanks so much for your prompt response. The "instproc configure" is perfect for what I need to do. I do appologise for not being able to find it in the documentation - I guess if you dont know what you are looking for then its difficult to find it.
>
>
One can alway ask XOTcl, what's going on. The tiny script below shows
the call-order for creates and recreates.

best regards
-gustaf neumann


==== create
CALL ::C ::xotcl::Class->create c1
CALL ::C ::xotcl::Class->alloc ::c1
EXIT ::C ::xotcl::Class->alloc (::c1)
CALL ::c1 ::xotcl::Object->configure
EXIT ::c1 ::xotcl::Object->configure (0)
CALL ::c1 ::xotcl::Object->init
EXIT ::c1 ::xotcl::Object->init ()
EXIT ::C ::xotcl::Class->create (::c1)
==== recreate
CALL ::C ::xotcl::Class->create c1
CALL ::C ::xotcl::Class->recreate ::c1
CALL ::c1 ::xotcl::Object->cleanup
EXIT ::c1 ::xotcl::Object->cleanup ()
CALL ::c1 ::xotcl::Object->configure
EXIT ::c1 ::xotcl::Object->configure (0)
CALL ::c1 ::xotcl::Object->init
EXIT ::c1 ::xotcl::Object->init ()
EXIT ::C ::xotcl::Class->recreate (::c1)
EXIT ::C ::xotcl::Class->create (::c1)
DONE

===================================================
package req XOTcl
namespace import -force ::xotcl::*

Object instproc F args {
  puts "CALL [self] [self calledclass]->[self calledproc] $args"
  set r [next]
  puts "EXIT [self] [self calledclass]->[self calledproc] ($r)"
  return $r
}

Class C -instfilter F -filter F

puts "==== create"
C create c1

puts "==== recreate"
C create c1

puts DONE

From: Kurt Stoll <stoll_at_mac.com>
Date: Sun, 23 Apr 2006 10:58:07 -0700

I was in the process of writing this email to ask whether XOTcl
currently supports, or could easily be extended to support, a
particular pattern of parameter defaults that I often use, and then
was pleased to discover that XOTcl already provides most of what I
was looking for. Though, it's not documented as such, so I'm not
certain whether this was intentional. I suspect it may have been a
side effect of the generality of parameters. I don't mean to dismiss
the foresight of the XOTcl authors, but since it is a simple
mechanism, and not documented, I am concerned that the feature may
disappear in the future.

The pattern is simple - parameter defaults, instead of being
constants, should be changeable so that client code can modify the
defaults as desired. For example, if the default is a class
variable, then client code can modify the class variable. Then, when
a new instance is created, the new default is used. To extend the
example from the tutorial:

        Car set doors 8
        Car create limo
        limo doors ; # ==> 8
        Car set doors 5
        Car create minivan
        minivan doors ; # ==> 5

I originally supported this pattern by putting the appropriate
intelligence in the init instproc. But, since I use this pattern a
lot, I saw that code commonly in many of my init instprocs. So, I
was looking to find a way to have XOTcl automatically pick up the
default from the class. I decided that the most general thing to do
was to put a script in the default and then execute it. But, when I
tried that, I found that XOTcl executed the script for me! So, to
support the above, I simply did:

        Class create Car -parameter { {doors {[[self class] set doors]}} }

I also found that the default can be a simple variable, though
accessing it requires scope qualifiers (but, I find this much less
useful):

        Class create Car -parameter { {doors $::DOORS} }
        set DOORS 4
        Car create sedan
        sedan doors ; # ==> 4

Obviously, XOTcl supports much more general default behavior than I
was originally looking for. But, for me, this is the appropriate
solution. I can express simple defaults very simply. If I am
looking for something more complicated, I can create a proc to
support it, and then have the proc called.

Note that with parametercmd we can make this slightly cleaner to use:

        Class create Car -parameter { {doors {[[self class] doors]}} }
        Car parametercmd doors

        Car doors 8
        Car create limo
        limo doors ; # ==> 8
        Car doors 5
        Car create minivan
        minivan doors ; # ==> 5

This then begs for automatic creation of the parametercmd on the
class. I had hoped that this could be accomplished by subclassing
Class::Parameter and extending the init instproc (note that I had to
actually use ::xotcl::Class::Parameter), but this did not work:

        Class MyParameter -superclass ::xotcl::Class::Parameter
        MyParameter instproc init args {
                ## I would like to create parametercmd's on the class here; but, I
need a handle
                ## to the class. Is it one of the args? Let's find out:
                puts [info level 0]
                next
        }
        Class create Car -parameterclass MyParameter -parameter { {color
green} }
        ## Hmm - didn't see what I hoped I would see.
        Car create ferrari
        ## init ::ferrari
        ## ::ferrari
        ## Ok, this is where the parameter gets instantiated. So, how do
the instparametercmd's get created?

Maybe there is no hook for me to do what I'm trying to do? Maybe I
just have to accept manually adding the parametercmd to the class?
It's not such a big deal, but I thought it might be useful.

Thanks,
Kurt Stoll

From: Jeff Hobbs <jeffh_at_ActiveState.com>
Date: Mon, 4 Apr 2005 10:13:41 -0700

Gustaf Neumann wrote:
> Since xotcl uses ordinary tcl interps, i would assume, it
> inherits the safetiness of save tcl interps. Since xotcl does
> not do any socket handling, file-i/o, exec's, etc., i would
> think, this is a good start. If you see commands that we
> should deactivate in safe interps, please let me know.

You have to be careful with anything you add at the C level for
safe interps. Whatever you create in Tcl in safe interps is by
definition safe (if you aren't aliasing into the master), because
of the model. However, in C you can expose anything. While you
might not directly expose exec, IO, etc., you have to consider
how you might indirectly expose that functionality and how a user
might exploit that. I'm not saying that xotcl does, but you
should just consider the implications of each C-based command
individually. You also have the Tcl_IsSafeInterp C API for
variant behavior in safe interps.

  Jeff Hobbs, The Tcl Guy
  http://www.ActiveState.com/, a division of Sophos

From: Kristoffer Lawson <setok_at_scred.com>
Date: Mon, 26 Apr 2010 17:37:33 +0300

On 26 Apr 2010, at 11:04, Stefan Sobernig wrote:
>
> Well, there is a slight difference between the [package] and TEA
> versioning schemes. While for [package] version numbers,
> compatibility is only indicated by the major version number (*1*.2.0
> vs. *1*.6.0), this is not a strict requirement for TEA version
> numbers. Here, as for the Tcl versioning (8.*4* vs. 8.*5* vs. 8.*6*
> vs 9), the minor number can indicate possible incompatibilities. I
> do not say that this distinction between [package] and TEA
> versioning makes any particular sense (apart from the Tcl stubs
> mechanism, probably). XOTcl has always followed the TEA approach
> from what i can tell and, while being very keen to avoid backward
> incompatibilities, does not give firm guarantees here.

Hm, I don't believe that is correct? In Tcl the minor number should
not indicate incompatibilities to the script at all. Basically all 8.0
scripts should run fine on 8.5. At least I can't think of any cases
where this has not been true, and that's the main reason why some TIPs
have been considered for 9.0 and not earlier.

-- 
Kristoffer Lawson, Co-Founder, Scred // http://www.scred.com/

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Fri, 20 Oct 2006 21:33:04 +0300

Are these stored anywhere within XOTcl? If not, I presume that
information is not currently available to the script end? I'm just
wondering as I think I could make good use of that with object
recreation based on its serialised form.


            / http://www.fishpool.com/~setok/

From: Gustaf Neumann <Gustaf.Neumann_at_wu-wien.ac.at>
Date: Thu, 4 Jan 2001 14:19:17 +0100 (CET)

>>>>> "DL" == David LeBlanc <whisper_at_oz.net> writes:

DL> Hi;
DL> I am so far unable to run any of the sample programs or get gdbm or qgdbm or
DL> whatever to run. There seems to be many steps in installing xotcl that are
DL> not described in the installwin readme.

DL> I have installed the software, fixed a bug in the makefile.vc that causes
DL> auto_path to be wrong in the built make file (INSTALLDIR is defined, but
DL> INSTDIR is used in the lib path macro).

DL> Then, I ran installwin.tcl.

DL> Then, even though not in the instructions, I ran make.xotcl in the new
DL> /tcl/lib/xotcl dir.

 Dear David,

 incidentially, yesterday, I ran into similar problems as you
 describe. There seems to be a few things messed up in the win binary
 distribution that we should fix asap.

 * first of all, the binary dll of gdbm that is included in the
   distribution is called
     libgdbm.dll
   and not like the unix-version
     libtclgdbm.so
   (maybe due to the classical 8+3 name restriction?)
   Please rename the dll to
     libtclgdbm.dll
   such it matches the name mentioned in
     lib\xotcl\pkgIndex.tcl

  * secondly, the dll seems to require Tcl 8.2. Please, install
    Tcl 8.2 (in can be installed in parallel to Tcl 8.0 and 8.3 etc).

  * thirdly - this does not seem to affect you, since you compiled
    xotcl yourself - it seems to me that the binary of xotclsh
    requires Tcl 8.3 (That means, to you the binary distribution,
    you need Tcl 8.2 and 8.3 installed)

 running make.xotcl manually should not be neccessary.

DL> Then, I ran qgdbm0.3/install.tcl - something else not in the instructions,
DL> but it looked right.

 this should not be necessary.

DL> Now, whenever I try to run almost any example program (in awo etc.) I get
DL> errors. In the case of awo/webdocument.xotcl it says it can't find
DL> webagent.xotcl. This file is in the mos dir.

DL> Trying to run any of the store files gets a very curious problem:
DL> couldn't load library "K:\tcl\lib\tcl8.3\gdbm0.3\libtclgdbm.so": this
DL> library or a dependent lib
DL> rary could not be found in library path
DL> while executing
DL> "load K:/tcl/lib/tcl8.3/gdbm0.3/libtclgdbm.so"
DL> ("package ifneeded" script)
DL> invoked from within
DL> "package require -exact gdbm 0.3"
DL> (file "qgdbm.tcl" line 28)

 The .so filename is hardcoded in the gdbm distribution.
 to be on the safe side, remove the pkgIndex.tcl file from
 gdbm0.3 (and undo the results of the install file, e.g. remove
 K:/tcl/lib/tcl8.3/gdbm0.3/)

DL> Firstly, this is windows and the shared lib extension is "dll", not "so".
DL> (the .so error is in tcl/lib/xotcl/qgdbm0.3/pkgIndex.tcl file - hard coded
DL> shared lib extension. (Curiously, the pkgIndex.tcl in the sources doesn't
DL> have this problem - in fact it looks completely different.)) Secondly
DL> whatever extension you use, there is no libtclgdbm.dll or .so file anywhere!
DL> I have a tclgdbm.dll, a libgdbm.dll and a gdbm.dll, but no libtclgdbm.dll.
DL> Which is which and where should they go?

DL> Another problem is with trying to run counter.xotcl in the
DL> /tcl/src/xotcl/apps dir - again, I get a package not found error: in this
DL> case, htmlplace.xotcl. It's almost like Xotclsh or XoWish don't do a
DL> pkgIndex search in any of the lib/xotcl dirs or subdirs.


 have you set TCLLIBPATH to something like
   set TCLLIBPATH=c:/Programms/Tcl/lib/xotcl

 Please, note the slashes and do not use backslashes!


DL> If anyone can tell me how to get all this running on windows I would be VERY
DL> greatful.

DL> Thanks,

 Hope, this helps

 best regards

 -gustaf neumann

 PS: Please send the modified makefile.vc to me or to uwe.
 PPS: I will talk to Uwe to bring out an improved win binary asap.

DL> Dave LeBlanc


DL> _______________________________________________
DL> Xotcl mailing list - Xotcl_at_wi.wu-wien.ac.at
DL> http://wi.wu-wien.ac.at/mailman/listinfo/xotcl

From: Uwe Zdun <uwe.zdun_at_wu-wien.ac.at>
Date: Wed, 19 Nov 2003 18:33:28 +0100

Hi!

the -volatile option of new does something like this for local objects in the
current scope (it uses an "unset" trace set in C). Example:

package require XOTcl
namespace import ::xotcl::*

Class A
A instproc destroy args {
  puts "I'm destroyed: [self]"
  next
}
A proc x {} {
  A new -volatile
}
A x

Does this help?

Uwe


On Wednesday 19 November 2003 16:53, Jim Russell wrote:
> Uwe:
>
> Thank you so much for the very lucid explanation. I was hoping that
> I could use the trace mechanism to implement a garbage collection
> scheme. I was storing the XOTcl object name in an ordinary Tcl variable
> upon which I placed the unset trace. When the variable goes out of
> scope, the unset callback is called, and I had hoped to dereference the
> variable to call the XOTcl object's destroy method. However, this
> doesn't appear to be a good approach. Do you have any suggestions?
>
> Jim
>
> Uwe Zdun wrote:
> > Jim,
> >
> > at first glance, the behavior seems ok to me. You're setting 2 traces to
> > the local scope variable "f" which get unset in reverse order -> so
> > the two "f" outputs should be ok.
> >
> > The rhs traces "2" and "3" are for the two inner invocations. For the
> > outer invocations, the callframe is deleted before the Trace is executed.
> > The problem here is that Tcl does not print the error that occurs.
> >
> > Consider the following plain Tcl example:
> >
> > proc tracecb { name1 name2 op } {
> > if {[catch {
> > upvar $name1 var
> > puts "tracecb \"$name1\" \"$name2\" \"$op\" \"$var\""
> > } err]} {
> > puts $err
> > }
> > }
> > proc x {a} {
> >
> > ::trace add variable a [list unset] ::tracecb
> >
> > if {$a == 0} {return}
> > incr a -1
> > x $a
> > }
> >
> > x 4
> >
> > This prints:
> > tracecb "a" "" "unset" "0"
> > tracecb "a" "" "unset" "1"
> > tracecb "a" "" "unset" "2"
> > tracecb "a" "" "unset" "3"
> > can't read "var": no such variable
> >
> > so you cannot rely on the "upvar" in the trace to a local scope variable.
> >
> > You can try to refer to an XOTcl variable (an instance variable)
> > with "[self] trace ..." instead.
> >
> > Uwe
>
> _______________________________________________
> Xotcl mailing list - Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl

-- 
Uwe Zdun
Department of Information Systems, Vienna University of Economics
Phone: +43 1 313 36 4796, Fax: +43 1 313 36 746
zdun_at_{xotcl,computer,acm}.org, uwe.zdun_at_wu-wien.ac.at

From: Teemu Hukkanen <tjhukkan_at_fishpool.fi>
Date: 22 Aug 2001 06:31:30 +0300

I've been maintaining debian packages of xotcl for some time now and
thought it might be useful to mention that on this list too.

Xotcl 0.85.2 is currently in debian's "testing" distribution and 0.85.3
is in "unstable". If you use debian, please test the packages and give
me feedback if you find that something doesn't work.

If you want the packages for debian stable ("potato"), drop me a line.