Weblog Page

From: Gustaf Neumann <neumann_at_wu.ac.at>
Date: Fri, 08 Jun 2012 10:50:04 +0200

The problem was verified and is fixed in the head version of
git.

From: Ben Thomasson <ben.thomasson_at_gmail.com>
Date: Thu, 20 Jul 2006 16:58:15 -0400

Hello all,

Please that a look at http://xotcllib.sourceforge.net and reply with
comments or critiques. XOTclLib is a library of debugging, logging,
profiling, documentation, tracing, serialization, and unit-testing
utilities.
The documentation for the project is still in progress and will improve over
time.

Thanks,

Ben Thomasson
ben.thomasson_at_gmail.com

From: Scott Gargash <scottg_at_atc.creative.com>
Date: Mon, 11 Dec 2006 11:06:11 -0700

xotcl-bounces_at_alice.wu-wien.ac.at wrote on 11/28/2006 07:41:26 PM:

> ActiveState is pleased to announce the release of ActiveTcl 8.4.14.0
> and 8.5.0.0 Beta 6, the quality-assured distribution of Tcl, available
> for AIX, HP-UX, Linux, Mac OS X, Solaris and Windows.

Is there any way to get the xotcl c-interface files (the .h/.lib files) that correspond to the
version of XOTcl that ships with the ActiveState release? They're not present in the distribution.

      Scott

From: <h8853209_at_wu-wien.ac.at>
Date: Mon, 03 May 2004 13:06:38 +0100

From: Kristoffer Lawson <setok_at_scred.com>
Date: Wed, 4 Aug 2010 12:07:34 +0300

On 4 Aug 2010, at 10:08, mail_at_xdobry.de wrote:

> Hi!
>
> I found a work around according to xotcl documentation.
>
> 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.

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

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Mon, 20 Mar 2006 15:20:55 +0200

On 20 Mar 2006, at 14:46, Gustaf Neumann wrote:
>
> I have added "::xotcl::mymethod" and "::xotcl::myvar" to my
> development version. i guess, you would you prefer to have
> these exported. Opinions?

On giving it some thought I think I actually prefer the version that
would be part of Object. After all, it is that object's variable that
we want. I don't use it that frequently so I don't mind writing a bit
extra, for clarity's sake.

I'm also wondering what the name should be, to make it really clear.
Is [my var] clear enough? or should it be [my normalisedVar]?

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

From: Neophytos Demetriou <k2pts_at_phigita.net>
Date: Thu, 02 Feb 2006 19:47:48 +0000

Matthew Dodwell wrote:
> MemoryLineController instproc AddNode {name} {
> eval GUINode [self]::[my autoname gNode%02d] -DisplayName {$name}
> }

* Replace the body of addNode as follows:

        my lappend __children [eval GUINode ...etc... ]

    and [my info children *gNode*] in CreateTreeview as follows:

        [my set __children]

OR

* Use an OrderedComposite class that does it for you. You will either
have to mix it in or define it as one of the superclasses of
MemoryLineController, i.e.:

        Class MemoryLineController -superclass OrderedComposite


Class OrderedComposite

OrderedComposite instproc children {} {
   set children [expr {[my exists __children] ? [my set __children] : ""}]
   return $children
}
OrderedComposite instproc add obj {
   my lappend __children $obj
   $obj set __parent [self]
}


Best,
Neophytos

From: Victor Mayevski <vitick_at_gmail.com>
Date: Thu, 30 Sep 2010 21:34:24 -0700 (PDT)

Thanks, I am looking forward into discussing this in the future.



----- Original Message -----
From: "Gustaf Neumann" <neumann_at_wu-wien.ac.at>
To: xotcl_at_alice.wu-wien.ac.at
Sent: Thursday, September 30, 2010 12:56:08 AM GMT -08:00 US/Canada Pacific
Subject: Re: [Xotcl] new feature idea



Dear Victor,

yes, this looks nice. It is premature to add it to the set
of builtins, i have not had much uses cases for this functionality.
But as you say, it can be easily scripted (see below)....
or provided as and optional package.

> This functionality is even more enhanced with mixins and
> superclasses where each chained method would be passed to a
> mixin/superclass via [next].

one could pass in the list of methods as well per-object
mixins,
which could be added before and removed after the invocation.
however, this would make invocation less elegant, and i doubt
that there are many use cases for this.

It is not fully clear what's the best way to return the results
or errors of the multiple method invocations. The small
implementation below returns a list of results of the
individual methods, and does nothing about errors.

we plan on the new web site a community space, where can
place some implementation studies like this one.

Btw., the "opposite" problem is to call a single method with
a set of argument vectors (the method is called repeatedly
with each element of the set). There is an implementation
of that in the new regression test using the tcl8.6 function
apply (similar in length to the example below).

-gustaf neumann

=================================
package require nx

nx::Object public method chain args {
   set methods [lrange $args 0 end-1]
   set arguments [lindex $args end]
   set result [list]
   foreach m $methods {
     lappend result [$m {*}$arguments]
   }
   return $result
}

Class create MyClass {
   :method a {x y z} {
     return "a $x"
   }
   :method b {x y z} {
     return "b $y"
   }
   :create m1
}

puts [::m1 chain :a :b {1 2 3}]

_______________________________________________
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: Wed, 22 Nov 2006 17:00:04 +0200 (EET)

On Wed, 22 Nov 2006, Kristoffer Lawson wrote:

> It's probably not desirable but if you think about it, you can see why that
> is happening. Objects are basically implemented as namespaces (well, at least
> they were at some point). A method is a proc inside a namespace. Thus a::name
> is the proc for that method. Now, objects are also commands. Placing it
> inside the namespace will create, well, the command a::name, thus overriding
> the method.

OK, I checked and the documentation does actually mention this behaviour
so I guess it is desired. Check:

http://media.wu-wien.ac.at/doc/tutorial.html#obj-agg

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

From: Catherine Letondal <letondal_at_pasteur.fr>
Date: Thu, 11 Jul 2002 23:54:38 +0200

Gustaf Neumann wrote:
> PS: how comes that debian still uses Tcl 8.2?

It is a debian potatoe...

Thanks for the fix, it worked!

--
Catherine Letondal -- Pasteur Institute Computing Center