Weblog Page

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Sun, 19 Nov 2006 22:02:40 +0100

Ramam,

you should change "upvar" to "my upvar" as in the following method

X instproc bar {ar args} {
  puts "bar"
  my upvar $ar arr
  puts "upvard"
  barray arr
}

otherwise you will upvar to the filter. The plain tcl upvar is not
very useful, when interceptors are added/removed dynamically.

Therefore, xotcl provides the methods "upvar" and "uplevel"
to achieve interceptor transparency. This means that an upvar/uplevel
refers always to the last non-interceptor method (skipping
filters and mixins).

best regards
-gustaf neumann



Shishir Ramam schrieb:
>
> I am passing an array name by reference across an instproc.
>
> The vanilla version works just fine (see creation of x1 midway through
> the code segment).
>
> To add some debugging in, I essentially used the trace example from
> the tutorial, and funnily,
> the upvar stopped doing it's job (see error on creating x2 towards the
> end of the code segment).
>
> To get rudimentary debug control of the parray proc, I copied it into
> a proc called barray. None of the logic is changed -
> just my crude attempt at adding breadcrumbs.
>
> I have included the output at the end of the code segment.
>
> Running Windows XP Pro + Active Tcl 8.4.13 + XoTcl 1.4.0.
>
> thanks for all help.
> -shishir
>
> <CODE SEGMENT>
> package require XOTcl
> namespace import ::xotcl::*
>
>
> proc barray {a {pattern "*"}} {
> puts "barray"
> upvar 1 $a arr
> if {![array exists arr]} {
> error "\"$a\" isn't an array"
> }
> set maxl 0
> foreach name [lsort [array names arr $pattern]] {
> if {[string length $name] > $maxl} {
> set maxl [string length $name]
> }
> }
> set maxl [expr {$maxl + [string length $a] + 2}]
> foreach name [lsort [array names arr $pattern]] {
> set nameString [format %s(%s) $a $name]
> puts stdout [format "%-*s = %s" $maxl $nameString $arr($name)]
> }
> }
>
> Class X
>
> X instproc bar {ar args} {
> puts "bar"
> upvar $ar arr
> puts "upvard"
> barray arr
> }
>
>
>
> X instproc init {args} {
> array set arr {a 1 b 2}
> parray arr
> my bar arr
> }
>
> X x1
>
>
> Object Trace
> Trace set traceStream stdout
> Trace proc openTraceFile name {
> my set traceStream [open $name w]
> }
> Trace proc closeTraceFile {} {
> close $Trace::traceStream
> my set traceStream stdout
> }
> Trace proc puts line {
> puts $Trace::traceStream $line
> }
> Trace proc add className {
> $className instfilter [concat [$className info filter] traceFilter]
> }
>
> Object instproc traceFilter args {
> # don't trace the Trace object
> if {[string equal [self] ::Trace]} {return [next]}
> set context "[self class]->[self callingproc]"
> set method [self calledproc]
> switch -- $method {
> proc -
> instproc {::set dargs [list [lindex $args 0] [lindex $args 1] ...] }
> default {::set dargs $args }
> }
> Trace::puts "CALL $context> [self]->$method $dargs"
> set result [next]
> Trace::puts "EXIT $context> [self]->$method ($result)"
> return $result
> }
>
> Trace add X
>
> X x2
>
> </CODE SEGMENT>
>
> ------------
>
> <OUTPUT>
> arr(a) = 1
> arr(b) = 2
> bar
> upvard
> barray
> arr(a) = 1
> arr(b) = 2
> CALL ::xotcl::Object->> ::x2->cleanup
> EXIT ::xotcl::Object->> ::x2->cleanup ()
> CALL ::xotcl::Object->> ::x2->configure
> EXIT ::xotcl::Object->> ::x2->configure (0)
> CALL ::xotcl::Object->> ::x2->init
> arr(a) = 1
> arr(b) = 2
> CALL ::xotcl::Object->init> ::x2->bar arr
> bar
> upvard
> barray
> "arr" isn't an array
> </OUTPUT>
>
> ----
>
> <ERRORINFO>
> % set errorInfo
> "arr" isn't an array
> while executing
> "error "\"$a\" isn't an array""
> (procedure "barray" line 5)
> invoked from within
> "barray arr"
> (procedure "bar" line 6)
> invoked from within
> "next"
> (procedure "bar" line 13)
> ::x2 ::xotcl::Object->traceFilter
> invoked from within
> "my bar arr"
> (procedure "init" line 5)
> invoked from within
> "next"
> (procedure "init" line 13)
> ::x2 ::xotcl::Object->traceFilter
> ::X ::xotcl::Class->recreate
> ::X ::xotcl::Class->create
> ::X ::xotcl::Class->unknown
> invoked from within
> "X x2"
> (file "c:/temp/trace_trouble.tcl" line 81)
> invoked from within
> "source c:/temp/trace_trouble.tcl"
> </ERRORINFO>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Xotcl mailing list
> Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
>

From: Neil Madden <nem_at_cs.nott.ac.uk>
Date: Thu, 26 Aug 2004 19:43:48 +0100

Hi all,

I've just been compiling XOTcl 1.3.0 on Mac OS X against the latest (as
of about an hour ago) CVS HEAD versions of Tcl and Tk. It initially
failed on the final linking stages, missing the TclGetInterpProc
function. This function has been taken out of Tcl in CVS. Commenting
out the 1 reference to this function in the XOTcl sources
(generic/xotcl.c line 10461) allows the compile to finish, all the
tests pass and the resulting library seems fine. Talking to Donald
Porter on the Tcl'ers Chat indicates that use of this function should
no longer be necessary as Tcl doesn't create any procs using the old
string-based interfaces anymore.

Just thought I'd send out a heads-up, as you probably want to fix/alter
the XOTcl code to deal with this.

Cheers,

Neil.

From: Jim Lynch <jim_at_jam.sessionsnet.org>
Date: Tue, 6 Apr 2004 07:00:06 -0700

The following patch should solve the problem.

One way of applying it:

 - save it to a file, say "xotch-1.2.0/choose-right-tclsh.diff"
 - cd xotcl-1.2.0
 - cat choose-right-tclsh.diff | patch -p1

Once you have done this, you must run autoconf to regenerate
the script "configure". Following this, the configure script
will always choose the tclsh specified by the supplied tclConfig.sh.

---- cut here ----
diff -Naur xotcl-1.2.0-orig/unix/configure.in xotcl-1.2.0/unix/configure.in
--- xotcl-1.2.0/unix/configure.in 2004-01-28 00:20:39.000000000 -0800
+++ xotcl-1.2.0-work/unix/configure.in 2004-04-05 06:49:39.000000000 -0700
_at_@ -471,7 +471,26 @@
 # versions have bugs in the pkg_mkIndex routine.
 #--------------------------------------------------------------------
  
-SC_PROG_TCLSH
+#--------------------------------------------------------------------
+# tclsh should be at $TCL_PREFIX/bin/tclsh$TCL_VERSION after
+# loading tclConfig.sh, so: test for this file; do equiv of
+# SC_PROG_TCLSH if found, otherwise complain about error.
+# Require (instead) that we use the tclsh -specified- by
+# tclConfig.sh since others won't be able to do things like
+# find the right module/lib files, etc.
+# -Jim Lynch
+#--------------------------------------------------------------------
+
+
+if test -x "$TCL_PREFIX/bin/tclsh$TCL_VERSION"
+then
+ TCLSH_PROG="$TCL_PREFIX/bin/tclsh$TCL_VERSION"
+ AC_MSG_CHECKING([for tclsh])
+ AC_MSG_RESULT(found at $TCLSH_PROG)
+ AC_SUBST(TCLSH_PROG)
+else
+ AC_MSG_ERROR(the appropriate tclsh was not found)
+fi
  
 #
 # XOTcl specific configs
---- cut here ----

-Jim

--
Jam sessions community web site: http://jam.sessionsnet.org

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Wed, 18 May 2011 10:55:37 +0200

On 21.01.11 00:17, Victor Mayevski wrote:
> Although it might be something obvious but I cannot think of it at the
> moment. How do I delete attributes created with the "attribute"
> method?
NX provides now an explicit "delete" ensemble, containing
"delete method" and "delete attribute",
therefore it does not require the classic Tcl metaphor "proc
foo {} {}" for deleting a function foo.
Furthermore, "delete attribute" removes the slot objects as
well.

So, one can use now

/obj/ delete attribute/name/

-gustaf neumann

From: Artur Trzewik <mail_at_xdobry.de>
Date: Mon, 13 Aug 2001 20:39:04 +0200

> sure. the point is, that we need both: an explicit interface for getting
> the details right and for distinguising as far as neccessary, and
> a high level interface, that hides part of this details for a user who
> does not care about these. for the latter case, an "info procs" or
> "info instprocs" is not the right way, since the names are not necessarily
> disjunct. a new thing called "info methods" that returns a list of
> method-objects (see last mail) could help here returning all the callable
> methods (which are procs, instprocs, mixins, filters).
>
> what is it, that would fit your needs best? what are you doing exactly?
>

Yes. I thing such new interface is needed

$object info methods

Is one to get all methods that object can understand.

Another one is to get additional meta information
I use this method to get all instprocs and the place, where they are defined
for my purposes.

Class instproc getAllFullInstMethods {} {
    set fmethods {}
    foreach m [[self] info instprocs] {
        lappend fmethods [list $m [self]]
        set marr($m) 1
    }
    foreach class [[self] info heritage] {
        foreach m [$class info instprocs] {
            if {![::info exist marr($m)]} {
                lappend fmethods [list $m $class]
                set marr($m) 1
            }
        }
    }
    return $fmethods
}

Such think sould be implemented internally (and not so unclean) and can be
used also for procs and mixins (instance or class).

$object info fullMethods myMethod
sould return list
{methodName methodType definitionPlace}

for example

Class A
A instproc foo1
A instproc foo2
Class B
B instproc foo1

B b
b proc foo3

b info fullMethods
>{foo3 proc b} {foo1 instproc B} {foo2 instproc A}
b info methods
>{foo1 foo2 foo3}

I think the method type can be rather not needed if man use
[Object isclass A]

Very similar interface is known by Smalltalk
Object>>responseTo: method
(return true or false if object understand message)

Behavior>>allSelectors
(get all methods)

Behavior>>findSelector: method
(get the definition class of method)

Artur Trzewik

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Mon, 23 Jul 2007 20:09:59 +0200

Stefan and all,

Many thanks for the test cases. Below is the bug-fix for the
empty argument.
Concerning bug#2: i think you sent me the same bug (with a different
testfile) on march 15, i have sent you a fix back on march 16.

i will put togehter today a bugfix version containing the fixes
developed over the last months for testing for Ben to
see, if this helps already for his crashes. Maybe the fix for bug2
helps already.

-gustaf


% diff -u generic/xotcl.c-old generic/xotcl.c
--- generic/xotcl.c-old 2007-07-23 19:47:21.000000000 +0200
+++ generic/xotcl.c 2007-07-23 19:45:30.000000000 +0200
_at_@ -5049,7 +5049,7 @@
       /* arg = ObjStr(argsv[i]);
          fprintf(stderr, "*** argparse0 arg='%s'\n",arg);*/
       rc = Tcl_ListObjGetElements(in, argsv[i], &npac, &npav);
- if (rc == TCL_OK) {
+ if (rc == TCL_OK && npac > 0) {
         arg = ObjStr(npav[0]);
         /*fprintf(stderr, "*** argparse1 arg='%s' rc=%d\n",arg,rc);*/
         if (*arg == '-') {


Stefan Sobernig schrieb:
> I attached two scripts, each reproducing bugs
> I found with most recent versions of XOTcl
> (1.5.2/1.5.3).
>
> Bug -1-: Argument declarations to proc/instproc
> containing a single empty tcl string yield a segfault/bus error.
>
> Bug -2-: Nesting objects through per-object evals (evals
> in the object scope) yields segfaults/bus errors under
> certain conditions.
>
> all the best,
>
> //stefan
>

From: Uwe Zdun <uwe.zdun_at_wu-wien.ac.at>
Date: Fri, 21 Nov 2003 11:55:38 +0100

Hi all,

I'm currently updating the XOTcl documentation for the next release, 1.1,
and due to this discussion I've added a section "Integrating XOTcl Programs
with C Extensions (such as TK)" to the tutorial ... perhaps the contributors
to this discussion might want to review this doc. Perhaps you use some
practices I've forgotten?

(It's the last section in the attached file)

Uwe

From: jim <jamesmc_at_localnet.com>
Date: Tue, 9 Dec 2003 01:19:34 -0500

>hi-
>i did a zip binary distribution for windows
>xotcl-1.1.0-win32-tcl8.4.5.zip

>my tcl directory was in c:\tcl . when the install took place it tried
to put xotcl in c:\program files\tcl directory.
>since that is not where i originally installed tcl i copied the files
with the file manager back over to c:\tcl and its >subdirectories.
>i have an environment variable named tcllibpath that points to
c:\tcl\lib\xotcl. i moved the 4 include files over to c:>\tcl\include .
>the libxotcl1.1.dll resides now in my c:\tcl\lib directory.

>when i run this code in ASED it prints out "failure" as it is not
loaded properly. I am using version 8.4.

>set fail [catch [load libxotcl.dll]]
>if {$fail} {
>puts "failure"

>}

>i wanted to expirement with xotcl. i have swig working and know a
little c++ but i thought i'd try out this new way of >>doing things.

>>please let me know if you can think of any tricks i am not thinking of
to get this to load properly.
>>i could reinstall TCL to c:\program files\tcl and then reinstall xotcl
from the beginning zip file. Is that necessary?

>>thanks
>>Marvin

Hi again-

I fired this code up and it seems to work :-) problem solved!!

   package require XOTcl;
        namespace import -force xotcl::*
   

Object kitchen
# Peter enters the kitchen to cook
kitchen set persons(cook) Peter
# Marion enters the kitchen to take one of the seats
kitchen set persons(seat1) Marion
kitchen array names persons
kitchen array get persons

...cant seem to get ASED output to copy. There probably is a way.

Here is the output of the last command anyways.
cook Peter seat1 Marion

From: Shishir Ramam <sramam_at_gmail.com>
Date: Sat, 26 May 2007 09:47:26 -0700

I'm using ActiveState's 8.4 distribution on Windows XP, and am unable to
explain the behaviour in the example below.

Shouldn't '-exact' be allowed as the default initializer for match? It seems
to have something to do with the
leading '-' since removing it seems to create the class Foo without issue.

Any help much appreciated.

thanks,
-shishir

C:\Tools\Tcl\lib\xotcl1.5.3>tclsh
% package require XOTcl
1.5.3
% namespace import xotcl::*
% Class Foo -parameter {{match -exact}}
 during '::Foo parameter'
% set errorInfo
 during '::Foo parameter'
    ::Foo ::xotcl::Object->configure
    ::xotcl::Class ::xotcl::Class->create
    ::xotcl::Class ::xotcl::Class->unknown
    invoked from within
"Class Foo -parameter {{match -exact}}"

Changing -exact to exact, the error is resolved.
% Class Foo -parameter {{match exact}}
::Foo

From: Gustaf Neumann <neumann_at_wu.ac.at>
Date: Mon, 10 Jan 2011 22:54:24 +0100

Am 10.01.11 22:26, schrieb Artur Trzewik:
> I suppose effect by redefining class
Artur, i had the same guess, since all
the files load fine as they are. Something
is missing in the picture.

But most probably, the problem is the redefinition
problem, where the standard redefining semantics
are a destroy followed by a create. When a class
is destroyed, the references to the class are deleted,
so a superclass relation (or similar) will get lost.

In this case, xotcl::configure softrecreate will help:

=========================================
namespace import xotcl::*
::xotcl::configure softrecreate true

Class F1
Class F2 -superclass F1
#
# Before 2nd create of F1
#
puts "F2 superclass [F2 info heritage]"
Class F1
#
# After 2nd create of F1
#
puts "F2 superclass [F2 info heritage]"
=========================================

Krzysztof, soucing your file extendedContainer.xotcl and
creating an instance of ExtendedContainer works fine:

=========================================
~/scripts/krz% xotclsh
% source extendedContainer.xotcl
% ExtendedContainer x
Calling testB on class B object...
testB was called
...proc called successfully
Calling testA on class B object...
testA was called
...proc called successfully
::x
=========================================

btw, not sure that you are aware that you are creating
in several of your source files classes twice. E.g.
in extendedContainer.xotcl, you create the class
ExtendedContainer in line (2) and once again in
line (8).

-gustaf neumann

=======================================
1 package require XOTcl
2 xotcl::Class ExtendedContainer
3
4 namespace import xotcl::*
5 source b.xotcl
6
7
8 Class create ExtendedContainer
9
10 ExtendedContainer instproc init {} {
...
=======================================

-- 
Univ.Prof. Dr. Gustaf Neumann
Institute of Information Systems and New Media
WU Vienna
Augasse 2-6, A-1090 Vienna, AUSTRIA