Weblog Page

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

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Thu, 8 Nov 2001 22:09:17 +0100

 
 Dear XOTcl-community
 
 Konrad Wagner <konrad.wagner_at_wu-wien.ac.at>, one of our studends,
 finished a project with XOTcl on the ipaq

    http://www.compaq.com/products/handhelds/pocketpc/

 and contributed the binaries. No xotcl source modifications
 were necessary. The binaries are now on the download page of www.xotcl.org.

 Maybe, somebody finds it useful
 best regards

-gustaf neumann