Weblog Page

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Wed, 18 Aug 2004 11:44:02 +0200

Dear XOTcl Community,

i am proud to announce the availability of XOTcl 1.3.0.
Major changes relative to 1.2.0 are:

  - Qualitative Improvements
     * Improved portability:
       + TEA3 compatible build
       + Much more polished configure+makefile (many thanks to
         Jim Lynch for his help)

     * Improved code quality:
       + fixed 2 possible segmentation violations (error handling)
       + fixed free memory reads (many thanks to Zoran Vasiljevic
         for his help with purify)

     * Less intrusive usage of XOTcl components:
       + XOTcl procs and instprocs use now the namespace in which
         they were defined. One can use XOTcl packages without having
         the need to import xotcl globally or to use the xotcl-prefix
         in all xotcl procs/instprocs.

  - Functional Improvements
     * New forwarding mechanisms for fast delegation:
       new methods 'forward' and 'instforward' (many thanks
       to Bryan Schofield for fruitful discussions and suggestions).
       This method is a superset of tclcmd/insttclcmd, which has
       been marked as deprecated. See the tutorial for more details.

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

     * Extended methods filter, mixin, instfilter, instmixin as
       discussed in the XOTcl mailing list. These commands can be
       used more flexibly as follows

             obj mixin same as: obj info mixin
             obj mixin {C1 C2} same as: obj mixin set {C1 C2}
             obj mixin set {C1 C2} sets the mixins for obj
             obj mixin get same as: obj info mixin
             obj mixin add C3 adds a mixin on front of the mixin list
             obj mixin add C3 end adds a mixin at the end the mixin list
             obj mixin add C3 3 adds a mixin at the 3rd position
             obj mixin delete ::C3 removes the mixin from the mixin list

        The same semantics are available as well for filter, instmixin
        and instfilter. This change is fully backward compatible.
        {filter,instfilter,mixin,instmixin}append are deprecated now.


 For more details about the changes, please consult the ChangeLog and documentation.

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

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

From: Martin Matuska <martin.matuska_at_wu-wien.ac.at>
Date: Thu, 15 May 2008 14:18:16 +0200

A single-file Windows binary of Tloona IDE (Tcl editor with OO features
and XOTcl support) is available at:
http://prdownloads.sourceforge.net/wintcltk/tloona-1.3.2-0.exe

In addition, a single-file Windows binary of Tkcon (2.5) with XOTcl
support and font resizing (CTRL+, CTRL-) is available at:
http://prdownloads.sourceforge.net/wintcltk/tkcon-8.5.2-1.exe

The binaries are created with a modified Tkwrap
(http://wintcltk.sourceforge.net/tkwrap.html)

--
WinTclTk - Open Source Tcl/Tk distribution for Microsoft Windows
http://wintcltk.sourceforge.net/
Tloona Tcl/Tk IDE
http://tloona.sourceforge.net/

From: <j_marvin_at_localnet.com>
Date: Mon, 8 Dec 2003 23:32:17 -0500

hi-
i did a zip binary distribution for windows
 <http://media.wu-wien.ac.at/download/xotcl-1.1.0-win32-tcl8.4.5.zip>
xotcl-1.1.0-win32-tcl8.4.5.zip
 
my tcl directory was in c:\tcl . when the install took place it tried
to put xotcl in c:\program files\tcl directory.
since that is not where i originally installed tcl i copied the files
with the file manager back over to c:\tcl and its subdirectories.
i have an environment variable named tcllibpath that points to
c:\tcl\lib\xotcl. i moved the 4 include files over to c:\tcl\include .
the libxotcl1.1.dll resides now in my c:\tcl\lib directory.
 
when i run this code in ASED it prints out "failure" as it is not loaded
properly. I am using version 8.4.
 
set fail [catch [load libxotcl.dll]]
if {$fail} {
puts "failure"
 
}
 
i wanted to expirement with xotcl. i have swig working and know a
little c++ but i thought i'd try out this new way of doing things.
 
please let me know if you can think of any tricks i am not thinking of
to get this to load properly.
i could reinstall TCL to c:\program files\tcl and then reinstall xotcl
from the beginning zip file. Is that necessary?
 
thanks
marvin

 

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Sun, 24 Feb 2008 16:23:18 +0100

Dear XOTcl Community,

XOTcl 1.6.0 is available. This release provides in short:
 - orthogonality improvements for introspection,
 - more introspection methods (one can now e.g. query, into which
   classes a mixin class is mixed into) and
 - performance improvements (some methods are significantly
   faster. e.g. by a factor of 1000 for larger systems).

In addition, the XOTcl source code follows now closer the Tcl
source code guidelines (e.g. variable naming), a few potential
crashes have been fixed.

See below for more details.
Best regards

-gustaf neumann

===============================================

Announcing XOTcl 1.6.0
*************************

We are pleased to announce the availability of XOTcl 1.6.0.

Major changes relative to 1.5.6 are:

   * Provide a uniform interface to the following info subcommands

        <class> info superclass ?-closure? ?pattern?
        <class> info subclass ?-closure? ?pattern?
        <class> info instances ?-closure? ?pattern?
        <class> info instmixin ?-closure? ?pattern?

     The new option "-closure" returns the transitive set of the
     relation (e.g. .. info subclass -closure) returns the subclasses
     and the subclasses of the subclasses. For "info instances
     -closure" the instances of the subclasses are returned as
     well. For more details, please see the language reference manual.
    
     In cases, where a pattern is specified, and the pattern contains
     meta-characters, a list of results is returned matching the
     pattern (like "string match"). When no matching value is found,
     an empty list is returned.

     In cases, where a pattern is specified, and the pattern contains
     no meta-characters, a single value is returned corresponding to
     the specified value. The pattern is used to lookup an object or
     class, such it is not necessary to provide fully qualified
     names). if there is no match, empty is returned. Previously,
     "info superclass" and "info subclass" returned a boolean value
     and performed always a transitive search. Returning "" is more
     consistent and more in line with Tcl.

     Note that "<class> info superclass -closure" is a replacement for
     "<class> info heritage", and "<class> info instances -closure"
     is a replacement for "<class> allinstances". The old commands
     will be marked as deprecated in the near future.

     Please note, that the behavior of the match pattern has
     changed and is therefor not completely compatible with
     prior versions.

   * New info subcommands:

        <class> info instmixinof ?-closure? ?pattern?
        <class> info mixinof ?pattern?

   These info subcommands are used to determine, into
   which classes a mixin class was mixed into.

   These inverse functions of mixin and instmixin are used as well
   internally. These functions help to speed certain operations
   (e.g. superclass, or registering a mixin class) up by a factor of
   1000 (!) or more, when a large number of objects exist.

   This functionality was primarily implemented by Martin Matuska.
   Many thanks!

  * Made the behavior "pattern" in the following calls identical
    concerning wild cards and object lookups

        <object> mixin delete pattern
        <class> instmixin delete pattern
        <class> superclass delete pattern
        <object> info mixin ?pattern?

   * Fix to preserve var traces when copying objects
      (Many thanks to Florian Murr for reporting)

   * Fix problem in Tcl 8.5.* when setting variables
      from C (problem with Tcl_ObjSetVar2()?); many
      thanks to Florian Murr and Neophytos Demetriou
      for reporting)

   * Improved documentation

   * Extended regression tests


 For more details about the changes, please consult the ChangeLog and
 documentation.

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

From: Martin Matuska <martin.matuska_at_wu-wien.ac.at>
Date: Wed, 13 Jun 2007 13:25:19 +0200

XOTcl is included in the Windows distribution *WinTclTk*.
It includes XOTcl-related packages:

    * XOTcl v1.5.3
    * xotclexpat
    * xotclgdbm
    * xotclsdbm
    * additional XOTcl libraries (e.g. xml, storage, etc.)
    * XOTclIDE

The distribution is available under the following URL:
http://wintcltk.sourceforge.net

A single-file wrapper with XOTcl support is available, too, see URL:
http://wintcltk.sourceforge.net/tkwrap.html

From: Uwe Zdun <uwe.zdun_at_uni-essen.de>
Date: Tue, 30 Jan 2001 14:06:56 +0100

On Monday 29 January 2001 23:54, Kristoffer Lawson wrote:
> [~] package require XOTcl
> 0.83
> [~] namespace eval Foo {
>
> >Class MyClass
> >MyClass instproc init {} {
> >AnotherClass newChild
> >}
> >Class AnotherClass
> >}
>
> AnotherClass
> [~] Foo::MyClass new
> invalid command name "AnotherClass"
> while evaluating {Foo::MyClass new}
>
> Ie. it appears as if methods aren't run in the same namespace as
> where classes exist (or a child namespace of this). I know this isn't
> exactly a bug (as I don't think it's specified anywhere?), but I believe
> the natural behaviour would be for AnotherClass to be found in the example
> above, as it's specified within the same namespace as Foo.
>
> Is the any chance the current behaviour could be altered to one that I
> think is more intuitive? Or is there a good reason why not?
>

XOTcl classes actually consist of two namespaces, one for the class object
(where procs and class variable are defined) and one for the class features
(where the instprocs are defined). The later one is "hidden" in the namespace
"XOTclClasses". So during execution of the "init" method the current namespace
is:

::XOTclClasses::Foo::MyClass

Usually -- as a user of XOTcl -- you don't have to be aware of that
namespace separation. We probably should document it more prominently
in the tutorial.

But in the given case its not hard to find out where the
AnotherClass command resides, because its in the parent namespace
of "MyClass":

namespace eval Foo {
  Class MyClass
  MyClass instproc init {} {
    [[self] info parent]::AnotherClass newChild
  }
  Class AnotherClass
}
Foo::MyClass new

BTW, here, the ::XOTclClasses namespace ain't the problem ... but the Tcl
namespace resolution. E.g., we expect:


  Object p
  p proc putHello {} {puts Hello}
  Object o
  o proc putHello {} {
    p putHello
  }
  o putHello

to work because Tcl first searches the current Namespace and then the global
namespace. This wouldn't functions here either if we surround it with a
namespace definition:

namespace eval Foo {
  Object p
  p proc putHello {} {puts Hello}
  Object o
  o proc putHello {} {
    p putHello
  }
}
Foo::o putHello

But, again info parent works ;)

Regards,

Uwe

-- 
Uwe Zdun
Specification of Software Systems, University of Essen
Phone: +49 201 81 00 332, Fax: +49 201 81 00 398
zdun_at_xotcl.org, uwe.zdun_at_uni-essen.de

From: Adam Turoff <adam.turoff_at_gmail.com>
Date: Fri, 22 Oct 2004 17:06:28 -0400

On Fri, 22 Oct 2004 16:51:41 -0400, Schofield, Bryan (GE
Transportation) <bryan.schofield_at_trans.ge.com> wrote:
> I think you've stumbled on the namespace resolution bug that appeared with 1.3.0. Gustaf & Uwe have been working on fix and appear to close to releasing a new version. I'm testing a 1.3.3 version of XOTcl for Gustaf now.

Whoops. Sorry. I'm using 1.2.0.

-- Adam

From: Eckhard Lehmann <eckhardnospam_at_gmx.de>
Date: Wed, 02 Jan 2008 22:46:26 +0100

Kristoffer Lawson schrieb:
> You could just wrap it in a package that sets a Tcl [trace] for normal
> commands combined with filters for the XOTcl stuff, just checking to
> see if the command names match, if necessary. Or maybe I've missed
> something here and I'm thinking to simple :-)
The problem is that I need something that is like enterstep/leavestep
for [trace], but for XOTcl. Filters do only intercept calls to XOTcl
objects but not to Tcl proc's.
Consider the example from Gustaf above. I have extended it a little bit:

B instproc doit {args} {
 my set x 1
 my foo
 set l {a b c d} ;# <------
 for {set i 0} {$i < 10} {incr i} { ;# <------
     puts $i ;# <------
 } ;# <------
 next
 my set y 4
}

The whole script is below, you can paste it into a file and run it. If
you do so, the output is:
-----
Call: ::b1 set x 1
Exit: ::b1 set x 1 => 1
Call: ::b1 foo
Exit: ::b1 foo => 2
0
1
2
3
4
5
6
7
8
9
Call: ::b1 set a 3
Exit: ::b1 set a 3 => 3
Call: ::b1 set y 4
Exit: ::b1 set y 4 => 4
-----
As you can see, the calls to [my set x 1] and [my foo] are intercepted
("Call"/"Exit"), but the calls to [set l {a b c d}] and to the [for]
loop are not. Therefore it is only partially useful, if yo want to
intercept *every* statement in a method (which is what I want).


Eckhard


#----------------- Script --------------
Class A
A instproc foo {} {
 my set f 2
}
A instproc doit {args} {
 my set a 3
}
Class B -superclass A
B instproc doit {args} {
 my set x 1
 my foo
 set l {a b c d}
 for {set i 0} {$i < 10} {incr i} {
     puts $i
 }
 next
 my set y 4
}
B b1

Class F
F instproc traceFilter args {
 if {[self callingproc] eq "doit"} {
   puts "Call: [self] [self calledproc] $args"
   set r [next]
   puts "Exit: [self] [self calledproc] $args => $r"
   return $r
 } else {
   next
 }
}

B instmixin F
B instfilter {{traceFilter}}
b1 doit

From: <seva_at_design.kiev.ua>
Date: Tue, 26 Dec 2000 21:04:13 +0200 (EET)

Hello

I'm working on real-life application, which controls some hardware
devices throw network protocol.

For now this application consist of several instances of some objects,
which implements FSM (finite state machines) of hardware devices. Now it is
implemented using Itcl, but I need possibility to change fsm
states and implementation without restarting application. Itcl does
not allow me to do this, so I decided to switch to XOTcl.

I split my application in several source files. Each of files
implements one of fsm's or helper functions, and when I need to change logic
of work, i simply source all files.

There are several problems with this:
  1) when I execute command Class Some, previous instance of this
class deleted, and all objects move to ::Object class.
    This problem I solve by using filter for create command on ::Object (idea
stolen from recoverypoint class :)) ). But with that second problem
arrives:
  2) when some instproc used as a filter, and redefined, it's filter become
inactive. (so first problem arrives again, when I source recover.tcl which
has recoverfilter definition)
     after setting filter again, all works as expected

  Hope for your help :))

Example code:
----------------- a.xotcl -----------------
#!/usr/local/bin/tclsh8.2

package require XOTcl

Object instproc filter {args} {
        puts "filter: [self] [[self] info calledproc]"
        next
}

Object filter filter

puts "Object test"
Object test
puts "test set a a"
test set a a

puts "Object instproc filter"
Object instproc filter {args} {
        puts "new filter: [self] [[self] info calledproc]"
        next
}

puts "test set a a"
test set a a

puts "Object filter filter"
Object filter filter

puts "test set a a"
test set a a
-----------------------------------------
Result:

Object test
filter: ::Object test
filter: ::Object create
test set a a
filter: ::test set
Object instproc filter
filter: ::Object instproc
test set a a
^^^^^^^^^^^^^^^ unfiltered
Object filter filter
test set a a
new filter: ::test set
new filter: ::_at_ destroy
new filter: ::test destroy

From: Gustaf Neumann <neumann_at_wu.ac.at>
Date: Tue, 18 Aug 2009 16:00:13 +0200

Hi Jeff,

your work sounds great (pls. send as well the announced generated
samples, they
were not included in your message). We are in the process towards xotcl 2.0
(there will be a paper at the forthcoming tcl conference); therefore it
would be
a very good time for such improvements.

all the best
-gustaf neumann


Jeff Levesque schrieb:
> Hi All,
> I hope this is still the right place for this, but I was wondering if anyone
> has any interest in some changes I've made to xodoc. I've really only added
> a couple things but they were big requirements for our documentation and I
> figured it might be this way for others as well. Here's the feature list and
> what I've completed so far:
>
> - Cleanup the output appearance/Make it look more like javadoc (In
> progress)
> - List inherited procedures for each class (Mostly finished)
> - Fix package (_at_ package provide ...) documentation (Mostly finished)
> - Create a side navigation bar of classes/procedures (similar to javadoc)
> (Not started)
> - Add HTML functionality to xodoc as needed (In progress)
>
> I've attached a sample of the files generated from my version of xodoc. If
> other people are interested I would go through and clean up the code before
> I made it available.
>
> - Jeff
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Xotcl mailing list
> Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
>

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