Xotcl

xotcl@alice.wu.ac.at

2 participants
653 discussions

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

XOTcl 1.5.2
by Gustaf Neumann 29 Sep '06

29 Sep '06

Dear XOTcl Community, XOTcl 1.5.2 is available. This is mostly a bug fix release and fixes most prominantly two serious bugs, which were in the code for a some longer time, but showed up after 1.5.1. It seems as if the new features of XOTcl attracked more users to try/upgrade the code. One bug showed up on 64 bit code on AMD processes with FreeBSD, the other bug showed on some "odd, old, 64-bit system" of Don Porter, but turned out to be a problem on every system. I hope, this ends the series of quick bug fix releases, such we can address more functional improvements. Another good news is that Martin Matuska has volunteered to provide a FreeBSD port such that XOTcl will be most likely included on the DVD of the forthcoming 6.2 release. Many thanks! best regards -gustaf neumann PS: The binary version for windows will follow soon. ======================================================== Announcing XOTcl 1.5.2 ************************* Hi everybody. We are pleased to announce the availability of XOTcl 1.5.2. Major changes relative to 1.5.1 are: * Improved Functionality + allowing to trace objects as well as classes via the package xotcl::trace (many thanks to jima for suggesting this) * Improved code quality: + terminating all vararg lists in C by ..., (char *) NULL There was a problem with this on 64bit AMD on FreeBSD, as some lists were terminated previously by an integer typed zero-value. + better handling of Tcl result objects. Make sure that no changes happen on shared objects. Removed all occurrences of Tcl_AppendResult() from xotcl.c + Fixed memory corruption (accessing feed memory) in the invalidation of transitive mixins (many thanks to Don Porter for reporting) For more details about the changes, please consult the ChangeLog and documentation. MORE INFO General and more detailed information about XOTcl and its components can be found at http://www.xotcl.org Best regards, Gustaf Neumann Uwe Zdun

1 0

OSX + XOTcl + ActiveTcl
by Robert 27 Sep '06

27 Sep '06

Is there anything special about that combination that I need to know before compiling XOTcl on OSX? Robert

3 2

Device chaining from Objects/Classes defined in C
by Scott Gargash 23 Sep '06

23 Sep '06

I have some classes that are defined in C using the xotcl (cersion 1.4) C API. Things seem to work (I can create objects and invoke methods), but I can't get chaining to function. I can invoke the "next" command (using Tcl_Eval( interp, "xotcl::next")), but that fails with "next: can't find self" I've stepped into the XOTcl code and it looks like it's searching the the interpreter's call stack to determine the active object but as near as I can tell, my C-defined methods don't correctly annotate Tcl's call stack. I'm not aware of any documentation for the C API, so I used the library code (xotclsdbm.c) as an example. Is there anything I need to do beyond XOTclAddIMethod to get "next" to function? I'm using a locally built version of XOTcl (the binary versions don't include header/libs). Is it possible I've built something incorrectly? I see two defintions for the RUNTIME_STATE macro which looks like it plays a role in this. I don't know which version I'm using or if it even matters, but I assume I'm using the default version. Scott

2 2

← Newer
1
...
23
24
25
26
27
28
29
...
66
Older →

Jump to page:

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