Weblog Page

From: Uwe Zdun <uwe.zdun_at_uni-essen.de>
Date: Fri, 19 Oct 2001 14:02:02 +0200

On Friday 19 October 2001 01:44 pm, Theado, Brian P. wrote:
> On Fri, 19 Oct 2001 09:07:31 +0200, Gustaf Neumann wrote:
> > the xotcl binaries are built with tcl 8.3.2.
> > therefore it should work without compiling only with
> > 8.3.
> >
> > however, when it is compiled with 8.4, it will work.
>
> I remember that stubs support was recently added to xotcl.
> From the above, I gather stubs support is not being used
> when compiling the distributed binaries. Is there a reason
> why not? It seems like it is a low cost (simply add the
> "-DUSE_TCL_STUBS" compile switch?) thing to do in order to
> get the benefit of distributing more widely usable binaries.
>

We produce both a lib with tclstubs support and one without. Since Tcl does
not export everything we need in the stub table, we had to build some
workarounds ... these are slower than the direct calls. There's a little
glitch in linking in 0.9 binary release (we will put out a patch today), but
then it should work. So you can choose which one you want to use.

However, in Tcl versions 8.3.1 and 8.4a3 there is a crash when using the stub
library of one of them with the other Tcl version: A Tcl_FindHashEntry call
crashes before Tcl_FindHashEntry is reached. In 8.3 Tcl_FindHashEntry was a
macro in tcl.h, and it is now moved to the stub lib in 8.4. Perhaps something
went wrong in this transition.

At least, loading the stub-supported lib into the sane Tcl version functions
...

--uwe

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

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Fri, 30 Sep 2005 19:28:06 +0200

-------- Original-Nachricht --------
Betreff: Re: [Xotcl] memory leak analysis
Datum: Fri, 30 Sep 2005 19:25:52 +0200
Von: Gustaf Neumann <neumann_at_wu-wien.ac.at>
An: Ben Thomasson <ben.thomasson_at_gmail.com>
Referenzen: <44eb229c0509300852m10e879a7k_at_mail.gmail.com>



Ben Thomasson schrieb:

> Hi,
>
> I am writing a simulation engine using xotcl. I have noticed as I
> create and destroy objects over time this process will use all
> available memory. I have tracked down and eliminated old objects.

what do you mean by "old objects"?

> With the object count staying roughly constant the memory continues to
> increase at about 1k per second. What tools or tricks are useful for
> tracking down memory leaks in Tcl or XOTcl?

are you using theads?

If something is leaking memory it is most likely more complicated than
just object creation
and destruction. At least on my system the following script runs without
any leaks.

for {set i 1} {$i < 10000000} {incr i} {
 set o [Object create obj-$i]
 $o destroy
}

can it be that you are somewhere building a table (assoc. array)
with object names?

xotcl has a bunch of compile flags to report memory usage, one can compile
tcl with a flag that enables a command for memory checking.

-gustaf

>
> Thanks,
>
> Ben
>
> --
> You know you have reached perfection of design not when you have
> nothing more to add, but when you have nothing more to take away.
> --Antoine de Saint Exupéry
>
>------------------------------------------------------------------------
>
>_______________________________________________
>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: Tue, 26 Feb 2008 22:46:42 +0100

Hi everybody,

XOTcl is now available from sourceforge,
in additon to www.xotcl.org:

SourceForge project page
http://sourceforge.net/projects/xotcl

Download link (with mirror and maxmind geo location):
http://downloads.sourceforge.net/xotcl/xotcl-1.6.0.tar.gz

best regards
-gustaf neumann

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Mon, 6 Sep 2004 17:11:29 +0300 (EEST)

On Mon, 6 Sep 2004, Uwe Zdun wrote:

> I would like to make it impossible to call doStuff directly here, as in the
> example below, but this would
> require changes to the Tcl core or has a performance impact; so we chose to
> live with the problem that
> procs can be called directly via the namespace

That's fine, just so I know that's not the intended use. Though I still
think it may be interesting to have a method that would allow access to
methods and everything in that fashion, but that may not be feasible.

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

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Thu, 15 May 2003 13:28:28 +0300 (EEST)

On Thu, 15 May 2003, Uwe Zdun wrote:

> you're right, there is no mega-widget packet for XOTcl (I often use Tcl
> megawidgets such as Bwidgets) ... yet it is
> quite simple to integrate Tk and XOTcl; and build you're own megawidgets.
> I found that wrapping the simple Tk widgets (or Bwidgets) does not make too
> much sense, but building classes that represent more complex GUI elements is
> very useful. The most simple thing you can do is to store the widget
> IDs of the associated widget in a variable on the object representing it.

I have a small bunch of classes and methods that makes using Tk with XOTcl
a good bit easier (IMO, of course). If I remember later I can stick them
up somewhere. Just remind me :-)

(Have to go to a meeting soon)

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

From: Rene Zaumseil <r.zaumseil_at_freenet.de>
Date: Mon, 9 Apr 2007 20:19:02 +0200

Hi,

as a novice xotcl user I found the following crash.

% package req XOTcl
1.5.3
% namespace import ::xotcl::*
% Object x
::x
% x configure -set
Speicherzugriffsfehler

I got the same behaviour with a self build xotcl extension (IRIX system,
tclkit, tcl version 8.5) and with the last ActiveTcl 8.4 version under linux.


rene

From: Gustaf Neumann <neumann_at_wu.ac.at>
Date: Fri, 26 Jul 2013 02:55:51 +0530

Dear all,

I've added one more script to the example script collection for NX:
the game of Ludo (in German "Mensch ärgere dich nicht"), which
is essentially the result of the airplane flight to my vacation:

https://next-scripting.org/xowiki/file/docs/nx/examples/tk-ludo.html?html-content=1

One interesting part is the usage of the "expression converter":
NX supports user-defined argument checkers and converters,
where converters might transform arguments. This can be
used e.g. to normalize values. In this game, this feature is used
to "normalize" expressions to values. This means, instead of
having to write

    $obj point [expr {$x-$d}] [expr {$y-$d}] [expr {$x+$d}] [expr {$y+$d}]

one can write

    $obj point $x-$d $y-$d $x+$d $y+$d

when the 4 arguments of method "point" are defined as expression
converters. This is at least an option, when performance is not critical.

best regards
-gustaf neumann

From: Zoran Vasiljevic <zoran_at_archiware.com>
Date: Fri, 22 Feb 2002 11:11:54 +0100

Hallo !

The problem of automatic object garbage collection was itching me
for some time now. So I did spend some time and here is the solution.

The basic idea is to auto-destroy objects created within a procedure
when the procedure goes out of context. I would like to hear some
comments from Uwe/Gustaf and/or other experienced XOTcl'ers.
Similar might even be included in 1.0 if people need such thing.
I definitely do.

The below depends on the array "__gc" created in the calling's procedure
context, one class proc "__gc" and one new costructor, "volatile"
as shown below.

Attached is a piece of test-code to verify the operation.

Cheer's
Zoran

#------- CUT HERE -------

#
# Gets invoked from variable unset callbacks.
#
Class proc __gc {n1 n2 op} {
  set l [::expr {[::info level] > 0}]
  if {![::uplevel $l ::info exists __gc($n1)]} {
      ::incr l
  }
  ::uplevel $l \$__gc($n1) destroy
}

#
# Used to instantiate "volatile" objects.
# These get auto-destroyed when the procedure goes out of context.
#
Class instproc volatile {n args} {
  ::upvar $n v
  ::trace variable v u [list Class __gc]
  ::set v [[self] autoname -instance [self]]
  ::uplevel [::expr {[::info level]<2?1:2}] ::set __gc($n) $v
  ::eval [self] create $v $args
}

#
# Test routines
#
proc aa {} {
  _foo_ volatile obj
  $obj test
  bb
}
proc bb {} {
  _foo_ volatile obj
  $obj test
  cc
}
proc cc {} {
  _foo_ volatile obj
  $obj test
  unset obj
  dd
}
proc dd {} {
  _foo_ volatile obj
  $obj test
}
proc gctest {} {
  Class _foo_
  _foo_ instproc test {} {puts stderr [self]}
  set cmds [info comm _foo_*]
  aa
  if {[info comm _foo_*] == $cmds} {
     puts stderr ok
  } else {
     puts stderr fail
  }
}

#------- CUT HERE -------

From: Victor Mayevski <vitick_at_gmail.com>
Date: Fri, 21 Jan 2011 14:52:55 -0800

Hello Gustaf,

After adding attributes to an object, and creating nested objects
within it, I need to list those nested objects. When I do [myobject
info children], "::myobject::slot" is listed among other nested
objects that I created. Since my code did not specifically create the
"slot" object (it is an artifact of creating attributes), it seems
that it should not be listed along with my scripted objects, perhaps
[myobject info lookup children] is a better place to list the "slot"
object?

Thanks,

Victor

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Fri, 20 Oct 2006 22:11:42 +0200

Kristoffer Lawson schrieb:
> Are these stored anywhere within XOTcl? If not, I presume that
> information is not currently available to the script end? I'm just
> wondering as I think I could make good use of that with object
> recreation based on its serialised form.
Kristoffer,

i am not sure, i understood your question. however, there is no hidden
information
in xotcl, which is not accessible for a script writer.

The default values for attributes are stored as ordinary attributes in
the slot objects. the
Attribute slot objects have for this purpose the attribute named
"default". See:
http://media.wu-wien.ac.at/doc/tutorial.html#attribute-slots

If objects are serialized with the xotcl serializer, they are serialized
with their current settings.
In other words, the object created after derserialization is identical
to the object which was
serialize.

Per default, the slot objects are created as child objects of the class.
That means, if
someone serializes the class as well, the default values are kept as
well in the serialized
state.

-gustaf