Weblog Page

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Mon, 15 Oct 2001 20:28:53 +0200

Fellow XOTcl community,

here comes the annoucemnt of XOTcl 0.9.

best regards
-gustaf neumann
.uwe zdun
==================================================================================

Announcing XOTcl 0.9
********************

WHAT IS XOTCL?

  XOTcl is an object-oriented extension of Tcl that was derived from
  OTcl. In short, XOTcl tries to provide a highly flexible,
  reflective, component-based, and object-oriented environment. It
  integrates language support for high level concepts which are not
  found in other languages, with reasonable performance. It prevails
  the Tcl programming style and the dynamic/introspective nature of
  the language, rather than introducing other language's styles and
  rigidness (such as C++) into Tcl.


RECENT CHANGES relative to 0.85 are:

  - new functionality:

    * Per object filters: in addition to traditional filters
      (which are called now "instfilters") one can define now
      filters per objects as well. XOTcl supports now
      the following interceptors: per class filters and
      mixins (called instfilters and instmixins),
      and per object filters and mixins (called filters and
      mixins).

    * filterguards:
      This is a new mechanism to specify when filters
      should be applied (see tutorial and language reference).

    * Namespace transparency for XOTcl procs and instprocs:
      In previous releases, the programmer was responsible
      to use :: prefixes in order to safely address Tcl commands
      from XOTcl (e.g. an instance of a class defining
      "set" had to use ::set). Now, the namespaces of Classes
      and objects are ignored for command resolutions avoiding
      potential interferences.

    * Namespace on demand:
      XOTcl objects allocate namespaces on demand
      (e.g. when procs or child objects are defined).

    * XOTcl is now a "well behaved" extension:
      When libxotcl is loaded everything resides in
      the ::xotcl namespace. Use "namespace import xotcl::*"
      to import the global commands (xotclsh and xowish do
      this per default).

    * Improved parameter settings (see tutorial)


  - Speed improvements:
    * Significant speedup through the more consequent use
      of Tcl_Objs for accessing classes and objects.

    * Methods for append/lappend/array etc. are about 3 times
      faster through the use of insttclcmd (see below)

    * Parameter methods:
      Methods for accessing parameters are now 4 to 5 times faster.
      In the following example, "name" and "age" are parameters:
        Class Person -parameter {{age 0} name}
        Person p1 -age 99 -name gustaf
        puts [p1 age]
      setting and retrieving of parameters has now roughly the same
      speed as the set methods


  - Reduced memory consumption for objects and classes:

    The size of XOTclObject structure went from 172 bytes
    to 48 bytes by

      * allocating assertion structures and namespaces on demand, and
      * by and by omitting in the default setup metadata

    10 thousand XOTcl objects consume now on a 32bit machine
    about 2 MB of memory in total (including whatever Tcl needs
    for commands etc)


  - new Class methods
    * instparametercmd: define a new getter/setter for instance
      variables for instances of used class
    * insttclcmd: evaluate an Tcl command in the context of an object

  - new Object methods:
    * parametercmd: define a new getter/setter for instance
      variables for an object
    * configure: method to call a series of methods on an object
      e.g.
       Object o1
       o1 configure -set x 1 -set y 2


  - new subcommands for info method:
    * info methods:
      returns procs, commands and mixins, accepts
      modifiers: -noprocs, -nocmds, -nomixins
    * info instfilters
    * info filter
      accepts new modifiers: -guards, -order




  - fixes:
     * propagation of return codes (e.g. ... return -code continue ...)
       which is needed for Tk event maps

     * various actiweb fixes (agent migration was broken)

     * improved documentation


  - Support for AOLserver:
 
    XOTcl is now prepared for use in the AOL-server. The stubs for
    AOL-server are integrated in XOTcl (many thanks to
    Zoran Vasiljevic). The required patch for the AOL-Server
    is available from http://media.wu-wien.ac.at/download.html#aol


  - Stub-library support:

    XOTcl supports now the stub library. This means that
    it is less dependent on particular Tcl implementations.
    The support was quite tricky since some commands used by XOTcl
    (like Tcl_IncrObjCmd, Tcl_UpvarObjCmd, ...) are
    not exported by the stub library, and the solution
    has to work in the multithreaded AOL-server environment)



  - potential incompatibilities:
    * "[self] next" is gone, use "next" instead.
    * The access of instance variables through the
      tcl-set command is deprecated and works only
      when the namespace is created. Instead of
         Object o
         set o::x 1
      use
         Object o
         o set x 1
    * procsearch returns a different format (see Changelog)



MORE INFO
  General and more detailed information about XOTcl and its components
  can be found at http://www.xotcl.org


Best regards,

Gustaf Neumann
Uwe Zdun

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Mon, 12 May 2003 17:10:27 +0200

On Monday 12 May 2003 16:42, MichaelL_at_frogware.com wrote:
> Look at the following code, which is meant to be a stripped-down and
> simplified version of my real code:

 hi Michael,

 this mail ist the fastest to answer:

>
> Class DatabaseMgr
> DatabaseMgr instproc openDatabase {} {
> Database [self]::db
> }
>
> Class Database
> Database instproc init {} {
> puts "init [self]"
> }
>
> Database instproc destroy {} {
> puts "destroy [self]"
> }

In the method above, you are overwriting the "Object instproc destroy",
which initiates the physical destroy. Add a "next" as in:

Database instproc destroy {} {
    puts "destroy [self]"
    next
}

>
> DatabaseMgr dbmgr
>
> dbmgr openDatabase
>
> dbmgr::db info class
> dbmgr::db destroy
> dbmgr::db info class
>
> The second call to "info class" should fail but doesn't. That's because
> the object isn't actually destroyed. (In my real code the objects have
> dynamically generated names; I used the static names to simplify the
> example.)
>
> The above style is similar to the style of code used in xoRBAC (eg,
> factories & self-destruction) so I'd be surprised if it too wasn't leaking
> objects.
>
> After the above code run this code:
>
> dbmgr info class
> dbmgr destroy
> dbmgr info class
>
> Now both dbmgr and dbmgr::db are destroyed--but note that the "destructor"
> gets called twice at this point!

 since dbmgr::db exists at this point, the destroy of dbmgr will trigger
 the destroy of the child objects. That is ok.

 best regards
-gustaf

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

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Thu, 27 May 2004 12:16:49 +0200

On Thursday 27 May 2004 09:55, Nicolas Boretos wrote:
> Hello,
>
> Have had a chance to set up the actiweb framework and now trying out the
> examples;-)
> This is really good stuff....

 thanks.

> ...
> {Object 'c1' unknown} {}
>
> I would have expected that a text representation would have been
> returned via .../c1
> ...web-c1 returns the html facade as expected...

 The example is meant as an example, where the counter objects
 are accessed through a facade only.

> Is this because we dont export to the receiver class, or am I missing
> something else?

 correct. only "exported" objects can be called via HTTP, and only
 the exported procs of the exported objects can be called.
 This can be done via a the following magic lines:

   # export the object
   receiver exportObjs c1
   # provide behavior to (a) export procs, (b) a stragey for sending back the result
   # and (c) a persistency berhavior
   c1 mixin {WebObject Send=PlainString Persistent=Eager}
   # export the method increment
   c1 exportProcs increment

 best regards
-gustaf neumann

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

From: Damon Courtney <damon-xotcl_at_tclhome.com>
Date: Tue, 2 Nov 2004 14:26:56 -0600 (CST)

    I figured as much. I guess I'll just do import the commands into the
root namespace. It doesn't really bother me, but some of the other
Tcl'ers are real sticklers about namespacing everything. I just use
what's best. 0-]

    So, does this still constitute a bug then, or should I just chalk it
up to expected behavior?

Thanks,

Damon

> 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
>>
>
> _______________________________________________
> 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: Wed, 07 Nov 2007 17:26:45 +0100

Shishir Ramam schrieb:
> Not sure if this should be considered expected behaviour - but does
> the type have to be defined before declaration?
yes, the checking predicate is determined currently at definition time;
if the specified "type" is not an existing class, the checker uses the
"string is ..." as test method, therefore the error message.

All checking is in tcl, so it can be redefined, if you want (see method
check_single_value
of ::xotcl::Attribute in predefined.xotcl).

However, you can define also the slots after the class is defined:

  Class DerivedA -superclass Base
  Class DerivedB -superclass Base

  DerivedA slots { Attribute connects_to -multivalued true -type DerivedB }
  DerivedB slots { Attribute connects_to -multivalued true -type DerivedA }

This will work out of the box....

best regards

-gustaf neumann

From: Gustaf Neumann <neumann_at_wu.ac.at>
Date: Tue, 09 Feb 2010 21:41:32 +0100

Dear Koen,

thanks for the feedback. TclObjInterpProcCore() came in tcl 8.5 and allows
a much faster dispatch for scripted methods. Unfortunately, it is gone
in 8.6
(replaced by a NRE variant, which would require many more changes).
i built a version of 1.6.5 not requireing TclObjInterpProcCore() and
uses the slower 1.6.1-like method dispatch when compiled against 8.6.
This version will eventually get released as 1.6.6

all the best
-gustaf neumann

Am 09.02.10 17:37, schrieb Koen Danckaert:
> Dear Gustaf,
>
> I have seen the slides on XOTcl 2.0 and am looking forward to it :-)
> However, in the meantime, I wanted to get an existing version of XOTcl
> working with Tcl 8.6.
>
> XOTcl 1.6.5 does not work with Tcl 8.6 because it requires a function
> which is not present in Tcl8.6 anymore: TclObjInterpProcCore().
>
> So I switched back to an earlier version of XOTcl (1.6.1), which
> apparently does not require this function.
>
> I still had to apply some small modifications:
> - replacing interp->errorLine by Tcl_GetErrorLine(interp)
> - adding some "const" qualifications
> but finally managed to compile XOTcl 1.6.1 with Tcl8.6.
>
> If you're interested, I can send you the patch.
>
> Thanks for all the good work on XOTcl !
>
> Best regards,
> Koen Danckaert
>
>
> Gustaf Neumann wrote:
>> Dear Koen,
>>
>> we are busy working on xotcl 2.0, which works for tcl 8.5 and tcl 8.6
>> (we will most probably not be able to make 2.0 work with tcl 8.4;
>> the 8.4 support is still in the 2.0 code base, but getting it to work
>> with 8.4 would require a lot of work, so we will skip it).
>>
>> i am currently in the midst of reworking slots, which is the
>> last biggy before the release (which i hoped to get finished
>> by end of 2009)). There will be some more polishing on
>> the interfaces and the code, documentation is at an early
>> state, so end of q1 seems in reach for the release.
>>
>> xotcl 2.0 is quite different from xotcl 1.*, but there
>> is an xotcl 1.* layer available, which is highly backwards
>> compatible (i have tested it e.g. against xotcl-core and xowiki
>> inside openacs, about 46000 lines of code). in case, you have
>> not seen the slides an the xotcl 2.0 paper, drop me a note.
>>
>> if you have interest on getting access to the development version
>> of xotcl 2.0, i can give you access to the git repository.
>>
>> -gustaf neumann
>>
>> Am 08.02.10 18:17, schrieb Koen Danckaert:
>>> Dear XOTcl developers,
>>>
>>> I'm trying to use XOTcl (1.6.5) with Tcl8.6.
>>>
>>> Apparently XOTcl does not compile with Tcl8.6, but on Linux, I can
>>> get it to work by using a version compiled for Tcl8.5.4.
>>>
>>> However, this is not the case on Windows: loading XOTcl will make
>>> Tcl8.6 crash there.
>>>
>>> I also tried to use the xotcl165.dll provided by Activestate in the
>>> Tcl8.6b1 distribution. This seems to work with Tcl8.6b1 indeed, but
>>> not with newer versions of Tcl fetched from CVS (which I need).
>>>
>>> Is it possible today to use XOTcl in a recent Tcl8.6 ?
>>> Or are there any plans to update XOTcl ?
>>>
>>> Best regards,
>>> Koen Danckaert
>>> _______________________________________________
>>> Xotcl mailing list
>>> Xotcl_at_alice.wu-wien.ac.at
>>> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
>>
>>

From: Sheik Yussuff <sheik_at_carib-link.net>
Date: Sat, 15 Dec 2001 11:28:35 -0400

Below is nonsensical sample code to illustrate a problem I
am having with filters. On invocation of:
   a mb (see code section below)
1. Object a is sent the message mb(not an instproc) of A
2. Filter af of object a intercepts and
   dispatches message mbb to object b
3. Filter bf of object b intercepts and
   redispatches message maa to object a
   This time the filter af does not intercept message maa!!
   The message maa is sent directly to object a with
   the resulting error: object a unable to dispatch
   method maa.

Can anyone assist me in explaining what is happening here?
------------------------------------------------------------
#Code: Win 98 version 0.91; got same problem with ver 0.85 3 months ago.

Class A -parameter {delegate}

A instproc af args {
  set method [self calledproc]
  if {[[self] exists delegate]} {
    set del [[self] set delegate]
    if {$method == "maa"} {
      return [eval $del mbb]
    }
    if {$method != "ma"} {
      return [eval $del $method $args]
    }
  }
  next
}

A instfilter {af}

A instproc ma args {
  puts "method ma of A"
}


Class B
B instproc bf args {
  set sender [self callingobject]
  set method [self calledproc]
  puts "method is: $method"
  if {$method == "mb"} {
    
    return [eval $sender maa]
  }
  next
}

B instfilter bf

B instproc mb args {
  puts "method mb of B"
}

B instproc mbb args {
  puts "method mbb of B"
}

B b
A a
a delegate b
#a ma ; #works ok
a mb

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Fri, 24 Jan 2003 17:57:19 +0200 (EET)

On Fri, 24 Jan 2003, Gustaf Neumann wrote:

> Certainly, when all references are gone (stringified, only string callbacks
> point to an object) the object will be destroyed.... still, we would
> have the choice btwn traditional objects (that can be used safely
> in callbacks) and refcounted objects, there are many cases,
> where this might be useful ... i my code, i have not experienced
> the problem with unneeded objects (people that grew up with
> Java rather than C might thing differently)

I've actually experienced fewer problems with manual destruction than
I imagined, but I do still stumble across problems every now and then
and in a way it is an extra headache to have to work out the proper
destruction point. I think it is a good idea to do what you're doing with
the refcounts and to have all the facilities there for auto-destruction --
at least for when and if Tcl is ever able to provide a way to be sure
that references last for as long as needed.

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

From: Kristoffer Lawson <setok_at_scred.com>
Date: Sun, 29 Aug 2010 17:51:45 +0300

On 29 Aug 2010, at 14:54, Gustaf Neumann wrote:

> - The call "$targetclass info ..." was then letal especially
> with the standard unknown handler of the metaclass:
> xotcl belived incorrectly that "info" is unknown, and
> since an "unknown" call on a class (here $targetclass)
> creates an object, it was creating the object "info"
> as instance of that class, and the nightmare turned
> even worse.

Ah yes, this confirms my suspicions of what was going on. I'll report this to Apple to try and get them to upgrade the included XOTcl on OS X. I'm trying to keep my own work in sync with what is available on OS X to ease any deployment I might do.

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

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Fri, 19 Nov 2004 02:38:32 +0100

> 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.)

 Hi Michael,

 the problem was the [self callinglevel] in the nesting uplevel calls.
 Tcl reports in the nesting case a [info level] of 2 although there
 are three levels on the stack. xotcl tries to skip filters and mixin-frames
 and it pointed incorrectly to the invocation frame and not to the variable
 frame. I have fixed the problem at least for your example, all regressions
 tests continue to work. If you come up with more such examples, please
 let me know.

 the problem is fixed in the current working release and should be
 available soon.

 best regards
-gustaf neumann

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