Weblog Page

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Sat, 21 Oct 2006 00:32:37 +0300

On 20 Oct 2006, at 23:11, Gustaf Neumann wrote:

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

I don't mean the state of the object at time of calling, in the sense
of slots, but the values passed to the constructor on object
creation. The args to 'init'. The reason for this is that it might
not be enough to just create the object with the appropriate state,
but it might need to go through the 'init' stage as well, so the
proper initialisation chain is done (f.ex. might be calls to other
things taking place there, registration with managers etc). After
that, slots can be set.

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

From: Uwe Zdun <uwe.zdun_at_wu-wien.ac.at>
Date: Mon, 12 May 2003 17:28:52 +0200

hmm ... Can you provide a bit more detail? where have you installed xotcl?
from where do you run it? what is the setting of the variable auto_path (
use: puts $auto_path at the beginning your program)?

Uwe


On Monday 12 May 2003 16:35, MichaelL_at_frogware.com wrote:
> With XOTcl 1.0.2 on Windows 2000 I get the "Cannot locate the XOTcl
> library on your system!" message despite the fact that the library is
> successfully found. I read the message in the archives on this, but a) the
> workaround didn't seem to work for me (if I understood it correctly) and
> b) it seemed like 1.0.2 was supposed to fix the problem (but obviously
> didn't in my case).

-- 
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: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Fri, 22 Sep 2006 20:27:03 +0200

Hi everybody,

XOTcl 1.5.1 is available. This is mostly a bugfix release
+ improved interface for implementing XOTcl methods in C.

all the best
-gustaf neumann

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

Announcing XOTcl 1.5.1
*************************

Hi everybody. We are pleased to announce the availability of XOTcl 1.5.1.
Major changes relative to 1.4.0 are:

    * Improved Functionality

        + Improved interface to develop XOTcl methods in C
           (Many thanks to Scott Gargash for the constructive discussions
           and suggestions).

           New functions imported through the XOTcl's stub interface:
            - XOTclNextCmd()
            - XOTclCallMethodWithArgs

          New constant XOTCL_NONLEAF_METHOD to allow C-implemented
          methods to call next. This constant can be passed as 5th
          argument to XOTclAddIMethod (or ...AddPMethod). The
          following is a short example for defining and registering
          a C-implemented constructor "init" to a class.

              static int MyClassInit( ClientData cdata, Tcl_Interp *interp,
                        int objc, Tcl_Obj *CONST objv[] ) {
                 int rc;
                 /*** before next ***/
                 rc = XOTclNextObjCmd(cdata, interp, objc,objv);
                 /*** after next ***/
                 return rc;
              }
              ...
              MyClass = XOTclGetClass(interp, "MyClass" );
              XOTclAddIMethod(interp, MyClass, "init", MyClassInit,
                         XOTCL_NONLEAF_METHOD, 0 );


    * Improved code quality:
       + fixed a bug with the backward-compatible and deprecated
           "setter" interface (many thanks to Manfred Stelzhammer for
           reporting the bug)
        + fixed a bug in parsing nonpositional arguments, when
           e.g. square brackets are used in type declarations for
           parameters (Many thanks to Stefan Sobernig for reporting)
        + fixed autoname crash under Windows NT (Many thanks to Mark
           Janssen for reporting and providing a patch)
        + fixed serializer to handle deeper stratification layers
        + simplification and speedup of dispatcher
        + Makefile.in improvements for genstubs
        + Changed "test -e" to "test -f" in Makefile.in, since the
           standard test command in Solaris does not understand
           "test -e" (Many thanks to Andreas Kupries for reporting)
        + improved 64-bit compatibility on POWER5+

 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


Best regards,

Gustaf Neumann
Uwe Zdun

From: <mail_at_xdobry.de>
Date: Mon, 10 Jan 2011 13:21:14 +0100 (CET)

 
 


> I found XOTclIDE, but it looks a little bit exotic... 
XOTcl is exotic too ;)
 

>
> Second question: lets assume that I want to check if particular variable
> contains a TCL object of given class: $var istype MyClass. It works
> good, assuming that $var contains an object, but if there is a value
> like "15" we get an error.
> Is there a nice way to check if a variable contains an object of given
> class and at the same time just get a false answer in case it does not
> contains a XOTCL object? 
Object isobject $var && $var istype MyClass
 
Perhaps "hasclass" is better for you.
Consult documentation for a difference.
After I have started to use mixins so time ago, I have to adapt all istype to
hasclass.
 
proc isObjectOfType {obj type} {     expr {[Object isobject $obj] && [$obj
istype $type]}
}
 
Could be defined as Object proc
 
 
Artur

From: <MichaelL_at_frogware.com>
Date: Tue, 16 Sep 2003 16:34:54 -0400

Since you're getting 1.1 ready...

I ran across a very, very subtle bug. I was using the serializer to
serialize an obj tree. The topological sorting wasn't quite working for
one case. In the end, I tracked it down to the fact that I was passing in
an unqualified name. The sorting routine was in turn using fully qualified
references as it tried to build the correct ordering, and the mismatch
meant that it got some orderings for the root object slightly wrong.
(Basically a few objects were being created before their containers; their
containers were objects aggregated by the root object.)

In effect, I was using this:

        Serializer deepSerialize obj

when I should have been using this:

        Serializer deepSerialize ::obj

I don't think you'd be able to reproduce this easily, because it turned
out to relate to a specific set of objects and relationships. It turns out
that for other reasons, even when you make this "mistake" the algorithm
nearly works.

To make this work you'd either have to a) require fully qualified names or
b) turn a name into a fully qualified name. I don't know enough about Tcl
internals to say that (b) is a realistic option--but on the face of it it
doesn't seem like it would be.

Don't know if this helps much. :-)

From: Murr, Florian <florian.murr_at_siemens.com>
Date: Tue, 13 Dec 2005 12:08:24 +0100

Thanks a lot for your thorough explanation!

I tend to think in "invariants" and I memorized that having a method
specialized this way

    C instproc someMethod {args} { next }

 should leave my program invariant with respect to functionality.

But this obviously has the exception of getter/setter methods.

Regards,
 - Florian

-----Original Message-----
From: Gustaf Neumann [mailto:neumann_at_wu-wien.ac.at]
Sent: Thursday, December 08, 2005 4:15 PM
To: Murr, Florian
Cc: xotcl_at_alice.wu-wien.ac.at
Subject: Re: [Xotcl] Is this a bug?

Murr, Florian schrieb:

>Yes, you are right, I overload the setter/getter method and expected
>naively that it just prints the puts-statement and works otherwise
>unchanged. [Should have read the manual more properly, I guess :-)]
>
>
for each parameter a method for getting and setting variables
registered. This
method is a "instparametercmd" implemented in C, which is very similar
to the
set method. This can be as well explained with the forwarder, which
could be
used to implement the *parametercmds

   Class C
   C instforward x %self set %proc

now a method named x is defined, that calls "[self] set x" when issued.
eg.

   C c1
   c1 x 123

here "c1 set x 123" is called, or in the following line "c1 set x" is
issued.

   puts [c1 x]

This behavior is more or less identical to

   Class C
   C instparametercmd x

or to

  Class C -parameter x

therefore, the instparamtercmd is strictly speaking not needed, but
predates
instforward and is slightly faster, since everything is in C. The
parameters do
more, since they can be used to provide as well default values which are
used during initialization of objects.

anyhow, in all cases a method named "x" is defined.
When you define an instproc named x

  Class C
  C instproc x args {...}

you will overwrite the method "x", in a similar manner as
you can overwrite any tcl command, e.g
   proc if args { ...}

Therefore, there is no chance to do a next in these cases,
because the class has now the new method (instproc) instead
of the c-level implementation we had earlier.

Furthermore "next" works only when methods are shadowed, when
a same-named method is defined by a class/object earlier in the
precedence order. This can be achieved e.g. via mixins or filters.

therefore, in your example

>X instproc y {args} {
> puts "[self] y '$args'"
> my instvar y
> if {[llength $args]} { set y [lindex $args 0] }
> next
>}
>
>
the "next" is not doing anything useful, you should replace the
last line of your instproc by e.g. "return $y", such that .... [x1 y]
... works

hope this explains, how this works...

-gustaf neumann

From: Victor Mayevski <vitic_at_sbcglobal.net>
Date: Tue, 01 Apr 2008 13:35:12 -0700

Can somebody please update the XOTcl tutorial/reference to explain in
detail what abstract class is and how to use it (examples of usage)?
I've been looking everywhere and can't find the info.
Thanks.

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Mon, 20 Sep 2004 23:04:39 +0200

On Monday 20 September 2004 17:33, MichaelL_at_frogware.com wrote:
> I have a class I use to manage collections of aggregated objects. I'm
> trying to use it with the -Class parameter option and instforwarding so
> that I can do things like this:
>
> Test x
> x apples add Z
> x apples items
>
> *That* part I can get to work as expected. But I can't get the default
> option of instforwarding to work for this case:
>
> x apples

Michael,

the default values are only used in te substitution of %1,
which refers to the first argument of the invocation. The
default ist used, whenever the argument is not specified
in the invocation. So, essentially, the %1 was missing
in your example (see below)

best regards
-gustaf

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

  Test instforward apples -default {items add} {%my _apples_} %1
  Test instforward oranges -default {items add} {%my _oranges_} %1

  Test z
  z apples new TestItem
  z apples new TestItem

  # no arguments, use default
  puts [z apples]

  Class GoldenDelicious
  GoldenDelicious apple1
  GoldenDelicious apple2

  # explicit add
  z apples add apple1

  # implcit add (via default)
  z apples apple2

 puts [z apples]
=================================

-- 
Univ.Prof. Dr.Gustaf Neumann
Abteilung für Wirtschaftsinformatik und Neue Medien
Wirtschaftsuniversität Wien, Augasse 2-6, 1090 Wien

From: Jim Lynch <jim_at_jam.sessionsnet.org>
Date: Thu, 8 Apr 2004 17:03:20 -0700

Hi,

I got an error when building xotcl without tk and wish support where it
tries to do a chmod on xowish (which of course doesn't exist at that
point.)

This patch will fix the problem (as well as being self-explanitory as
to why it should be applied). See attachment for patch; my email client
seems to be translating white space, which would render the patch
(and the resulting Makefile.in) inoperative.

Please let me know if the previous patch I sent for the tclsh location
problem is similarly broken; I'll provide a fix if so.

Jim

--
Jam sessions community web site: http://jam.sessionsnet.org

From: Zoran Vasiljevic <zoran_at_munich.com>
Date: Wed, 13 Dec 2000 07:32:51 -0500 (EST)

------Original Message------
From: <uwe.zdun_at_uni-essen.de>
To: Gustaf.Neumann_at_wu-wien.ac.at
Sent: December 13, 2000 11:33:51 AM GMT
Subject: Re: [Xotcl] RE: [Xotcl] Re: [Xotcl] Object mixin with passing init
args ?

Wow ! After all this, what should be the best way to go ?

Patch xotcl.c and fix the mixin args?

Rewrite the app and wait until there is
a general-elegant-allmighty solution ?

What do you think ?
Zoran


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