Weblog Page

From: Eckhard Lehmann <eckhardnospam_at_gmx.de>
Date: Mon, 31 Dec 2007 17:14:28 +0100

Hello,

is it planned - or already possible - to have full trace support for XOTcl methods and procs? E.g.:

xotcl::Class A
A instproc doit {args} {
   ...
}

# later
A trace add execution doit enterstep some_proc
A trace add execution doit leavestep some_other_proc
A trace add command doit rename some_proc

I know there are filters, but I am looking for an easier way to react on execution of particular methods/procs... for a mechanism that works for xotcl objects the same way as [trace] works for pure Tcl.

TIA
Eckhard

-- 
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger?did=10

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Fri, 09 May 2008 12:01:33 +0200

Jeff Hobbs schrieb:
> Someone asked on chat why the unknown stuff (e.g., typing an unknown
> command name into the console) in tkcon "broke" after doing:
>
> package require xotcl::upvar-compat
>
>
Thanks for reporting. I rewrote the functions to use catch, as you
suggested,
and tried to make clearer what happend in the code. This changes will be in
the next release of XOTcl, and are already checked in the xotcl code
repository.

For the curious, some background about upvar-compat:

Suppose, one has a script like

   Class C

   C method foo {varname} {
     upvar $varname v
     ...
   }

   C method bar {} {
     ...
     my foo x
     puts "bar x=$x"
     ...
   }

   C create c1
   c1 bar

where a variable name is passed to the method foo. The variable
is in the proc scope of the method var. This example works perfectly fine
with plain tcl upvar, the package upvar-compat is not needed.

However, suppose, one adds an interceptor (e.g. filters, or a mixin class).
For dynamic composition, one should be able to add functionality
(e.g. tracing via filters), without breaking the original code, otherwise
these interceptors are quite useless. Therefore, interceptor transparency
is desired.

Let us take a simple example, adding a per object-mixin

   Class M
   M method foo args {
     set x 200
     next
     puts M.foo.x=$x
   }

   c1 mixin M

In general the intensions is that the upvar linkage from C.foo to C.bar
should not be affected by the mixin, which should be transparent.
However, when c1 bar is called, M.foo lies in the callstack
between C.bar and C.foo. Plain Tcl upvar has no clue, that M.foo
is an interceptor, and refers to M.foo instead of to C.bar. The old behavior
is broken. The situation is even more drastic when filters are used.

The recommended way to achive interceptor transparency is to
use the XOTcl methods upvar and uplevel instead of the Tcl commands.
In the example above, this would be

   C method foo {varname} {
     my upvar $varname v
     ...
   }

The package xotcl::upvar-compat changes the global commands
::upvar and ::ulevel to behave like the XOTcl methods, when used
within XOTcl methods.

The approach with the package xotcl::upvar-compat is not recommended,
but supplied for making the application writers life more convenient.

My feeling is that we should drop this package from the xotcl distribution
in the future.

Hope this explains the background.
-gustaf neumann

From: Catherine Letondal <letondal_at_pasteur.fr>
Date: Sat, 12 May 2001 09:48:04 +0200 (CEST)

Hi,

I have a filter on Object which purpose is to register the called procs
of every class in my application, for debugging purpose.
The list of called procs is then displayed in a graphical component where
it can be selected to be traced (http://www-alt.pasteur.fr/~letondal/biok/Images/tracegui.gif).

I would like to have also mixin procs registered, but apparently, the
calledclass in the filter, when called on the mixin, does not return
the mixin class, but the actual called class.
Is there a way to know that the mixin proc was called - in the filter scope
I mean ?

This filter is put on every class during a given period:
Object instproc spyFilter args {
       set proc [self calledproc]
       set class [self calledclass]

       # debug is an Object doing debugging tasks and registering
       # trace/debug informations

       debug instvar calledprocs
       lappend calledprocs($class) $proc
}

Class UpdateMixin
UpdateMixin instproc update args {
...
}

UpdateMixin filter actually displays spyFilter, but the filter
does not "see" the UpdateMixin as the calledclass, but rather the
class the mixin is associated with.

Thanks for your help,

--
Catherine Letondal -- Pasteur Institute Computing Center

From: Stefan Sobernig <stefan.sobernig_at_wu.ac.at>
Date: Fri, 11 Feb 2011 10:15:43 +0100

>> What would be the proper way to "register" the object myObject (which already exists) in another thread?
>
> No way. You need to ask Gustaf to give you serialisation-code
> that you can use to replicate your object/classes blueprints
> from one thread into others as a matter of thread inits.

I can help out here: In order to serialize an object (in XOTcl, creating
a canonical script from a in-memory snapshot of the given object,
capable of creating an object and its dependencies with all the
shebang), [package require] the serializer package which comes with your
XOTcl distribution:

Class create C -slots {
   Attribute a1 -default aaa
} -set x 1

C create c1

package req xotcl::serializer

#
# this provides a new method to all ::xotcl::Object instances, i.e. all
# objects -> serialize():
#

c1 serialize

-> ::C create ::c1 -noinit \
        -set a1 aaa

the resulting script can be stored (e.g., in a tsv) and shared between
thread interps. in the target interp, simply [eval] the script.

//stefan

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Sun, 29 Jan 2006 15:45:54 +0100

Kristoffer Lawson schrieb:
>
> On 29 Jan 2006, at 15:26, Gustaf Neumann wrote:
>
>> maybe you are interested in joining the frappr group of xotcl to
>> locate the people based
>> on the google map... See: http://www.frappr.com/xotcl
>
> I guess that system sucks. I put my city as Helsinki and it said
> 'Invalid City'. You have to press tab or wait for a dropdown to get
> your correct city identifier.
>
> Oh well, added myself anyway.

It seems, that you are currently located in a lake close to a railway
station :) The satellite maps of
Helsinki are great, much better resolution than these of Vienna. You can
correct the location
via "My Frappr", "My Profile", "Edit My Basic Profile" and click on the
Satellite map.....

-gustaf
>
> / http://www.fishpool.com/~setok/

From: Zoran Vasiljevic <zoran_at_munich.com>
Date: Wed, 13 Dec 2000 06:15:16 -0500 (EST)

------Original Message------
From: Gustaf Neumann <Gustaf.Neumann_at_wu-wien.ac.at>
To: Zoran Vasiljevic <zoran_at_munich.com>
Sent: December 13, 2000 10:41:01 AM GMT
Subject: [Xotcl] RE: [Xotcl] Re: [Xotcl] Object mixin with passing init args
?


> from the implementation point of view this is not a big issue.
>however, from my experience, i should note that i switched from a
>style of "passing arguments to init" to the "-parameter style of
>configuring objects", which is in almost all cases the more
elegant
>solution.

<snip>

Yes. I must admit that your reasoning is correct. One gets wierd
constructs if thinking about all possible situations.

But, let me explain my issue. There may be another solution.

I have couple of classes impementing tree-like operations on
XML files and regular filesystems. Both classes share the same
abstract class, Tree (when I think of the Storage implementation in XOTcl
distro, then this case would be very similar).
Now, each of (Xml/Ufs) classes are mixed-in the general
Tree object. Each of them needs a different argument
pointing to a xml-file/file-directory where to hook on.

Consider ...

Class Tree ;# has abstract methods mostly
Class XmlTree -superclass Tree ;# implements above methods
Class UfsTree -superclass Tree ;# ...

XmlTree instproc init {xmlFile} {....}
UfsTree instproc init {rootDir} {....}

Tree t
t mixin XmlTree /path/to/xmlfile.xml ;# use the Xml driver
t mixin UfsTree /some/dir ;# switch to filesystem driver

Dang ! Showstopper, since I cannot pass arg to XmlTree/UfsTree.
Any suggestions ?


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

From: Neil Madden <nem_at_cs.nott.ac.uk>
Date: Mon, 26 Sep 2005 20:50:46 +0100

Jeff Hobbs wrote:
> I know that many on this list will be interested in the
> following TIP just propsed:
>
> TIP #257: Object Orientation for Tcl
> http://www.tcl.tk/cgi-bin/tct/tip/257
>
> This is indeed based on xotcl, but it is *not* xotcl. There
> are good reasons for this overall (but not necessarily for
> each individual change ;) ). I would like xotcl users who
> are interested to please read this TIP carefully, but to
> bear a few items in mind:

I feel slightly uneasy that debate about this TIP is occurring here and
on the wiki, and yet notification of its existence hasn't even reached
tcl-core yet. I have written some fairly substantial notes on the TIP at
http://www.cs.nott.ac.uk/~nem/newoo.txt . These notes were supposed to
be a post to tcl-core, but I don't want to further pre-empt the TIP
publication.

I'm only an occassional XOTcl user, so my comments are aimed mostly at
what I think would be consistent and useful for Tcl generally, and not
consistency with XOTcl.

Anyway, many cheers to you all for kicking off this process.

-- Neil

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Wed, 04 Aug 2010 11:37:01 +0200

Dear Kristoffer and all.

yes, this is a part, where xotcl was criticized for in the past - not
without reason.
The problem is a tribute to invocations to methods with a variable number
of arguments in the dash notation (calling methods with zero to n
arguments)
without knowing the length of the argument list (which is in the general
case not possible in Tcl due to args). For me it is sometimes surprising,
how well it works even for large projects, with several thousand lines
of code and many developers involved. The XOTcl serializer
uses the dash notation as well, but analyses the arguments and adds the
lists
as needed.

Anyhow, the next incarnation of XOTcl, on which we are hard working
right now, has this feature dropped, and provides a much more orthogonal
parameterization for objects and methods. As the new framework
supports multiple object systems in one interpreter, one can use classical
XOTcl and the new object system in parallel.

best regards
-gustaf neumann

Am 04.08.10 11:07, schrieb Kristoffer Lawson:
> On 4 Aug 2010, at 10:08, mail_at_xdobry.de wrote:
>
>
>> Foo new [list -init $a]
>>
> Thanks yes, as tired as I was last night, I didn't come up with that. The thing is, that basically has to be done all the time if you are passing in variables. Obviously any time you pass user-generated string, but also in other cases as well when you can't be 100% sure of the content (and often you can't). I probably have hundreds of places where this can cause a bug, at best, and a security hole, at worst.
>
> Using [list -init<vars>] all the time does not, to me, sound like elegant programming. I use the dash feature much more infrequently than just plain instantiation. Besides, you are at risk even with the dash feature, if you pass it an argument...
>
> I'm not exactly sure even how I would solve this for XOTcl. Any special argument syntax is always going to be at risk. As mentioned, even arguments to the dash values are risky. In that respect I would consider dropping the whole feature. It's that risky.
>
>

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Mon, 29 Oct 2007 22:32:50 +0100

Just a small followup: Since xotcl has about 30 tests for nonposargs,
which are
all passing for tcl 8.5, i was trying to extend the xotcl regression
test, and
found some more insight:

Your original script

  Class X
  X instproc ListOfStringsOption {{-default ""} {-cb ""} name} {
    if {$cb eq {}} { set cb "::set ::$name " } ;# global variable
    eval $cb \$default
  }

could be as well be repaired in 8.5 by avoiding eval with the new-style
expand operator

X instproc ListOfStringsOption {{-default {}} {-cb ""} name} {
    if {$cb eq {}} { set cb "::set ::$name " } ;# global variable
    {*}$cb $default
}

or strangely, by mentioning the variable "default" explicitely
in the procbody

  X instproc ListOfStringsOption {{-default ""} {-cb ""} name} {
    if {$cb eq {}} { set cb "::set ::$name " } ;# global variable
    set _ $default
    eval $cb \$default
  }

I have still no clear understanding why in the original version the
variable "default" is unknown within eval. Maybe there is a
bad interaction with the byte-code compiler in Tcl 8.5...

Anyhow, altering Tcl_ObjSetVar2() to Tcl_SetVar2Ex() on the C level
works fine in all cases.

best regards
-gustaf neumann

From: Uwe Zdun <uwe.zdun_at_wu-wien.ac.at>
Date: Wed, 8 Jan 2003 16:12:34 +0100

Hi Adrian,

you're right. The orginal idea was to provide one XOTcl version that is only
XOTcl (the xotcl-1.0.1) on its own and own "full" version with the actiweb
packages etc. especially for students and testing purposes; so someone not
using actiweb does not have to install all the persistence, xml, web object,
etc. stuff just ot use XOTcl; however, since then (to my knowledge) nobody
uses the smaller xotcl-only version. We're thinking about removing the
version number again. I guess, we try to move to the TEA2 directory naming
scheme ....

For you immediate problem: in the makefiles there are variables "PATCHLEVEL"
(this is the release level ... "" for 1.0, ".1" for 1.0.1) and FULLVERSION
defined, which contain the necessary information. Within XOTcl you can get
the patchlevel with "set xotcl:patchlevel":

xotclsh
% set xotcl::patchlevel
.1

--uwe




On Wednesday 08 January 2003 16:37, Adrian Wallaschek wrote:
> Hi there!
>
> I do like version numbers, but there is a "too much" in everything.
>
> What is the deeper benefit of having the version number for xotcl
> recursively even inside the source-tree?
>
> What actually happens for me is that now I seem to have problems building
> the code because in 1.0.1
> When running xotcl-1.0.1/xotclsh I do find ..../xotcl-1.0 in the auto_path
> instead of the required/expected .../xotcl-1.0.1.
>
> I haven't yet found out where it goes wrong but it looks like the $VERSION
> doesn't use the revision counter in some Makefile.
>
> The question is: why all this fuzz?
>
> Didn't anybody else see this occurring, did I mess up anything?
>
>
> Regards,
> Adrian Wallaschek
>
> "Just when you think, life can't possible get worse,
> it suddenly does!"
> The Hitchhiker's guide to the galaxy - Douglas Adams
>
> _______________________________________________
> 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