Xotcl September 2006

xotcl@alice.wu.ac.at

7 participants
9 discussions

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

XOTcl 1.5.1 available
by Gustaf Neumann 22 Sep '06

22 Sep '06

Hi everybody, XOTcl 1.5.1 is available. This is mostly a bugfix release + improved interface for implementing XOTcl methods in C. all the best -gustaf neumann ============================================================= Announcing XOTcl 1.5.1 ************************* Hi everybody. We are pleased to announce the availability of XOTcl 1.5.1. Major changes relative to 1.4.0 are: * Improved Functionality + Improved interface to develop XOTcl methods in C (Many thanks to Scott Gargash for the constructive discussions and suggestions). New functions imported through the XOTcl's stub interface: - XOTclNextCmd() - XOTclCallMethodWithArgs New constant XOTCL_NONLEAF_METHOD to allow C-implemented methods to call next. This constant can be passed as 5th argument to XOTclAddIMethod (or ...AddPMethod). The following is a short example for defining and registering a C-implemented constructor "init" to a class. static int MyClassInit( ClientData cdata, Tcl_Interp *interp, int objc, Tcl_Obj *CONST objv[] ) { int rc; /*** before next ***/ rc = XOTclNextObjCmd(cdata, interp, objc,objv); /*** after next ***/ return rc; } ... MyClass = XOTclGetClass(interp, "MyClass" ); XOTclAddIMethod(interp, MyClass, "init", MyClassInit, XOTCL_NONLEAF_METHOD, 0 ); * Improved code quality: + fixed a bug with the backward-compatible and deprecated "setter" interface (many thanks to Manfred Stelzhammer for reporting the bug) + fixed a bug in parsing nonpositional arguments, when e.g. square brackets are used in type declarations for parameters (Many thanks to Stefan Sobernig for reporting) + fixed autoname crash under Windows NT (Many thanks to Mark Janssen for reporting and providing a patch) + fixed serializer to handle deeper stratification layers + simplification and speedup of dispatcher + Makefile.in improvements for genstubs + Changed "test -e" to "test -f" in Makefile.in, since the standard test command in Solaris does not understand "test -e" (Many thanks to Andreas Kupries for reporting) + improved 64-bit compatibility on POWER5+ 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

::xotcl::object autoname crashes in Tcl 8.5
by Mark Janssen 18 Sep '06

18 Sep '06

When using XOTcl 1.4 or 1.5 on Tcl 8.5 creating an instance with an autoname crashes the Tcl process. On 8.4.13 it works: XOTcl 1.4 > tclsh % set tcl_patchLevel 8.4.13 % package require XOTcl 1.4.0 % ::xotcl::Object autoname a a0 % >tclsh % package require XOTcl 1.4.0 % set tcl_patchLevel 8.5a5 % ::xotcl::Object autoname a # crash with access violation XOTcl 1.5 > tclsh % package require XOTcl 1.5.0 % set tcl_patchLevel 8.4.13 % ::xotcl::Object autoname a a1 % > tclsh % package require XOTcl 1.5.0 % set tcl_patchLevel 8.5a5 % ::xotcl::Object autoname a # crashed with access violation % parray tcl_platform tcl_platform(byteOrder) = littleEndian tcl_platform(machine) = intel tcl_platform(os) = Windows NT tcl_platform(osVersion) = 5.1 tcl_platform(platform) = windows tcl_platform(threaded) = 1 tcl_platform(user) = mjanssen tcl_platform(wordSize) = 4 Is this a known problem? I am able to work around it by only using new and create. Regards, Mark

2 2

XOTcl behaviour
by Murr, Florian 18 Sep '06

18 Sep '06

Dear XOTcl team, with XOTcl1.4.0 and XOTcl1.5.0 I encountered the following behaviour: ------------------------------------------------------------------------ Class X -parameter { {p {}} } # works fine X create x1 -p {a b c} # blows up!! X create x2 -p {-name a -xyz b} ------------------------------------------------------------------------ -- IMHO there should be no dependency on the value of a parameter, whether an Object is created or not. In my programs I depend on being able to pass any value to the parameter in question! regards, - Florian

2 1

potential problem in makefile for solaris fixed
by Gustaf Neumann 16 Sep '06

16 Sep '06

Hi everybody, Andreas Kupries found a small problem with the makefile on solaris. > The Makefile target "install-shells" (around line 421) > uses > 'test -e' > The '-e' option is not understood by the 'test' command of Solaris. > I have to use 'test -f', or the installation of xotcl fails. This is the same code as in prior versions, so it won't effect many people. I have fixed the tar file on www.xotcl.org without upgrading the version number. best regards -gustaf

1 0

XOTcl 1.5.0 available
by Gustaf Neumann 14 Sep '06

14 Sep '06

Dear XOTcl community, I am pleased to announce the availability of XOTcl 1.5.0. To sum up, the biggest change is the introduction of slots objects, which generalize the handling of "parameters" and object class relations (like e.g. mixins). Slots provide a general and extensible interface for changing properties of objects and classes. Every multi-valued slot has e.g. a "<slot> add ..." method to add values like previously only possible for mixin and filters. Slots contain as well support for partial and lazy initialization of objects (important, when e.g. variables are initialized through costly SQL commands). Another important change is that it is now possible to attach the predefined methods of xotcl to arbitrary objects/classes. For example, the XOTcl class system is created on the C-level completely without any methods, all methods are attached from the script initializing XOTcl. I would like to thank the XOTcl community for many fruitful inputs and discussions, that contribute significantly to the development of XOTcl. Best regards -gustaf neumann ================================================= Announcing XOTcl 1.5.0 ************************* Hi everybody. We are pleased to announce the availability of XOTcl 1.5.0. Major changes relative to 1.4.0 are: * Improved Functionality + The C-level implementation of XOTcl creates now the basic classes ::xotcl::Object and ::xotcl::Class completely without any methods. All predefined methods are now registered from the initialization script-code (predefined.xotcl) via the new command ::xotcl::alias <class>|<obj> <methodName> \ ?-objscope? ?-per-object? <cmdName> which is used for registering predefined Tcl commands as methods. These aliases are like zero cost forwarders, since they lookup the function pointer from the commands and used these in the methods. This change makes it possible to register the same command on different classes (with maybe different names), such that for example the predefined set method of ::xotcl::Object can be replaced with a different method and the set method can be registered on some other classes (maybe some application classes). This change makes it as well quite easy to develop some other object oriented languages based on the XOTcl framework, since all methods can be rearrange from the Tcl layer . + Slots A slot is a meta-object that manages property-changes of objects. A property is either an attribute or a role of an relation. In a nutshell, a slot has among other attributes - a name (which it used to access it), - a domain (object or class on which it can be used) , and - can be multivalued or not Every slot defines a uniform interface to access its content. So has for example, every multivalued slot a method "add" to add a value to the list of values and a method "remove" to remove it again. We distinguish between system slots (predefined slots like class, superclass, mixin, instmixin, filter, instfilter) and application slots (e.g. attributes of classes). System Slots ======== System slots are predefined slots defining e.g. some relations between classes, or between objects and classes. The predefined system slots are: - superclass: every class in XOTcl has one or more superclasses. The name of this slot is "superclass", the domain is "::xotcl::Class", the slot is multivalued. One object might have multiple superclasses. - class: every object has a class; therefore, the domain of the slot is "::xotcl::Class", the property is not multivalued. - mixin: every object in XOTcl can have one or more mixin classes. The name of this slot is "mixin", the domain is "::xotcl::Object", the slot is multivalued. - instmixin: same as above, but the domain is "::xotcl::Class" - filter, instfilter: similar to "mixin" and "instmixin" Every slot can be used set and query the property from its domain. The syntax for setting values is <object> <property> newValue and for getting its values is set x [<object> <property>] Every multivalued slot has as well a method "add" and "remove" Examples for using the system slot "mixin" Object o; Class M; class N o mixin ::M ;# replacing the per-object mixins of o with M o mixin add ::N ;# add N to the front of the mixin list o mixin delete ::M ;# delete M from the mixin list puts [o mixin] ;# query the current mixin list Attribute Slots ========= Attribute slots are used to manage the setting and querying of instance variables. We define now a person with three attributes,"name", "salary" and "projects". Class Person -slots { Attribute name Attribute salary -default 0 Attribute projects -default {} -multivalued true } Examples for using the slots are Person p1 -name "Joe" p1 projects add project1 Some additional features of the slots are: - Support for value checking for * primitive types (all types from "string is", like integer, boolean, ...) * instances of Classes (e.g. value must be an instance of Person) * custom value checkers * uniform interface for single and multi-valued slots - Support for lazy initialization (e.g. when costly commands (like SQL) are used to initialize instance variables, not all variables are used for each object) - more experimental low level functionality, like * initcmd (executed, whenever the variable is read the first time) * valuecmd (executed, whenever the variable is read) * valuechangedcmd (executed, whenever the variable is altered) For more details, see http://media.wu-wien.ac.at/doc/tutorial.html#slots + Re-implementation of the method "parameter" based on slots. All forms except ... -parameter {name1 {name2 default2}} ... (I.e. pure accessor parameters and parameters with defaults) are deprecated, since slots are the much more powerful and orthogonal construct. The old c-based parameter support based on "parameterclass" is deprecated. It is still in the C-code (the method "parameter" is redefined in predefined.xotcl). If someone urgently needs it, please remove the parameter instproc from predefined for the time being, and write an email to me, in case you really need it). The C code for parameter will be removed in the next release. + Improved introspection though the procsearch method. This method reports now in its second argument not only [inst]proc but as well [inst]forward, [inst]parametercmd and [inst]cmd (the latter for methods implemented in C. * Improved introspection through "info" - new subcommand "info slots" - implemented backwards bug-compatible "info parameter", deprecated + Improved serializer - better handling of cyclical dependencies, when mixins are involved - fix for namespace handling to make the XOTcl communication library classes working with the aolserver (thanks for Stefan Sobernig for pointing this out) - Now other ::xotcl::* objects can be included in the aolserver blueprint (e.g. non positional argument handlers) - handling of slot dependencies - more convenient calling of the serializer: Method "serialize" for Object is defined when the package xotcl::serializer is loaded. + Improved forwarding commands - New option for the argument substitution. When the argument list of the forward command contains "%argclindex {a b c}", then depending of the number of arguments at invocation "a", "b" or "c" is substituted. If more arguments are used at the invocation of the forwarder than values are contained in the list after %argclindex, an error is generated. - New options for forwarder: * The option -earlybinding can be used to look up the function pointer of the called Tcl command at definition time of the forwarder instead of invocation time. This option should only be used for calling C-implemented Tcl commands) * The option -verbose prints the substituted command in the forwarder prior to invocation. + New snit-like utility functions: - ::xotcl::myvar varName: return the fully qualified variable name of the specified variable. - ::xotcl::myproc methodName ?args?: call an xotcl method without the need of using "[list [self] methodName ...]" Both commands are namespace exported + added "subst" to the set of Tcl imported methods (like e.g. incr, append, ...) On can do now: % Object o ::o % o subst {I am [self]} I am ::o + added new method for ::xotcl::Object named "contains": This method is essentially a value added back-port of the OpenACS version. It allows to create a nested object structure with little syntactic overhead. See tutorial or language reference for more details. * Improved code quality: + fixed a bug with nonpositional arguments, some positional arguments and "args" + fixed a bug in nonpositional arguments when called without arguments + tested with Tcl 8.4.13 and 8.5a4 + improved error messages in connection with nonpositional arguments + fixed a bug in the xotcl trace module (many thanks to jima for reporting) + fixed a namespace bug in ::xotcl::package require in connection with xotclide (many thanks to Bill Paulsen and Artur Trzewik for identifying the problem and suggesting a fix) + improved documentation (e.g. new sections added, some sections deleted, spelling improved, in total 8 pages longer) + fixed documentation bugs (many thanks for Kristoffer for reporting) + more regression tests added 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

Precedence Order
by Scott Gargash 07 Sep '06

07 Sep '06

As I understand it, precedence order is computed as filters then mixins the superclasses, and this sort order is applied "globally" to an object. In other words: Class create Base Class create Derived -superclass Base Derived d d info precedence ==> ::Derived ::Base ::xotcl::Object Class create BaseMixin Base instmixin add BaseMixin d info precedence ==> ::BaseMixin ::Derived ::Base ::xotcl::Object This behavior seems to violate encapsulation. BaseMixin is intended to intercept messages to Base. Derived doesn't know about BaseMixin and BaseMixin doesn't know about Derived, yet BaseMixin ends up being the first interceptor of messages to Derived. Since BaseMixin is intended to modify the behavior of Base, it would be better BaseMixin preceeded Base (and only Base) in the sort order. d info precedence ==> ::Derived ::BaseMixin ::Base ::xotcl::Object The current behavior means you can't really add a mixin without understanding everywhere that the object being extended is used. Is there some benefit to the current behavior that I don't understand?

3 6

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 2006