Weblog Page

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Mon, 03 Nov 2008 12:53:22 +0100

Dear XOTcl Community,

XOTcl 1.6.2 is available. See below for more details.

Best regards
-gustaf neumann


Announcing XOTcl 1.6.2
*************************

We are pleased to announce the availability of XOTcl 1.6.2

Major changes relative to 1.6.1 are:

   * Functional extensions:
      - handle nonposargs in method "copy" properly

      - new command ::xotcl::finalize
       (for forcing cleanup and destuctor execution at a time in
       a multi-threaded environment, where it is still safe to execute
       all tcl commands)

   * Extended and generalized "info" method

    - Added "<class> mixinof -closure ?pattern?"
      Query the objects for which <class> is used as a per-object-mixin
      (directly or indirectly)

   * Fixes for potential crashes

    - Implemented proper downgrading of Classes to Objects (handle
      cases, where something was created first as an object and is
      reclassed/recreated later as a class) and vice versa

    - Reset mixin order for per-object mixins, when the superclass of
      a class is deleted, which is used as per-object mixin


   * Improved documentation

   * Extended regression tests

   * Some code cleanup
 

 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

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Mon, 08 May 2006 22:15:41 +0200

> BTW, this will happen with any method, not just "destroy".
>
i know.
>
> Is it not considered acceptable to ever remove a mixin class?
>
> When is it valid to remove a mixin if removing it corrupts the method
> chaining?
>

removing a mixin class from the mixin list does not "corrupt" the chain
in the sense that there
is a memory corruption etc. The current implementation does not allow to
remove
***active*** mixin classes, this are the classes of which the method is
currently executing.

what does this mean, assume there are classes M1, M2, M3, all of the form

Class M2
M2 instproc foo {} {
    BEFORE
    next
    AFTER
}

Object o -mixin {M1 M2 M3}

when method foo of M2 is called, M2 is the active call. If between the
invocation
of foo of M2 and "next" the mixin class M2 is removed for o, "next" has the
problem to find the continuation (next searches the current mixin
classes of o
for the currently executing Class). If this class is not found (your
example),
the list is searched to the end and no other Mixin classes are searched.

So, the only restriction is that you are not allowed to remove the mixin
from o
in the BEFORE part of M2. If you remove M2 from the BEFORE part of
M1, there won't be a problem, since foo of M2 won't be called. If you remove
M2 in AFTER of M2 foo, there would not be a problem either, since "next"
was alreday executed.

It looks quite easy to give a reasonable error message, when the
currently active
mixin class is deleted, it will be more expensive to handle this problem in
a friendly way.

Hope, this explains, what is happening.

-gustaf

PS: wouln't be conditional mixins a solution for your problem?

From: Jade Rubick <jade_at_volunteersolutions.org>
Date: Wed, 6 Feb 2008 07:18:08 -0800

Kristoffer:

Can you post some more information about how the API looks and works?
Your blog post doesn't have much information on how it works or looks.

Jade

Jade Rubick
Acting Chief Technology Officer
United eWay

jade.rubick_at_uwa.unitedway.org
w: 503.285.4963
f: 707.671.1333

http://www.UNITEDeWAY.org

On Feb 6, 2008, at 3:00 AM, xotcl-request_at_alice.wu-wien.ac.at wrote:

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Fri, 24 Jan 2003 15:01:33 +0100

On Friday 24 January 2003 04:32, Kristoffer Lawson wrote:
> Been thinking if this would make sense:
>
> while {$stuff} {
> tie myVar [MyClass new]
> ...
> }
>
> And the instance created from MyClass would be automagically collected on
> each iteration. Ie. [tie] would tie an object to a variable: when the
> variable's value is changed, or when the variable is destroyed, the object
> is too -- or at least the refcount decreased. I often have Message objects
> which are used once (after some data is read from somewhere) and then
> destroyed. Quite often I forget the latter part ;-)
>
> / http://www.fishpool.com/~setok/

 there are already many approaches for destroying object automatically.
 look at the following code (hope there are not to many typos)
  
Class C
C instproc destroy {} {puts "[self] destroy"; next}

C c1
c1 proc t1 {} {
  for {set i 0} {$i < 10} {incr i} {
    O new -volatile
  }
}
c1 proc t2 {} {
  for {set i 0} {$i < 10} {incr i} {
    O new -childof [self]
  }
}
c1 proc t3 {} {
  for {set i 0} {$i < 10} {incr i} {
    O [self]::$i
  }
}
c1 proc t4 {} {
  for {set i 0} {$i < 10} {incr i} {
    O [self]::i
  }
}


 -t1: after the loop, all objects exist, the automatically destroyed, when t1 is left.
 -t2: all objects survive t2, they are deleted, when c1 is destroyed
 -t3: same as t2, but the programmer has more control over object names (see also t4)
 -t4: on each iteration an object is created and destroys a potentially same-named object.
    after t4, c1 contains one sub-object, which is destroyed, when c1 is destroyed
    (this is somewhat similar in the behavior to the code that uwe posted).

 we could provide an option -bind <varname> to the new instproc to allow
 the user to specify a local or a per-object or global variable name, but
 this does not provide reference counting at all. i have started some time ago
 to work on reference counting, and xotcl has some good prerequirements
 for this: we have tcl_objs for xotcl objects, they maintain already a reference
 count. the obvious idea is to destroy the object, when the reference count
 reaches 0. however, practically this showed to be quite tricky in the current
 implementation since the refcount = 0 condition happens in some unvonveniant
 situations... i have not given up on this, but it needs a bigger chunk of time to
 devote to this...

 best regards
-gustaf


>
>
> _______________________________________________
> Xotcl mailing list - Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl

-- 
Univ.Prof. Dr.Gustaf Neumann
Abteilung für Wirtschaftsinformatik
WU-Wien, Augasse 2-6, 1090 Wien

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Sun, 13 Nov 2005 13:14:21 +0300

This is with XOTcl 1.3.6, but I couldn't find if 1.3.8 fixes it. The
following code does not appear to work as expected:

package require XOTcl
namespace import xotcl::*


Class A

A instproc init {test} {
     puts "init: $test"
}

A instproc foo {text} {
     puts "foo: $text"
}

A instproc bar {text} {
     puts "bar: $text"
}

A new "on taas" -foo jou -bar blah
A new -foo jou -bar blah "on taas"

The first will work, but the latter will not. The error is:

wrong # args: should be "bar text"
     ::xotcl::__#1 ::A->bar
     ::xotcl::__#1 ::xotcl::Object->configure
     ::A ::xotcl::Class->create
     ::A ::xotcl::Class->new
     invoked from within
"A new -foo jou -bar blah "on taas""
     (file "dashCreateTest.tcl" line 23)

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

From: Ben Thomasson <ben.thomasson_at_gmail.com>
Date: Wed, 4 Jun 2008 09:23:12 -0400

Hi,

I have a problem with the following code:

[xotcl-1.6.0]$ ./xotclsh
% ::xotcl::Object eval set a 5
5
% ::xotcl::Object eval ::xotcl::Object set a 5
5
% ::xotcl::Object eval ::xotcl::Object set
Segmentation fault


This line works fine:

::xotcl::Object eval ::xotcl::Object set a 5

This line causes a Segmentation fault:

::xotcl::Object eval ::xotcl::Object set

It should just throw an error.

This code is similar but does not have the problem:

[xotcl-1.6.0]$ ./xotclsh
% ::xotcl::Object eval ::xotcl::Object lappend a 5
5
% ::xotcl::Object eval ::xotcl::Object lappend
wrong # args: should be "lappend varName ?value value ...?"
% exit

This was on a fresh compile of Tcl8.4.19 and XOTcl1.6.0.

Let me know if you see this in your builds.

Thanks,

Ben

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Tue, 23 Jan 2001 00:59:32 +0200 (EET)

We're still getting the odd problem with destroy, even with an update to
0.83. The situation is the following:

An Event object exists in the system.
An event is sent to this object (and the 'event' method of this object is
called).
The event method calls another method in another object which is
set to be the event callback.
As a result of this call the object gets destroyed. Or rather it destroys
another object (its parent), which in turn destroys the Event object.

According to the "destroy" logic, this should work fine. And in fact it
does.. for a while. At some point during the execution of the
callback I get this message:

destroy failed (probably wrong # args?) or object called after physical
destroy
    while executing "$ob event [$cmd getAttrs]"
    (procedure "newData" line 24)
    ::eniak::EniakServer0 ::eniak::EniakServer->newData
    invoked from within "
::eniak::EniakServer0 newData"

This comes at some point during the execution of the event method (which,
as mentioned, is a method of the Event object). This seems to be very
difficult to replicate as the simple cases I've built wont do the trick.
To give you some idea why it's so difficult I'll mention that in my first
case it crashed (as above) just after (successfully) creating a
SelectionList object in my callback. To see if it was the amount of
created objects that mattered, I instantiated a Text object before this.
It still crashed with the SelectionList. The natural assumption then is
that there might be something funny with the SelectionList. Just to be
certain, I created a Button between the Text and SelectionList. Now it
crashed immediately after the Text object -- before it even reached the
Button or SelectionList in the code! Removing the Button made it crash
after the SelectionList again...

This would lead me to believe that there may just be a small possibility
of some kind of memory overwriting taking place or something else very
funny. I'm really sorry to be this vague. Maybe I missed something after
all, but I've been debugging this all day and I just can't find anything
suspicious myself and am running so tight with time I can't really spend
much on this -- especially as it's rather random. The problem is also that
it's not very obvious how to go round this particular case without
seriously altering the structure of the code.

If there is anything that can cause this I'd really appreciate some
tips. Or if there is a bug somewhere in there a patch would be
splendid. As we've already missed one deadline I'd appreciate any help I
can get. I can send the code that causes the problem, although I'm not
sure how much it will help as there's quite a bit of it. I might be able
to cut some irrelevant parts off, though...

Meanwhile I'll sleep over it and see if I solve it in my dreams.

         - ---------- = = ---------//--+
         | / Kristoffer Lawson | www.fishpool.fi|.com
         +-> | setok_at_fishpool.com | - - --+------
             |-- Fishpool Creations Ltd - / |
             +-------- = - - - = --------- /~setok/

From: Troy Heron <troy.heron_at_hixxy.org>
Date: Sat, 27 Apr 2013 08:24:34 +1000

Hello,

Before I look at using the NSF Mongodb driver, I'd just like to know if the
driver compatible with the latest mongodb (2.4)? Also, does it support
tailable cursors?

Thanks,
Troy

From: Jeff Hobbs <jeffh_at_ActiveState.com>
Date: Mon, 4 Apr 2005 13:23:10 -0700

Ben Thomasson wrote:
> Considering there is a safe interp in Tcl, there should be
> extensive unit testing that can be run in regression to make
> sure any new functionality like this does not break the
> security model. Does Tcl have regression tests (tcltest or
> other) that exercise the ability of safe interp to stop

Yes, Tcl has testing for its core safe functionality, as does Tk.

> dangerous code? If there is, then these tests could be run
> in at least Object eval to whether this simple
> approach would work. If not, there should be. Or is the
> security model based
> on proving the safety of an interp by analysis of the code?
> If you take this second approach them much more work must be
> done before xotcl includes this code for the safe interp.

The point is that xotcl could expose its own set of unsafe
functionality - like a completely alternative FS API. How
would that ever be covered by the Tcl test suite?

> ps ( In open source projects, is it the person who comes up
> with the idea who is the person to implement it? Dang. )

You betcha - you're hired! ;) I don't think it is actually
that much work in xotcl's case, I'm just saying that it should
not be rubber-stamped.

Jeff

From: Michael Schlenker <schlenk_at_uni-oldenburg.de>
Date: Mon, 25 Nov 2002 03:01:45 +0100

Hi,

i tried to use tclkit (8.4.1, windows) with XOTcl 1.0 and always get the
annoying error message:
"Cannot locate the XOTcl library on your system!"

when i try to [package require xotcl] in tclkit.

I read the source code, where the message seems to be generated and
found that it is produced by some code that tries to modify the
auto_path on loading of the xotcl**.dll. This seems to fail when loaded
as a dll.

What has to be done to get rid of the error message and to get the
library found?

At the moment i do:
lappend auto_path [file join $xotcl-dir library]

This seems to work, if xotcl-dir is set to the lib dir used by XOTcl.

Other than those minor problems, are there any known problems using
XOTcl 1.0 with Tclkit?

Michael Schlenker