Weblog Page

From: Jeff Hobbs <jeffh_at_ActiveState.com>
Date: Fri, 3 Dec 2004 15:29:29 -0800

> I am proud to announce XOTcl 1.3.4.
        ...
> MORE INFO
> XOTcl source, binaries and documentation can be obtained
> from http://www.xotcl.org

This works great out of the box on a small test set of
platforms. We will be incorporating this into the next
release of ActiveTcl (next week).

  Jeff Hobbs, The Tcl Guy
  http://www.ActiveState.com/, a division of Sophos

From: Ben Thomasson <ben.thomasson_at_gmail.com>
Date: Fri, 30 Sep 2005 11:52:10 -0400

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

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

From: Zoran Vasiljevic <zoran_at_archiware.com>
Date: Sun, 20 May 2001 13:40:21 +0200

On Sunday 20 May 2001 12:39, Artur Trzewik wrote:
>
> 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'd love to see such a thing. A good idea.

Cheer's
Zoran

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Fri, 17 Mar 2006 17:05:19 +0100

Scott Gargash schrieb:

> This works (I get the behavior I desire), but it means I have to 1)
> define a proc that duplicates the default behavior and 2) construct n
> identical copies of the implementation for the -setter proc, when
> really I can get by with the default behavior and one copy of the
> override behavior shared across all instances, just revectored the
> setter behavior once it's safe to do so.
>
there is as well the option to use a mixin or to use namespace import to
share the proc.

> # What I'd prefer
> Class create A -parameter {foo}
> A instproc init {args} {
> # [self] is valid, revector [self]'s foo setter from default to the
> side-effectful variant
> [self] parametercmd {foo -setter myfoo}
> }
> A instproc myfoo {p v} {
> my set $p $v
> # do side effects
> }
>
in general, it is certainly possible to parametercmd/instparametercmd; i
am currently
working on a general overhaul of parameter etc. based on a more general
slot
mechanism that generalizes parameters and object/class relations (class,
superclass, mixins, ...)
with more poweful ways to initialze data, etc. one can use e.g "...
superclass add " in the same
way than "mixin add", and in the same way as one can do this for
ordinary attributes.
While i am more interested in a powerful and extensible structure, i am
also condidering
extending the paramtercmd...

> Besides being more memory efficient, it seems to more clearly express
> my intent. As you say, a trace would work, but traces tend to look and
> feel a bit like magic.
>
not so bad:

Class create A -parameter {foo}
A instproc myfoo {var sub op} {
  puts "$var is now [my set $var]"
}
A instproc init {args} {
  my trace add variable foo write [list [self] myfoo]
}

A a1 -foo 123
puts HU
puts [a1 foo 234]


> I've seen the part of the tutorial about wrapping C-extensions with
> XOTcl, but is there a reference/tutorial for extending XOTcl in C?
> How would I go about reimplementing a method in C? Can I just use the
> vanilla Tcl API or do I need to compile/link against XOTcl also?
>
there were some recent postings in this regard. in short: look for e.g.
the gdbm integration part of the
xotcl distribution, or into critcl.

>
> One thing that has confused me so far is the "namespace on demand"
> concept. Where are instance variables stored if not in a namespace?
>
> % Object a
> ::a
> % a set foo 123
> 123
> % namespace exists a
> 0
>
> Where does Object a's foo variable reside?
>
xotcl allocates namespaces on demand. this is a speed and memory issue.
in earlier versions, every
xotcl object had its own namespace, and was quite heavyweight (around
2001). The namespace
allocation on demand lead to a significant improvement in speed and
memory, since most
objects do not need the namespaces. namespaces are allocated on demand,
when an object defines
procs or subobjects. When no namespace
is allocated, the variables are stored in a private hash-table. You can
force xotcl to allocate
a namespace for an object by "Object create a -requireNamespace"

>
> If I wanted to implement a method as a C function, how does the C
> function find the value of "[a set foo]" via the Tcl API? I.e., what
> would I pass as the varname to Tcl_GetVar()? Or do I need XOTcl's C
> API to look it up? Where do I install my C commands such that they
> are found automatically by XOTcl's method lookup alogrithm?
>
look at the XOTclSetterMethod() in xotcl.c, it is (currenty) quite simple.

hope this helps
-gustaf neumann

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Wed, 25 Apr 2001 23:27:53 +0200

On Wednesday 25 April 2001 20:51, Artur Trzewik wrote:
> Halo
>
> The problem is more complicated than I have expected.
> It is true, proc are not good for this purposes.
> Classproc are very good idea but it would complicate the model.
>
> It is really a program style not to use class methods.
> If you come from C++ or Java (brr...) you will seldom use it.
> Smalltalk-programmers will miss it (there are many smalltalk based
> languages) A main usage is individual instance creation
> (such as Factory Patterns in C++ or type based polymorphismus)
> for example
>
> MyClass createFromXML "...xml string"
> MyClass createFromFooObject myObject
>
> C++ programmers will write
>
> class MyClass {
> public:
> MyClass(XMLNode node);
> MyClass(FooClass myObject);
> };

 i would recommend to use "-methods" to tag the type; at the
 place, where you create instances of myclass, you will most probably
 know the kind of argument you are passing:
 
 Class MyClass
 MyClass instproc xml value { ;# convert xml value to internal rep
    ...
 }
 MyClass instproc obj value { ;# convert obj to internal rep
    ...
 }
 ...
 MyClass o1 -xml "...xml string"
 MyClass o2 -obj myObject


> > InheritClassProc instproc unknown {m args} {
> > foreach c [[self] info heritage] {
> > if {[info command ${c}::$m] != ""} {return [eval $c $m $args]}
> > }
> > next
> > }
> > Class instmixin InheritClassProc
>
> The solution do not do what I expect
> See this example. It demostrate how inheritable class method can be used
>
> Class TkWidget
> TkWidget proc testMe {} {
> set toplevel [toplevel [Object autoname .toplevel]]
> set inst [[self] create [Object autoname twidget] ${toplevel}.test]
> pack $toplevel.test
> return $inst
> }
> Class TkText -superclass TkWidget
> TkText instproc init {win} {
> text $win
> }
> Class TkEntry -superclass TkWidget
> TkEntry instproc init {win} {
> puts "window $win"
> entry $win
> }
> TkEntry testMe

 i see; what you want is not delegation to the class, where the
 proc is defined (in this case the call to [self] in testMe would
 return "TkWidget"), but you want to evaluate the method testMe in the
 context of the calling class ([self] in testMe will return "TkEntry")

 Fortunately, we have a questionable feature in xotcl, which allows this
 currently, but notice that you have limited interception capabilities.
 it is possible to call a proc directly, bypassing the xotcl dispatcher.
##################################################################
Class InheritClassProc
InheritClassProc instproc unknown {m args} {
  foreach c [[self] info heritage] {
    if {[info command ${c}::$m] != ""} {
      return [eval ${c}::$m $args]
    }
  }
  next
}
Class instmixin InheritClassProc
###################################################################

 a casual reader will hardly notice the difference, but instead of calling
 '$c $m $args', a call to '${c}::$m $args' is performed.

 if i look at your program, the main reason for using the class proc seems
 to be to call "pack" **after** init without the need to write it into
 TkEntry or TkText. You can also use filters or an instmixin to achieve the
 same behavior:

==========================================================================
Class TkPacker
TkPacker instproc init args {
  set r [next]
  pack [[self] set name]
  return $r
}

Class TkWidget -instmixin TkPacker
TkWidget instproc init {} {
  [self] instvar toplevel
  set toplevel [toplevel [Object autoname .toplevel]]
  [self] set name ${toplevel}.[string trimleft [self] :]
}
Class TkText -superclass TkWidget
TkText instproc init {win} {
  next
  text [[self] set name]
}
Class TkEntry -superclass TkWidget
TkEntry instproc init {} {
  next
  entry [[self] set name]
}
TkEntry a
==========================================================================

 This version has the advantage that you get more predictable widet names.


> I will try to use metaclasses for my problems.
> It can be good to take a look on other new objectbased languages
> ruby, self, python.
> How do these languages handle class methods?


 this is not an easy question; the language of this list which is closest
 to XOTcl is ruby, which has a single construct named "def" to define a
 proc or instproc (in xotcl terms). within a class definition, def Classname.methodname
 defines a class method. there is no word about inheritence of class procs in the
 documentation.

 self is quite different, since self does not have classes, but traits and mixins,
 which provide a bundle of methods through specially marked "parent" slots. since
 there are not classes, class methods can't be defined. As i see it, one needs
 can define two slots for traits, one defined as a parent slot (which will provide
 methods for the "instances", and another slot for a separate object, that can be
 reached via delegation, which will have the counterpart of a proc. Two objects can
 share a trait, therefore it is possible to define something like inherited class procs
 by "manually" assigning the appropriate slot to all involved objects. This is like defining
 per object mixins to all effected classes. therefore, the short answer is no, there
 is no direct language support for this behavior.
 
 python has a rather week oo support. it has no distinction between instproc and proc,
 all methods are defined by "def". python has no class methods. the trick to achieve
 a similar behavior in python is to define a "module" and to define in the module
 a function outside the scope of a class. Therefore: there is no way get inheritance.

 hope this helps
-gustaf

From: Andreas Kupries <andreask_at_activestate.com>
Date: Wed, 05 Jun 2013 12:56:52 -0400

[[ Notes:
   Abstracts and proposals are now due July 6, 2013
   [+ 2 weeks]
]]

20'th Annual Tcl/Tk Conference (Tcl'2013)
http://www.tcl.tk/community/tcl2013/

September 23 - 27, 2013
Bourbon Orleans Hotel
New Orleans, Louisiana, USA
http://www.bourbonorleans.com/

Important Dates:

Abstracts and proposals due July 6, 2013 [+ 2 weeks]
Notification to authors July 22, 2013 [- 2 weeks]
Author materials due September 2, 2013
Tutorials Start September 23, 2013
Conference starts September 25, 2013

Email Contact: tclconference_at_googlegroups.com

Submission of Summaries

Tcl/Tk 2013 will be held in New Orleans, Louisiana, USA from September
23 - 27, 2013. The program committee is asking for papers and
presentation proposals from anyone using or developing with Tcl/Tk
(and extensions). Past conferences have seen submissions covering a
wide variety of topics including:

* Scientific and engineering applications
* Industrial controls
* Distributed applications and Network Managment
* Object oriented extensions to Tcl/Tk
* New widgets for Tk
* Simulation and application steering with Tcl/Tk
* Tcl/Tk-centric operating environments
* Tcl/Tk on small and embedded devices
* Medical applications and visualization
* Use of different programming paradigms in Tcl/Tk and proposals for new
  directions.
* New areas of exploration for the Tcl/Tk language

Submissions should consist of an abstract of about 100 words and a
summary of not more than two pages, and should be sent as plain text
to <tclconference AT googlegroups DOT com> no later than August 5,
2013. Authors of accepted abstracts will have until September 2, 2013
to submit their final paper for the inclusion in the conference
proceedings. The proceedings will be made available on digital media,
so extra materials such as presentation slides, code examples, code
for extensions etc. are encouraged.

Printed proceedings will be produced as an on-demand book at lulu.com

The authors will have 25 minutes to present their paper at the
conference.

The program committee will review and evaluate papers according to the
following criteria:

* Quantity and quality of novel content
* Relevance and interest to the Tcl/Tk community
* Suitability of content for presentation at the conference

Proposals may report on commercial or non-commercial systems, but
those with only blatant marketing content will not be accepted.

Application and experience papers need to strike a balance between
background on the application domain and the relevance of Tcl/Tk to
the application. Application and experience papers should clearly
explain how the application or experience illustrates a novel use of
Tcl/Tk, and what lessons the Tcl/Tk community can derive from the
application or experience to apply to their own development efforts.

Papers accompanied by non-disclosure agreements will be returned to
the author(s) unread. All submissions are held in the highest
confidentiality prior to publication in the Proceedings, both as a
matter of policy and in accord with the U. S. Copyright Act of 1976.

The primary author for each accepted paper will receive registration
to the Technical Sessions portion of the conference at a reduced rate.

Other Forms of Participation

The program committee also welcomes proposals for panel discussions of
up to 90 minutes. Proposals should include a list of confirmed
panelists, a title and format, and a panel description with position
statements from each panelist. Panels should have no more than four
speakers, including the panel moderator, and should allow time for
substantial interaction with attendees. Panels are not presentations
of related research papers.

Slots for Works-in-Progress (WIP) presentations and Birds-of-a-Feather
sessions (BOFs) are available on a first-come, first-served basis
starting in August 5, 2013. Specific instructions for reserving WIP
and BOF time slots will be provided in the registration information
available in June 3, 2013. Some WIP and BOF time slots will be held open
for on-site reservation. All attendees with an interesting work in
progress should consider reserving a WIP slot.

Registration Information

More information on the conference is available the conference Web
site (http://www.tcl.tk/community/tcl2013/) and will be published on
various Tcl/Tk-related information channels.

To keep in touch with news regarding the conference and Tcl events in
general, subscribe to the tcl-announce list. See:
http://code.activestate.com/lists/tcl-announce to subscribe to the
tcl-announce mailing list.


Conference Committee

Clif Flynt Noumena Corp General Chair, Website Admin
Andreas Kupries ActiveState Software Inc. Program Chair
Gerald Lester KnG Consulting, LLC Site/Facilities Chair
Arjen Markus Deltares
Brian Griffin Mentor Graphics
Cyndy Lilagan Nat. Museum of Health & Medicine, Chicago
Donal Fellows University of Manchester
Jeffrey Hobbs ActiveState Software Inc.
Kevin Kenny GE Global Research Center
Larry Virden
Mike Doyle National Museum of Health & Medicine, Chicago
Ron Fox NSCL/FRIB Michigan State University
Steve Landers Digital Smarties

Contact Information tclconference_at_googlegroups.com


Tcl'2013 would like to thank those who are sponsoring the conference:

ActiveState Software Inc.
Buonacorsi Foundation
Mentor Graphics
Noumena Corp.
SR Technology
Tcl Community Association

From: Jeff Hobbs <jeffh_at_activestate.com>
Date: Tue, 26 Sep 2006 19:57:29 -0700

> Is there anything special about that combination that I need
> to know before compiling XOTcl on OSX?

xotcl may need private headers, I can't recall. Otherwise, no, it is
TEA-based and should just work.

  Jeff Hobbs, The Tcl Guy, http://www.ActiveState.com/

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Fri, 21 Jul 2006 17:24:26 +0300

On 20 Jul 2006, at 23:58, Ben Thomasson wrote:

> Hello all,
>
> Please that a look at http://xotcllib.sourceforge.net and reply
> with comments or critiques. XOTclLib is a library of debugging,
> logging, profiling, documentation, tracing, serialization, and unit-
> testing utilities.
> The documentation for the project is still in progress and will
> improve over time.

I tried to access this URL but it didn't seem to work. I just got an
empty page.

I have some stuff which might be useful for that, like a profiler
tool and a debug output library which is useful both for with Tcl and
XOTcl.

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

From: Kurt Stoll <kstoll_at_echelon.com>
Date: Sun, 26 Feb 2006 11:24:55 -0800

Thanks! That helps. And, yes, that was what I had in mind. I had
similarly simple examples, but, when I said that I couldn't come up with a
simple example, I meant that I couldn't come up with one that had a
justifiable need, without getting reasonably complex.

I like both of the last two solutions, at least to some extent (the first
one is, as you said, "rude"). I had proceeded down an approach similar to
the second one, and found that it works. It just seems as if it is a
general enough requirement that the language should have built in support
for it (and I thought it might already be there and I couldn't find it).
But, given the extensible nature of XOTcl (and Tcl, in general), I suppose I
can add it to my environment and not worry about the rest of the world.

The last solution is one that I had not considered. I find it intriguing
and may use it as well. My first objection was that a class proc does not
normally have access to instance variables. But, this can be solved by
passing in the object itself. This still feels kind of wrong, but I can
imagine there may be times when it works.

Finally, I did not appreciate all of the complexities that would be involved
with eliminating polymorphism. (Of course, I don't really want to eliminate
polymorphism; I just want to start the search higher up the tree.) I'm just
glad there is someone in a position to appreciate, understand, and plan for
these complexities.

Thanks again,
Kurt Stoll

From: Gustaf Neumann <Gustaf.Neumann_at_wu-wien.ac.at>
Date: Thu, 28 Dec 2000 19:40:22 +0100 (CET)

>>>>> "seva" == seva <seva_at_design.kiev.ua> writes:
>> On Tue, 26 Dec 2000 seva_at_design.kiev.ua wrote:
>> >
>> > 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 behavior is intended: from a "programming language point of view" you
>> can not predict whether a destroyed class is going to be redefined or not.
>> There could be another class with the same name, but with different
>> semantics.

seva> Ok, I agree with that point :)) (But does'nt like it too much :)) )

We have discussed the redefinition of Classes recently, and we
are thinking about ways to improve it. However, for the time being
you can use something like the following (take care, this version
is very simplistic and assumes that the new class is defined exactly
like the original

===============================================================
# The following create method is non-destructive, it lets
# exiting classes untouched
Class CheckCreate
CheckCreate instproc create {cn args} {
  puts "[self] [self proc] $cn <$args>"
  if {[[self] isclass $cn]} {
    puts "Dont redefine $cn, ignore '$args'"
  } else {
    next
  }
}
#overload create of the Metaclass
Class mixin CheckCreate
===============================================================

you can use it later like in the following example: the
create method, which is implicitly invoked, does not delete
the old class in cases it exists already....

===============================================================
Class A
Class B -superclass A
B a

foreach i {instances heritage} {puts "$i of B:\t[B info $i]"}
puts stderr =============
Class B -superclass A
foreach i {instances heritage} {puts "$i of B:\t[B info $i]"}
===============================================================


I would expect that the solution above is quite similar to what you
have already achieved via filters....

The redefine problem of the filter method, that you mention
in your mail, looks like a bug to me, that we should fix in the next
release. In the meantime, you should be able to use something like
the following: you can redefine "instproc" to check, whether the new
definition of a method is a definition of a filter, and if yes, you
can register the filter again automatically. For simplicity, the
following piece of code assumes, that the filter is defined in the
same class for which it is registered.

==========================================================================
# The following instproc method circumvents a bug in XOTcl 0.84
# and earlier
Class FilterInstproc
FilterInstproc instproc instproc {name args} {
  set filters [[self] info filter]
  next
  if {[lsearch $filters $name]>-1} {
    puts "redefined filter $name"
    [self] filter $filters
  }
}
# overload insproc
Object instmixin FilterInstproc
==========================================================================

with this definition, your example will work as expected.....

best regards

-gustaf neumann