Xotcl October 2006

xotcl@alice.wu.ac.at

10 participants
10 discussions

Namespaces and Xotcl
by Shishir Ramam 29 Oct '06

29 Oct '06

Hi, Was wondering why it's not possible to import namespaces when XOTcl objects are involved. The shortest example that I could rustle up is included below. Help in understanding what prevents this from working is much appreciated. -shishir % package require XOTcl 1.4.0 % namespace eval ::my::test { namespace import ::xotcl::* Class Foo Foo instproc bar {} { puts " foo bar is a very tasty!" } } % ::my::test::Foo foo ::foo % foo bar foo bar is a very tasty! % ::my::test::Foo info instances ::foo % # Why doesn't the following work? % namespace import ::my::test::* % Foo foo2 invalid command name "Foo" % ::my::test::Foo info instances ::foo % Foo info instances invalid command name "Foo"

2 2

Creating objects from C
by Scott Gargash 28 Oct '06

28 Oct '06

When creating XOTcl objects from C, it would be nice to be able to initialize the new object's clientData prior to any methods being invoked on the object. Right now, the only way I can think of to do this is to 1. create the object (which invokes "init", which can't rely on the ClientData) 2. XOTclSetObjectClientData( XOTclGetObject(), data); // Or the Class equivalent 3. Invoke some secondary, private "init"-like method that does true initialization It would be nice to have two new exported functions: int XOTclCreateObjectCl (Tcl_Interp* in, Tcl_Obj* name, ClientData data, struct XOTcl_Class* cl); int XOTclCreateClassCl (Tcl_Interp* in, Tcl_Obj* name, ClientData data, struct XOTcl_Class* cl); That initialize the XOTcl ClientData field prior to invoking "init" so that "init" could rely on the XOTcl ClientData being valid. This would make it much easier to construct XOTcl wrappers around C/C++ objects. Is this reasonable? Is there a better way to accomplish this? Scott Notice The information in this message is confidential and may be legally privileged. It is intended solely for the addressee. Access to this message by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying or distribution of the message, or any action taken by you in reliance on it, is prohibited and may be unlawful. If you have received this message in error, please delete it and contact the sender immediately. Thank you.

2 1

Building debug version on Windows
by Jamie Rasmussen 25 Oct '06

25 Oct '06

Hello, I have a binary installer of AOLserver 4.5 for Win32, and I'd like to add XOTcl 1.5.2 to it, since I know OpenACS 5.3 will require it. While running some load tests on the binaries I built I saw a crash in XOTclAddIMethod. I'm not worried about that crash yet, since I think it might have been caused by a bad interaction with the nstclprof module. But to investigate further, I tried to compile a debug version of XOTcl, and I've run into some problems. The compiler is Visual Studio 6, and the command line I was using is: nmake /f Makefile.vc DEBUG=1 * I am trying to compile against TCL 8.4.14, which was compiled with the threads and thrdalloc options. The first problem I had was with the values of TCLIMPLIB and TCLSH in Makefile.vc, which didn't reflect that the threaded build includes a 't' in the filename before $(DBGX) for the .lib and tclsh. This applies to \library\store\XOTclSdbm\Makefile.vc too. * The -WX compiler option (error instead of warning) is specified for DEBUG=1, so compilation aborts because of this warning: ..\generic\xotcl.c(5271) : warning C4018: '==' : signed/unsigned mismatch. * I also noticed XOTCL_RELEASE_LEVEL=.0 and not .2 - is that intentional? Any suggestions? I'm new to XOTcl, but I already like it - thanks. Jamie

1 0

Initialisation arguments
by Kristoffer Lawson 24 Oct '06

24 Oct '06

Are these stored anywhere within XOTcl? If not, I presume that information is not currently available to the script end? I'm just wondering as I think I could make good use of that with object recreation based on its serialised form. / http://www.fishpool.com/~setok/

2 7

Re: [Xotcl] xotcl-1.5.2-win32-tcl8.4.13.zip
by Gustaf Neumann 13 Oct '06

13 Oct '06

Should be fixed now. please refetch. -gustaf neumann Murr, Florian schrieb: > Dear XOTcl developers, I can't find > installWin.tcl > or > libxotcl1.5.dll > in this distribution anymore. > > Am I looking in the right place? > > regards, > - Florian > > _______________________________________________ > Xotcl mailing list > Xotcl(a)alice.wu-wien.ac.at > http://alice.wu-wien.ac.at/mailman/listinfo/xotcl >

1 0

xotcl-1.5.2-win32-tcl8.4.13.zip
by Murr, Florian 13 Oct '06

13 Oct '06

Dear XOTcl developers, I can't find installWin.tcl or libxotcl1.5.dll in this distribution anymore. Am I looking in the right place? regards, - Florian

1 0

How to build XOTcl as universal binary
by Scott Gargash 12 Oct '06

12 Oct '06

Is it possible to build XOTcl as universal/fat binary for OS X? What is the command line for the configure tool ? Thanks. Scott

2 1

XOTcl method call precedence order
by Neil Madden 06 Oct '06

06 Oct '06

Hi Gustaf et al., I have a quick query regarding the precise method call order used in XOTcl. The basic concepts involved seem to be filters, mixins, object methods and inheritance. If I understand things correctly, these apply in the following order: filters -> mixins -> instance methods -> "unknown" and for each of the first three, lookup is done using the inheritance hierarchy, i.e.: object -> class -> [superclass -> ...] So, e.g. a per-object filter happens before a class-filter, but a class-filter still happens before a per-object mixin. "instance method" refers to procs when we are examining the actual object instance, and "instprocs" when we are searching its class/superclasses. Is this description correct? The only two mechanisms that I don't know where to put are assertions and forwarders. Are these implemented using e.g. mixins? Or are they a special-purpose mechanism? If so, where do they come in the order? Cheers, -- Neil

3 2

TIP #257 & XOTcl as an OO framework
by Gustaf Neumann 05 Oct '06

05 Oct '06

Dear XOTcl community, i am sure, some of you are following with interest the discussions about TIP #257 (adding OO to the core), where the proponents have developed an (incompatible) subset of XOTcl, that gives me the impression, that it will be very hard to build on it. There is a new implementation built from scratch, the implementor repeats, that he is not understanding certain functionalities from XOTcl (e.g. instmixins), is fixing hard bugs (forgot e.g. to loop check on filters), is not handling thread/interpreter exits, etc. It will take a while to debug the code, many other problems will (naturally) show up with that code. The code does not seem to be build for extensibility. Functionalities, that were dropped from XOTcl that depend on dispatcher or callstack properties are very hard to extend, especially, when there are no hooks. The implementor has no ear for xotcl requests and repeats that he has no time. Maybe i see the situation to negative, but i don't think currently, the TIP is going into a direction doing a good thing for the Tcl community (or XOTcl in particular). Here is a slightly different proposal. Let me know, what you think about it. I have this proposal already implemented (see below, 1.5.3alpha) and i am wondering - no matter how the TIP develops - whether we should go this direction with XOTcl. Allthough the first set of regression tests work already with an accordingly bootstrapped XOTcl, the introspection tests don't work (since there are now two top-level classes above ::xotcl::Object and ::xotcl::Class. Btw, the implementation took me less time than writing this proposal, and fits very nice with the new slot model (one can define a default superclass with the standard slot mechanism for e.g. "::xotcl::Class Dog", where te superclass of Dog should be ::xotcl::Object" and not necessarily the topmost superclass). The change will be visible in XOTcl programs, since there will be two new top-level classes. If you care and you have objections against adding these classes, please let me know. In case there is a strong objection, i will reconsider this change. -gustaf neumann The proposal: Rather than proposing any kind of OO language, i would suggest to add a framework to the core, that every extension (including XOTcl) can use. This framework is not useful as an OO language on its own, but an environment that can host multiple OO languages in parallel, such as Snit or XOTcl (maybe the language from current TIP 257 as well), without pushing a single model. Languages like Snit or XOTcl can continue to develop, the core developers can optimize and integrate better with the tcl-core, etc. This approach (and implementation) is much closer aligned with the original intention suited for multiple object systems. This proposal provides a flexibility much higher than in other popular scripting languages and lets object systems designer continue to improve their work. My proposal is to add a framework consisting of an flexible enough object interpreter (dispatcher) able to run the most powerful current object extensions. This dispatcher is accompanied by a "minimal object system" and an "extension mechanism". For the bootstrapping of different object systems, only a single method for allocating objects or classes is proposed, plus a few commands (for e.g. setting up the object/class relations and registering methods). The remainder of the object system (like XOTcl) can be loaded as an extension (being not part of the core), but providing the method set. The Minimal Object System The minimal object system consists of a base class (::oo::object) and a meta-class (::oo::class, subclass of ::oo::object). superclass instance-of ::oo::object class ::oo::object ::oo::class ::oo::class meta-class ::oo::object ::oo::class The meta-class ::oo::class has a single method named "alloc" (name is arbitrary, as shown later) to create objects or classes. ::oo::object has no methods at all. The minimal object system is intended to be specialized by one or more different object systems. An object system is created by sub-classing the base classes configuring these according to the object systems needs. This configuration consists of defining its relations to the general base and meta class, and equipping these extension specific classes with additional functionality (providing methods). The whole configuration of the object system can be done completely from the scripting level. Example for XOTcl: Create base and meta class: oo::class alloc ::xotcl::Object oo::class alloc ::xotcl::Class Define relation to the minimal object system: ::xotcl::setrelation ::xotcl::Class superclass {::oo::class ::xotcl::Object} ::xotcl::setrelation ::xotcl::Object class ::xotcl::Class ::xotcl::setrelation ::xotcl::Class class ::xotcl::Class The superclasses of ::xotcl::Class are defined to be ::oo::class and ::xotcl::Object. ::xotcl::Object and ::xotcl::Class are defined as instances of ::xotcl::class. The command setrelation supports the following relations: "mixin", "instmixin", "filter", "instfilter", "class", and "superclass" (alternatively, a reduced set "mixin", "filter", "class", and "superclass", when a flag "per-object" can be specified). The meaning of this relations is defined by the dispatcher, which is responsible for the linearizion of the commands. Methods from extensions: This proposal does not define methods (maybe except alloc), but instead an extension mechanism for defining methods. An implementor of an OO-language can provide methods. These methods can be loaded dynamically via package require. The object system developer can provided the methods as Tcl commands in the extension's namespace. These commands can be attached to the objects and classes of the object system to be defined. This is achieved by the command alias: ::oo::alias <class|object> methodName cmdName The following three commands register the method "instvar" and "proc" for ::xotcl::Object (available for all objects in XOTcl) and "instproc" for ::xotcl::Class ::xotcl::alias ::xotcl::Object instvar ::xotcl::cmd::instvar ::xotcl::alias ::xotcl::Object proc ::xotcl::cmd::proc ::xotcl::alias ::xotcl::Class instproc ::xotcl::cmd::instproc The name of the method (3rd argument) can differ from the name of the command (4th argument). Therefore, also the "alloc" method mentioned above can be registered the same way under arbitrary names. The same command can be registered under several names for different objects or classes. The command alias should not allow to register methods on ::oo::object and ::oo::class. All end user object systems should only be allowed to subclass (e.g. oo::object or ::xotcl::Object) and to register the methods on their objects and classes. The registered methods are defined with the standard signature for TclCommands but receive in ClientData the object or class structure (like in today XOTcl implementation). The handling for different client data (as for example for XOTcl's forwarders) is provided in an XOTcl style. C-extension writers can define non-leaf methods calling "next" from the C level. Example: static int MyMethod1( ClientData cdata, Tcl_Interp *interp, int objc, Tcl_Obj *CONST objv[] ) { int rc; /* ... */ rc = XOTclNextObjCmd(cdata, interp, objc,objv); /* ... */ return rc; } The primitive commands (like my, next, self, configure, ...) can be provided by the OO namespace (if there is sufficient agreement), or can be provided by the extension writers (provided they have access to obtain the needed information). Advantages: - All OO extensions can use the powerful dispatcher - If a certain extensions don't require filters, mixins, etc. they simply don't have to activate these. - The XOTcl dispatcher can be seen as a prototype implementation, but it can be replaced by a more efficient implementation with tighter core integration, provided the regression tests of the languages (e.g. XOTcl) continue to work. - The prototype implementation * is proven to work and sufficiently bug-free, * is free of memory leaks, * thread safe, * provides execution of the destroy callbacks when a thread or program exits, * provides uplevel transparency for interceptors, * is well suited for IDEs (an arbitrary class from a class tree can be reloaded and redefined without altering the relations between classes and/or instances) - All OO systems are equal: * since we do not want to allow to register methods on ::oo::object or ::oo::class, there is no "preferred" object system, * every object system defines its own classes with its own names and own methods (although, it can reuse methods from all extensions with arbitrary names, as shown above) * there is no need to namespace export from "oo::*" (these are no end-user commands). * nobody is forced on any predefined semantics - no extensions are locked out: * existing "high level" extensions like XOTcl continue to work * the XOTcl language definition is not part of the core, its development can continue * the XOTcl requirements are a superset of the requirements of other languages. * XOTcl can be executed with essentially the same speed as current versions. - This proposal is in the Tcl tradition of Tcl as a 2-level meta-language, since it provides a highly adjustable framework for object oriented languages. - Providing such a framework will attract people and put Tcl in front of the other OO scripting languages, at least in terms of flexibility. Sample Implementation: The actual snapshot of XOTcl is based on this framework using ::oo::object and ::oo::class as base object system. It contains a preprocessor variable OO, that turns on the sub-classing of the base object system (per default). The XOTcl C-Code does defines only oo::object and oo::class, the XOTcl base objects are created already by the scripting code. Note, that this is a preview version of XOTcl and not suited for running critical applications on it. It is passing the the first sets of the regression tests but fails on the introspection regression tests (it is not expecting to see e.g. ::oo::object as base class). It would be possible to hide the base object system from the introspection, but i am not sure this is a good idea. I am waiting for some feedback from the community before either finishing the regression test or removing the sub-classing of ::oo::object again. Here is the snapshot code: http://media.wu-wien.ac.at/download/xotcl-1.5.3-alpha.tar.gz Below is the basic script level initialization for XOTcl, where the classes ::xotcl::Object and ::xotcl::Class and their methods are defined. best regards -gustaf neumann =================================================== # $Id: predefined.xotcl,v 1.12 2006/10/04 20:40:23 neumann Exp $ if {[info command oo::object] ne ""} { ::xotcl::alias ::oo::class alloc ::xotcl::cmd::Class::alloc oo::class alloc ::xotcl::Object oo::class alloc ::xotcl::Class ::xotcl::setrelation ::xotcl::Class superclass {::oo::class ::xotcl::Object} ::xotcl::setrelation ::xotcl::Object class ::xotcl::Class ::xotcl::setrelation ::xotcl::Class class ::xotcl::Class } # provide the standard command set for ::xotcl::Object foreach cmd [info command ::xotcl::cmd::Object::*] { ::xotcl::alias ::xotcl::Object [namespace tail $cmd] $cmd } # provide some Tcl-commands as methods for ::xotcl::Object foreach cmd {array append eval incr lappend trace subst unset} { ::xotcl::alias ::xotcl::Object $cmd -objscope ::$cmd } # provide the standard command set for ::xotcl::Class foreach cmd [info command ::xotcl::cmd::Class::*] { ::xotcl::alias ::xotcl::Class [namespace tail $cmd] $cmd } # "init" must exist on Object. per default it is empty. ::xotcl::Object instproc init args {}

4 4

Testing for execution inside object
by Kristoffer Lawson 03 Oct '06

03 Oct '06

I need to know if the current procedural context is inside a method (isntproc, proc, whatever) or not. What is the best way to do this? I used [self] to check by catching the error, but that doesn't work particularly well if another package happens to define the command [self]. Besides, I've never been fond of having to resort to error- catching to find out information (a bit like how people used to test for the existence of an array element with [catch]). / http://www.fishpool.com/~setok/

2 2

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 October 2006