Weblog Page

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Sat, 04 Dec 2004 00:16:19 +0100

Dear XOTcl Community,

I am proud to announce XOTcl 1.3.4.
Major changes relative to 1.3.1 are:

  - Qualitative Improvements

     * Improved code quality:
       + fixed possible segmentation violations in free memory reads
         (many thanks to Zoran Vasiljevic for his help with purify)
       + fixed "self callinglevel" when uplevel was called from uplevel
       + Improved portability (many thanks to Jeffrey Hobbs)
       + fixed nonposargs
       + fixed configure in connection with enable-symbols and
         for aolserver configuration
       + extended regression test

     * Improved Functionality
       + Producing error messages when a non-existing proc/instproc
         is tried to be deleted
       + fixed "exists" method for objects with namespaces by using
         a namespace resolver
       + fixed return code for unknown handling in next
       + reduced memory consumption for objects and classes with procs/instprocs
         of about 14%

     * Improved Documentation

MORE INFO
  XOTcl source, binaries and documentation can be obtained
  from http://www.xotcl.org

Greetings
-gustaf neumann

From: Gustaf Neumann <Gustaf.Neumann_at_wu-wien.ac.at>
Date: Thu, 16 Nov 2000 18:56:09 +0100 (CET)

---

>>>>> "Zoran" == Zoran Vasiljevic <zoran_at_munich.com> writes:

Zoran> ------Original Message------
Zoran> From: <uwe.zdun_at_uni-essen.de>
Zoran> To: Zoran Vasiljevic <zoran_at_munich.com>
Zoran> Sent: November 14, 2000 4:37:09 PM GMT
Zoran> Subject: Re: XOTcl, threading and AOLserver ?

Zoran> Hi Uwe !

>> So if you like to volunteer to help out, you're invited :)

Zoran> Indeed. The modified src/xotcl.c.mod and src/xotclInt.h.mod
Zoran> are attached. Run diff against 0.82 versions and you will
Zoran> see the changes. There are very few of them (3 - 4), all are
Zoran> marked with /* zv */ comments so it's easy to spot them.

Dear Zoran,

many thanks for your contribution!

Zoran> Basically, the global_objects array is now member of the runtime
Zoran> state so as the errorCount (the only one local static!!).

I see the point for errorCount, but global_objects is only
initalized once and never written. Therefore, it should be safe
to keep it global. Do i miss something?

Zoran> Did test on Solaris 2.5.1 with Purify 4.2 and it seems to work
Zoran> w/o problems. Also, Linux/Suse works fine as well.

Thanks for the Purify test, this is good news (we have no Purify).

Zoran> Hey, I like the idea of putting the runtime state in
Zoran> global NS clientData. This IS a good trick !

we did not have much other options.

Zoran> PLS, check wether this is ok for you. You might include it
Zoran> in the standard distro if you like (I'll appreciate it, so
Zoran> I don't have to patch it for any new version.:)

we are in the process of rolling out 0.83, your
patches should be included in this verison.

Zoran> BTW, new versions...
Zoran> o. do you plan to modularize the xotcl.c? It's grown big!

we have done some first steps, but it will take some more time.

Zoran> o. the 1.0 version: if? when? what functionality planned?

the forthcoming version comes with "inst mixins" which are
similar to per-object mixins, but on the class level. instmixins
make it easy to intercept e.g. the predefined methods of Object.

Zoran> Again, thanks for your nice work. I'm going to attack the
Zoran> problem of copying the interpreter state with xotcl... I'll
Zoran> drop you a note.

Zoran> Cheer's (and tschuess....)
Zoran> Zoran Vasiljevic
Zoran> Munich, Germany.

Your input is very much appreciated
best regards

-gustaf

Zoran> ______________________________________________
Zoran> FREE Personalized Email at Mail.com
Zoran> Sign up at http://www.mail.com/?sr=signup

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Fri, 24 Jan 2003 17:35:24 +0100

On Friday 24 January 2003 17:03, Kristoffer Lawson wrote:
> On Fri, 24 Jan 2003, Gustaf Neumann wrote:
> > > Oh, I meant to say that an option to [new] is not necessarily the best.
> > > Often (at least in my case) it is a method of an object which creates
> > > an instance and returns it, like:
> > >
> > > set msg [$cmdReader getNewMessage]
> > >
> > > So at the level where I want the automisation I don't directly call
> > > new. Naturally this could be changed to accommodate the use of new, but
> > > then my interface wouldn't be as cleanly split up.
> >
> > i don't get your point: getNewMessage has to create the Object,
> > so it can use certainly new (with all variants). is your argument:
> > the caller of newmessage should decide, whether the created
> > object should be dynamically reclaimed or not?
>
> Yes, obviously getNewMessage will use [new], but it wont be using [new
> -bind] for obvious reasons! The caller is the one that wants to bind it to
> a variable, so yes my argument is that the caller should decide. In fact,
> it could be argued that the same applies to -volatile. That there are
> cases when a new object should be returned by some method other than [new]
> but the caller is generally the one that wants to decide the dynamics of
> the object.

 The caller can certainly do with the object whatever she wants.
 if these are properties needed in the creation method they
 have to be passed somehow there, or the object can be altered,
 or one can put a mechanism on top of the creation to handle this.
 I personally would not have a problem in using two different method
 names for the different cases, like
   set msg [$cmdReader getMessage]
   set msg [$cmdReader getNewMessage]
 or to use an option like in
   set msg [$cmdReader getMessage -volatile]

 i agree, using -bind here with an explicit variable name is not
 syntactically pleasing...

-gustaf

>
> / http://www.fishpool.com/~setok/
>
>
> _______________________________________________
> Xotcl mailing list - Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl

-- 
Univ.Prof. Dr.Gustaf Neumann
Abteilung für Wirtschaftsinformatik
WU-Wien, Augasse 2-6, 1090 Wien

From: Matthew Dodwell <mjd_at_orcaspirit.co.uk>
Date: Tue, 28 Feb 2006 23:25:07 -0000

Dear All,

I've got a question about the behaviour of the destroy / instdest methods;


The code below outputs the following:

Base init ::MyBase
Destroy
Base destroy ::MyBase
Destroyed

... which is what I would expect. However, if the "next" call in TBase
destroy is commented out, the output is:

Base init ::MyBase
Destroy
Base destroy ::MyBase
Destroyed
Base destroy ::MyBase

The extra call to destroy occurs when the command interpreter closes, so
must mean that MyBase was not properly destroyed because "next" was not
called. This is probably the intended behaviour, but it is difficult to work
it out from the examples given in
http://media.wu-wien.ac.at/doc/tutorial.html.

Can somebody tell me the creation and destruction processes that go on
"behind the scenes" in XOTcl?

Also, it would be helpful if the differences between XOTcl and other OO
languages, say C++, were highlighted as I know I have made assumptions which
turn out to be wrong.

------------------------------------------------------------------------
Here is the code:

package require XOTcl; namespace import -force xotcl::*
package require Tcl 8.4

# define a class

Class TBase

TBase instproc init {} {
 my instvar Children Parent
 puts "Base init [self]"
 next
}

TBase instproc destroy {} {
 my instvar Children Parent
 puts "Base destroy [self]"
 next
}

# do something with it

TBase MyBase

puts "Destroy"

MyBase destroy

puts "Destroyed"

# code ends

Thanks

From: Stefan Sobernig <stefan.sobernig_at_wu-wien.ac.at>
Date: Sat, 04 Apr 2009 14:48:38 +0200

Jeff,

> Message: 2
> Date: Fri, 03 Apr 2009 11:29:34 -0700
> From: Jeff Hobbs <jeffh_at_activestate.com>
> Subject: Re: [Xotcl] XOTcl packages
> To: Victor Mayevski <vitick_at_gmail.com>
> Cc: xotcl_at_alice.wu-wien.ac.at
> Message-ID: <49D6558E.200_at_activestate.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 03/04/2009 11:24 AM, Victor Mayevski wrote:
>> I really like that XOTcl is being included with ActiveState
>> distribution, and even updates via teacup are working. But there is
>> one issue - why is it that the rest of XOTcl packages (comm,
>> serializer etc) are not being included?
>
> The teapot is designed for individual packages (though they can have
> dependencies). In building, it goes through the usual configure / make
> / install steps. XOTcl only packages up the core library when it does
> that. The other packages would be best handled separately somehow.

Couldn't teacup provide the "--with-all=yes" configure flag so that the
accompanying infrastructure is included?

//stefan

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Wed, 28 Sep 2005 22:57:54 +0200

Hi everybody,

As others have pointed out the TIP is not easy to swallow and has to
be digested in multiple courses, here is some partly feedback:

> Some changes will be necessary. Certain aspects of XOTcl syntax are
> peculiar from a conventional OO point-of-view, and it is deeply
> unfortunate that a very large number of methods are predefined in
> the XOTcl base class.

It is common for the conventional OO view to
define common behavior for all Objects in the top-Level class, look
e.g. Ruby, Python, Smalltalk or Java. Certainly the common behavior
changes from language to language. The "deeply unfortunate"
does not seem appropriate.

Can you explain, more about the envisioned object system?
I am confused about the TIP. It says:

> Standard Metaclasses
> XOTcl defines two standard Metaclasses, xotcl::Object and
xotcl::Class....

This is not true, only xotcl::Class is a meta-class.

> The new core object system will ... be ... based on the metaclasses
> oo::object and oo::class.

I am not sure whether there is a misconception about xotcl or about
metaclasses in general. Since the TIP says:

> meta-classes: These are subclasses of class, which permit more
> advanced customization of class behaviour.

which is partly true (except, that "class" is a metaclass as well (at
least in xotcl) , furthermore, without a meta-class, one cannot create a
class.

If the statement in the TIP is true (two basic meta-classes), some of
the class diagrams are wrong. Another consequence is that the proposed
object system can only create classes and no simple objects (every
instance will be able to create new instances). This is quite
interesting, xotcl can achieve this currently via providing Class as
instmixin on Object. .... But most likely this was not intended.

> filters: These are constraints (implemented in Tcl code, naturally)
> on whether a method may be called

if this is intended to describe, what filters in xotcl are, this is
incorrect. If this is something different form xotcl, please explain.
This description sounds more like a "guard" in xotcl.

> In XOTcl, every class and every object has an associated namespace.

mostly true. Strictly speaking, xotcl allocates namespaces on
demand. Namespaces are only allocated, when per-object procs or subcommands
(e.g. nested objects) are added, since we need namespaces with tcl's c
api as method repositories). If one uses objects with variables or
using inherited methods, no namespace is allocated. So, the
vast majority of objects in real life applications have no tcl-namespace.
This lazy namespace allocates improves
object allocation speed and - more important - saves a lot of memory
(see space comparison of objects on the xotcl home page). Do you plan
to change this?

>The namespace associated with a class ::myclass is
::xotcl::classes::myclass;

This is as well only partly true. myclass has a lazy namespace like
objects for procs or subobjects. It has as well a
second namespace as method repository for its instances with the
mentioned name (the variable part of the namespace is not used).

Since this section is called differences to xotcl: how is this intended
in oo::tcl?


> Exported procs appear as object subcommands; non-exported procs do
> not, but remain available as subcommands of the my command. In this
> way, the object itself can still use them, but they need appear in
> the object's interface only if desired.

you seem to mean this literally. even inside an object, you cannot call an
private (non-exported) method by
    [self] p-method
 but only by
    my method
why is this? i am not aware of any oo-language with such an
restriction. or is this a misinterpretation?

> .. oo::define
i have argued my concerns in length in an another mail.

>... names: export and unexport.

i would call these rather "protected" and "public". Tcl's namespace
exports are not about protection but about but about providing
forwarders. One can call any tcl method of a namespace, no matter
whether this is exported or not. This is conceptually different to the
protection where some other object should not be able to call a
protected method .

The TIP says:

> oo::object name
> Constructs a new object called name of class
> oo::object; the object is represented as a command in the current
> scope. ... If name is the empty string, oo::object generates a name
> automatically that is guaranteed to not clash with any existing
> command name.
....

> The new object has two predefined non-exported methods: eval and
> variable. Other subcommands and other behaviour can be added using
> oo::define
...

> When an attempt is made to invoke an unknown method on any object,
> the core then attempts to pass all the arguments (including the
> command name) to the public unknown method of the object. If no such
> method exists, an error message is generated. Instances of the core
> oo::object class do not have an unknown method by default.

> oo::class has the methods "create", "new" and "unknown"
>

just to be sure:
  oo::object is an instance of ::oo::class and has superclass
  oo::object (please make this in the TIP more explicit; please define
  instance-of relationships in the suggested class hierarchy to be
  clear about what is an instance of what?)

This raises a lot of questions:

  - why you want to create an direct instance of oo::object. I would
     think, you won't.

  - why has oo::define a "variable" method (i assume a new name for
     xotcl "instvar") when it has no set, append, etc, which are part
     of "struct"; i would assume that oo::object is designed so
     minimal that it cannot contain variables. i wonder, whether it
     makes sense to call "oo::object" object at all.

  - while we are on this topic: is it intended that an oo::class
     instance cannot contain variables (oo::class has no class
     variables)?

  - why is the description of what i believe is the behavior of the
     method unknown of oo::class part of the description of object?
     (what happens when you call "oo::object somename")

  - why is there an alternate way to specify "new" (via empty strings)
     in the core? let users do this (e.g. via mixins) if they want it.

  - why has oo::object no unknown. even namespaces have it
     nowadays. if i interpete correctly and one calls on an instance
     o1 of oo::object with the method "bar", then some built-in
     magic calls "o1 unknown bar"; if this is not defined, then
     "o1 unknown unknown bar" is called and the loop is detected? if
     the system calls internally "o1 unkown", then it is certainly
     part of the interface and should be defined and documented in
     oo::object.

 - i did not see a "class" method; intended?

 - what is the exact sequence of steps during object creation. i am
     not sure what you have in mind: how is the class assigned, when
     and how are the configuration parameters evaluated (since you
     dropped the configure method "deliberately")

I would suggest to drop the following sentence, which confuses me,
since i would assume that the xotcl linearization should be left as it
is.

> Inheritance will follow the XOTcl pattern (except with a somewhat
> different class hierarchy, of course)

i am running out of time now, two simple questions:

>next The next command allows methods to invoke the implementation of
> the method with the same name in their superclass (as determined by
> the normal inheritance rules; if a per-object method overrides a
> method defined by the object's class, then the next command inside
> the object's method implementation will invoke the class's
> implementation of the method). The arguments to the next command are
> the arguments to be passed to the superclass method; this is in
> contrast to the XOTcl next command, but other features in Tcl 8.5
> make this approach viable and much easier to control. The current
> stack level is temporarily bypassed for the duration of the
> processing of the next command; this is in contrast to the XOTcl
> version of the next command, but it allows a method to always
> execute identically with respect to the main calling context.

I try to extract the differences to "next" in xotcl,

  - one difference is that one has now to specify the argument list (i
     don't see the advantage)
  - "executing in the same callframe" seems a problem to me. what
     happens with upvar, uplevel, debuggers? some of the information
     like the current class are kept on the stack. How will this be
     realized? after next the calling proc continues in the original
     frame. how will this work?

why is next changed? have i interpreted something wrong?

> It is an error to invoke the next command when there is no
> superclass definition of the current method.

What is a superclass definition of a method? Should i read this as "an
error is issued when next is called on non-shadowed methods"? This
would make it quite ugly to write generic interceptors, since all next
calls have to be wrapped in "catch"es.

concerning self: when i see correctly,
 - a few subcommands were folded into complexer ones returning more
   information (e.g. "self caller" is essentially "[list [self
   calllingobject] [self callingclass] [self callingproc]]") which
   makes it slower to produce and consume this info, especially, when
   only a part of this is needed. These infos are mostly used in
   speed sensitive situations such as filters or debuggers or tracecs,
   which call these commands frequently.

 - a few subcommands are removed (info for transparency
   for interceptors, isnextcall). Why is this? Is your plan to drop this?

 - a few new subcommands "self object" (equivalent to "self", why is
   this needed?) and "self namespace" (2 comments about "self
   namespace": self returns in general information about incovation
   records on the callstack, so this subcommand should not be there;
   why is this needed at all, when objects are namespaces?)

best regards
-gustaf neumann

From: Victor Mayevski <vitic_at_mayevski.us>
Date: Sat, 19 Dec 2009 14:26:26 -0800 (PST)

Any news on XOTcl 2.0?
Sorry for being so impatient. :)
I have several projects in the queue but I want wait for XOTcl 2.0 so I can use the latest features.

Thanks

From: Uwe Zdun <uwe.zdun_at_uni-essen.de>
Date: Tue, 30 Jan 2001 10:20:40 +0100

On Tuesday 30 January 2001 10:09, Catherine Letondal wrote:
> Kristoffer Lawson wrote:
> > Is there any plans for an XOTcl presence there? I was thinking of going
> > and it'd be great to meet the developers and/or users. It might also be
> > worthwhile presenting some systems people have used XOTcl for, along with
> > an actual presentation of the project.
>
> This would be great! When and where will this meeting take place? The only
> information I could find is about last year's meeting
> (www.tu-harburg.de/skf/tcltk/ ).
>

Hi,

we were discussing to submit something, but aren't sure about that yet. It
would be great if someone else could also present something, as Kristoffer
suggested. I'll forward the announcement & CFP to the mailing list.

--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: Uwe Zdun <uwe.zdun_at_wu-wien.ac.at>
Date: Tue, 16 Sep 2003 11:48:32 +0200

Michael,

this problem does not seem to exist anymore in the forthcoming 1.1
release ... in the 1.0.* releases it should work to use the
xotcl::interp command (which pre-initializes xotcl in the child interp)
instead:

 package require XOTcl

 xotcl::interp create Interp
 Interp eval {package require XOTcl}
 xotcl::interp delete Interp

Uwe



On Monday 15 September 2003 23:15, MichaelL_at_frogware.com wrote:
> The following script produces a "Tcl_Release couldn't find reference for
> 0x..." message followed by an "abnormal program termination" when Tcl
> exits:
>
> package require XOTcl
>
> set Interp [interp create]
> $Interp eval {package require XOTcl}
> interp delete $Interp
>
> As you can see, XOTcl is being loaded once in the main interpreter and
> once in a sub-interpreter.
>
> I'm running XOTcl 1.0.2 with Tcl 8.4.2 and 8.4.4 on Windows.

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

From: BRIAN THEADO <brian.theado_at_usa.net>
Date: 11 Jul 2001 09:34:11 EDT

Gustaf Neumann <neumann_at_wu-wien.ac.at> wrote:
>the only difficulties i see is
>for older tcl-version not supporting the stub library.

I encountered some issues with undefined references while trying
to build libxotcl.so using stubs on Linux.

Here's what I did:
Added the following lines to the top of function Xotcl_Init
in the file xotcl.c:
 #ifdef USE_TCL_STUBS
    if (Tcl_InitStubs(in, "8.1", 0) == NULL) {
        return TCL_ERROR;
    }
 #endif

Compiled with the additional flag -DUSE_TCL_STUBS

Linked libxotcl.so against libtclstub.a


Here are the undefined references I encountered:
One set of undefined references was due using the macro version
of TclNewObj instead of the function version (Tcl_NewObj) in
xotclInt.h. This can be fixed with an extra #ifdef USE_TCL_STUBS

The other undefined references stem from the use of the following
functions:
    Tcl_FormatObjCmd
    Tcl_IncrObjCmd
    Tcl_InfoObjCmd
    Tcl_RenameObjCmd
    Tcl_UplevelObjCmd
    Tcl_UpvarObjCmd
    Tcl_VariableObjCmd

I'm assuming these can be fixed by using Tcl_EvalObjv to access
the Tcl commands instead of calling them directly. I haven't
tried it yet, but it seems reasonable to me.

____________________________________________________________________
Get free email and a permanent address at http://www.amexmail.com/?A=1