Weblog Page

From: Victor Mayevski <vitick_at_gmail.com>
Date: Fri, 19 Mar 2010 22:20:11 -0700

Hello Gustaf,

I've been watching the change log in the git repository for XOTcl2 and
you are still making changes. Do you think it would be too early to
start transitioning my code to XOTcl2? Or the API is pretty stable
now?
Thanks.

From: Scott Gargash <scottg_at_atc.creative.com>
Date: Sat, 18 Mar 2006 15:12:08 -0700

Gustaf Neumann <neumann_at_wu-wien.ac.at> wrote on 03/18/2006 01:39:35 PM:
>
> I do not see much evidence of a speed increase when adding a layer of
> indirection for every object access.

Well, for example, it might be possible to get rid of namespaces in the implementation. If the
access to the object is always through the reference and the true object was never visible, you
might not have to create a new namespace (on demand or not) or ever move an existing object to make
it a child of another object. The parent/subobject relationship could be inferred from the alias's
location in the namespace, or even tracked in child/parent hash tables if you wanted to support
object relationships beyond a tree (DAGs), but it would not be a property of the object's location.
If objects never moved, everything could live in the same namespace, and just tracked via the object
hashes. And is method dispatch done via a command lookup? If so, an invariant method location should
allow command lookup to be elided.

Of course, since I'm the one who keeps asking "How do I do this?" questions, I'm probably completely
wrong.
BTW, does invocation via an alias have any overhead? I would guess not as it's (seems like) a
string->Tcl_Obj mapping, the same as a native command lookup, but I don't know.

> if the goal of such a project is "everything should be the same as in
> xotcl now, but move should be faster",
> then i would estimate a man-month of work of somebody with some
> tcl/xotcl c-level experience (like uwe or me).
> without looking into the details, i would expect problems from
> instrospection (including call stack),
> namespace handling (namespace import/exports, namespace completion),
> dynamic aggregation
> (creation, cleanup, semantics, when e.g. an alias is moved), and most
> probably many more hurldes
> will show up when going into the details.

I can't imagine it's a useful effort simply to optimize "move", and I'd also guess that some things
might be faster, some would be slower, and some would be incompatible with such a design. It would
have to have more payoff than speeding up "move" to to justify it.

> In general, it is possible to
> have multiple aliases (references) pointing
> to a physical object, in some cases you are interested in the namespace
> of the reference(s), in others in the
> namespace of the object.

When would you need the namespace of the object? If all you have is the reference (the handle is
truly opaque), you'd have no knowledge of the namespace of the object. Containment would have to be
implemented instead of just inferred, but if it's implemented it could have new properties.

This is what I meant by making new things possible. As you say, if you have references you can have
multiple references to the same object. Object hierarchies could be a directed graph instead of a
tree. I can imagine cases where that would be useful. (I can also imagine cases where it's a
bug...)

As an aside, I find Tcl's lack of true references to be one of its nagging flaws.

> it is certainly an interesting exercise considering such a
> strucure in general (therefore i wrote the simple example).

Yes, this is just a thought experiment, not a proposal.

> However, one could go much further:
> Thinking loudly:
> Since xotcl objects/classes are tcl_objs pointing to a c-structure
> representing the object/classes in c,
> and the tcl_objs are refcounted refcounted, i would think there could be
> ways achieving the flexibiliy
> even without indirection. Currently, these tcl_objs are bound to a
> single tcl-command. The aliasing
> effect could be achived in theory by using these tcl_objs in multiple
> tcl commands. I would
> expect some deeper changes here: what happens, if a child object is
> added under one name of
> the object; will this be visible for another name of the same object as
> well? If we continue to
> see an object as a object tree, it should. i expect here the same
> problems with namespaces as
> indicated earlier with the namespace rename command.

I agree. I think as long as the implementation and the interface for containment are the same
(namespace aggregation), the renaming problem remains. The handle needs to be opaque to break the
implementation dependency.

      Scott

From: Michael Schlenker <schlenk_at_uni-oldenburg.de>
Date: Wed, 19 May 2004 17:37:24 +0200

Neil Madden wrote:

> Just a random thought, not totally paying attention to this thread:
>
> Is there a reason why the filter/mixin lists could not just be normal
> object/class variables? Seems XOTcl already has plenty of flexibility
> to deal with these. E.g.:
>
> instead of:
>
> Object mixin ....
>
> do:
>
> Object set mixins [list ... ]
>
> or something like that (not completely familiar with the current
> syntax). The old methods could be setup to just be wrappers around
> these new variables. Or is there some reason why these lists are
> treated specially?

mixins and filters are no variables.

Its similar in tcl, where you have [info commands] and not a magic
$commands variable as you might have in other languages.

Using traces it should be possible to provide such an interface if
anyone really wants it.

Michael

From: Matthew Smith <chedderslam_at_gmail.com>
Date: Wed, 7 May 2008 13:20:18 -0500

Makes sense. Thank you for the help.

On Wed, May 7, 2008 at 1:15 PM, Kristoffer Lawson <setok_at_scred.com> wrote:

>
> On 7 May 2008, at 21:09, Matthew Smith wrote:
>
> Thank you for the help.
> >
> > Now I am getting another error I don't understand.
> >
> > invalid command name "my".
> >
>
> "my" is probably in the xotcl namespace. When I'm coding with XOTcl I
> always start with the following:
>
>
> package require XOTcl
> namespace import xotcl::*
>
> Then I have direct access to all XOTcl commands:
>
> Class Stack
>
> Stack instproc init {} {
> my instvar things
> # ...
>
> }
>
> / http://www.scred.com/
> / http://www.fishpool.com/~setok/<http://www.fishpool.com/%7Esetok/>
>
>
>

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Thu, 20 Jul 2006 14:13:37 +0200

Michael Schlenker schrieb:
> Probably not if you add a Tcl_IncrRefCount Tcl_DecrRefCount for the
> option Object.
>
> Michael
>
sure, i was just commenting the patch as it was posted in order to reduce
potential suprises...

 -gustaf

From: Neil Madden <nem_at_cs.nott.ac.uk>
Date: Wed, 19 May 2004 17:08:01 +0100

On 19 May 2004, at 16:37, Michael Schlenker wrote:

> Neil Madden wrote:
>
>> Just a random thought, not totally paying attention to this thread:
>>
>> Is there a reason why the filter/mixin lists could not just be normal
>> object/class variables? Seems XOTcl already has plenty of flexibility
>> to deal with these. E.g.:
>>
>> instead of:
>>
>> Object mixin ....
>>
>> do:
>>
>> Object set mixins [list ... ]
>>
>> or something like that (not completely familiar with the current
>> syntax). The old methods could be setup to just be wrappers around
>> these new variables. Or is there some reason why these lists are
>> treated specially?
>
> mixins and filters are no variables.

No, but a list of them can be put in a variable.

> Its similar in tcl, where you have [info commands] and not a magic
> $commands variable as you might have in other languages.

The reason for this is that commands are not first class, but are
instead implemented as a handle - you never get a first class command
value in Tcl (currently, see recent TIPs though), so you'd have nothing
to store in the variable (just another name, which has to be resolved
somewhere). This leads to a duplication of manipulator commands for
vars and commands:

set var value -> proc name ... / interp alias
set var -> info args/info default/info body
unset var -> rename cmd {}

etc, etc. This duplication of commands is what appears to be happening
for mixins/filters too. However, we are not storing mixins themselves
in this scheme, but the handles to them - which are in fact,
first-class. The fact that these handles are themselves command names,
which are already handled specially by Tcl, allows us to resolve them
without an infinite recursion.

There was another post about pre-processing which is done on mixin
lists (resolving names, removing duplicates etc). This is a better
argument, as it points out that wrappers would be needed anyway, so
looks like duplication of methods is unavoidable (at least, not
without more thought).

Cheers,

Neil.

From: <michael.heca_at_email.cz>
Date: Wed, 01 Sep 2004 19:12:50 +0200

Hi,

I found error in running XOTclIDE with new xotcl from version 1.3.0.

Error is raised by similar code:
---------------------------------------------
#!/usr/bin/tclsh

package require XOTcl
namespace import ::xotcl::*

Class NS
Class NS::Main

NS::Main proc m1 {} {
    my m2
}

NS::Main proc m2 {} {
    namespace eval :: Object crash
}

NS::Main m1
---------------------------------------------
Error is:
---------------------------------------------
couldn't find result of alloc
    ::xotcl::Object ::xotcl::Class->create
    ::xotcl::Object ::xotcl::Class->unknown
    invoked from within
"Object crash"
    (in namespace eval "::" script line 1)
    invoked from within
"namespace eval :: Object crash"
    (procedure "m2" line 3)
    ::NS::Main->m2
    invoked from within
"my m2"
    (procedure "m1" line 3)
    ::NS::Main->m1
    invoked from within
"NS::Main m1"
    (file "T:\home\heca\test\xotcl\e130.tcl" line 18)
---------------------------------------------

If i directly call NS::Main m2, everything is ok.

It is xotcl error or problem is in this code?


Michael Heca

From: Artur Trzewik <mail_at_xdobry.de>
Date: Sun, 14 Apr 2002 13:07:18 +0200

Hallo!

The Integrated/Interactive Development Environment for XOTcl
The new version of XOTclIDE 0.30 is ready on
http://www.xdobry.de/xotclide

The Changes from last annouced Version 0.24
- support for tcl procs (importing, genarating, managing). That let
  you mix old tcl code with xotcl code in one xotclIDE project.
  There are some reason still to write some tcl procs.
- unit tests cover almoust whole application.
- show of versions trees (components, classes, methods)
- better import function
- component save wizard (flexible source generation). Let you save
  componets: in many or one files, with or without metadata.
- many small improvements (same bags was removed)
- improvements in GUI
- support of MS Window platform (zip file)

have fun

Artur Trzewik

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Wed, 21 Mar 2007 12:25:18 +0100

Koen,
this should be fixed by the patch from january:

http://alice.wu-wien.ac.at/pipermail/xotcl/2007-January/005193.html

all the best
-gustaf

Koen Danckaert schrieb:
> Hi,
>
> It seems that error messages generated during object creation get lost
> sometimes. An example (using XOTcl 1.5.3 and tcl8.4.12):
>
> Define a class and a method foo with a typo in it:
>
> % Class C
> ::C
> % C instproc foo {} {puds foo}
>
> When foo is called on an existing object, we get the right error message:
> % C c
> ::c
> % c foo
> invalid command name "puds"
>
> However when foo is called during object creation, the error message
> is lost:
> % C d -foo
> during '::d foo'
> % set errorInfo
> during '::d foo'
> ::d ::xotcl::Object->configure
> ::C ::xotcl::Class->create
> ::C ::xotcl::Class->unknown
> invoked from within
> "C d -foo"
>
>
> Regards,
> Koen
> _______________________________________________
> Xotcl mailing list
> Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl

From: Krzysztof Frukacz <frukacz.krzysztof_at_gmail.com>
Date: Tue, 08 Feb 2011 10:18:37 +0100

Hello Stefan,

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). Is it a bad idea to expand that list and
pass 7200 arguments to init?

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

Best regards,

-- 
Krzysztof