Weblog Page

From: <MichaelL_at_frogware.com>
Date: Mon, 12 May 2003 10:42:10 -0400

Look at the following code, which is meant to be a stripped-down and
simplified version of my real code:

Class DatabaseMgr

DatabaseMgr instproc openDatabase {} {
    Database [self]::db
}

Class Database

Database instproc init {} {
    puts "init [self]"
}

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

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!

By contrast, the following example (which also uses nested/aggregated
objects) succeeds (which is to say that the second call to "info class"
fails):

Object instproc doSomethingAndDie {} {[self] destroy}
set xxx [Object new]
set yyy [Object new -childof $xxx]
set zzz [Object new -childof $yyy]
puts "[$yyy info class]"
$yyy doSomethingAndDie
puts "[$yyy info class]"

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Sun, 21 Oct 2001 23:42:06 +0200

Hi folks,

i've put 0.9.1 on the server. See below for the changes.
We have also new figures from the shootout benchmark,
XOTcl is here now about twice as fast as OTcl. I've posted these
figures to c.l.t as well. The benchmark results and sources
are on the download page (supplemental resources)

best regards
-gustaf

=====================================================
XOTcl
  methcall: 2.040u 0.010s 0:02.05 100.0% 0+0k 0+0io 283pf+0w
  objinst: 4.730u 0.030s 0:04.76 100.0% 0+0k 0+0io 283pf+0w
OTcl
  methcall: 4.050u 0.000s 0:04.04 100.2% 0+0k 0+0io 330pf+0w
  objinst: 9.240u 0.010s 0:09.24 100.1% 0+0k 0+0io 330pf+0w
itcl
  methcall: 3.130u 0.000s 0:03.12 100.3% 0+0k 0+0io 285pf+0w
  objinst: 6.040u 0.000s 0:06.03 100.1% 0+0k 0+0io 286pf+0w
stooop
  methcall: 6.930u 0.010s 0:06.94 100.0% 0+0k 0+0io 259pf+0w
  objinst: 14.180u 0.000s 0:14.17 100.0% 0+0k 0+0io 259pf+0w
classytcl
  methcall: 3.030u 0.020s 0:03.04 100.3% 0+0k 0+0io 284pf+0w
  objinst: 8.980u 0.040s 0:09.02 100.0% 0+0k 0+0io 284pf+0w
====================================================


2001-10-20 Gustaf.Neumann_at_wu-wien.ac.at
        * reimplemented method 'new' of Class in C
        * various cleanups for stub handling
        * added regression test for stub library

2001-10-18 Uwe Zdun <uwe.zdun_at_uni-essen.de>
        * removed linking glitch in 0.9: stub enabled lib was linked
          with non-stub enabled obj-files.
        * added a stub enabled lib to Windows make procedure
        * renamed stub enabled lib to (lib)xotcl-tclstubs.(so|dll)

2001-10-17 Uwe Zdun <uwe.zdun_at_uni-essen.de>
        * removed "can't instvar to link" problem during aliasing
          to a link var

From: Koen Danckaert <koen_at_retarget.com>
Date: Fri, 06 Jan 2006 12:30:36 +0100

Hello,

The predefined.xotcl file uses a global variable "cmd":
  foreach cmd {array append lappend trace eval} ...

Which may, of course, give unexpected results:

tclsh
% set cmd mycommand
mycommand
% package require XOTcl
1.3.8
% set cmd
eval

Regards,
Koen

From: Stefan Sobernig <stefan.sobernig_at_wu.ac.at>
Date: Sat, 25 Jul 2009 15:16:08 +0200

> Message: 1
> Date: Fri, 24 Jul 2009 10:21:04 +0200
> From: Gustaf Neumann <neumann_at_wu.ac.at>
> Subject: Re: [Xotcl] xotcl crash
> To: Tibichte <zak_at_isa-software.com>
> Cc: xotcl_at_alice.wu-wien.ac.at
> Message-ID: <4A696EF0.7010906_at_wu.ac.at>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> > 2- This forwarding method causes xotcl to crash:
> >
> > obj forward f2 list {%_at_end 13} %self %1
> >
> > ? { obj f2 1 2 3 }
>
> There is a bug in the current xotcl versions when both
> %_at_end and %1 is used, which will be fixed in the next release.
> The %1 means that the first argument from the provided
> argument list (here "1") will be placed at the given
> position. The argument is consumed and the remaining
> arguments (here "2" and "3") are appended to the arguments
> from the forward definition. S
The fact that %1 consumes = mutates the caller arg list and the %_at_POS
substitution operates on the mutated state of the resulting (=final)
list (kind of) made me think. And ... I guess I found the culprit of
this crashy interaction (see the patch attached):

once %1 consumes the first element of the caller arg list, the
currently arg handling mechanism for forwards counts %1 as an extra
arg in the overall arg list erroneously. however, it is rather a
placeholder for an already counted arg (=the first in the caller arg
list). This +1 overestimation in the internal assembly of the final
arg list led to a memory access violation for the %_at_POS substitution
under end offsets (end, end-1, end-2; in the Tcl sense of the word)
because end offsets require a correct total args count internally
(which used to report +1).

as for the patch: it is a minor and fairly non-invasive change. all
regression tests pass, i added some extra cases to test for the %1 +
%_at_POS-under-end-offsets interaction. the patch can be applied to the
a xotcl-1.6.3 source snapshot.

cheers
//stefan

From: Victor Mayevski <vitick_at_gmail.com>
Date: Thu, 22 Jan 2015 00:29:06 -0800

Based on your input, I have created a proc to simplify the entire process:

#Create a proc ::nx::clone in order to put the NX OO system under a private
#namespace, so that the ::nx namespace doesn't get polluted with custom
methods.
#It also allows further unlimited cloning into other namespaces, where the
custom
#methods are inherited down the line.
###############################################################
proc ::nx::clone {ns {nsbody ""}} {
        set cns [namespace current];
        if {![regexp ^:: $ns]} {
                set ns ::$ns;
        };

        namespace eval $ns $nsbody;

        ${cns}::Class create ${ns}::Object -superclasses ${cns}::Object;
        ${cns}::Class create ${ns}::Class -superclasses ${cns}::Class {
                upvar cns cns
                upvar ns ns
                ::nx::slotObj [self];
                ::nx::ObjectParameterSlot create [self]::slot::superclasses
\
                -methodname "::nsf::methods::class::superclass" \
                -elementtype class -multiplicity 1..n \
                -default ${ns}::Object
        };
        proc ${ns}::clone {ns {nsbody ""}} [info body ::nx::clone];
        namespace eval $ns {namespace export Object Class};
        return $ns;
};

##################################################################
::nx::clone ::my {puts "you could put your custom package code here"};

::my::Object public method mymethod {} {puts "hello from mymethod in [:],
it will be inherited by the next clone"};
::my::Class create ::MyClass;
::MyClass create myobject;
::myobject mymethod;

::my::clone ::your;

::your::Class create YourClass;
::your::Object create yourobject;
::YourClass create yourobject1;
::yourobject mymethod;
::yourobject1 mymethod;



On Tue, Jan 20, 2015 at 12:21 PM, Gustaf Neumann <neumann_at_wu.ac.at> wrote:

> Dear Victor,
>
> below is a small improvement for the working suggestion:
>
> - the first suggestion used the constructor to fix the superclass
>
> - it is better, the change the default of the "superclasses" slot
> (inherited from nx::Class) from "nx::Object" to "nx::Class"
>
> - this is a slot, that is not linked to a variable, but to a method
> altering the class. Therefore the definition of this slot is slightly
> more magic.
>
> - This solution has the advantage, that one has not to care
> that further specializations of my::Class call in their
> constructor always "next". Furthermore, it should be
> slightly faster.
>
> all the best
> -gn
>
> namespace eval my {
>
> Class create Object -superclasses nx::Object
>
> Class create Class -superclasses nx::Class {
>
> # create a slot container ...
> ::nx::slotObj [self]
>
> # ... and redefine slot "superclasses" with a different default
> # value, such we can write
> #
> # my::Class create Foo
> #
> # instead of
> #
> # my::Class create Foo -superclasses ::my::Object
> #
> ::nx::ObjectParameterSlot create [self]::slot::superclasses \
> -methodname "::nsf::methods::class::superclass" \
> -elementtype class -multiplicity 1..n \
> -default [namespace current]::Object
> }
>
> namespace export Object Class
> }
>
> #
> # show parameter definition of "superclasses" with changed default
> #
> puts "parameter definition for '-superclasses': [my::Class info lookup parameters create super*]"
>
>
>
> Am 20.01.15 um 11:28 schrieb Victor Mayevski:
>
> That's beautiful! Thank you!
>
> On Tue, Jan 20, 2015 at 1:11 AM, Stefan Sobernig <
> stefan.sobernig_at_wu.ac.at> wrote:
>
>> A more complete solution (preserving any pre-existing superclass lists)
>> is as follows:
>>
>> package req nx
>>
>> namespace eval ::vitick {
>>
>> Class create Object -superclasses nx::Object
>>
>> Class create Class -superclasses nx::Class {
>> :method init {} {
>> ##
>> ## Rewire the default superclass
>> ##
>> if {[:info superclasses] eq "::nx::Object"} {
>> :configure -superclasses [namespace current]::Object
>> }
>>
>> }
>> }
>>
>> namespace export Object Class
>> }
>>
>> namespace import -force ::vitick::*
>>
>> puts [[Class create MyClass] info superclasses]; # default is:
>> ::vitick::Object
>> puts [[Class create AnotherClass -superclasses MyClass] info
>> superclasses]; # ::MyClass
>> puts [[Class create AnotherClass -superclasses MyClass] info superclasses
>> -closure]; # ::MyClass ::vitick::Object ::nx::Object
>>
>> //stefan
>>
>> Hi Victor,
>>>
>>> > Any suggestions?
>>>
>>> As always, there are several options. One way of nursing our custom
>>> Object/Class is to use proper specializations of nx::Object/nx::Class:
>>>
>>> package req nx
>>>
>>> namespace eval ::vitick {
>>>
>>> Class create Object -superclass nx::Object
>>>
>>> Class create Class -superclass nx::Class {
>>> :method init {} {
>>> :configure -superclasses [namespace current]::Object
>>> }
>>> }
>>>
>>> namespace export Object Class
>>> }
>>>
>>> namespace import -force ::vitick::*
>>>
>>> This is less invasive and you have the benefit of monitoring any
>>> changes/additions to nx::Object/nx::Class for free.
>>>
>>> Cheers,
>>> Stefan
>>> _______________________________________________
>>
>>
>

From: Artur Trzewik <mail_at_xdobry.de>
Date: Sun, 20 May 2001 12:39:21 +0200

Hi

The really problem of Xotcl is, it has no garbage collector.
It means you must destroy your object yourself per destroy method.

The garbage collector of such languages as Java, smalltalk, ruby work by
tracking references to one object. if no reference point to object, this
object is destroyed.

This would not work by xotcl. Xotcl object are localized per name (string)
and no reference. (And it is very flexible in most cases)
It can by hardly changed.
It is pity, if one consider that tcl has internal full garbage collector
based on Tcl_Obj (structure) with references counter.

This problem is no so dramatic if one use object aggregation.
So the aggregated object is deleted automatically if parent object
is to be destroyed.
But is can be rather hard by using "short-live" object (for example by
implementing special data structures in Xotcl).

The solution of this problem can be to add new create method in Xotcl.
To create object to use only as reference.
It means object lives only so long if the reference exist.
It will use internal standard tcl structures (as Tcl Stings, Integer, Arrays)

example usage

proc exampleScope {} {
     # create short-live Object for reference
    set ref [Object newReference]
    # using object
    $ref set var 11
    # be exit the object referenced by variable ref
    # will be deleted automatically
}

The best think is one can choose to use garbage collector
or not.
>Object newReference
will for example create one object and destroy it immediately.
So in such case the old method
>Object new
should be used.


Internal implementation.

The main thing is to tread Xotcl objects in the same way
as other tcl objects (Stings, Interger, Array) and use tcl garbage collector
I thing there should be a wrapper Tcl_Obj (new Type)

Here only the main idea
static Tcl_ObjType XOTclReferenceObjectType = {
  "XOTclReferenceObject",
  (Tcl_FreeInternalRepProc *) ourNewDestroyMethod,
  (Tcl_DupInternalRepProc *) NULL,
  UpdateStringOfXOTclObject,
  SetXOTclObjectFromAny
};

The newReference method must create such reference Tcl_Obj
and return it as result. Of course newReference must be implemented
in C in libxotcl.so.

What do you think about it?
I mean I can implement it but I am not sure how it would suite to another
concepts or future plans.
For example for xotcl objects created per newReference the destroy method make
no sense.
It can make also another problems that should be discused.


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

 Artur Trzewik
 http://www.xdobry.de

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

From: Andreas Kupries <andreask_at_activestate.com>
Date: Tue, 14 Oct 2014 09:59:54 -0700

21'th Annual Tcl/Tk Conference (Tcl'2014)
http://www.tcl.tk/community/tcl2014/

This is a reminder that Registration for the Conference is open and
can be done at

        http://www.tcl.tk/community/tcl2014/reg.html

Note that the holding period for hotel rooms has passed. To register
for a room, call 1-503-796-3851, speak to Mary Kirchner and mention
the Tcl Conference to receive the reduced rate.

See you in Portland,

Andreas Kupries
Tcl 2014 Program Chair
ActiveState Software Inc.
Vancouver, BC, Canada

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Tue, 13 Feb 2001 04:42:45 +0200 (EET)

I'm not sure if I should send this to Uwe and Gustaf directly or this
list, so if this is wasting bandwidth then tell me and I'll try to
remember to send further suggested updates directly to them. Anyhow
here are some changes I made:

- It bugged when a file did not end with a newline (this was actually the
cause of my earlier problem).
- Slightly changed the errorCode documentation section.
- Fixed some other HTML bugs (quite possibly caused by my previoues
ventures into playing with xodoc ;-).
- Removed a lot of space that was being fed out. This was problematic
when I use the <pre> tags. The downside is that the code looks rather
messy, but I might just be posting a kind of solution for that soon.

Anyhow, my version of the xodoc file is attached here.

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

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Mon, 6 Sep 2004 16:51:35 +0300 (EEST)

[self proc] inside a method that has been called inside an [ob eval] block
gives the result "eval" inside of the method we're in.

In practise this is now causing so many headaches I think I'm going to
give up on doing this package using XOTcl that way. There appears to be no
(working?) way to run a script within the 'context' of an object, in order
to easily parse data which is formed in the style of a Tcl script. This is
unfortunate as it would likely have offered clear performance benefits.

I may still try to do it directly with normal namespaces instead of XOTcl.

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

From: Uwe Zdun <uwe.zdun_at_uni-essen.de>
Date: Mon, 24 Sep 2001 17:28:14 +0200

Hi,

in the forthcoming XOTcl release will be several new filter features ... I've
already reported on the obj-filters. Another feature we have ready are
"filter guards". A filter guard is a condition whether a filter will be
executed or not. It is registration-centric, thus you can append the
conditions to the filter registration, example:

A instfilter {filter-1 {filter-2 {[self calledclass] == "::FigureElement"}}}

that means: filter-1 will always be executed (as in 0.85) .. filter-2 only
wenn self calledclass is ::FigureElement. Of course, you can call methods
from the filter guard, filters will not be applied to these calls.

Moreover, we have info (inst)filterguard and (inst)filterguard instcommands
on Object/Class ...

I've a half-working AOP extension written in about 100 lines of code with
this feature. Pointcuts can be defined in instprocs, so that you can do
something like:

Aspect PointCutBoundsChecking
PointCutBoundsChecking appliesTo {FigureElement Point}
PointCutBoundsChecking pointcut setXs {
  [[self] calls "Point" "setX"] ||
  [[self] calls "FigureElement "setXY"]
}
PointCutBoundsChecking before setXs {x} {
  if {$x < 100 || $x > 1000} {
    error "out of bounds x=$x"
  }
}


I hope to have a first version with the next XOTcl release ...

--Uwe

On Sunday 23 September 2001 12:08 pm, Catherine Letondal wrote:
> Hi,
>
> I guess there are interesting applications of XOtcl filters and
> mixins to aspect oriented programming? Are there any
> publications or work on this subject?
>
> Thanks,

-- 
Uwe Zdun
Institute for Computer Science, University of Essen
Phone: +49 201 81 00 332, Fax: +49 201 81 00 398
zdun_at_{xotcl,computer,acm}.org, uwe.zdun_at_uni-essen.de