Weblog Page

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Mon, 29 Oct 2007 15:30:01 +0100

You are right,

there seems to be a problem with default values for nonpos args
in tcl 8.5 after the var reform changes. i will look into the problem
today evening or tomorrow morning.

best regards
-gustaf neumann



Murr, Florian schrieb:
> Dear XOTcl-guys!
> I tried to upgrade from Tcl8.4+XOTcl1.5.3 (all my projects worked fine
> here!) to Tcl8.5b1, but my projects won't run due to some XOTcl
> problems.
> The following snippet is extracted from my project and I tested it with
> XOTcl1.5.5 (from WinTclTk) and XOTcl1.5.6 from ActiveState-Teacup.
> But both failed with the same error message.
> My guess: Non-positional Arguments don't work!
>
> #
> ************************************************************************
> *****
> # The script:
>
>
> Class X
> X instproc ListOfStringsOption {{-default {}} {-cb {}} name} {
> if {$cb eq {}} { set cb "::set ::$name " } ;# global variable
> eval $cb \$default
> }
> ::X create x1
> ::x1 ListOfStringsOption uu
>
>
> #
> ************************************************************************
> *****
> # Error message:
> can't read "default": no such variable
> while executing
> "::set ::uu $default"
> ("eval" body line 1)
> invoked from within
> "eval $cb \$default"
> (procedure "ListOfStringsOption" line 5)
> ::x1 ::X->ListOfStringsOption
> invoked from within
> "::x1 ListOfStringsOption uu"
>
>
> _______________________________________________
> Xotcl mailing list
> Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
>

From: Schofield, Bryan \(GE Transportation\) <"Schofield,>
Date: Tue, 2 Nov 2004 14:59:58 -0500

because "self" is a command in the xotcl namespace. you will also find that there are others, such a "my"

If you don't import xotcl, you end up with source that looks like this:

::xotcl::Class foo
Foo instproc bar {} {
   puts "[::xotcl::self] is a [::xotcl::my info class]"
}


I'd suggest, do something like the following...

package require XOTcl 1.3
namespace eval fooPackage {
   namespace import ::xotcl::*
   Class Foo
   Foo instproc bar {} {
     puts "[self] is a [my info class]"
   }
}


hope that helps.
-- bryan

> -----Original Message-----
> From: xotcl-bounces_at_alice.wu-wien.ac.at
> [mailto:xotcl-bounces_at_alice.wu-wien.ac.at]On Behalf Of Damon Courtney
> Sent: Tuesday, November 02, 2004 2:23 PM
> To: xotcl_at_alice.wu-wien.ac.at
> Subject: [Xotcl] [Fwd: Bug with namespace'd Class?]
>
>
> Why does this not work?
>
> package require XOTcl
>
> ::xotcl::Class Foo
>
> Foo instproc bar {} {
> puts "SELF = [self]"
> }
>
> Foo foo
> % Foo foo
> ::foo
> % foo bar
> invalid command name "self"
>
>
> But, if I "namespace import ::xotcl::*" and make the
> class with just
> the Class command (not ::xotcl::Class), it works.
>
> Any ideas?
>
> D
>
> PS: Windows, Tcl 8.4.3, XOTcl 1.3.1
>
> _______________________________________________
> Xotcl mailing list
> Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
>

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Mon, 12 May 2003 22:14:52 +0200

On Monday 12 May 2003 20:04, Uwe Zdun wrote:
> Looking through this code again, the ::xotcl::lib is not really used in
> XOTcl's code anymore ...

 hmm? The line after the error message says:
    set ::auto_path [concat $::xotcl::lib $::auto_path]
 if the variable is not set, you get the error message there.
 it is certainly possible to set a default value, say from the
 configure prefix....

 The more sensible change is to use the patch below, which will
 be ok, when you load xotcl via xotclsh, but will not find xotcl
 packages, when xotcl is loaded via tclsh; try:

  tclsh
  package require XOTcl
  namespace import ::xotcl::*
  package require package

 Currenty, xotcl does a patch checking in C (findXOTcl.c) and
 in tcl (predefined.xotcl). my hope was rather to get rid of the c-code...
 The background of this code is as follows:
   - tcl searches the libraries in auto_path and the subdirs of that.
   - with xotcl i would like the get one more level to organize the
     xotcl packages more nicely.
   - therefore the xotcl library is added to the auto_path.
 We would not need the library, when we assemble a large
 tclIndex.tcl file in the xotcl directory. Maybe that is the better
 way... we will check this more carefully...

 best regards
-gustaf

-- predefined.xotcl~ 2003-04-24 22:49:14.000000000 +0200
+++ predefined.xotcl 2003-05-12 21:48:20.000000000 +0200
_at_@ -357,12 +357,9 @@
        }
     }

- if {![info exists success]} {
- puts stderr "Cannot locate the XOTcl library on your system!"
- return 0
+ if {[info exists ::xotcl::lib]} {
+ set ::auto_path [concat $::xotcl::lib $::auto_path]
     }
- #puts stderr "[info exists success] <$::xotcl::lib>"
- set ::auto_path [concat $::xotcl::lib $::auto_path]

     #
     # and forget all "xotcl::" packages in Tcl's packageTable so that they

-- 
Univ.Prof. Dr.Gustaf Neumann
Abteilung für Wirtschaftsinformatik
WU-Wien, Augasse 2-6, 1090 Wien

From: Matthew Smith <chedderslam_at_gmail.com>
Date: Wed, 7 May 2008 12:54:20 -0500

I am trying to learn xotcl classes and their use from the xotcl-
core.pdf examples. Most of the code examples look like they are being
entered into a console while I am trying to write tcl files and then
run them.

Here's the class definition:
------------------------------------------------------------
package require XOTcl
::xotcl::Class Stack
Stack instproc init {} {
# Constructor
my instvar things
set things ""
}

Stack instproc push {thing} {
my instvar things
set things [concat [list $thing] $things]
return $thing
}

Stack instproc pop {} {
my instvar things
set top [lindex $things 0]
set things [lrange $things 1 end]
return $top
}

---------------------------------------------------------
How do I access the class methods(i guess they are called) from within
the tcl file?
The examples show this:
--------------------------------------------------------
# Create Object s1 of class Stack
% Stack s1
::s1
% s1 push a
a
% s1 push b
b
% s1 push c
c
% s1 pop
c
% s1 pop
b
# Delete object s1
s1 destroy
--------------------------------------------------------

I have tried this:
set s1 [Stack]
puts $s1

Which outputs:
::Stack

But I'm not sure where to go from here...
Thank you.

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Tue, 18 May 2004 21:45:22 +0200

Hi there,

> Object instproc insert_mixin {mixin_list} {
> my mixin [append mixin_list " " [my info mixin]]
> }

with names like mixinappend, mixinprepend for mixins, filters,
instmixins, instfilters we would introduce a large number of
methods, which do more or less the same.

what do you people think about the following "interceptor"
method: it is more verbous, but much more powerful as well; it
allows appending/prepending/inserting at a certain position and
deletion of all kinds of interceptors:

================================================
  Object instproc interceptor {op kind name {pos 0}} {
    switch -exact $op {
        add {my $kind [linsert [my info $kind] $pos $name]}
        delete {
            set old [my info $kind]
            set p [lsearch -glob $old $name]
            if {$p>-1} {my $kind [lreplace $old $p $p]} else {
               error "$name not in $old"
            }
        }
    }
    puts "$kind list: [my info $kind]"
  }

  Class A
  Class B
  Class C

  Object o
  o interceptor add mixin A
  o interceptor add mixin B
  o interceptor add mixin C end
  o interceptor delete mixin *A
================================================
The output of this script is:

mixin list: ::A
mixin list: ::B ::A
mixin list: ::B ::A ::C
mixin list: ::B ::C

best regards
-gustaf neumann

-- 
Univ.Prof. Dr.Gustaf Neumann
Abteilung für Wirtschaftsinformatik
WU-Wien, Augasse 2-6, 1090 Wien

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Sun, 9 Mar 2008 01:17:29 +0200

On 7 Mar 2008, at 15:56, Stefan Sobernig wrote:

> Dear XOTcl community!
>
> XOTcl is now available in the official Debian sid/unstable suite of
> packages, starting with the most recent release (1.6.0)!
> We are also confident that XOTcl will, therefore, be featured in
> upcoming Ubuntu releases (probably in the second half of the year,
> i.e.
> the post-8.04 release).

Good work, guys. Nice to see it back in there.

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

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Mon, 4 Mar 2002 18:47:47 +0100

On Monday 04 March 2002 18:21, Zoran Vasiljevic wrote:
> > suggestion implemented in C. Actually there is no need
> > in general for using tcl-variables to implement volatile
> > objects (we could handle this on a pop of stack frames),
> > but at least for pure tcl-procs, var traces are the simplest
> > implementation. The current implementation (purely in C)
>
> It is not clear: does the C implementation use internal stack
> for garbage collection or the Tcl-trace variable mechansim?

 the var-trace mechanism

> It is important to know when doing (or not doing!) such
> constructs:
>
> Class foo
> foo instproc test args {}
>
> [foo new -volatile] test ; # object leak ?

 this sets as a side effect a tcl variable in the current
 scope. if the scope is e.g. a tcl proc, it will be
 automatially unset, when the scope is left.

> In case of volatile implementation with var traces,
> one should do:
>
> set bar [foo new -volatile]
> $bar test

 Note, that this is essentially the same as
 above. the call of [foo new] cannot set a
 vartrace on the "bar" variable. The result
 of the "new" is a tcl_obj, and not a variable.
 the tcl_obj is bound to the variable bar...
 so, the magic of the object deletion happens
 via another variable, that is set as a side
 effect. these magic variables are named similarly
 to the object name: in the example

    set bar [foo new -volatile]

 the objname will be ::xotcl::__#1 (or ...__#2, etc),
 the magic variable is __#1. therefore, one can
 refer from the object name to the variable name via

    set vn [namespace tail $bar]
    unset $vn

 will trigger the deletion of the object
 created with new. There is a potential danger
 of name conflics, but if one follows the rule:
 don't start user-variable names with "__",
 everyting will be safe.

 I have used this example with the manual unset
 for explanatory purposes. Under most conditions you will
 not need to unset the magic variable by hand....

 hope that this explains the details.

 best regrads
-gustaf

 

From: Michael Aram <michael_at_aram.at>
Date: Thu, 16 Jul 2015 10:46:14 +0200

Thank you, Stefan.

After fiddling around, it seems (at first sight) that the following snippet
does the trick:

if {[info command ::nx::methodParameterSlot] ne ""} {
  ::nx::MethodParameterSlot method type=sourced_guid {name value} {
    if {![::nsf::is object $value] || [xotcl::Object info instances
-closure $value] eq ""} {
      return -code error "'$value' is not an XOTcl object"
    }
    if {![$value istype ::foo::bar::SourcedGuid]} {
      return -code error "'$value' is not of type SourcedGuid but [$value
info class]"
    }
  }
  ::Serializer exportMethods {
    ::nx::MethodParameterSlot method type=sourced_guid
  }
}

All the best,
Michael

PS: For novices the "mixture" of ::nx and ::xotcl is a bit unexpected, for
example when serializing ::xotcl::MetaSlot on my OpenACS instance, one can
see, that e.g. the superclass of ::xotcl::MetaSlot is ::nx::MetaSlot et
cetera. My intuitive expectation was that both XOTcl 2 and NX exist as
different languages within NSF, but more or less completely isolated from
each other. I suppose the reason is to keep the source code required to
support the "legacy" XOTcl syntax as small as possible?


On Wed, Jul 15, 2015 at 1:58 PM, Stefan Sobernig <stefan.sobernig_at_wu.ac.at>
wrote:

> Hi Michael!
>
> What is the correct way to port this to XOTcl 2.0?
>>>
>>
> This is most likely not an authoritative answer, I don't have the time
> right now to think this through properly. The following should get you
> going for the time being:
>
> if {[info command ::nx::methodParameterSlot] ne ""} {
> ::nx::methodParameterSlot object method type=sourced_guid {name value
> args} {
> if {![::nsf::is object $value] || [xotcl::Object info instances
> -closure $value] eq ""} {
> error "'$value' is not an XOTcl object"
> }
> if {![$value istype ::foo::bar::SourcedGuid]} {
> error "'$value' is not of type SourcedGuid but [$value info
> class]"
> }
> }
> }
>
> If you plan to co-maintain two code bases (one compatible with 1.6 and the
> other for 2+), then you might want to consider factoring out the value
> checker into a plain Tcl proc and forward/alias to this proc conditionally
> from ::xotcl::nonposArgs and ::nx::methodParameterSlot, respectively.
>
> I leave this as an exercise to you ;)
>
> Let me know whether the above works for you for the time being.
>
> Cheers,
> Stefan
>
> P.S.: I suggest using "return -code error" in your value checker to skip
> one level on the callstack trace reported to the developer, to hide the
> details of the value checker in the reported trace.
>

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Thu, 18 Jan 2001 15:56:49 +0200 (EET)

Is operation of the destroy method documented in more detail
somewhere? What I'm concerned about is how destroy works when method calls
to an object are still active? Obviously if a method itself calls destroy,
the object will appear to exist until the method returns. But can this
method still call other methods?

The difficult question, I suppose, is what happens if say a fileevent is
activated which destroys an object that still has a method running? We are
coming up with some strange errors in our application for just this kind
of situation and I'm wondering if in fact the object if destroys when this
fileevent is run (which would differ from the situation that a method
itself calls destroy -- which still allows the method itself to run
normally). The problem is that exactly replicating this isn't easy. It
pops up in some situations. We get errors like "[self] called after
destroy" apparently in the middle of a method that is still running, the
destroy probably coming from an external influence.

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

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Fri, 17 Mar 2006 12:37:27 +0200

On 16 Mar 2006, at 14:15, Scott Gargash wrote:
>
> > I understand that the
> > operation is actually quite expensive, due to current Tcl internals,
> > but is there any reason why a destructor should be called? If we
> want
> > a method called for a move operation, surely it would be simple to
> > define that a "beingMoved" method is then called.
>
> I'm guessing that xotcl::object's "destroy" method does all the
> heavy lifting (cleaning up the source of the move). What would
> happen if the default move implementation was to change the source
> object's class to xotcl::object before invoking destroy? This way
> it would continue to use the xotcl::object's "destroy"
> implementation for cleanup purposes without invoking all of the
> subclass destroy methods, and derived classes wouldn't perceive
> move as a destroy operation. Would this have bad side-effects?
But I am guessing even this is unnecessary. Why call the destroy at
all? I am confident, without looking at the actual code, that
deallocation of the resources for the 'original' object could be
deallocated without going through the whole destruction procedure.

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