Xotcl September 2004

xotcl@alice.wu.ac.at

9 participants
15 discussions

Re: [Xotcl] experience installing xotcl on MacOsX ?
by Catherine Letondal 29 Sep '04

29 Sep '04

Gustaf Neumann wrote: > On Friday 17 September 2004 19:19, Catherine Letondal wrote: >> Dear members of xotcl the list, >> >> Has someone any experience in installing XOtcl on MacOsX ? >> I have found a "Portfile" but I don't know what to do with it? > > Catherine, > > isn't the Mac OS X Tcl/Tk Aqua 8.4.7 Release something for > you to use, it contains XOTcl binaries..... > > http://groups.google.at/groups?q=xotcl&hl=de&lr=&ie=UTF > -8&scoring=d&selm=pgpmoose.200408041618.26617%40despot.non.net&rnum=8 Thanks for the advice! I have indeed installed the TclTkAquaBI and tried but it'svery complicated. I don't know whether you can help ? 1) I need to build my own wish with shared objects (libtcl.dylib etc...) which are not provided in TclTkAquaBI distribution - even using it together with the native Tcl.framework you don't have the *.h files etc...). So I decided to use the Fink tcl/tk distribution which works fine. 2) Using the TclTkAquaBI (the one which includes xotcl-1.2) is also not easy when you want to link an xotcl shared object (called /Library/Tcl/xotcl1.2/libxotcl1.2.dylib) First, because you need xotcl.h, so you have to download separately the sources that have been used for building the shared library (sources are kindly distributed from http://tcltkaqua.sourceforge.net/8.4.7.html). Even using libxotcl.dylib file distributed in TclAquaBI not not make sense for a simple reason: if I need another package (such as BLT), which is not distributed in TclAquaBI, I will also have to compile it myself, which is very difficult when it is not configured for this purpose (blt is also distributed in Fink). 3) So, sy conclusion was to compile Xotcl myself, which I did, I think, successfully. configure; ./configure --with-tcl=/sw/lib --with-tclinclude=/sw/include --with-tk=/sw/lib --with-tkinclude=/sw/include I just got errors when building xowish: gcc -pipe -rdynamic -o xowish tkAppInit.o \ xotcl.o xotclError.o xotclMetaData.o xotclObjectData.o xotclProfile.o xotclTrace.o xotclUtil.o xotclShadow.o xotclCompile.o aolstub.o xotclStubInit.o \ -O3 -Wall -Wconversion -Wno-implicit-int -fno-common -L/sw/lib -ltcl8.4 \ gcc: unrecognized option `-rdynamic' ld: Undefined symbols: _Tk_Init _Tk_MainEx _Tk_SafeInit Apparently also: ==> -ltk8.4 is missing ? But xotclsh was successfully built. 4) then, I built a very simple tkAppinit.c: #include "tk.h" #include <xotcl.h> int main(argc, argv) int argc; /* Number of command-line arguments. */ char **argv; /* Values of command-line arguments. */ { Tk_Main(argc, argv, Tcl_AppInit); return 0; /* Needed only to prevent compiler warning. */ } int Tcl_AppInit(interp) Tcl_Interp *interp; /* Interpreter for application. */ { if (Tcl_Init(interp) == TCL_ERROR) { return TCL_ERROR; } if (Tk_Init(interp) == TCL_ERROR) { return TCL_ERROR; } Tcl_StaticPackage(interp, "Tk", Tk_Init, Tk_SafeInit); if (Xotcl_Init(interp) == TCL_ERROR) { return TCL_ERROR; } Tcl_Import(interp, Tcl_GetGlobalNamespace(interp), "xotcl::*", 1); if (Tcl_PkgRequire(interp, "XOTcl", XOTCLVERSION, 1) == NULL) { return TCL_ERROR; } return TCL_OK; } I got an executable (miniwish) built with the following compile/link commands (with some warnings): gcc -fno-common -DXOTCLVERSION=\"1.3.1\" -c -I/sw/include -I/sw/include -I/usr/include/X11 -I/sw/include tkAppInit.c gcc -bind_at_load -o minibiokwish tkAppInit.o -L/sw/lib -ltk8.4 -L/sw/lib -ltcl8.4 -L/usr/X11R6/lib -lX11 -lXmu -L/sw/lib/xotcl1.3.1 -lxotcl1.3.1 -lm ld: warning multiple definitions of symbol _tclPlatStubsPtr /sw/lib/libtcl8.4.dylib(tclStubLib.o) definition of _tclPlatStubsPtr /sw/lib/libtk8.4.dylib(tclStubLib.o) definition of _tclPlatStubsPtr ld: warning multiple definitions of symbol _tclIntStubsPtr /sw/lib/libtcl8.4.dylib(tclStubLib.o) definition of _tclIntStubsPtr /sw/lib/libtk8.4.dylib(tclStubLib.o) definition of _tclIntStubsPtr ld: warning multiple definitions of symbol _Tcl_InitStubs /sw/lib/libtcl8.4.dylib(tclStubLib.o) definition of _Tcl_InitStubs /sw/lib/libtk8.4.dylib(tclStubLib.o) definition of _Tcl_InitStubs ld: warning multiple definitions of symbol _tclIntPlatStubsPtr /sw/lib/libtcl8.4.dylib(tclStubLib.o) definition of _tclIntPlatStubsPtr /sw/lib/libtk8.4.dylib(tclStubLib.o) definition of _tclIntPlatStubsPtr ld: warning multiple definitions of symbol _tclStubsPtr /sw/lib/libtcl8.4.dylib(tclStubLib.o) definition of _tclStubsPtr /sw/lib/libtk8.4.dylib(tclStubLib.o) definition of _tclStubsPtr /sw/lib/xotcl1.3.1/libxotcl1.3.1.dylib(tclStubLib.o) definition of _tclPlatStubsPtr /sw/lib/xotcl1.3.1/libxotcl1.3.1.dylib(tclStubLib.o) definition of _tclIntStubsPtr /sw/lib/xotcl1.3.1/libxotcl1.3.1.dylib(tclStubLib.o) definition of _tclStubsPtr /sw/lib/xotcl1.3.1/libxotcl1.3.1.dylib(tclStubLib.o) definition of _tclIntPlatStubsPtr /sw/lib/xotcl1.3.1/libxotcl1.3.1.dylib(tclStubLib.o) definition of _Tcl_InitStubs But this executable does not work correctly: ./minibiokwish dyld: ./minibiokwish can't open library: libxotcl1.3.1.dylib (No such file or directory, errno = 2) Trace/BPT trap (executed from an X11 environment - not Aqua - of course). -- Catherine Letondal -- Pasteur Institute Computing Center

2 2

Segmentation fault
by Kristoffer Lawson 24 Sep '04

24 Sep '04

I'm getting a segmentation fault in relation to XOTcl. I believe the situation that causes it is as follows: * I have an object C which has a child M. * M has a fileevent callback. * On receiving complete message, M calls a method in C. * If that is an empty message, C destroys itself and closes the socket in the destructor (M is still in fileevent callback). After that I get a segmentation fault. But.. this only happens if I have my debug outputs turned on! They are just normal Tcl [puts] stuff, wrapped around in other things. The thing is I am unable to recreate this with a trivial piece of code so I'm finding it very difficult to pinpoint the exact cause (even, indeed if it is XOTcl at fault or if I have found a Tcl bug). Sorry for the very vague report. I wish I could be more specific. If it's any help, at one point, instead of a segmentation fault, I got: alloc: invalid block: 0x81264a0: b0 8 ef Aborted My guess, something is being freed before it should. Let me know if there's anything more I can do to help find this problem. / http://www.fishpool.com/~setok/

1 3

[Fwd: XOTcl and debian testing..]
by Uwe Zdun 23 Sep '04

23 Sep '04

Hi Ron, I forward you email to our mailing list: Teemu Hukkanen <mailto:tjhukkan@iki.fi> has provided the debian package of XOTcl, but I don't know what the status of this package is. maybe someone else on the list knows? Uwe -------- Original Message -------- Subject: XOTcl and debian testing.. Date: Thu, 23 Sep 2004 07:19:12 -0400 From: Ron Fox <fox(a)nscl.msu.edu> To: uwe.zdun(a)uni-essen.de Contrary to the XOTcl web page, it appears that XOTcl has fallen off the debian testing distribution (sarge) did you mean debian unstable? Thanks, Ron Fox NSCL Michigan State University East Lansing, MI 48824-1321 "The knack of flying is learning how to throw yourself at the ground and miss." -- Uwe Zdun Department of Information Systems, Vienna University of Economics Phone: +43 1 313 36 4796, Fax: +43 1 313 36 746 zdun(a)acm.org, uwe.zdun(a)wu-wien.ac.at

3 2

experience installing xotcl on MacOsX ?
by Catherine Letondal 21 Sep '04

21 Sep '04

Dear members of xotcl the list, Has someone any experience in installing XOtcl on MacOsX ? I have found a "Portfile" but I don't know what to do with it? Thanks in advance ! -- Catherine Letondal -- Pasteur Institute Computing Center

2 1

Problem With Forwarding Defaults
by MichaelL＠frogware.com 20 Sep '04

20 Sep '04

I have a class I use to manage collections of aggregated objects. I'm trying to use it with the -Class parameter option and instforwarding so that I can do things like this: Test x x apples add Z x apples items *That* part I can get to work as expected. But I can't get the default option of instforwarding to work for this case: x apples Some (simplified) sample code follows. ================================ package require XOTcl 1.3 namespace import ::xotcl::* # Collection Class Collection Collection instproc new {className args} { eval $className [self]::[[self] autoname -instance $className] $args } Collection instproc add {args} { foreach objName $args { $objName move [self]::[[self] autoname -instance [namespace tail [$objName info class]]] } } Collection instproc items {} { return [[self] info children] } Collection instproc remove {objName} { [self]::$objName destroy } # CollectionParameter ::xotcl::Class::Parameter CollectionParameter -superclass Collection # Test Class Test -parameter { {_apples_ -Class CollectionParameter -default 1} {_oranges_ -Class CollectionParameter -default 1} } # TestItem Class TestItem # Examples Test instforward apples {%my _apples_} Test instforward oranges {%my _oranges_} Test x x apples new TestItem x apples new TestItem # this works puts [x apples items] Test instforward apples -default {items add} {%my _apples_} Test instforward oranges -default {items add} {%my _oranges_} Test z z apples new TestItem z apples new TestItem # this works puts [z apples items] # this doesn't puts [z apples]

2 1

Missing Linux Binaries
by MichaelL＠frogware.com 20 Sep '04

20 Sep '04

The XOTcl 1.3.1 Linux binary distribution file (xotcl-1.3.1-bin-linux-i686-glibc.tar.gz) is missing libxotclexpat1.3.so libxotclgdbm1.3.so libxotclsdbm1.3.so all of which were present in (at least) the 1.2 and 1.1.1 files (in the appropriate version, of course).

2 1

Bug! 1.3.1 Nonpositional args and default arguments values
by Schofield, Bryan (GE Transportation) 15 Sep '04

15 Sep '04

Hullo - I found a little bug with non-positional arguments & regular default arguments in version 1.3.1. Consider the following example: Object o o proc foo {{-a apple}} {{b banana}} { puts "FOO: [info locals]" puts "a: $a b: $b" } We have a method "foo" that has one optional argument, "b", and one option non-positional argument, "a". Now consider the possible ways to call this method: o foo o foo -a ack o foo bar o foo -a ack bar In the cases where we let "b" use it's default value of "banana", we will get the error: wrong # args: should be {{b banana}} In the cases where we specify "b", we will find that "b" is not valid variable in method scope. In fact, what is happening is that the variable "{b banana}" is being set. Should we try to use "$b", we will get the error: can't read "b": no such variable It would seem that ::xotcl::interpretNonPositionalArgs does not take in to account for default values on regular type arguments. Regards. -- bryan

2 1

namespace incompatibility by XOTcl 1.3.1 (XOTclIDE)
by Artur Trzewik 14 Sep '04

14 Sep '04

Hi! XOTclIDE does not run with XOTclI 1.3.1 because of uncompatibility of the namespace handling. Thank to Michael Heca for noting it. I have played a little with xotcl and discovered following behavior incompatibility that make problems by XOTclIDE. Examples: package require XOTcl namespace import xotcl::* Object O Class O::B O::B instproc test {} { Class A } O::B create o o test # XOTcl 1.2 returns ::A # XOTcl 1.3 returns ::O::A using Class ::A solves the problem Another one should not occours by any XOTcl programm but by XOTclIDE this happened Object O Class O::A O::A proc test {} { A self } O::A create A O::A test # XOTcl 1.2 returns ::A # XOTcl 1.3 returns ::O::A # using ::A solves the problem So probably even with XOTcl 1.3.2 XOTclIDE will not work out of the box and need some changes. So all XOTclIDE user be patience and wait for new version of XOTclIDE that supports XOTcl 1.3. I will need also some time to support new XOTcl functionality. Artur Trzewik

3 2

Even more [eval] woes
by Kristoffer Lawson 14 Sep '04

14 Sep '04

[self proc] inside a method that has been called inside an [ob eval] block gives the result "eval" inside of the method we're in. In practise this is now causing so many headaches I think I'm going to give up on doing this package using XOTcl that way. There appears to be no (working?) way to run a script within the 'context' of an object, in order to easily parse data which is formed in the style of a Tcl script. This is unfortunate as it would likely have offered clear performance benefits. I may still try to do it directly with normal namespaces instead of XOTcl. / http://www.fishpool.com/~setok/

2 2

info not working?
by Kristoffer Lawson 14 Sep '04

14 Sep '04

% package require XOTcl 1.3 % xotcl::Class Foo ::Foo % Foo instproc bar {a} {puts $a} % Foo ob ::ob % ob info args bar % ob info body bar Or have I misunderstood something about what should be going on? I would assume args to return 'a' and body to return 'puts $a'? Do they only work on procs? Does that not slightly go against the 'slot' idea? / http://www.fishpool.com/~setok/

3 3

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

Xotcl September 2004