Weblog Page

From: Artur Trzewik <mail_at_xdobry.de>
Date: Tue, 22 May 2001 21:41:30 +0200

Hi

Thanks for good resource tip to Kristoffer Lawson.
There are good publication at
http://ftp.sage.usenix.org/events/tcl2k/duffin.html

The Feather tcl extension seems to be very interesting.
It is shame it was published only as Windows binary
(Kann ein Mensch so tief sinken?)

I have made first attempt to implement it and I have noticed
one big Problem.
source as Xotcl extension
http://www.xdobry.de/xotclref.tar.gz
(copy in xotcl/src and make -f XRMakefile)

example

Class A
set a [A newReference]
$a set var value

by last line the tcl interpreter try to convert my new type
to Tcl_ObjType tclCmdNameType
by this operation the internal representation is freed.
And so the object is deleted before I can use it as command

There can be 2 solution on this problem

1. Special invoke of referenced objects
    invokeRef $a set var value
   it is probably also used by Feather extension.

2. Overwrite the interal pointers of Tcl_ObjType tclCmdNameType
    SetCmdNameFromAny see tcl sources generic/tclExecute.c
    it should not freed our new Tcl_ObjType XOTclReferenceObjectType

So I give up. These two solution does not seems to be acceptable.
Maybe futures version of tcl interpeters will offer more flexible
type conversion solution. The new type should decide by itself
how it can be converted to another type.

=========================================

 Artur Trzewik
 http://www.xdobry.de

=========================================

From: Artur Trzewik <mail_at_xdobry.de>
Date: Sun, 12 Oct 2003 11:29:36 +0200

Hi!

I have noticed some problems by passing parameters by class creating

Example

% Class A -parameter par
::A
% A create a -par -e
Can't find result of parameter par during '::a par'
%

# This one was OK.

% A create a
::a
% a par -e
-e

It seems it is imposible to pass any parameter value beginning with '-' by
creating some instance.
Is there any workaround for this problem?

Artur Trzewik

From: Jeff Hobbs <jeffh_at_ActiveState.com>
Date: Mon, 18 Oct 2004 13:43:33 -0700

> > > xow - A megawidget framework. This is a package that allows
> > > xotcl objects to be megawidgets.
> >
> > Does this handle the option db correctly, do composition
> > of megawidgets, handle focus and events right, etc.?
>
> No, currently doesn't handle the option db. This is a tricky
> area of building megawidgets. An xow widget can be based off
> of any other existing widget or megawidget. That can make
        ...
> There is no special code to handle composition of
> megawidgets, focus, or event processing.

While I don't want to discourage good coding exercises, I
do want to encourage others to use code based on all the
best practices. We don't have a perfect megawidget
framework to rely on yet, but hopefully you'll be willing
to take part when we get around to it, or maybe work on
yours until it is that system. ;)

> > > xcentuate - a theme engine for tk. This isn't all that

> > I would not propagate this in favor of Tile. There is

> I'm not sure what "style" package you are refering to. I see
> none in the docs for TkLib, but maybe I missed them or it's
> not in the latest official release. I did manage to google up
> a "as::style" package that you appear to have written. So
> I'll assume that's the package to which you refer.

Yes, that's a variant that was included.

> xcentuate provides the common things like colors and
> borderwidth for widgets. It also provides some named colors
> and eventually named fonts. I have some good font generation

Hmmmm ... ok, you have created something more for users to
define their own themes, whereas 'style' says "these are
better overall alternate themes". I must say that I
personally encourage the latter. It's a pity you couldn't
make it to Tcl'2004 last week, because I had a tutorial
and talk on these points. I don't mean to pick on you, I
just want to give my ideas and how they may affect your
current efforts.

The whole idea of themeing, which will be core in 8.5, is
to enable a better look for Tk. However, it is not
intended for the user (in the common case) to change this
theme. The functionality is there merely for Tk to better
adapt to current styles. Thus, the 'style' code defines
styles for users to just use, rather than providing a
framework to create their own.

> I look forward to Tile being part of 8.5 so I can declare
> this obsolete.

Note that tile works perfectly well with 8.4. ActiveState
will actually be shipping an app RSN that uses tile. What
is now a testbed will soon be a core feature, but that
doesn't mean you can't use it now.

> interact with each other. Also, on a side note, I hate having
> to specify a test name with tcltest.
        ...
> It's fine until you realize next month that you need a new
> test, and that it make more sense from a readability
> viewpoint to stick it in between example-1.1 and example-1.2.
> Do I call it example-1.1.5 or renumber the other tests below?
> The test name doesn't add much to me, the tester. It's the
> description that matters. For comparison purposes, xout test

OK, I've dealt with this before. There is nothing in the
naming of that test that requires it be numbers, that is
just convention. It makes it easier for grouping and such,
and is handy when searching through the test suite after
failures. In your example below:

> file would be structured as follows:
>
> TestSuite foo \
> -description "blah" \
> -setup {set file [makeFile {} test]} \
> -cleanup {removeFile test}
> foo test \
> -description "test file existence"
> -result 1 \
> -script {file exists $file}

What happens when you don't provide a description? This
should be a required field, as it is in tcltest, so why
have it an option? Otherwise, I see the structure you
have chosen could make it easier to build tests.

> Finally, xout is only a framework. It can be embedded into
> other applications such as an IDE. That can easily find and
> query TestSuite objects to run and get their results. Just so
> happens that the GUI can also be embedded in or run standalone.

I like the UI you added to it.

> I threw some screen shots of xcentuate & xout in action on my
> (unfinished) website if anyone wants to take a look.
> http://www.abschofield.com/code/ss/

Very nice.

> Sorry for being long winded.

No problem, and I don't want to sound negative. I'm just
trying to assist constructively. As I've told Gustaf and
Uwe before, xotcl (or some close variant) could be the OO
for the core, if it provided 100% itcl compatability (for
the many many folks that rely on itcl).

Jeff

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Mon, 10 Mar 2008 08:42:49 +0100

Dear Edmond,

Thanks for noting this. There is indeed a bug in this
version concerning info class, at least a documentation
bug.

"<obj> info class ?pattern?" is implemented in the case a
pattern is given internally by the means of in info superclass.
"info superclass ?-closure? ?pattern?" was changed together
with other info options (see changelog). Since "info"
is not fully backwards compatible, the major release
number changed.

The recommended way to check, if an object is of a certain
type (is a direct/indirect instance of a certain class) is to
use "istype".

   % Class Foo
   ::Foo
   % Foo f
   ::f
   % f istype Foo
   1
   % f istype Object
   1

The old interface matches only with the
superclass elements, when pattern is specified.
There are essentially two options to proceed:

(a) "info class ?pattern?" could be fixed to match
with the current class and the superclasses, but then
it should return always empty, when the pattern
does not match, as it is now in accordance to
other cases, where ?pattern? is used.

(b) It is as well possible to remove the ?pattern?
argument from "info class", since there is as well
istype. Note that there is as well
"info precedence ?pattern?", which returns the
resolution order including mixins and superclasses.

approach (a) makes it easy to query the classes either
with or without mixins, but to get the full list,
one should use "[f info class] info superclass -closure",
or we implement as well a "info class -closure".

Or in the case (b) "info precedence" could get
an option to list only intrinsic classes (classes
which are no mixins). One can use a single
method to get a full or partial list, and one can
use ?pattern? to filter the list in a uniform way.

Opinions?

best regards
-gustaf neumann

Edmond Ho schrieb:
> Hello all,
>
> I downloaded XOTcl 1.6.0 today, and I immediately ran into an issue in
> some of my existing code. The following example works in XOTcl 1.5.6,
> but is different in XOTcl 1.6.0 -- as I understand the documentation
> on the website, there should be no difference between versions.
>
>
> package require XOTcl
> namespace import ::xotcl::*
> Class Foo
> set f [Foo new]
> $f info Class ;# returns "::Foo", which seems correct
> $f info Class "Foo" ;# in 1.5.6, returns 1; in 1.6.0, returns an empty
> string
>
>
> To repeat, the issue is that "Object info class <classname>" returns a
> boolean value in XOTcl 1.5.6, but returns an empty string in 1.6.0 --
> the current documentation on the website suggests that the 1.5.6
> behavior is correct.
>
> Am I missing something? Should the documentation be changed, or is the
> behavior in 1.6.0 incorrect? I downloaded the package via
> ActiveState's teacup service; I'm working on Mac OS X 10.4 Intel.
>
> Thanks in advance for any help!
>
> Cheers,
> Edmond
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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: Mon, 28 May 2001 20:02:52 +0300 (EEST)

On Mon, 28 May 2001, Gustaf Neumann wrote:

> Dear Kristoffer,
>
> are you aware of the predefined methods "new" and "newChild" (the first one
> simplifies only the call to autoname, while the second one creates a new
> autonamed object as an aggregated child object). These convenience methods are defined
> in the langRef. the definition of newChild is below...

Yes, I'm aware of them, but they do not do what I mean. I want to
create an object as a child of an already existing object which != [self].
"new" creates a new object, but not as an aggregate of another object,
"newChild" creates a new object as the child of the calling object. These
are very convenient and I use both a lot, but the method I proposed is
for easily aggregating a new object to anything.

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

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Mon, 3 Mar 2003 13:30:33 +0200 (EET)

Seeing as I use XOTcl on the server side, this might be interesting to
people on this list.


What is the Ants project?

Ants is a generic system for running any kind of distributed code,
intended to replace application-specific systems like the one used by
SETI_at_home. The idea is to be able to write scripts with areas defined to
be run on the Ants network. These script fragments can then communicate
with the original script by passing messages. The server admin can specify
which libraries scripts are allowed to load. In addition to that, by
configuring the system and attaching more scripts to it, it can be a
valuable system administration framework for both small and large
networks.

http://people.fishpool.fi/~setok/ants/


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

From: Laurent Duperval <lduperval_at_videotron.ca>
Date: Fri, 28 Feb 2003 23:41:42 -0500 (EST)

HI,

I just installed xotcl 1.0.1 with a version of Tcl taken from CVS. WHen
I tried to install and test, I had problems because the
tcl_platform(platform) variable couldn't be found in the pkgIndex.tcl
files. I had to change all of them to ::tcl_platform(platform).

Just thought you should know.

L

-- 
Laurent Duperval <mailto:lduperval_at_videotron.ca>
ESTRIDGE'S LAW
    No matter how large and standardized the marketplace is, IBM can
    redefine it.
                                                          -
Tap Into Your Full Potential/Puisez Dans Votre Plein Potentiel
My/Mon Club:          http://www.geocities.com/tmsuroit
My/Mon District:      http://www.toastmastersdistrict61.org
My/Mon Organisation:  http://www.toastmasters.org

From: Uwe Zdun <uwe.zdun_at_wu-wien.ac.at>
Date: Sat, 22 May 2004 12:29:41 +0200

Hello,

my 2 cents: I liked the earlier proposal with the "interceptor" method
better
than this delegator,because it is more XOTcl style. I think it is important
to have one kind of
interface; we always use methods on the object itself, not methods that
delegate.
That's also the reason why I don't think the magic variable should be
introduced: it is
simply not Tcl style to have magic variables. Even though both ideas are
appealing, I think
sticking to Tcl/XOTcl style is important.
I agree with the critic on the term interceptor:
the interfaces for filters and mixins should be distinct: they are different
concepts.
BTW, superclass lists could make use of the same interface: obviously here
the
term interceptor is not appropriate.

what about just extending the usually interfaces with new arguments, such
as:

A mixin X
A mixin add Z 3
A mixin add Y end
A mixin delete Y
A instmixin add T 1
A superclass B
A superclass add C

--uwe



> -----Ursprüngliche Nachricht-----
> Von: xotcl-admin_at_alice.wu-wien.ac.at
> [mailto:xotcl-admin_at_alice.wu-wien.ac.at]Im Auftrag von Gustaf Neumann
> Gesendet: Freitag, 21. Mai 2004 20:09
> An: Adam Turoff
> Cc: xotcl_at_alice.wu-wien.ac.at
> Betreff: Re: [Xotcl] Mixins in XOTcl
>
>
> On Wednesday 19 May 2004 17:03, Adam Turoff wrote:
> > > what do you people think about the following "interceptor"
> > > method: it is more verbous, but much more powerful as
> > >
> >
> > Hm...
> >
> > One minor niggle is the use of the term 'interceptor'. The
> > term is quite overloaded. First, this instproc manages two kinds of
> > 'interceptor' interfaces for an object: mixins and filters.
> Second, the
> > proc itself is an interceptor -- it traps calls to manage the mixin and
> > filter lists. Third, as you have written this proc, it manages
> > both mixins and filters, which makes them appear more similar than they
> > really are.
>
> what you said is certainly true. I have suggested the term with a
> mindset that these two are "additional kind of interceptors normally
> not supported by other languages" (similiar to the section "Message
> Interception Techniques" in the tutorial).
>
> Your concern seems to be mostly the "name" interceptor.
> The commands have to do with what's sometimes is called
> "write introspection" in analogy to "read introspection", where
> you query some properties and relations of created artefacts.
> The former lets you change some properties/relations.
>
> The normal xotcl interface to (stack-independet) introspection
> is the info command. The pattern to change things is
>
> set old [X info PROPERTY]
> X PROPERTY [modify $old]
>
> where property is for example mixin, instmixin, filter, instfilter.
> The same pattern works with some more properties
> such as "superclass", or to some extend "class"
> as well. Some of the read-introspectable tcl properties
> such as [info body ...] or [info args] or [info default]
> could be made writable as well, but the benefit
> compared to a proc command would be relative small.
>
> I am not a big friend of magic variables as base
> mechanism, since otcl did not let me allow to use
> "class" or "proc" as names of instance variables.
> Methods are better since they can be easily refined.
>
> Look at the following study; it does not have the
> switch ugliness with different arglists, it is
> extensible and interceptible:
>
> Object introspection
> introspection proc get {obj prop} {$obj info $prop}
> introspection proc set {obj prop value} {$obj $prop $value}
> introspection proc add {obj prop value {pos 0}} {
> $obj $prop [linsert [$obj info $prop] $pos $value]
> }
> introspection proc delete {obj prop value} {
> set old [$obj info $prop]
> set p [lsearch -glob $old $value]
> if {$p>-1} {$obj $prop [lreplace $old $p $p]} else {
> error "$value is not a $prop of $obj ($old)"
> }
> }
> introspection proc unknown {m args} {
> puts "method '$m' unknown for [self]"
> puts " valid commands are: {[lsort [my info procs]]}"
> }
>
> we can define a filter to see the consequences of
> our doings:
>
> introspection proc i-filter {obj args} {
> set r [next]
> if {[string compare $args ""] && [my isobject $obj]} {
> set prop [lindex $args 0]
> puts "$prop of $obj = [$obj info $prop]"
> }
> return $r
> }
> introspection filter i-filter
>
> now we can try it out:
>
> Object o1
> introspection add o1 mixin A
> introspection add o1 mixin B
> introspection add o1 mixin C end
> introspection delete o1 mixin *A
> introspection delete o1 mixin *A
>
> well, we can shuffle the arguments in a little
> reflector instproc:
>
> Object instproc introspection {cmd prop args} {
> eval introspection $cmd [self] $prop $args
> }
> o1 introspection add mixin A
>
> and we have an "... introspection get ..." and friends again
> and get an error message for a
>
> o1 introspection cancel mixin A
>
> .... but: i am not so happy about the name
> "introspection" in "introspection set" and
> "introspection add" as well, since it requires
> familiarity with "write introspection" which is
> not only a "*spection" in the sense of
> "looking into", but destructive.
>
> suggestions?
> -gustaf neumann
> --
> Univ.Prof. Dr.Gustaf Neumann
> Abteilung für Wirtschaftsinformatik
> WU-Wien, Augasse 2-6, 1090 Wien
> _______________________________________________
> Xotcl mailing list - Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
>

From: Stefan Sobernig <stefan.sobernig_at_wu.ac.at>
Date: Mon, 13 Feb 2012 10:51:55 +0100

Artur,

> The new release of XOTclIDE 0.85 is [...] Compatible with XOTcl 2.0

Many thanks for your efforts, this is much appreciated!

> Indeed XOTcl 2.0 seems to be the most backward compatible version ever
> of XOTcl. I was quite surprised that my many thousand of XOTcl code runs
> without problems with XOTcl 2.0. So version difference 1.6 to 2.0 seems
> to be most internal nature.

This is good news for us!

> The method names can not start with : but it was used in _at_ Object to
> store meta information for IDE.

> All just remove the colons from meta descriptions
>
> For example
> _at_ ::IDE::Browser idemeta component IDEBaseGUI
>
> to
>
> _at_ IDE::Browser idemeta component IDEBaseGUI

If you allow for a suggestion: You may easily offer a backward
compatibility patch here, to take this tiny burden of XOTclIDE users:

Register a filter method for your _at_ object which takes care of mangling
and redirecting ::-qualified names, for example like this:

xotcl::Object create ::_at_ -proc unknown {selector args} {
   puts stderr "TRAPPED: ::$selector"
}

proc ::foo {} {
   puts stderr "PROC called"
}

_at_ ::foo; # the proc ::foo is called

#
# Provide for backward compatibility of meta descriptions ...
#
::_at_ proc asMetaDescription args {
   set componentName [self calledproc]
   if {[string match {::*} $componentName]} {
     my [string trimleft $componentName :] {*}$args
   } else {
     next
   }
}
::_at_ filter add asMetaDescription

_at_ ::foo; # trapped by filter + unknown

::_at_ filter delete asMetaDescription

_at_ ::foo; # the proc ::foo is called, again

Assuming that the _at_ processing is not a performance-critical evaluation
path in XOTclIDE component scripts, this is an acceptable approach. You
could optimise the code further, by inlining the component handling from
unknown into asMetaDescription ... rendering unknown obsolete.

//stefan

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Thu, 2 Sep 2004 19:58:07 +0300 (EEST)

It states that object-local variables are accessible as normal Tcl
variables inside the script, but what about methods? I noticed the
following:

% package require XOTcl
1.1
::ob
% ob proc pomous {} {puts pomous}
% ob eval pomous
pomous
% xotcl::Class JOu
::JOu
% JOu instproc uoah {} {puts jeah}
% JOu ob
::ob
% ob eval uoah
invalid command name "uoah"

Is that guaranteed to work at all? Is there any proper way to get what I
want to do?

The reason I'm doing this is because I'm implementing a type of binary
reading command which looks something like this:

buynary::scan $clusterDat {
     option endian little

     format {
         object root {
             short objNum
             short $objNum objIDs
         }

         object * children {
             short 3 cellID

             short addObjNum
             short $addObjNum addObjIDs

             short rmObjNum
             short $rmObjNum rmObjIDs
         }
     }
}

It uses XOTcl to build a representation of the binary data as objects. I
made a version which parses the format manually, but for performance
reasons I'd like Tcl to do that. Ie. to have, in a particular context,
commands such as 'format', 'short', 'object' etc. Then I could just [eval]
the whole nonsense and get all the performance benefits that has to offer.

One could always do this using namespaces, but that would be really
annoying as I've started off with XOTcl for this.

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