Weblog Page

From: Stefan Sobernig <stefan.sobernig_at_wu.ac.at>
Date: Tue, 08 Feb 2011 10:39:52 +0100

> On 02/08/2011 09:58 AM, Stefan Sobernig wrote:
>> t.001: 26.2 mms, MyClass myObject $myList; set ::out
>> t.002: 32.6 mms, eval MyClass myObject $myList; set ::out
>> t.003: 26.9 mms, MyClass myObject 1 2 3 4; set ::out
>> t.004: 26.0 mms, MyClass myObject {*}$myList; set ::out
>>
>> from this bird eye perspective (and without knowing the details of your
>> scenario), you might want to consider avoiding the [eval] overhead by
>> using the {*} operator in 8.5+ for the boxing case ...
>>
>> (t.003 is a kind of baseline measurement and appears slightly more
>> expensive because the values in the argument vector must be turned into
>> Tcl_Objs first etc., a conversion which has already been achieved if
>> dealing with a [list] and its values).
>>
>
> Thank you for this example. I forgot to mention that my application
> will, in some cases, create argument list that may be long (few thousand
> integer values). I expect it to handle up to 7200 values that are
> integers (2 digits maximum).

This changes the picture. If you look at my examples, they assume that
you want to turn each list value a value to a proper method parameter
and so into a local variable in the init body ($a, $b, $c, ...). This is
certainly not the case here ...

What is going to happen to with this data vector in init? Why do you
want to treat each value of this vector as a method parameter of init?

> Is it a bad idea to expand that list and
> pass 7200 arguments to init?

Let me rephrase the question: Is it a bad idea to have a method with
7200 method parameters :) Besides: The # of method parameter of init
would have to change which each call, depending on the size of your data
vector.

One might think of using args on init, but args simply boxes a variable
argument vector into a single Tcl list. So why not pass the data vector
as a single list value right from the beginning?

> In this example it appears that it is actually better to expend the list
> using {*}, than to pass it as a value?

Only and only *iff* you want to treat each list value as a method
parameter. In your scenario, it is more likey a data vector which is to
be addressed by a single handle:

MyClass instproc init {v} {
     foreach value $v {
         # do sth. to each of the 7200 values
     }
}

//stefan

From: Murr, Florian <florian.murr_at_siemens.com>
Date: Thu, 5 Jan 2006 14:04:26 +0100

I extracted the code below from a very large XOTcl program that I am
developing right now.
The output of the last line 'puts "uuuuu guest_bathroom3
[guest_bathroom3 currTemp]"' puzzles me!
If I uncomment the line 'set temp [Celsius2Kelvin 20]' the output is
even weirder (an error message).
Any helpful comments?

Regards,
 - Florian


My code:


package require XOTcl
namespace import xotcl::my xotcl::self xotcl::next xotcl::Class
xotcl::_at_
namespace eval tih {
    Class Floor -parameter {
         {cubicles {}}
    }
    Class Room -parameter {
         {cubicles {}}
    }
    Room instparametercmd currTemp
    # --- 'unknown'-mechanism.
    Floor proc createRoom01 {floor aName args} {
        #set temp [Celsius2Kelvin 20]
        set room [eval {Room create $aName} $args]
        $floor lappend cubicles $aName
        $room set Floor $floor
    }
    Floor instproc rooms {{a {}}} { ;# getter/setter
        my instvar cubicles
        if {[llength $a]} {
            set itp [self]_createRoom01
            interp create $itp
            interp alias $itp unknown {} ::tih::Floor createRoom01
[self]
            set rval [$itp eval $a]
            interp delete $itp
            return
        }
        set rval [list]
        foreach i $cubicles {
            # xxx verbessern!
            if {[$i istype Room]} { lappend rval $i }
        }
        set rval
    }
    proc Celsius2Kelvin {a} { expr {$a+273.15} }
    Floor floor3 -rooms {
        guest_room
        guest_bathroom3 -currTemp [Celsius2Kelvin 30]
    }
    #puts "uuuuu guest_room [guest_room currTemp]"
    puts "uuuuu guest_bathroom3 [guest_bathroom3 currTemp]"
}

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Tue, 08 Feb 2005 13:25:14 +0100

>> There are two fixes for that, one simple (don't allow reclassing of
>> objects to classes)
>> or a more complex one (do more or less a recreate automatically when
>> this happens;
>> it tries to keep the object information as far as possible).
>
>
> I don't know the internals really of XOTcl but basically making an
> object a class would mean giving it the methods 'instproc' and 'new'
> and various other stuff, thus allowing an instance of it to be
> created. I guess it's some internal thing if it has to be recreated?
> In some sense it would be 'pure' if this was possible.

 From the C level, a class has to keep more information than an object.
The class structure is an
extension of an object, containing hash tables and a couple of pointers:

typedef struct XOTclClass {
  struct XOTclObject object;
  struct XOTclClasses* super;
  struct XOTclClasses* sub;
  short color;
  struct XOTclClasses* order;
  struct XOTclClass* parent;
  Tcl_HashTable instances;
  Tcl_Namespace *nsPtr;
  Tcl_Obj* parameters;
  XOTclClassOpt* opt;
  Tcl_HashTable *nonposArgsTable;
} XOTclClass;

therefore classes need somewhat more memory than objects, these
structures have to
be allocated and maintained, so everything is a little more costly than
it has to
for objects.

Providing means to make "obj class Class" and "cl class Object" working
is certainly
doable, but i am not sure that is worth the effort, since one can
achieve similar effects
already from the tcl level (see below).

> I wonder if this has any relevance to changing the meta-class of a class?

Check out the code below, it might be pretty close to what you might be
thinking about.

-gustaf
===============================================================
package req XOTcl
namespace import ::xotcl::*

    # we will defined our own Class and Object commands
    namespace forget Class Object

    # redefine Class and Object
    ::xotcl::Class create Class -superclass ::xotcl::Class
    Class instproc unknown {m args} {puts "[self] unknown called for $m
$args"}
    Class instproc init {} {
       set sc [my info superclass]
       if {$sc eq "::xotcl::Object"} {set sc [list]}
       my superclass [concat $sc Class]
    }
    ::xotcl::Class Object -superclass Class

    # create some object
    Object c

    # ... which is a class that can create an object ...
    c create d
    # ... and so on ...
    d create e

    # provide a method
    d instproc foo {} {puts [self proc]}
   
    # call the method from it's instance
    e foo

    # create another object which should use the methods provided
    # by some other objects....
    e create f -mixin d

    # call the method
    f foo

From: Uwe Zdun <uwe.zdun_at_wu-wien.ac.at>
Date: Sat, 15 Nov 2003 10:09:59 +0100

Hi Ken,

perhaps others use other styles, but a simple way to bind variables,commands,
or other callbacks from TK into XOTcl is replacement of "self" (or "my") from
within a XOTcl method. Example:

Class BrowserTree
BrowserTree instproc init args {
   ...
   set tree [Tree $sw.tree \
                   -relief flat -borderwidth 0 -width 15 -highlightthickness
0\
                   -redraw 0 -dropenabled 1 -dragenabled 1 \
                   -dragevent 3 \
                   -droptypes {
                       TREE_NODE {copy {} move {} link {}}
                       LISTBOX_ITEM {copy {} move {} link {}}
                   } \
                   -opencmd "[self] modifyTree 1 $sw.tree" \
                   -closecmd "[self] modifyTree 0 $sw.tree"]
    ...
    $tree bindText <ButtonPress-1> "[self] selectTreeElement $tree"
    $tree bindText <Double-ButtonPress-1> "[self] openTreeElement $tree"
    ...
}

note that you cannot use curly brackets {} here, because then self would
not be replaced within the object's scope and would likely have a wrong value
or raise an exception.

this style of binding works nicely together with XOTcl's inheritance and
mixins

Uwe





On Saturday 15 November 2003 00:04, Ken Jones wrote:
> Hi. I've just starting tinkering around with XOTcl the past few days,
> trying to add it to my repertoire of Tcl OO extensions. It's definitely
> quite an interesting contrast to others like [incr Tcl] or Snit. While I
> won't be abandoning either of those, XOTcl is currently my leading
> candidate for a project I'm likely to be working on through the rest of the
> year, in large part because of its mixin support.
>
> But one issue I couldn't figure out from my reading of the documentation or
> examples is whether it's possible to use an object's instance variable as a
> widget's -textvariable or -listvariable. For example, [incr Tcl] supports
> the [itcl::scope] command, so I can do something like this:
>
> package require Itcl
>
> ::itcl::class Toggle {
>
> private variable _state "normal"
>
> constructor {} {
> checkbutton .cb -text Enable \
> -variable [::itcl::scope _state] \
> -onvalue "normal" -offvalue "disabled" \
> -command [::itcl::code $this toggle]
> .cb select ;# The checkbutton is initially on
>
> # ...
> }
>
> private method toggle {} {
> # ...
> }
> }
>
> Is there a similar feature for XOTcl?
>
> Thanks,
>
> - Ken Jones
>
> _______________________________________________
> Xotcl mailing list - Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl

-- 
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: jim <j_marvin_at_localnet.com>
Date: Wed, 10 Dec 2003 15:31:48 -0500

Hi-
 
I went into a console and typed
puts $auto_path;
 
when i load and run my project tcl file from inside the visual tcl
environment it works fine. it bombs out when i try to use the binary.
i'm including the auto_path printout for you to view for completeness.
 
C:/program files/Tcl/lib/xotcl1.1/xotcl {C:/Program
Files/Tcl/lib/tcl8.4} {C:/Program Files/Tcl/lib} {C:/Program
Files/Tcl/lib/tcllib1.5} {C:/Program Files/Tcl/lib/tk8.4} {C:/Program
Files/Tcl/lib/itk3.2} {C:/Program Files/Tcl/lib/iwidgets4.0.2}
{C:/Program Files/Tcl/lib/iwidgets4.0.2/generic} {C:/Program
Files/Tcl/lib/iwidgets4.0.2/scripts}
 
thanks,
marvin

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Fri, 24 Sep 2004 16:54:21 +0300 (EEST)

On Fri, 24 Sep 2004, Kristoffer Lawson wrote:

> On Fri, 24 Sep 2004, Kristoffer Lawson wrote:
>
>> I'm getting a segmentation fault in relation to XOTcl. I believe the
>> situation that causes it is as follows:
>>
>> * I have an object C which has a child M.
>> * M has a fileevent callback.
>> * On receiving complete message, M calls a method in C.
>> * If that is an empty message, C destroys itself and closes the socket in
>> the destructor (M is still in fileevent callback).
>
> For what it's worth, here's some more information from the debug output:
>
> Client connected.
> * init: MsgHandler init called
> * destroy: next
> * destroy: destroy MsgHandler
> * destroy: CmdHandler destroy
> * destroy: close socket
> * destroy: ClientConn destroy
> * destroy: destroy MsgHandler
> * destroy: destroy MsgHandler
> --var-- ::::readData: data: ,
> * MsgHandler readData: return
> Segmentation fault

Now I'm also getting it even without the debug output, after having some
data pass back and forth:

called Tcl_FindHashEntry on deleted table
Aborted

Perhaps it's related to some other issue that was brought up here? Turning
into a bit of a showstopper so at the very least I need some kind of
workaround.

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

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Thu, 08 Sep 2005 10:37:48 +0200

Kristoffer Lawson schrieb:

> I was thinking about using packages to collect classes together.

i have started some work towards turning packages into objects, where a
package
is an instance of a class Package. This allows in general to
 - query which packages are loaded in which versions
 - easy means to query the content and dependencies btw. packages
   (package-relations, could be graphically presented)
 - provide unloading (with destructors) of packages
 - allow for nested packages
 - since packages are instances that export stuff, it could be in
pinciple possible
   to load multiple versions of a package simultiously, where one is not
required to
   base everything on the same version of the package.

Although i have a few pieces for this already working, this won't make
it into the next release.
Andreas Kupries from active state has done some great work to make the
xotcl libraries
namespace clean, there is still some more work to get everything running
again, and
this is an important step towards the above. The namespace clean
libraries are inteneded
to be in the next release.

> The problem with this is that classes are not automatically searched
> for in the same package. That is if Class A depends on Class B (A is
> B's sub-class), B needs to be read in before A is read. In Java it
> is enough that they are in the same package, they'll be found. With
> XOTcl you need to build a kind of stub file that represents the
> package and which then sources in all the other necessary files in
> the required order.

a few remarks to this:
 - what's wrong with "package req package-providing-class-B" in the
package containing class A?
   this is the natural tcl style for such issues.
 - if you need more fine-grained control, xotcl provides in additon the
__unknown method
   (which should be called actually "undefined class reference").
Zoran's ttrace package
   (part of the tcl thread library) uses this. see below for a short
example for __unknown ...

-gustaf

-----
  Class proc __unknown args {
    # called upon unresolvable Class names; here one can use e.g. an
    # index to load classes from source files or from serialized
    # definitions
    set r [Class create $args]
    puts "... class $r created on the fly ..."
    return $r
  }

  Class B -superclass A

----

From: Steve Redler IV <steve_at_sr-tech.com>
Date: Tue, 11 Apr 2006 15:11:18 -0000

diff -ruN xotcl-1.4.0/generic/xotcl.c xotcl-1.4.0sriv/generic/xotcl.c
--- xotcl-1.4.0/generic/xotcl.c 2006-02-23 12:41:47.000000000 -0500
+++ xotcl-1.4.0sriv/generic/xotcl.c 2006-04-11 08:44:47.000000000 -0400
_at_@ -1706,16 +1706,18 @@
             int instanceOpt, int resetOpt) {
   int valueLength, mustCopy = 1, format = 0;
   char *valueString, *c;
- Tcl_Obj *valueObject, *result = NULL, *savedResult = NULL;
+ Tcl_Obj *valueObject, *result = NULL, *savedResult = NULL, *incrPtr;;
   XOTcl_FrameDecls;
   int flgs = TCL_LEAVE_ERR_MSG;
 
   XOTcl_PushFrame(in, obj);
   if (obj->nsPtr)
     flgs |= TCL_NAMESPACE_ONLY;
+
+ incrPtr = Tcl_NewIntObj(1);
 
 #ifndef PRE83
- valueObject = TclIncrVar2(in, XOTclGlobalObjects[XOTE_AUTONAMES], name, 1, flgs);
+ valueObject = TclIncrObjVar2(in, XOTclGlobalObjects[XOTE_AUTONAMES], name, incrPtr, flgs);
 #else
   valueObject = TclIncrVar2(in, XOTclGlobalObjects[XOTE_AUTONAMES], name, 1, 0);
 #endif

--
Regards,
Steve Redler IV, SR Technology
steve #_at_ sr-tech.com
SR Tech Secure Webmail

From: Artur Trzewik <mail_at_xdobry.de>
Date: Wed, 31 Mar 2004 09:49:59 +0200

Hi!

New Version of XOTclIDE 0.60 is released.
http://www.xdobry.de/xotclIDE

changes:
- support of version control on ms access driver (per tclodbc). It is able to
use MS Officce Access format for version control database. You do not need
MS Access on your client, because this driver is standard component of Window.
It can be better (but not platform-independent) way to have sigle-user version
control on windows than sqlite (that can be pretty slow)
- some small changes in version control schema makes old repository not
upgrade-compatible. Please apply update sql (update60.sql) if you want to
use old repository (per plug-in SQL Browser)
- new variable access tracker. You can invoke debugger on write/read access to
global variables or XOTcl object variables.
Also GUI variable watch, that can link per entry widget -textvariable with any
global variable or XOTcl object variable
- updated documentation
- for another changes and bug-fixes see change-log file

Also updates in XOSql - XOTcl wrapper for database access
http://www.xdobry.de/xosql

Artur Trzewik

From: Victor Mayevski <vitick_at_gmail.com>
Date: Mon, 25 Oct 2010 21:36:22 -0700 (PDT)

Hello Gustaf,

I have been playing with NX, so far I really like it, the speed, the clean interface, everything is very nice. One thing I miss though, which I have been using often in XOTcl, is invocation of methods during object creation. Example "MyClass create myobject -dowork1 -dowork2 -finalize -destroy". I know that you mentioned in the git log somewhere that this was security concern and NX will not have this capability. However, you did say that this can be scripted in. Can you give an example of how to do it? Is it really such a security issue?

Thanks