Weblog Page

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Wed, 25 Jun 2008 09:50:16 +0200

Dear XOTcl Community,

XOTcl 1.6.1 is available. This release provides in short:
 - improved orthogonality for introspection,
 - improvements in the serializer
 - some minor fixes

Starting with XOTcl 1.6.0, release packages for XOTcl
are available for Debian GNU/Linux. XOTcl is included
in upcoming Ubuntu releases, starting with Ubuntu 8.10
"Interpid Ibex" (see also: http://media.wu-wien.ac.at/download.html).
Many thanks to Stefan Sobernig for his help!

See below for more details concerning the release
Best regards

-gustaf neumann


Announcing XOTcl 1.6.1
*************************

We are pleased to announce the availability of XOTcl 1.6.1

Major changes relative to 1.6.0 are:

   * Extended and generalized "info" method

   * Generalized serializing package: when deserializing code, now
     consistenly no constructors are called. In previous versions,
     constuctors were called on slots; due to the point above, this is
     not needed; background: the previous solution had problems in
     aolserver ns_eval, when a slot-constructor called db-functions,
     since during ns_eval, the database handles are non-functional)

   * Fixes for potential crashes when methods were called
     with invalid arguments

   * 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: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Wed, 26 Oct 2005 13:35:02 +0200

Dear Shawn,

>
> The tutorial shows that the syntax for extending nonposArgs is:
>
> /someobject|someclass/ *proc|instproc* methodName {?optional
> arguments? argName args} {
> ...
> }

actually, this should read most probably .... ?optional nonpositional
arguments? ...


For the time being, define an "argument type" named "mtu" as in:

   xotcl::nonposArgs proc mtu {{-from 54} {-to 65535} name value} {
     if {$value < $from || $value > $to} {
       error "invalid argument $name: $value is not between $from and $to"
     }
   }

   Class Foo
   Foo instproc setMtu {{-mtu:mtu "1500"}} {} {
     puts "setMtu mtu=$mtu"
   }

   Foo f
   f setMtu -mtu 66
   f setMtu -mtu 66999

Alternatively, one can use forward to be a little more generic, but
still defining an
own type mtu:

   xotcl::nonposArgs forward mtu %self RANGE 43 65553
   xotcl::nonposArgs proc RANGE {from to name value} {
     if {$value < $from || $value > $to} {
       error "invalid argument $name: $value is not between $from and $to"
     }
   }

Hope, this is acceptable for now.
-gustaf

From: Laurent Duperval <laurent.duperval_at_netergynet.com>
Date: Tue, 19 Dec 2000 12:15:32 -0500 (EST)

Hi,

Is there a CVS repository for xotcl?

L

-- 
MY EMAIL ADDRESS HAS CHANGED --> UPDATE YOUR ADDRESSBOOK
Laurent Duperval                   "Montreal winters are an intelligence test,
Netergy Networks - Java Center            and we who are here have failed it."
Phone: (514) 282-8484 ext. 228                                   -Doug Camilli
mailto:laurent.duperval_at_netergynet.com           Penguin Power!

From: Eckhard Lehmann <eckhardnospam_at_gmx.de>
Date: Fri, 30 May 2008 20:18:56 +0200

Hello Gustaf,

However, can you tell more about your use-cases?

I was thinking a few times about providing interceptors
for single methods, similar to the method combinator :around
in CLOS.

When I read it right (I have little idea about CLOS and not much experience with LISP...), this is exactly what I mean. Just a piece of code that is called whenever a certain method of an object is called and which can serve as kind of "observer" for this method.

One thing comes to mind since I play around with Tclhttpd and a persistency framework: Tclhttpd maintains sessions as safe slave interpreters. These interpreters must know about persistency objects in the server, so it is necessary that
- whenever a persistency object is created, a command alias for it must be created in certain sessions (interpreters)
- whenever a session is created, certain persistency objects must be "informed" (-> a command alias for them must be created in the new interpreter).
- whenever a session is destroyed, it's alias must be removed from all persistency objects that contain it.

It involves interception of several methods and attributes, which I currently do with instfilters and instfilterguards. But it would be simpler if the filter is optionally just called on one method. I am using different filters for different methods anyway, because it avoids large [switch] statements.

If that can be implemented with mixins, fine. I was seeing mixins more in the context of code reuse as an alternative to inheritance, and not as an interception technique.

--
Eckhard

From: Uwe Zdun <uwe.zdun_at_wu-wien.ac.at>
Date: Thu, 16 Feb 2006 18:00:30 +0100

It is pretty straightforward to extend XOTcl with C functions. Almost
the same as extending Tcl. See the XOTcl extensions XOTclGdbm,
XOTclSdbm, in the XOTcl distribution as examples. Unfortunately, there
is no documentation of the C API yet, only those examples

Uwe

Aamer Akhter wrote:

>Critcl allows us to easily create tcl callable C procs. Is there
>something similar avaliable for xotcl?
>
>Is there any C api documentation?
>
>
>
>--
>Aamer Akhter / aakhter_at_gmail.com
>
>_______________________________________________
>Xotcl mailing list
>Xotcl_at_alice.wu-wien.ac.at
>http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
>
>

-- 
Uwe Zdun
Department of Information Systems, Vienna University of Economics
Phone: +43 1 313 36 4796, Fax: +43 1 313 36 746
zdun_at_acm.org, uwe.zdun_at_wu-wien.ac.at

From: Artur Trzewik <mail_at_xdobry.de>
Date: Mon, 3 Mar 2003 19:27:26 +0100

Hallo!

New release of XOTclIDE 0.41 is available on
http://www.xdobry.de/xotclIDE

Changes:
- support sqlite (http://www.sqlite.org) as version control database (adapter
written by Oleg Oleinick)
- command line parameter -configmap is supported by all programms
- many bug fixes (thanks to Oleg Oleinick for bug reports)
- fixes and changes in debugger

all people that use atkdebugger should rebuild tcl with new
tcl8.4.1-atkdebugger.patch

Artur Trzewik

From: Shishir Ramam <sramam_at_gmail.com>
Date: Sun, 19 Nov 2006 12:42:49 -0800

I am passing an array name by reference across an instproc.

The vanilla version works just fine (see creation of x1 midway through the
code segment).

To add some debugging in, I essentially used the trace example from the
tutorial, and funnily,
the upvar stopped doing it's job (see error on creating x2 towards the end
of the code segment).

To get rudimentary debug control of the parray proc, I copied it into a proc
called barray. None of the logic is changed -
just my crude attempt at adding breadcrumbs.

I have included the output at the end of the code segment.

Running Windows XP Pro + Active Tcl 8.4.13 + XoTcl 1.4.0.

thanks for all help.
-shishir

<CODE SEGMENT>
package require XOTcl
namespace import ::xotcl::*


proc barray {a {pattern "*"}} {
    puts "barray"
    upvar 1 $a arr
    if {![array exists arr]} {
        error "\"$a\" isn't an array"
    }
    set maxl 0
    foreach name [lsort [array names arr $pattern]] {
        if {[string length $name] > $maxl} {
            set maxl [string length $name]
        }
    }
    set maxl [expr {$maxl + [string length $a] + 2}]
    foreach name [lsort [array names arr $pattern]] {
        set nameString [format %s(%s) $a $name]
        puts stdout [format "%-*s = %s" $maxl $nameString $arr($name)]
    }
}

Class X

X instproc bar {ar args} {
  puts "bar"
  upvar $ar arr
  puts "upvard"
  barray arr
}



X instproc init {args} {
  array set arr {a 1 b 2}
  parray arr
  my bar arr
}

X x1


Object Trace
Trace set traceStream stdout
Trace proc openTraceFile name {
  my set traceStream [open $name w]
}
Trace proc closeTraceFile {} {
  close $Trace::traceStream
  my set traceStream stdout
}
Trace proc puts line {
  puts $Trace::traceStream $line
}
Trace proc add className {
  $className instfilter [concat [$className info filter] traceFilter]
}

Object instproc traceFilter args {
  # don't trace the Trace object
  if {[string equal [self] ::Trace]} {return [next]}
  set context "[self class]->[self callingproc]"
  set method [self calledproc]
  switch -- $method {
    proc -
    instproc {::set dargs [list [lindex $args 0] [lindex $args 1] ...] }
    default {::set dargs $args }
  }
  Trace::puts "CALL $context> [self]->$method $dargs"
  set result [next]
  Trace::puts "EXIT $context> [self]->$method ($result)"
  return $result
}

Trace add X

X x2

</CODE SEGMENT>

------------

<OUTPUT>
arr(a) = 1
arr(b) = 2
bar
upvard
barray
arr(a) = 1
arr(b) = 2
CALL ::xotcl::Object->> ::x2->cleanup
EXIT ::xotcl::Object->> ::x2->cleanup ()
CALL ::xotcl::Object->> ::x2->configure
EXIT ::xotcl::Object->> ::x2->configure (0)
CALL ::xotcl::Object->> ::x2->init
arr(a) = 1
arr(b) = 2
CALL ::xotcl::Object->init> ::x2->bar arr
bar
upvard
barray
"arr" isn't an array
</OUTPUT>

----
<ERRORINFO>
% set errorInfo
"arr" isn't an array
    while executing
"error "\"$a\" isn't an array""
    (procedure "barray" line 5)
    invoked from within
"barray arr"
    (procedure "bar" line 6)
    invoked from within
"next"
    (procedure "bar" line 13)
    ::x2 ::xotcl::Object->traceFilter
    invoked from within
"my bar arr"
    (procedure "init" line 5)
    invoked from within
"next"
    (procedure "init" line 13)
    ::x2 ::xotcl::Object->traceFilter
    ::X ::xotcl::Class->recreate
    ::X ::xotcl::Class->create
    ::X ::xotcl::Class->unknown
    invoked from within
"X x2"
    (file "c:/temp/trace_trouble.tcl" line 81)
    invoked from within
"source c:/temp/trace_trouble.tcl"
</ERRORINFO>

From: Kristoffer Lawson <setok_at_scred.com>
Date: Thu, 5 Aug 2010 18:00:58 +0300

OK, I did a quick setup of an environment where [new] does not accept -dash initialised data, but with a separate [new-wish] that has a final argument, a script evaluated inside the object, which can do any pre-initialisation before the constructor is called. This solution works for me now and I'm not having issues with the couple of other XOTcl libraries I'm using.

I think this is a pretty decent solution and the resulting instantiation code actually looks pretty nice and readable. I'm up to other names for "new-with". Maybe something like <new ?args? with ?initscript?.There's a mini-example at the bottom.

Enjoy.


Class SafeInit

SafeInit instproc new {args} {
    return [next [concat [list -init] $args]]
}

SafeInit instproc new-with {args} {
    set script [lindex $args end]
    set args [lrange $args 0 end-1]
    set name [my autoname ::xotcl::stk__#]
    return [my create $name [list -eval $script] [concat [list -init] $args]]
}

# Mix safer [new] and [new-with] into every class
Class instmixin SafeInit


# Test:

Class Foo -parameter {
    {animal horse}
}

Foo instproc init {arg1 arg2} {
    puts "Constructor args: $arg1 $arg2"
}

Foo instproc hello {} {
    puts jou
}


# We do not override [create] or the auto-create from [unknown]. Ie.
# class creation still works and other stuff :-)
puts "Should say 'jou':"
Foo ob 1 2 -hello
puts "Animal: [ob animal]"

# Instantiate with -dash args
set ob [Foo new -hellou world]
puts "Animal: [$ob animal]"

# Instantiate with some presets
puts "Show say 'jou':"
set ob [Foo new-with 1 2 {
  my hello
  my animal cat
}]
puts "Animal: [$ob animal]"

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

From: <uwe.zdun_at_uni-essen.de>
Date: Wed, 13 Dec 2000 12:33:51 +0100 (CET)

>>>>> "GN" == Gustaf Neumann <Gustaf.Neumann_at_wu-wien.ac.at> writes:

>>>>> "Z" == Zoran Vasiljevic <zoran_at_munich.com> writes:
Z> ------Original Message------
>>> 2. However, in the "mixin" case we could enable argument passing,
>>> because "mixin" has just one argument? The rest could be passed > to
Z> "init". any objections?

Z> obj mixin Foo arg1 arg2 arg3
Z> would pass arg1-arg3 to init of Foo. Right?

Z> obj mixin [list Foo Bar] arg1 arg2 arg3

Z> would pass arg1-arg3 to init of Foo AND of Bar. Right again?

Z> Is so, then I think it should be done, if possible. 0.85 ? 0.9 ?

GN> from the implementation point of view this is not a big issue.
GN> however, from my experience, i should note that i switched from a
GN> style of "passing arguments to init" to the "-parameter style of
GN> configuring objects", which is in almost all cases the more elegant
GN> solution.

GN> With your example, you will run into a similar problem when
GN> multiple mixins are registered.

GN> a) Consider the following example:
 
GN> [Class C] instproc init {a} {puts "[self class] $a"; next}
GN> [Class M1] instproc init {b} {puts "[self class] $b"; next}
GN> [Class M2] instproc init {c} {puts "[self class] $c"; next}

GN> C c1 3 -mixin {M1 M2}

GN> here passing one argument to the mixin method should work
GN> (weirdly enough, the argument is before the -mixin, but would
GN> have similar semantics as
 
GN> C c1 3
GN> c1 mixin {M1 M2} 3

GN> but who says, that the arguments a b and c have the same
GN> intended semantics? ... using -parameter is much clearer

sure ... but "args" as argument wouldn't yield that behavior

-parameter is surely the better solution. But if you want some more
behavior in "init" then -parameter does, you need the
constructor. There is currently no way to get that argument into the
mixin constructor.

Moreover, for a newbie the error message may be hard to understand, if
you do not associate "mixin" with "init".


GN> b) Then we have the factoring problem: what, if M1 and M2 have the
GN> different argument lists. we could use something like:

GN> c1 mixin {M1 M2} {3 {a b}}

GN> but isn't that ugly?

that is the general problem I sketched in the first mail .. it also
appears for ordinary class composition with two different
constructors. You can build all these weird constructs also with
ordinary class constructors.

Again "args" should be used ... or something else then the constructor.
E.g. -paramter or -xyz

 
GN> this makes the manipulation of the mixin list (eg. automatically
GN> inserting a mixin, if it is not there) by a program over-complicated.

GN> c) From the idea, mixins are orthogonal to the intrinsic classes
GN> and can used for different classes as well. Should not the following
GN> work somehow as well?

GN> [Class D] instproc init {x y} {puts "[self class] $x $y"; next}
GN> D d1 a b -mixin M1

it seems to work in the extended version as expected:

% Class D
D
% D instproc init {x y} {puts "[self class] $x $y"; next}
% Class M1
M1
% D d1 a b -mixin M1
::D a b
d1

However, it is not very elegant.

Let us consider Zoran' exmaple:

  Class Tree ;# has abstract methods mostly
  Class XmlTree -superclass Tree ;# implements above methods
  Class UfsTree -superclass Tree ;# ...

  XmlTree instproc init {xmlFile} {....}
  UfsTree instproc init {rootDir} {....}

  Tree t
  t mixin XmlTree /path/to/xmlfile.xml ;# use the Xml driver
  t mixin UfsTree /some/dir ;# switch to filesystem driver

Here, the problem simply is that "-parameter" and other "-" methods
are not evaluated before the constructor. Withour arguments for mixin
you have no chance to get the vars into the constructor.

BTW, from the idea of class composability the mixin inits in this
exmaple should either have an "args" argument or no "next" call. Or
arguments could be given in pairs, like
"-xmlFile path/to/xmlfile.xml -rootDir /some/dir".


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: Gustaf Neumann <neumann_at_wu.ac.at>
Date: Fri, 08 Jun 2012 10:50:04 +0200

The problem was verified and is fixed in the head version of
git.