Weblog Page

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Sun, 13 Aug 2006 17:40:08 +0200

Scott Gargash schrieb:
>
> I've run into an interaction with threads and the XOTcl exit handler
> that I don't understand.
>
> I create a thread from within an object, and release that thread in
> the object's destructor. If I destroy the object directly,
> everything's fine, but if I destroy the object through "Object
> setExitHandler", I get an error. Am I treading into undefined
> behavior? Is there well-defined way to shut down multiple threads?
>
the thread and exit code is a tricky and sensitive area, especially if
it is supposed to work with tcl and the aolserver. below is the somewhat
simplified code (btw., your example works on mac os x without a
problem). In general. there is no need to destroy the objects by hand,
since these are destroyed automatically and the appropriate destroy
methods are executed. also, the destroy order is not completely trivial
in order to be able to execute the destroy methods correctly. i would
not do this by hand.

isn't the default beavior sufficient? it prints:

::a created
thread waits
exithandler
::a destroyed

-gustaf


package require XOTcl
package require Thread

namespace import {xotcl::*}
Class A
A instproc init {} {
  puts stderr "[self] created"
  my set tid [thread::create [subst -nocommands {
    set ::auto_path [list $::auto_path]
    package require XOTcl
    namespace import {xotcl::*}
    Object b
    puts stderr "thread waits"
    thread::wait
  }]]
}

A instproc destroy {args} {
  puts stderr "[self] destroyed"
  thread::send [my set tid] {b destroy}
  thread::release [my set tid]
  next
}

A a
xotcl::Object setExitHandler {puts stderr exithandler}

From: Victor Mayevski <vitick_at_gmail.com>
Date: Tue, 3 Jan 2012 11:47:58 -0800

Thank you Gustaf and Sefan,

Would it be possible to add that functionality into NX core? For example, via:

Obj property {key:constant value}
Obj variable key:constant value

I know I can code it myself but I think programmers would prefer for
it to be a built-in function.

> On Mon, Jan 2, 2012 at 8:28 AM, Stefan Sobernig <stefan.sobernig_at_wu.ac.at> wrote:
> Victor,
>
>
>> Maybe this simple study helps already
>
>
> I just recovered a variation of Gustaf's study which I had used in previous
> projects of mine. The study below differs with respect to enforcing the
> "immutability" (prohibiting vs. preserving state) and adds handling of
> variable unsets. It slightly optimizes over the method dispatch for write
> traces (using ::nsf::set::var), however, it also comes at extra costs
> (doubled variable writes).
>
> It can be easily extended for supporting basic introspection, kinds of
> "/obj/ info immutables" or the like ...
>
> //stefan
>
>
> package req nx
> package req nx::test
> package req nx::trait
>
> ::nx::Class create C {
>  :require trait nx::traits::callback
>  #
>  # Make selected (by default, all currently defined) variables of an
>  # object immutable
>  #
>  :public forward immutable %self traces add
>
>  #
>  # Make selected (by default, all currently defined) variables of an
>  # object mutable (again ...)
>  #
>  :public forward mutable %self traces remove
>
>  :protected method traces {op args} {
>    foreach varName [expr {[llength $args] ? $args : [:info vars]}] {
>      set writeCmdPrefix [list ::nsf::var::set [self] $varName [set
> :$varName]]
>      set unsetCmdPrefix "$writeCmdPrefix; [:callback immutable $varName]"
>      ::trace $op variable :$varName write "$writeCmdPrefix;#"
>      ::trace $op variable :$varName unset "$unsetCmdPrefix;#"
>
>    }
>  }
>  :create c1 {
>    set :x 1
>    set :y 2
>  }
> }
>
> #
> # c1 is mutable ...
>
> #
> ? {c1 eval {set :x}} 1
> ? {c1 eval {set :y}} 2
> ? {c1 eval {set :x 5}} 5
> ? {c1 eval {set :x}} 5
> ? {c1 eval {unset :y; set :y}} {can't read ":y": no such variable}
> ? {c1 eval {set :y 4}} 4
>
> ? {c1 eval {set :z 3}} 3
>
> #
> # c1 becomes immutable ...
>
> #
> c1 immutable
>
> ? {c1 eval {set :x}} 5
> ? {c1 eval {set :y}} 4
> ? {c1 eval {set :x 1}} 5
> ? {c1 eval {set :x}} 5
> ? {c1 eval {unset :y; set :y}} 4
> #
> # Subsequent unsets are handled ...
> #
> ? {c1 eval {unset :y; set :y}} 4
> ? {c1 eval {set :y 2}} 4
>
> ? {c1 eval {set :z 3}} 3
>
> #
> # c1 becomes mutable (again ...)
> #
>
> c1 mutable
>
>
> ? {c1 eval {set :x}} 5
> ? {c1 eval {set :y}} 4
> ? {c1 eval {set :x 1}} 1
>
> ? {c1 eval {set :x}} 1
> ? {c1 eval {unset :y; set :y}} {can't read ":y": no such variable}
> ? {c1 eval {set :y 2}} 2
> ? {c1 eval {set :z 3}} 3
> _______________________________________________
> Xotcl mailing list
> Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Sat, 16 Oct 2004 00:42:16 +0300 (EEST)

On Fri, 15 Oct 2004, Schofield, Bryan \(GE Transportation\) wrote:

>
> xol - Yet another logging framework. But since this is object oriented,
> this package provides some features that are not available in other
> packages. Foremost, the ability to use "Formatter" and "Receiver"
> objects. For example, the following simple line:
> $logger warn "Ack! Foo" could be able to log to file or console,
> package the message up as XML and send it over the network, or even feed
> an RSS stream depending on the formatter & receiver the logger is using.
> So far, I've only written a simple formatter and output channel
> receiver, but this is all possible.

I've been doing some logging using filters, actually. Kind of "separation
of concerns". Methods themselves concentrate on just getting functionality
right, and the filters 'slice in' and do logging.

> xout - a unit testing framework. I know, I know, tcl already provides
> one, tcltest. But I found tcltest to be too cumbersome and clunky. I'd
> write some tests, but maintaining those tests often was neglected
> because of the amount of programming overhead needed to write complex
> test cases. xout (X Out) simplifies unit tests. xout is only a
> framework, so I wrote graphical utility "xam" (think Exam) that puts
> xout to work. It is what I'm using these days to run my unit tests.

This sounds interesting.

> I mention all of this because if other have some handy xotcl packages,
> I'd be interested in creating a formal xotcllib project. Perhaps
> something at sourceforge. I'll be making these available soon either
> way.

I think atm from myself I could mostly offer the caching filter object,
which is already on the Wiki in some form or other, and maybe a couple of
other things if and when I get them ready and am allowed to release them.

Anyway, that all sounds pretty nice.

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

From: Michael A. Cleverly <michael_at_cleverly.com>
Date: Thu, 17 Apr 2003 11:47:26 -0600 (MDT)

On Thu, 17 Apr 2003, Gustaf Neumann wrote:

> This is the semantics of variable traces in tcl (the trace is called afted the fact).
> It is possible to keep shadow-values of the variable contents and to restore
> the variable after a write operation to the original content, but my feeling was
> that the purpose was rather trapping unwanted access than prohibiting it...

I understand now. Thanks. :-)

Michael

From: Victor Mayevski <vitick_at_gmail.com>
Date: Thu, 20 Jan 2011 15:09:13 -0800

Excellent. Thank you Gustaf.

On Wed, Jan 19, 2011 at 4:50 AM, Gustaf Neumann <neumann_at_wu.ac.at> wrote:
> Am 19.01.11 10:19, schrieb Victor Mayevski:
>>
>> 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]?
>>
> I assume, you want to obtain a fully qualified variable handle for an
> instance variable. Essentially, it works in nx very similar to XOTcl.
> See below for the method "bindvar" which obtains the fully
> qualified name and shows its usage in the context of Tk.
>
> -gustaf neumann
>
> ==================================================
> #
> # Tiny Tk example with bindvar and callback
> #
> # -gustaf neumann
>
> package require nx
> package require Tk
>
> nx::Class create Callbacks {
>  #
>  # A small support class to ease syntactically the reference to
>  # instance variables and the registration of callbacks.
>  #
>  :method bindvar {name} {
>    :require namespace
>    return [nx::self]::$name
>  }
>  :method callback {name args} {
>    return [list [nx::self] $name {*}$args]
>  }
> }
>
> nx::Class create Myclass {
>
>  #
>  # A sample application class that creates a text entry field bound
>  # to an instance variable. When the provided button is pressed, the
>  # content of the variable is placed into an additional output label.
>  #
>
>  :mixin Callbacks
>
>  :public method button-pressed {} {
>    .label configure -text ${:myvar}
>  }
>
>  :method init {} {
>    wm geometry . -500+500
>    pack [label .title -text "Type something and press start button...."]
>    pack [entry .text -textvariable [:bindvar myvar]]
>    pack [label .label]
>    pack [button .button -text start -command [:callback button-pressed]]
>  }
> }
>
> Myclass new
> ==================================================
>
>
> --
> Univ.Prof. Dr. Gustaf Neumann
> Institute of Information Systems and New Media
> WU Vienna
> Augasse 2-6, A-1090 Vienna, AUSTRIA
>
> _______________________________________________
> Xotcl mailing list
> Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
>

From: Adrian Wallaschek <adrian_wallaschek_at_be.ibm.com>
Date: Mon, 9 Dec 2002 19:05:21 +0100

Problem:

the build for AIX fails multiple times: mainly around building the shared
libraries.


Ok, I've worked a little bit:

the following issues came up:

- the choice of ALLOCA is not good vor Visual C/C++ 5.0. Choosing MALLOC
seems to be good and should be good for all IBM compilers
- the compilers were formerly versioned with hex codes now they are with
decimal codes which regrettably sabotages any scalar comparison so #if
__IBMC__ >= 0x306 won't work. This makes it hard to distinguish between
various IBM C compilers. If you insist compare only with = not with > or <.
- the shared library configuration is not correctly used in the makefiles.
see description below

I am currently collecting issues. With some help of the
creators/maintainers and probably somebody who gives them access to an AIX
box (sorry I cannot) we'll port correctly to AIX.

The thing with the shared libraries doesn't apply to AIX only but to all
systems like this.

What happens: The anatomy of the TCL (original within the TCL
configure/make system) is:

$(SHLIB_LD) $(SHLIB_LD_FLAGS) objects .... $(SHLIB_LD_LIBS)

The TCL configure sets the SHLIB_LD_LIBS to either being empty or ${LIBS}
in case the loader need the linkable libraries to generate the shared
library.

Now TCL would be linked like "shell + tcl-lib + dl-lib + c-lib + m-lib +
bsd-lib" (cited from memory not sure about the mathlib). So to create the
shared-lib tcl8.4 it uses "-ldl -lc -lm -lbsd" as value for $(LIBS)

Now XoTCL set the variable TCL_LIBS with those additional libs. This is
nice but ends here because the SHLIB_LD_LIBS needs LIBS

So the Makefile of XoTCL requires a line like:

LIBS=-ltcl8.4 $(TCL_LIBS)

If this is not set with the list of libraries needed to link an application
with XoTCL then the configuration in SHLIB_LD_LIBS is useless! AIX and some
other OSes need these libraries mentioned. TCL provides the list needed for
TCL, add TCL itself and any others you need yourself and set those to LIBS.

Now I suppose the tcl8.4 can also be taken from some variable. Also it
requires the either the LIBS or the SHLIB_LD_FLAGS to be extended with the
-L option to specify from where to take the libtcl8.4.so.

Currently my XoTCL library links correctly and is loadable nicely, but all
the changes are manually hacked. I need to redo in a more strucured way
later.

anyone offering help/support?


Regards,
         Adrian Wallaschek

"Just when you think, life can't possible get worse,
it suddenly does!"
The Hitchhiker's guide to the galaxy - Douglas Adams


                                                                                                                               
                      Uwe Zdun
                      <uwe.zdun_at_wu-wien To: Adrian Wallaschek/Belgium/Contr/IBM_at_IBMBE
                      .ac.at> cc:
                                               Subject: Re: [Xotcl] Announcing XOTcl 1.0
                      09.12.02 17:18
                                                                                                                               
                                                                                                                               




Hi Adrian,

hast du das an die Liste geschickt? Es sieht so aus, als wäre es nur an
mich
gegangen.

Sorry, das ich deine andere Mail noch nicht angeschaut hatte; ich war übers
Wochenende nicht verfügbar ...

Ich bin auch nicht sicher, was das Problem ist; ich hab ja auch keinen
Access
zu einem AIX system, vielleicht kannst du es etwas näher spezifizieren und
an
die Liste schicken? Ich weiss nicht, ob Gustaf Neumann noch an ein AIX
System drankommt, dass würde das Problemsuchen vereinfachen ...

Gruss,

Uwe



On Monday 09 December 2002 03:58 pm, you wrote:
> Hi there!
>
> Anybody playing with XoTCL on an AIX 4.3.x?
>
> XoTcl is giving me a hard time to get it working. I'd like to get in
touch
> with somebody who had some success.
> So far I get a far as getting a shared lib created but when loading it,
it
> core dumps the TCL.
>
> Any hints/clues?
>
> Using AIX 4.3 with Visual C/C++ 5.
>
> In the meanwhile I'll try getting a gcc together.
>
> Regards,
> Adrian Wallaschek
>
> "Just when you think, life can't possible get worse,
> it suddenly does!"
> The Hitchhiker's guide to the galaxy - Douglas Adams

--
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: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Mon, 22 Dec 2008 22:58:30 +0100

Bernard Devlin schrieb:
>
> However, following the main XOTcl tutorial
> (http://media.wu-wien.ac.at/doc/tutorial.html) in the IDE, I've got a
> problem. After running 'do it' on each stage of the tutorial, when I
> get to this line:
>
> set fb [bayernMunich newPlayer -name "Franz Beckenbauer" \
> -playerRole PLAYER]
>
> I get an error. Here's the stack trace:
>
> ::bayernMunich::__#WZ: unable to dispatch method 'name' during ...
>

Dear Bernard,

a first challenge is to interprete tcl's error messages. In the example you
gave, it says, that the player that you create (object
"::bayernMunich::__#WZ")
does not have a method called "name". In the example in the tutorial,
"name" is an attribute defined by ClubMember. XOTcl calls publically
accessible attributes "parameters" and creates for those accessor
methods.

Given the definitions

  Class ClubMember -parameter {{name ""}}
  Class Player -superclass ClubMember -parameter {{playerRole NONE}}

one can create a Player with the name "Kaiser Franz" with the command

   Player create p1 -name "Kaiser Franz"

Note that all tokens starting with a "-" are actually methods,
which are called during initialization (after allocation of the object,
but before init is called) with the provided arguments .
 
So, in your case, i guess, you have either omitted the name-definition
on ClubMember, or omitted the "superclass" on Player.

best regards
-gustaf neumann

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Mon, 22 Jan 2001 14:13:38 +0200 (EET)

[~] package require XOTcl
0.83
[~] Class Foo
Foo
[~] Foo instproc init {} {
>Bar [self]
>}

[~] Foo instproc destroy {} {
>puts rm
>}

[~] Class Bar
Bar
[~] Bar instproc init {blah} {}

[~] Foo ob
rm
no value given for parameter "blah" to "init"
while evaluating {Foo ob}
[~] Foo uh
rm
Segmentation fault


The "Bar [self]" line was actually a bug in my own code (oops, forgot
"new"), but it's interesting to note that it resulted in a segmentation
fault.


         - ---------- = = ---------//--+
         | / Kristoffer Lawson | www.fishpool.fi|.com
         +-> | setok_at_fishpool.com | - - --+------
             |-- Fishpool Creations Ltd - / |
             +-------- = - - - = --------- /~setok/

From: Kristoffer Lawson <setok_at_scred.com>
Date: Thu, 5 Aug 2010 16:48:48 +0300

One more cheeky idea, which might be too hacky. You can actually check what was used to call a method (see [info frame]). If the dash values were passed as-literals, then handle them as options, otherwise as values. This is probably quite un-Tclish, and possibly confusing, but I believe it is possible.

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

From: Gustaf Neumann <neumann_at_wu.ac.at>
Date: Tue, 22 Mar 2011 20:22:10 +0100

The updated version of xotcl/nx git works now correctly on all tests
with the trunk version of Tcl from fossil -gn

Am 21.03.11 12:02, schrieb Gustaf Neumann:
> The updated version in git compiles now nicely and runs all regression
> tests except the coro-test. Inside a coroutine, we get now a crash,
> the stack frame with the variables is apparently missing. I have
> deactivated the coro-test for the time being.

-- 
Univ.Prof. Dr. Gustaf Neumann
Institute of Information Systems and New Media
WU Vienna
Augasse 2-6, A-1090 Vienna, AUSTRIA