Weblog Page

From: Uwe Zdun <uwe.zdun_at_wu-wien.ac.at>
Date: Tue, 13 May 2003 12:22:35 +0200

On Tuesday 13 May 2003 11:49, Gustaf Neumann wrote:
>
> > and use the local directory
> > when you are in it so that you don't necessarily have to install.
>
> as stated in my last mail. extending the autopath or tcllibpath
> should solve this.
>

and that (extending the autopath) is exactly what the method
check_library_path essentially does. I think we can get rid
of the part:

            foreach d $::auto_path {
                set xl xotcl$::xotcl::version
                foreach x [list [file join $d $xl] [file join $d .. $xl]] {
                    #puts stderr "check $x"
                    if {[file isdirectory $x]} {
                        set ::xotcl::lib $x
                        set success 1
                        break
                    }
                }
                if {[info exists success]} {break}
            }

if we don't want the xotcl::lib variable ... the rest (except the ENV part) is
needed somewhere, i think. I guess, if we code these things into the pkgindex
files we would need a different version for the Win and unix installation.


> there is code in the xotcl package "package" to determine
> the name of the library directory. an application needing this
> info can use this approach...

I'm not sure, which method do you mean in package.xotcl??

--uwe

-- 
Uwe Zdun
Department of Information Systems, Vienna University of Economics
Phone: +43 1 313 36 4796, Fax: +43 1 313 36 746
zdun_at_{xotcl,computer,acm}.org, uwe.zdun_at_wu-wien.ac.at

From: Krzysztof Frukacz <frukacz.krzysztof_at_gmail.com>
Date: Tue, 18 Jan 2011 15:32:45 +0100

Hello,

I need an example of implementation of a getter.
I have an attribute in a class which now needs a customized getter.
Class A -slots {
        Attribute attr -proc get {domain var} {
                #how to get attr value here? if I do [my attr] I get recursive call.
$attr says that there is no such variable
        }
}

Another question: should I use -proc get or -proc valuecmd? valuecmd
does seems to be not called at all.

Best Regards

-- 
Krzysztof Frukacz

From: <uwe.zdun_at_uni-essen.de>
Date: Fri, 8 Dec 2000 12:57:35 +0100 (CET)

Hi Zoran,

ZV> The main problem is the ORDER! What I need to
ZV> do is run a script against an initialized interpreter
ZV> and construct another script which will replicate all
ZV> XOTcl objects, classes etc,etc in an fresh interpreter.
ZV> So the *ORDER* of commands is crucial.

I've played around with ordering, when I've created the -- still very
incomplete -- script creation for agents. So what I've done now is to
extend the ScirptCreator component (in packages/script-creation) to
support several classes & objects with a method makeScriptForAll. It
then writes scripts with one possible order regarding the object &
class hierarchy.

It is still very incomplete ... but should already show how things
could function. It only handles procs and instprocs, but not:

-- adavanded features, like filters, mixins, etc. (for them ordering
   matters, too .. you cannot define a mixin without the class
   being defined)
-- tcl namespaces
-- indentation

I'll hope to extend & test it ASAP to support more functionalities,
but today I will not make it. Therefore, I send what I have so far.

It already handles another crucial issue besides ordering: it can
exclude certain objects & classes from re-creation. You surely do not
want the script creator itself or the predefined stuff (like Object
and Class)to be re-created.

--Uwe

Here's the example script:

###################################################################
# load the ScriptCreator
package require ScriptCreator
ScriptCreator s

# exclude everything defined so far
s excludedObjs [s getAllInstances Object]
puts "EXCLUDED [s excludedObjs]"

# set up some classes for testing

#
# some meta classes
#
Class Meta -superclass Class
Class Meta2 -superclass Meta
Class Meta3 -superclass Meta2
#
# some classes
#
Class X
Class Y
Meta Z
Meta2 A
Meta2 B
#
# some objs
#
X x
Object o
Y y1
Y y2
A a1
A a2



puts [s makeScriptForAll]

###################################################################

-- 
Uwe Zdun
Specification of Software Systems, University of Essen
Phone: +49 201 81 00 332, Fax: +49 201 81 00 398
zdun_at_xotcl.org, uwe.zdun_at_uni-essen.de

From: Catherine Letondal <letondal_at_pasteur.fr>
Date: Thu, 05 Jul 2001 16:54:23 +0200

Hi,

One problem I have when using Tk and Xotcl together (actually the only one for
now), is that when I put a filter on a class (e.g for tracing purpose), the methods
which are called by a callback (a Tk binding for example) cannot return a -break
return code.

Here is an example of an error message:

invoked "break" outside of a loop
    while executing
"$view validate o o"
    (command bound to event)

This "validate" method is activated whenever the user enter something in a
text widget:

    ::bind $textwidget <KeyPress> {
        set view [names object %W]
        $view validate %K %A
    }

And this method does a return like this:
    return -code break

The problem happens only when a filter is put on the class.

What can I do to fix this?

-- 
Catherine Letondal -- Pasteur Institute Computing Center

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Fri, 24 Jan 2003 05:32:40 +0200 (EET)

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/

From: Jeff Hobbs <jeffh_at_ActiveState.com>
Date: Tue, 6 Apr 2004 11:51:40 -0700

Jim,

> As far as I've been able to determine, the tclsh which is
> called has to be able to find the libxotcl thing. Apparantly,
> not every tclsh I have is able to do that, so I looked closely at the
> SC_PROG_TCLSH macro (having traced the problem down to that
> macro) and noticed that it doesn't try to use the tclsh
> specified in the supplied tclConfig.sh, which as far as I
> know is the only correct choice (should use the tclsh linked
> to the same libs that were
> used in the build process of xotcl, and that can find the modules).

This is not correct, and indicates a problem elsewhere in the
xotcl make/test stuff. I see that it still uses the older TEA
stuff though, which might be the core problem (SC_* macros were
done away with a couple of years ago).

The TEA_PROG_TCLSH looks at TCL_BIN_DIR (specified in
tclConfig.sh), then the exec_prefix, prefix, and finally the
regular path. This is the right ordering, as it is better to
find the installed version first. It's still based off the
tclConfig.sh.

  Jeff Hobbs, The Tcl Guy
  http://www.ActiveState.com/, a division of Sophos

From: Victor Mayevski <vitick_at_gmail.com>
Date: Thu, 19 Jan 2012 11:33:41 -0800

Hello Gustaf,

Tried compiling NX today and it is failing. I am on Linux 64bit this
time, 3.2.0-8-generic kernel, compiling against latest TCL 8.6 Fossil
source. Make fails with the following error:

.....
gcc -DPACKAGE_NAME=\"nsf\" -DPACKAGE_TARNAME=\"nsf\"
-DPACKAGE_VERSION=\"2.0b3\" -DPACKAGE_STRING=\"nsf\ 2.0b3\"
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DSTDC_HEADERS=1
-DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1
-DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1
-DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1
-DHAVE_LIMITS_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_TCL_COMPILE_H=1
-DNSF_WITH_ASSERTIONS=1 -DUSE_THREAD_ALLOC=1 -D_REENTRANT=1
-D_THREAD_SAFE=1 -DTCL_THREADS=1 -DMODULE_SCOPE=extern\
__attribute__\(\(__visibility__\(\"hidden\"\)\)\)
-D_LARGEFILE64_SOURCE=1 -DTCL_WIDE_INT_IS_LONG=1 -DUSE_TCL_STUBS=1
-DCOMPILE_NSF_STUBS=1 -DNSF_VERSION=\"2.0\" -DNSF_PATCHLEVEL=\"2.0b3\"
     -I"/root/tcl-source/generic" -I"/root/tcl-source/unix"
-I./generic -g -O2 -pipe -O2 -fomit-frame-pointer -Wall -fPIC -c
`echo ./generic/nsfStubLib.c` -o nsfStubLib.o
rm -f libnsfstub2.0b3.a
ar cr libnsfstub2.0b3.a nsfStubLib.o
ranlib libnsfstub2.0b3.a
TclStackFree: incorrect freePtr (0x7fffc7179500 != 0xedabd0). Call out
of sequence?
/bin/bash: line 3: 19664 Aborted (core dumped)
TCL_LIBRARY=`echo /root/tcl-source/library`
LD_LIBRARY_PATH=".:/usr/local/lib:"
PATH=".:/usr/local/lib:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games"
TCLLIBPATH=". . " /usr/local/bin/tclsh8.6
./library/xotcl/library/lib/makeDoc.xotcl ./library/xotcl/doc $docs
make: *** [library/xotcl/doc/langRef-xotcl.html] Error 134


Thanks

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Fri, 21 May 2004 21:12:24 +0200

On Wednesday 19 May 2004 19:30, Neil Madden wrote:
> I was kind of expecting the last to say "Foo in Base", as the method
> call of "foo" was dispatched from the Base class level. This is an
> interesting problem, as I can see reasons why you might want to do the
> current behaviour. However, I'm worried about some of the implications
> of implementation details and name clashes. Suppose I implement some
> class Base, which as part of it's implementation has a (private) method
> DoStuff.

 XOTcl has no private methods, every method is public.
 the evaluation context does not change the semantics of
 an invocation.

 OO breaks sometimes locality, and refining existing classes
 is not the best concept for components.

 without thinking long, i can offer two approaches.
 1) The first one is rather for fun, it changes the class
     of the object on the fly:

    Object instproc local args {
      set oldclass [my info class]
      my class [uplevel self class]
      set r [eval my $args]
      my class $oldclass
      return r
   }
   ...
   Base instproc bar {} {
     my local foo
   }
 
 since it might have some unwanted effects,
 when the "local" called method (here "foo")
 calls other methods, which should be dispatched
 based on the true objects class. The help in
 mixins is also rather limited.

 2) following your prefix approach:

   Object instproc own {} {
       namespace tail [uplevel self class]
   }
   Object instproc private {method name arguments body} {
      set prefix [namespace tail [self]]
      [self] $method $prefix-$name $arguments $body
   }

  one can define now:

   Class Base
   Base private instproc foo {} {
        puts "Foo in Base"
   }
   ....
 
 and call this via:

   Base instproc bar {} { my [my own]-foo }

 to avoid stuttering while reading, one can define a global funciton

   proc own {} { namespace tail [self class] }
   Base instproc bar {} { my [own]-foo }

 in genereal, instead of [own], [self class] could be used, but currently,
 the leading colons are not allowed in xotcl. i guess, we can change this.

-gustaf neumann

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

From: Mykhaylo Sorochan <msorc_at_bigmir.net>
Date: Mon, 20 Jul 2009 13:57:23 +0300

Stefan,

I was interested in case a). I was a little wrong with the syntax and was not
able to build the statement right.

Thanks.

> # ad a)
> #
> Class create C -slots {
> Attribute create a1 -proc assign args {
> puts "[self]->[self proc] called"
> next
> } -proc get args {
> puts "[self]->[self proc] called"
> next
> }
> }
>
> C create c
> c a1 1
> c a1
>

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Sun, 02 Oct 2005 21:52:03 +0200

Dear XOTcl community,

XOTcl 1.3.8 is available. It is essentially a bug-fix release for 1.3.7,
containing the bugs detected by Koen, Zoran and Ben fixed.
The windows binary will follow tomorrow.

best regards
-gustaf neumann