Weblog Page

From: Michael Aram <michael_at_aram.at>
Date: Mon, 12 Oct 2015 17:10:57 +0200

Dear XOTcl/NX/NSF community,

I am in the process of upgrading one of our OpenACS based systems to XOTcl
2 and stumbled over the following legacy code:

Class create Person -slots {
  foreach e {username first_names last_name email etcetera} {
    Attribute $e -default "" -proc assign {o var value} {$o changed_var
$var $value}
  }
}

Person ad_instproc -private changed_var {var value} {} {
  my instvar __changed_vars
  lappend __changed_vars $var
  my instvar $var
  set $var $value
}


The intention of this not-so-pretty code mainly seems to be that the
Person->save method called by code like the following can recognize which
attributes have actually changed during the last request, and update the
database accordingly...

Person john
john last_name doe
john save


For some reason, now that I have upgraded the system to XOTcl 2, this does
not work anymore. The list __changed_vars is not updated (in the example
above, it would not contain last_name; for debugging purposes, I have put a
log statement into the "assign" proc, it seems that it does not get called.)

As the update process introduced many many other changes as well (compared
to the old and adapted OpenACS we had there), including changes in
xotcl-core, it could certainly be the case that this is simply a the
side-effect of some other change / or messed-up merge. So, my question is,
SHOULD this work anyway in the latest stable version of XOTcl 2, or did the
interface change?

Thanks for your help,
Michael :-)

From: <MichaelL_at_frogware.com>
Date: Mon, 15 Nov 2004 17:16:40 -0500

I've defined a proc which is supposed to be a control structure that
iterates over the children of an object. There's a problem, though, when I
nest calls.

Here's some code:

    Object instproc each {objName body} {
        puts " *** level = [info level]"
        puts " *** self callinglevel = [self callinglevel]"
        uplevel [self callinglevel] [list foreach $objName [lsort [[self]
info children]] $body]
    }

    Class TestB

    Class TestA

    TestA instproc init {args} {
        next
        TestB [self]::b1
        TestB [self]::b2
        TestB [self]::b3
    }

    Class Test

    Test instproc init {args} {
        next
        TestA [self]::a1
        TestA [self]::a2
        TestA [self]::a3
    }

    Test instproc loop1 {} {
        set i 0
        [self] each a {
            incr i
            puts "$a"
        }
        puts "Total = $i"
    }

    Test instproc loop2 {} {
        set i 0
        [self] each a {
            incr i
            puts "$a"
            $a each b {
                incr i
                puts " $b"
            }
        }
        puts "Total = $i"
    }

    Test t

    t loop1
    t loop2

Here's some output:

 *** level = 2
 *** self callinglevel = #1
::t::a1
::t::a2
::t::a3
Total = 3
 *** level = 2
 *** self callinglevel = #1
::t::a1
 *** level = 2
 *** self callinglevel = #2
can't read "i": no such variable
    (reading value of variable to increment)
    invoked from within
"incr i"
    ("foreach" body line 2)
    invoked from within
"foreach b {::t::a1::b1 ::t::a1::b2 ::t::a1::b3} {
                incr i
                puts " $b"
            }"
    ("uplevel" body line 1)
    invoked from within
"uplevel [self callinglevel] [list foreach $objName [lsort [[self] info
children
]] $body]"
    (procedure "each" line 5)
    ::t::a1 ::xotcl::Object->each
    invoked from within
"$a each b {
                incr i
                puts " $b"
            }"
    ("foreach" body line 4)
    invoked from within
"foreach a {::t::a1 ::t::a2 ::t::a3} {
            incr i
            puts "$a"
            $a each b {
                incr i
                puts " ..."
    ("uplevel" body line 1)
    invoked from within
"uplevel [self callinglevel] [list foreach $objName [lsort [[self] info
children
]] $body]"
    (procedure "each" line 5)
    ::t ::xotcl::Object->each
    invoked from within
"[self] each a {
            incr i
            puts "$a"
            $a each b {
                incr i
                puts " $b"
            }
    ..."
    (procedure "loop2" line 4)
    ::t ::Test->loop2
    invoked from within
"t loop2"
    invoked from within
"if 1 {
    Object instproc each {objName body} {
        puts " *** level = [info level]"
        puts " *** self callinglevel = [self cal..."
    (file "XOTcl-test.tcl" line 7)

You can see that the one-level iterator succeeds, but the two-level
iterator can't see the variable defined in the outer loop. You can also
see that the first time "level" and "callinglevel" are different (as you
would expect) but the second time they're the same (which looks like it
might be an XOTcl bug). Any ideas?

(I can work around this for now, of course, but it would be nice to figure
out what's wrong.)

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Wed, 18 Aug 2004 18:36:44 +0300 (EEST)

On Wed, 18 Aug 2004, Gustaf Neumann wrote:

>> What about if I don't define any nonpositional arguments,
>> can I pass arguments beginning with a dash? I kind of hope so, or
>> otherwise it may be necessary to pass "--" everywhere, and it adds
>> incompatibility with older XOTcls.
>
> one can define procs/instprocs with non-positional arguments
> and without. If you have nonposistional arguments defined, and
> you want to pass e.g. -a as "traditional" argument, you must use "--".
>
> Since existing scripts have no nonpositional arguments defined,
> nothing changed there, older scripts continue to work unmodified.

This is what I meant. That if no nonpositional args are defined, arguments
beginning with "-" will be sent as-is to the procedure. I understand from
your explanation, that this is indeed what happens.


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

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Fri, 15 Oct 2004 19:03:10 +0200

On Friday 15 October 2004 18:47, Schofield, Bryan \(GE Transportation\) wrote:
> Does xotcllib, or some other collection of XOTcl utility packages exist?
just the library that comes with the source in xotcl*/library
-gustaf

-- 
Univ.Prof. Dr.Gustaf Neumann
Abteilung für Wirtschaftsinformatik und Neue Medien
Wirtschaftsuniversität Wien, Augasse 2-6, 1090 Wien

From: Victor Mayevski <vitick_at_gmail.com>
Date: Wed, 19 Jan 2011 01:19:09 -0800

In NX, what is the correct way to give a direct access to an object
variable for outside caller, just like we used to do with XOTcl's
[myvar varname]?

Thanks

From: Koen Danckaert <koen_at_retarget.com>
Date: Mon, 20 Mar 2006 17:13:16 +0100

>>> I have added "::xotcl::mymethod" and "::xotcl::myvar" to my
>>> development version. i guess, you would you prefer to have
>>> these exported. Opinions?
>>
>> On giving it some thought I think I actually prefer the version that
>> would be part of Object. After all, it is that object's variable that
>> we want.

Well, in any case we're not adding new functionality here, we're just adding convenience procedures to write callbacks in a more concise and readable way. I believe this is best achieved by having 2 short and concise keywords. In my code, "myproc foo" (vs "my foo") indicates clearly that I'm not actually calling foo, just referring to it. This distinction would be less clear with "my callback foo".

So indeed, if these keywords would be predefined in xotcl, I would prefer to have them exported, otherwise they'd not be short and concise either :-)

>> I don't use it that frequently so I don't mind writing a bit
>> extra, for clarity's sake.

I use it quite often. It's a very common construct in Tk and event-based scripts, I think. I've even customized my editor to highlight "myproc" and "myvar", such that they spring out immediately.

Koen

From: Uwe Zdun <uwe.zdun_at_wu-wien.ac.at>
Date: Tue, 28 Sep 2004 19:25:09 +0200

Hi Catherine,

on Unix we have moved the build system as default to the style preferred
by TEA: the shells
are not built anymore by default. Instead it is advisable to load XOTcl
dynamically into the
ordinary tclsh or wish. I propose you simply use this style of using
XOTcl as well:

% wish
> package require XOTcl
> namespace import xotcl::*

the shells, if build (what is optional) now do nothing else than this.

Uwe



Catherine Letondal wrote:

>
> Gustaf Neumann wrote:
>
>> On Friday 17 September 2004 19:19, Catherine Letondal wrote:
>>
>>> Dear members of xotcl the list,
>>>
>>> Has someone any experience in installing XOtcl on MacOsX ?
>>> I have found a "Portfile" but I don't know what to do with it?
>>
>>
>> Catherine,
>>
>> isn't the Mac OS X Tcl/Tk Aqua 8.4.7 Release something for
>> you to use, it contains XOTcl binaries.....
>>
>> http://groups.google.at/groups?q=xotcl&hl=de&lr=&ie=UTF
>> -8&scoring=d&selm=pgpmoose.200408041618.26617%40despot.non.net&rnum=8
>
>
> Thanks for the advice!
>
> I have indeed installed the TclTkAquaBI and tried but it'svery
> complicated.
> I don't know whether you can help ?
>
> 1) I need to build my own wish with shared objects (libtcl.dylib
> etc...) which
> are not provided in TclTkAquaBI distribution - even using it together
> with the native Tcl.framework
> you don't have the *.h files etc...).
> So I decided to use the Fink tcl/tk distribution which works fine.
>
> 2) Using the TclTkAquaBI (the one which includes xotcl-1.2) is also
> not easy when you
> want to link an xotcl shared object (called
> /Library/Tcl/xotcl1.2/libxotcl1.2.dylib)
> First, because you need xotcl.h, so you have to download separately
> the sources
> that have been used for building the shared library (sources are
> kindly distributed
> from http://tcltkaqua.sourceforge.net/8.4.7.html). Even using
> libxotcl.dylib file distributed in TclAquaBI not not make sense for a
> simple reason: if I need another package (such as BLT), which is not
> distributed in TclAquaBI, I will also
> have to compile it myself, which is very difficult when it is not
> configured for this purpose (blt is also distributed in Fink).
>
> 3) So, sy conclusion was to compile Xotcl myself, which I did, I
> think, successfully.
> configure;
> ./configure --with-tcl=/sw/lib --with-tclinclude=/sw/include
> --with-tk=/sw/lib --with-tkinclude=/sw/include
>
> I just got errors when building xowish:
>
> gcc -pipe -rdynamic -o xowish tkAppInit.o \
> xotcl.o xotclError.o xotclMetaData.o xotclObjectData.o
> xotclProfile.o xotclTrace.o xotclUtil.o xotclShadow.o xotclCompile.o
> aolstub.o xotclStubInit.o \
> -O3 -Wall -Wconversion -Wno-implicit-int -fno-common
> -L/sw/lib -ltcl8.4 \
>
> gcc: unrecognized option `-rdynamic'
> ld: Undefined symbols:
> _Tk_Init
> _Tk_MainEx
> _Tk_SafeInit
>
> Apparently also:
> ==> -ltk8.4 is missing ?
>
> But xotclsh was successfully built.
>
>
> 4) then, I built a very simple tkAppinit.c:
>
> #include "tk.h"
> #include <xotcl.h>
> int
> main(argc, argv)
> int argc; /* Number of command-line arguments. */
> char **argv; /* Values of command-line arguments. */
> {
> Tk_Main(argc, argv, Tcl_AppInit);
> return 0; /* Needed only to prevent compiler
> warning. */
> }
>
> int
> Tcl_AppInit(interp)
> Tcl_Interp *interp; /* Interpreter for application. */
> {
> if (Tcl_Init(interp) == TCL_ERROR) {
> return TCL_ERROR;
> }
> if (Tk_Init(interp) == TCL_ERROR) {
> return TCL_ERROR;
> }
> Tcl_StaticPackage(interp, "Tk", Tk_Init, Tk_SafeInit);
> if (Xotcl_Init(interp) == TCL_ERROR) {
> return TCL_ERROR;
> }
>
> Tcl_Import(interp, Tcl_GetGlobalNamespace(interp), "xotcl::*", 1);
> if (Tcl_PkgRequire(interp, "XOTcl", XOTCLVERSION, 1) == NULL) {
> return TCL_ERROR;
> }
>
> return TCL_OK;
> }
>
> I got an executable (miniwish) built with the following compile/link
> commands (with some warnings):
>
> gcc -fno-common -DXOTCLVERSION=\"1.3.1\" -c -I/sw/include
> -I/sw/include -I/usr/include/X11 -I/sw/include tkAppInit.c
> gcc -bind_at_load -o minibiokwish tkAppInit.o -L/sw/lib -ltk8.4
> -L/sw/lib -ltcl8.4 -L/usr/X11R6/lib -lX11 -lXmu -L/sw/lib/xotcl1.3.1
> -lxotcl1.3.1 -lm
> ld: warning multiple definitions of symbol _tclPlatStubsPtr
> /sw/lib/libtcl8.4.dylib(tclStubLib.o) definition of _tclPlatStubsPtr
> /sw/lib/libtk8.4.dylib(tclStubLib.o) definition of _tclPlatStubsPtr
> ld: warning multiple definitions of symbol _tclIntStubsPtr
> /sw/lib/libtcl8.4.dylib(tclStubLib.o) definition of _tclIntStubsPtr
> /sw/lib/libtk8.4.dylib(tclStubLib.o) definition of _tclIntStubsPtr
> ld: warning multiple definitions of symbol _Tcl_InitStubs
> /sw/lib/libtcl8.4.dylib(tclStubLib.o) definition of _Tcl_InitStubs
> /sw/lib/libtk8.4.dylib(tclStubLib.o) definition of _Tcl_InitStubs
> ld: warning multiple definitions of symbol _tclIntPlatStubsPtr
> /sw/lib/libtcl8.4.dylib(tclStubLib.o) definition of _tclIntPlatStubsPtr
> /sw/lib/libtk8.4.dylib(tclStubLib.o) definition of _tclIntPlatStubsPtr
> ld: warning multiple definitions of symbol _tclStubsPtr
> /sw/lib/libtcl8.4.dylib(tclStubLib.o) definition of _tclStubsPtr
> /sw/lib/libtk8.4.dylib(tclStubLib.o) definition of _tclStubsPtr
> /sw/lib/xotcl1.3.1/libxotcl1.3.1.dylib(tclStubLib.o) definition of
> _tclPlatStubsPtr
> /sw/lib/xotcl1.3.1/libxotcl1.3.1.dylib(tclStubLib.o) definition of
> _tclIntStubsPtr
> /sw/lib/xotcl1.3.1/libxotcl1.3.1.dylib(tclStubLib.o) definition of
> _tclStubsPtr
> /sw/lib/xotcl1.3.1/libxotcl1.3.1.dylib(tclStubLib.o) definition of
> _tclIntPlatStubsPtr
> /sw/lib/xotcl1.3.1/libxotcl1.3.1.dylib(tclStubLib.o) definition of
> _Tcl_InitStubs
>
> But this executable does not work correctly:
>
> ./minibiokwish
> dyld: ./minibiokwish can't open library: libxotcl1.3.1.dylib (No
> such file or directory, errno = 2)
> Trace/BPT trap
>
> (executed from an X11 environment - not Aqua - of course).
>
>
>
>
> --
> Catherine Letondal -- Pasteur Institute Computing Center
>
> _______________________________________________
> Xotcl mailing list - Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl

From: Uwe Zdun <uwe.zdun_at_wu-wien.ac.at>
Date: Fri, 14 Nov 2003 10:48:36 +0100

In XOTcl each class is an object: so a variable of a class can be used as a
classifier-scoped attribute of all instances of that class.

Example:

Class Point
Point set classVar 1
Point instproc getClassVarFromInstance {} {
  [self class] set classVar
}

Point p1
Point p2

puts [p1 getClassVarFromInstance]
-> 1
puts [p2 getClassVarFromInstance]
-> 1

Regards,

Uwe

On Thursday 13 November 2003 22:15, Jim Russell wrote:
> I may have overlooked it in the documentation, but I'm having trouble
> getting a classifier-scoped member variable in XOTcl. Is there a way to
> mimic the behavior of a C++ static data member?
>
> _______________________________________________
> 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: John McGlaughlin <jmcglaug_at_cisco.com>
Date: Thu, 07 Apr 2005 09:10:45 -0400

Thanks all,
Very helpful
Lazy John

Jeff Hobbs wrote:

>Oh yeah ... tkcon seems to be certainly well enough architectured
>(in this case ;) ) to handle this easily. Add this to tkcon:
>
>proc ::tkcon::ExpandXotcl str {
> # in a first step, get the cmd to check, if we should handle subcommands
> set cmd [::tkcon::CmdGet $::tkcon::PRIV(console)]
> # Only do the xotcl magic if there are two cmds and xotcl is loaded
> if {[llength $cmd] != 2
> || ![EvalAttached [list info exists ::xotcl::version]]} {
> return
> }
> set obj [lindex $cmd 0]
> set sub [lindex $cmd 1]
> set match [EvalAttached [list $obj info methods $sub*]]
> if {[llength $match] > 1} {
> regsub -all {([^\\]) } [ExpandBestMatch $match $str] {\1\\ } str
> set match [linsert $match 0 $str]
> } else {
> regsub -all {([^\\]) } $match {\1\\ } match
> }
> return $match
>}
>
>and then do this:
>
>tkcon master set ::tkcon::OPT(expandorder) \
> {Xotcl Variable Procname Pathname}
>
>Note that this puts pathname at the end, also addressing Gustaf's
>request that it's too picky. You have to have Xotcl before
>Procname for it to be really useful.
>
>I've added the above proc to the tkcon sources, but I didn't change
>the expandorder to include it yet ... I suspect it's "fast enough",
>but if somebody with a slow machine could confirm, that would be
>nice.
>
> Jeff Hobbs, The Tcl Guy
> http://www.ActiveState.com/, a division of Sophos
>
>
>

From: Uwe Zdun <uwe.zdun_at_wu-wien.ac.at>
Date: Wed, 18 Aug 2004 16:37:20 +0200

Hi Kristoffer,

there should be no incompatibilities with older versions.
non-pos args are a pure extension by one additional argument
if there is none, you have no non-pos arguments. See the tutorial for
examples.

Uwe


Kristoffer Lawson wrote:

> On Wed, 18 Aug 2004, Gustaf Neumann wrote:
>
>> * Nonpositional arguments for xotcl procs/instprocs; this is
>> a flexible way to check arguments, to provide defaults etc
>> for every xotcl proc/instproc. It uses a similar syntax as
>> ad_proc and ad_page_contract in OACS. See the tutorial for
>> more details.
>
>
> Interesting... I wonder if something like that could be TIPped into
> Tcl itself? What about if I don't define any nonpositional arguments,
> can I pass arguments beginning with a dash? I kind of hope so, or
> otherwise it may be necessary to pass "--" everywhere, and it adds
> incompatibility with older XOTcls.
>
> / http://www.fishpool.com/~setok/
> _______________________________________________
> 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_acm.org, uwe.zdun_at_wu-wien.ac.at