Weblog Page

From: Uwe Zdun <uwe.zdun_at_wu-wien.ac.at>
Date: Fri, 8 Nov 2002 21:02:07 +0100

Announcing XOTcl 1.0
********************

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.


CHANGES relative to 0.9.4 are:

  - fixes:
 
     * various small fixes for compilation with tcl8.4.*

     * fixed some more memory-leaks that showed up in connection
       with multi-threading (many thanks to Zoran Vasiljevic for
       his great help)

     * removed a few panics() by tcl errors (important for servers)

     * various small fixes in Httpd-code

     * fixes in filter-search mechanism

     * the general cleanup method __exitHandler (called on
       interpreter exits and on thread exits) defined now
       as a proc of Object

  - optimizations:

     * speedup during recreation of objects
  
 For more details, please consult the 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.ac.at>
Date: Thu, 23 Feb 2012 12:31:49 +0100

Dear Artur,

the mixins respect the class hierarchies, but maybe in a
different way than you expected. Mixin classes have a higher
precedence than the intrinsic classes (the actual class
structure implied by the "class" relation and the
"superclass" relations of this class). The details of the
mixin semantics and mixin composition is defined in detail
in the following paper:

http://nm.wu-wien.ac.at/research/publications/b613.pdf

As a summary, the full precedence order of an object is
     POMs PCMs O C

where
    POMs: a sequence of per-object mixins (classes, implying
their super-classes)
    PCMs: a sequence of per-class mixins (classes, implying
their super-classes)
    O: the actual object, not shown in "info precedence"
    C: the class of the object (implying its super-classes)

Mixins are sometimes criticized for their "total composition
ordering"; a more fine-grained control can be provided via
traits, see for an introductory example in:

http://nm.wu-wien.ac.at/research/publications/b886.pdf

all the best
-gustaf neumann



On 23.02.12 11:29, Arthur Schreiber wrote:
> Hello Gustaf,
>
> playing around with mixins, I came across the following behaviour:
>
> package require nx
>
> nx::Class create TestMixin {
> :public method test {} {
> puts "mixin"
> }
> }
>
> nx::Object mixin TestMixin
>
> nx::Class create TestClass {
> :public method test {} {
> puts "class"
> }
> }
>
> set test [TestClass new]
> puts [$test info precedence]; # => ::TestMixin ::TestClass ::nx::Object
> $test test; # => mixin
>
> Is that intended? I would have expected that the class hierarchy of
> ::TestClass instances would look like "::TestClass ::TestMixin
> ::nx::Object".
>
> Kind regards,
> Arthur
> _______________________________________________
> 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, 08 Dec 2010 06:39:01 +0100

On 08.12.10 05:40, Victor Mayevski wrote:
> It came to my attention that [namespace import -force nx::*] is a
> requirement and not an option, otherwise things don't work right.
> Example:
>
> nx::Class create C
> C method init args {puts [self]; next}
> C create c
> #error, commands "self" and "next" do not exist, but if I first do
> [namespace import -force nx::*], everything works fine.
well, if i take the first sentence literally, this is not true.
there are several options:

if one uses a plain tcl shell, one can use

a)
      package req nx

      nx::Class create C
      C method init args {puts [nx::self]; nx::next}
      C create c

b)
      package req nx
      namespace path nx

      nx::Class create C
      C method init args {puts [self]; next}
      C create c

c)
      package req nx
      namespace import nx::*

      nx::Class create C
      C method init args {puts [self]; next}
      C create c

Concerning (c): there is no need to use "-force", except
these commands were already imported (e.g. from some
other package).

One can use alternatively the "nxsh" (tcl-file, which does a
      package req nx
      namespace import nx::*
automatically) and then in the script file just

      nx::Class create C
      C method init args {puts [self]; next}
      C create c
> This is not how I thought the namespaced commands should work. Is this
> a feature or a bug? If not a bug, then it needs to be clearly
> documented.
I don't understand, what you expected. If you use just (a)
then Tcl has no indication, what "self" or "next" should be
used.
For unprefixed names, Tcl requires to have to use either
"namespace import" or "namespace path".

The behavior is the same as in XOTcl 1. XOTcl/nx do not play
any magic games with namespaces, they just use the standard
tcl behaviour.

-gustaf neumann

From: jim <j_marvin_at_localnet.com>
Date: Thu, 11 Dec 2003 03:46:56 -0500

hi-

i fixed it so i can run my exe file from the desktop for my tcl script
created in visual tcl that uses xotcl code.

here are the steps to do this:

after the tcl project file is saved in tcl open it in notepad.
you will see this line of code that starts... at the top of the project
tcl file

if {![info exists vTcl(sourcing)]} {

#add this code below this comment
 lappend auto_path "C:/Program Files/Tcl/lib/xotcl1.1/xotcl"

if you are using notepad choose file save as and put quotes around the
project tcl file.
choose file type all files from the drop down in the save as window.
# as always before overwriting make sure you have a backup file.
save and overwrite.

now you have to manually freewrap the file.
copy your project file to c:\program files\vTcl\freewrap\windows\bin
directory.
this way the project file is now in the same directory as the
freewrap.exe file.

choose start run and type this...
"C:\Program Files\vTcl\freewrap\windows\bin\freewrap.exe" elevator5.tcl
substitute the name of your project tcl file instead of elevator5.tcl
click ok

an exe file should now be created called something like elevator5.exe.

now you can create a shortcut to the desktop if you like.


hope this helps.
thanks,
marvin

From: Gustaf Neumann <neumann_at_wu.ac.at>
Date: Sun, 29 Aug 2010 13:54:44 +0200

  Dear Kristoffer,

many things went wrong. It is true, there is a bug in all XOTcl 1.*
releases,
which is there most likely since many years (8+).

the bug:

   - when a filter chain comes to its end without finding the method
     (e.g. "ob foo"), xotcl records its fact, but this affected as well
     the method invocations from the filter after the "next".

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

I have fixed the bug in 1.6.6, you can obtain it via

    git clone git://alice.wu-wien.ac.at/xotcl

best regards
-gustaf neumann

Am 29.08.10 03:02, schrieb Kristoffer Lawson:
> Take a look at this code:
>
> package require XOTcl 1.6
> namespace import xotcl::*
>
> Class Foo
>
> Foo instproc hello {} {
> puts hello
> }
>
> Foo instproc myfilter {args} {
> puts "\nme: [self]"
> ::set targetclass [my info class]
> puts "targetclass: $targetclass"
> puts "calledproc: [self calledproc]"
> ::set r [next]
> puts "back from next"
> puts "paramcmds: [$targetclass info instparametercmd]"
> }
>
> Foo instfilter myfilter
>
> Foo ob
> ob hello
> ob foo
>
>
> So first I have a filter installed which does nothing but print some information, and checks something using the [info] method afterwards. I call an instantiated object with [hello] (an existing method) and again with [foo] (a non-existing method). The latter is when things get interesting. Check the output:
>
>
> me: ::ob
> targetclass: ::Foo
> calledproc: configure
> back from next
> paramcmds:
>
> me: ::ob
> targetclass: ::Foo
> calledproc: init
> back from next
> paramcmds:
>
> me: ::ob
> targetclass: ::Foo
> calledproc: hello
> hello
> back from next
> paramcmds:
>
> me: ::ob
> targetclass: ::Foo
> calledproc: foo
> back from next
>
> me: ::alloc
> ::alloc: unable to dispatch method 'info'
> while executing
> "my info class"
> (procedure "cleanup" line 4)
> ::alloc ::Foo->myfilter
> ::Foo ::xotcl::Class->recreate
> ::Foo ::xotcl::Class->create
> ::Foo ::xotcl::Class->unknown
> ::Foo ::xotcl::Class->create
> ::Foo ::xotcl::Class->unknown
> ::Foo ::xotcl::Class->create
> ::Foo ::xotcl::Class->unknown
> invoked from within
> "$targetclass info instparametercmd"
> (procedure "foo" line 9)
> ::ob ::Foo->myfilter
> invoked from within
> "ob foo"
> (file "filtertest.tcl" line 24)
>
> me: ::alloc
> targetclass: ::Foo
> calledproc: destroy
> back from next
> paramcmds:
>
> me: ::info
> targetclass: ::Foo
> calledproc: destroy
> back from next
> paramcmds:
>
> me: ::ob
> targetclass: ::Foo
> calledproc: destroy
> back from next
> paramcmds:
>
> ...
> So while the [hello] method works as expected, things get totally weird for [foo]. The first thing we notice is that it doesn't jump out at [next] (which should give an error as it does not exist). It continue execution of the filter after [next]. This may or may not be intended, I don't know. The documentation is not clear on this.
>
> More interesting still, we end up with a totally unexpected error. The thing I believe is happening is that, for some reason or other [$targetclass info instparametercmd] is not ending up calling [info] for $targetClass, but creating an object called ::info (and thus overriding the original Tcl command). How [alloc] gets involved in the filter chain too, I am not sure. My guess is that the "unknown method" that resulted from [foo] is being interpreted by the XOTcl $targetclass C implementation as an error that occurred there, and that a new instance called "info" or possibly "alloc" should be created.
>
> This causes major havoc as soon as an unknown method is called. Does the filter code look correct?
>
> This happens with 1.6.2. I had a quick look at CHANGES for later versions and while there was some mention of memory leaks in [info] I wasn't sure if there was anything that would have fixed this.
>
> Any ideas?
>

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

From: Jim Russell <Jim.Russell_at_dynetics.com>
Date: Thu, 13 Nov 2003 15:15:16 -0600

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?

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Sun, 10 Oct 2004 00:45:45 +0200

 Hi Bryan and all,
 i just fixed the problem of attila and resolved the open namespace
 issues. We will do some more testing and will come out with 1.3.3. RSN.

 all the best
-gustaf

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

From: Scott Gargash <scottg_at_atc.creative.com>
Date: Tue, 7 Mar 2006 14:43:17 -0700

Hello,

I've just started looking at XOTcl over the last couple days, and so far I like it a lot. Since I'm
still learning, I assume I've overlooked something in the documentation, but I can't find how to
remove a forwarded method from an object. It seems that all I can do is add a forwarded method, but
once installed, I can never unforward a method. Is this true?

Here's an (simplified) example of what I'm trying to do:

Object a
a proc foo {args} {
  puts "a: [self] foo"
}

Object b
b set overrides {}
b proc foo {obj} {
  puts "b: [self] foo"
  if {-1 == [lsearch [my set overrides] $obj]} {
    puts "b is overriding $obj foo"
    $obj forward foo [self] overridefoo $obj
  }
}

b proc overridefoo {obj args} {
  if {$args eq "done"} {
    puts "stop forwarding foo for $obj"
    set idx [lsearch -exact [my set overrides] $obj]
    my set overrides [lreplace [my set overrides] $idx $idx]
    # This doesn't work! What should be here?
    $obj forward foo {}
    puts "redispatching foo to native $obj foo"
    $obj foo $args
  } else {
    puts "using override of foo on $obj $args"
  }
}
a foo 123
b foo a
a foo 234
a foo done

----------

>From what I gather, the intended mechanism for doing this is to use a mixin to intercept the foo
method, but a already has a foo method that's being used for other purposes. I suppose I could
dynamically create another object (or would it have to be a class?) to use as a mixin, but that
seems unnecessarily complex. Is there a better way to accomplish what I'm trying to do?


BTW, I'm running xotcl 1.3.6. If I run the above sample 3 times, I get the following error:

procedure "foo" has formal parameter "::xotcl::initProcNS" that is not a simple name

and the interpreter crashes on the next command. That's probably a bug, but since I'm not at the
latest release, I don't know if it's something that's been fixed already.

Thanks.

      Scott




Notice
The information in this message is confidential and may be legally privileged. It is intended
solely for the addressee. Access to this message by anyone else is unauthorized. If you are not
the intended recipient, any disclosure, copying or distribution of the message, or any action
taken by you in reliance on it, is prohibited and may be unlawful. If you have received this
message in error, please delete it and contact the sender immediately. Thank you.

From: Kristoffer Lawson <setok_at_scred.com>
Date: Thu, 5 Aug 2010 13:49:29 +0300

On 5 Aug 2010, at 13:38, Gustaf Neumann wrote:

> For XOTcl 2.0, the behavior for this example is like in XOTcl 1.* (it has to be
> for compatibility for many one-liners out there), for the new syntax, you get an
> error message (... and, by default, one has to use "Car create c1" instead of
> "Car c1", since the latter is dangerous as well).

Yeah, I agree the latter is dangerous, if in a different way. Basically you can end up with really obscure bugs if you mistype "instproc" somewhere. I speak with experience :-)

Must get round to reading your papers on XOTcl 2.0. They're open and waiting for me to get round to them...

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

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

Hello Gustaf,
> first, a happy new year to everybody!
Ihnen auch ein frohes neues Jahr :)!

> Here is a small example for tracing the calls within a method ("doit"),
> which is somewhat similar to enterstep. Given is the following sample
> script:
[...]

The example is very illustrative, thanks for that. However, it seems
that only calls to object methods are traced. In practical code I have
ordinary Tcl statements as well, e.g. the instproc "doit" could look like:

B instproc doit {args} {
 my set x 1
 my foo
 set l {a b c d}
 for {set i 0} {$i < [llength $l]} {incr i} {
   puts $i
   my_old_tcl_proc $i [lindex $l $i]
 }
 # lots of other stuff...
 next
 my set y 4
}

When I run that, only the calls to [my set x 1], [my foo] etc. are
intercepted, but not [set l {a b c d}] and [for].
> Allthough all xotcl methods are commands, with the current framework,
> the tcl command traces are not called autmatically, since the basic
> invocation mechanisms (with inheritance, filters, mixins) are handled
> by xotcl. Without looking into the details, i think it should be possible
> with moderate effort to incorporate tcl command traces in xotcl. But
> one has to convince the developers, that adding yet another interception
> mechanism to xotcl adds more benefits than causing confusion.
I see that there is no need for another interception technique, but it
would be really helpful to have the current filter techiques also
applied to ordinary Tcl code inside methods.

To be more precise, I am looking for a way to debug larger XOTcl
programs. http://wiki.tcl.tk/6007 describes a very nice and small
debugger that uses [trace exec] and can be applied to ordinary Tcl
proc's. I would like to extend that code, e.g. create an XOTcl class
"Debugger", that provides methods for step, breakpoint etc. It should be
possible to mixin this to any other XOTcl object for debugging purposes.


Thanks so far,
Eckhard