Weblog Page

From: <MichaelL_at_frogware.com>
Date: Mon, 15 Sep 2003 17:15:37 -0400

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.

From: Kristoffer Lawson <setok_at_scred.com>
Date: Thu, 5 Aug 2010 14:48:47 +0300

I resolved my own situation with sending args with "-" at the start by replacing stuff for Class. I then changed that to use a mixin, as per Gustaf's suggestion. I wanted to do this for everything without having to bring in the mixin to every class, or creating a new meta-class, but of course a couple of external libs don't work as they use the dash parameters. This got me thinking. I do see that it is a handy notion to have sometimes, so played around with several ideas on how to do that.

I'm thinking aloud here, so excuse me for rambling.

Anyway my idea is to use a different method, instead of [new], for the cases where pre-configuration is desired. Here are some of the options:

IrcConnection preconf {-nick $IrcNick -channel $IrcChannel} $IrcServer

IrcConnection -new {-nick $IrcNick -channel $IrcChannel} $IrcServer $IrcChannel

IrcConnection -new $IrcServer $IrcChannel {-nick $IrcNick -channel $IrcChannel}

IrcConnection -new $IrcServer $IrcChannel {
    -nick $IrcNick
    -channel $IrcChannel
}

IrcConnection -new $IrcServer $IrcChannel {
    nick $IrcNick
    channel $IrcChannel
}

Of these I actually like the last one most. It's almost as if you have a Tcl script passed in. In fact, why not implement exactly that way, but with implicit access to the object's methods in-scope. It also solves the problem of passing values beginning with dash as arguments to the parameters. To use without configuration, just use the normal [new] method, or have an empty configuration script.

One option would also be to have the last option, but with the normal [new] command. It would work so that any mandatory arguments to the constructor are always picked up first (and only the last argument is configuration). Naturally this doesn't make those cases safe where 'args' or optional arguments are used, so would not be 100% safe.

-- 
Kristoffer Lawson, Co-Founder, Scred // http://www.scred.com/

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Tue, 26 Oct 2010 13:20:48 +0200

Hi victor,

also with nx, one can call methods during the object creation,
very similar to "eval":

    # create class
    nx::Class create Foo {
      :public method bar {} {return 1}
      :public method baz {} {return 2}
    }

    # create object
    Foo create f1 { :bar; :baz; :destroy }

Calling methods during creation is very common, and happens
as well in the example above during the creation of the
class Foo.

The example above can be written as well more compact via

     # create new class and object and cleanup everything
     nx::Class new {
       :public method bar {} {return 1}
       :public method baz {} {return 2}
       :create new { :bar; :baz; :destroy }
       :destroy
     }

In this example, the class is created with new, during
initialization, the methods "bar" and "baz" are created,
then an instance of the class is created (and calls
"bar" and "baz", and destroys itself), and finally the
class is deleted. If you want to run theses examples,
please update from git).

The problem with the dash ("-") commands is that they support
variable number of arguments. Unless one puts dash-commands
into a list (which is not usually done), and e.g. a variable
v has
the content "-foo", an invocation "... create f1 -x $v -y 1"
will try
to call a method foo. The security problem comes in, when
one has untrusted variable contents (e.g. provided via web).
It is certainly possible (and recommended) to validate
untrusted
content, or to use the list notation "... create f1 [list -x
$v] -y 1"
but in practice, this is often not done (by oversight,
non-awareness,
laziness, ...)

Finally, the standard xotcl answer: eveything can be configured.
Since nsf supports XOTcl 2.0 (and both, nx and xotcl2
are fully scripted), it is certainly possible to reconfigure nx
to get the good old dash-processing again to your scripts.

-gustaf neumann

On 26.10.10 06:36, Victor Mayevski wrote:
> 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
>

From: Stefan Sobernig <stefan.sobernig_at_wu.ac.at>
Date: Fri, 27 Jul 2012 21:56:31 +0200

> The compilation of tcl ran into the following problem (the fetched tcl
> version is 8.5.11).
> Does one have to install the "20110211" version of mingw? is there a
> configure problem
> on win7?

I have never encountered this behavior before. I need to check it out
when returning next week.

//s

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Thu, 08 May 2008 17:59:00 +0200

Matthew Smith schrieb:
>
>
> Putting in:
> s1 push a
> results in an error, however I can do:
>
> what is the error? this indicates that you have not defined the method
> push correctly
>
> I get:
> invalid command name "s1"
this indicates, that you have not created an object s1. Your program
should look like the following.....

hope this helps
-gustaf neumann

===========================================
package require XOTcl; namespace import ::xotcl::*

Class Stack
Stack instproc init {} {
    my instvar things
    set things ""
}
Stack instproc push {thing} {
    my instvar things
    set things [concat [list $thing] $things]
    return $thing
}
Stack instproc pop {} {
    my instvar things
    set top [lindex $things 0]
    set things [lrange $things 1 end]
    return $top
}

set s1 [Stack new]

s1 push a
s1 push b

set x [s1 pop]
puts "The popped value is $x"
===========================================

From: Kristoffer Lawson <setok_at_scred.com>
Date: Wed, 7 Jul 2010 11:14:08 +0300

Has anyone done any code or a framework for managing per-class permissions? Basically a way to do rules describing which other objects, or which roles users must have, in order to call the different methods provided by instances of the class (plus any class procs). This is kind of like an expanded approach to Java style simple permissions (private/protected/public), which of course could also be incorporated into that, if wanted.

I'm just asking as I've been giving that some thought in relation to my web framework (and object store) and reckoned it would make sense asking here so as not having to reinvent the wheel.

-- 
Kristoffer Lawson, Co-Founder, Scred // http://www.scred.com/

From: Uwe Zdun <uwe.zdun_at_uni-essen.de>
Date: Wed, 19 Dec 2001 15:38:24 +0100

I've tried it on Win NT with xotcl 0.9.3 (as released two days ago) and the
result is the same as on my linux machine:

filter f of A
filter f of A
filter f of A
method ma of A
filter f of A

Perhaps there's some problem with your xotcl/tcl installation on
your win platform?

--uwe

On Tuesday 18 December 2001 23:15, Sheik Yussuff wrote:
> It seems that filter is broken on the Win32 platform(ver 0.91
> and ver 0.93).
> The following code runs ok on Linux(XOTcl ver 0.91) but not
> on the Win32 platforms(>= 0.91). I don't think my installation
> is at fault.(library installed ok, etc) but I could be wrong.
> I haven't tried ver 0.93 on Linux as I am waiting on the RPM.
>
> Code:
> Class A
> A instproc ma args {
> puts "method ma of A"
> }
>
> A instproc f args {
> puts "filter f of A"
> next
> }
>
> A instfilter f
> A a
> a ma
>
> The Result on Win32:
>
> method ma of A
>
> Regards,
> --sheik
>
> _______________________________________________
> Xotcl mailing list - Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl

-- 
Uwe Zdun
Institute for Computer Science, University of Essen
Phone: +49 201 81 00 332, Fax: +49 201 81 00 398
zdun_at_{xotcl,computer,acm}.org, uwe.zdun_at_uni-essen.de

From: Sheik Yussuff <sheik_at_carib-link.net>
Date: Sun, 22 Jul 2001 08:07:14 -0300

Please ignore previous post as it was
a trivial problem.

Thanks.
--sheik
----- Original Message -----
From: Sheik Yussuff <sheik_at_carib-link.net>
To: <xotcl_at_alice.wu-wien.ac.at>
Sent: Saturday, July 21, 2001 11:41 PM
Subject: [Xotcl] Help: Meta-class and derived Classes


> Class A is a derived class of meta-class Consultation.
> In the filter conFilter I would like to obtain
> the class of the object that received the message "m"
> when invoking the command: [a m 123]. That is, the
> class of the original receiver of method "m".
> (Please see code below).
>
> Thanks for any help.
>
> Regards
> sheik
> .........................................................
> #Code:
> Class Consultation -superclass Class
>
> Consultation instproc conFilter args {
> set method [self calledproc]
>
> #The following is of course not correct!
> #[self class] evaluates to Consultation;
> #I need it to evaluate to A. Help!!
>
> if {[[self class] info instprocs $method] == ""} {
> if { [[self] exists delegate] } {
> return [eval [[self] set delegate] $method $args]
> }
> }
> next
> }
>
> Consultation instproc init args {
> [self] instproc setDelegate {d} {
> [self] set delegate $d
> }
> next
> [self] filterappend [self class]::conFilter
> }
>
> Consultation A -parameter delegate
>
>
> A instproc m {x} {
> puts "[self] [self class] [self proc] $x"
> return [next]
> }
>
> Class B
> B instproc m {x} {
> puts "[self] [self class] [self proc] $x"
> return [next]
> }
>
> A a
> B b
> a setDelegate b
> # send message m to object a
> puts "result = [a m 123]"
>
>
> _______________________________________________
> Xotcl mailing list - Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Tue, 14 Aug 2007 21:19:09 +0300

On 14 Aug 2007, at 20:49, Gustaf Neumann wrote:
>
> We are pleased to announce the availability of XOTcl 1.5.4.
> Originally, this release was planned as a small bug fix release.
> However,
> the total size of the (unified) diff between 1.5.3 and 1.5.4 is more
> than 5000 lines, mostly due to the varRefom changes (see first
> item below).

Cheers. Good to see the releases coming regularly. I wonder if Apple
would still manage to incorporate this into Leopard...

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

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

> Murr, Florian schrieb:
>
>> Dear XOTcl-guys!
>> I tried to upgrade from Tcl8.4+XOTcl1.5.3 (all my projects worked fine
>> here!) to Tcl8.5b1, but my projects won't run due to some XOTcl
>> problems.
>> The following snippet is extracted from my project and I tested it with
>> XOTcl1.5.5 (from WinTclTk) and XOTcl1.5.6 from ActiveState-Teacup.
>> But both failed with the same error message.
>> My guess: Non-positional Arguments don't work!
>>
>>

Dear all,

not sure if this helps immediately, since your are refering to binary
distros, but however, below is the fix to the problem. Tcl 8.5 seems
much more agressive in sharing variables. The variable was set,
but lost later, maybe due to shimmering. Switching back to the
more conservative approach helps. The change will be included
in the next xotcl release.

best regards
-gustaf neumann


--- generic/xotcl.c~ 2007-10-09 20:44:45.000000000 +0200
+++ generic/xotcl.c 2007-10-29 21:48:13.000000000 +0100
_at_@ -11438,9 +11438,9 @@
     r1 = Tcl_ListObjGetElements(in, nonposArgsDefv[i], &npac, &npav);
     if (r1 == TCL_OK) {
       if (npac == 3) {
- Tcl_ObjSetVar2(in, npav[0], NULL, npav[2], 0);
+ Tcl_SetVar2Ex(in, ObjStr(npav[0]), NULL, npav[2], 0);
       } else if (npac == 2 && !strcmp(ObjStr(npav[1]), "switch")) {
- Tcl_ObjSetVar2(in, npav[0], NULL, Tcl_NewBooleanObj(0), 0);
+ Tcl_SetVar2Ex(in, ObjStr(npav[0]), NULL, Tcl_NewBooleanObj(0), 0);
       }
     }
   }