Weblog Page

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Thu, 27 Dec 2001 13:23:01 +0100

On Monday 24 December 2001 21:15, Andriy Tkachuk wrote:
> I've just tried an new (last) version of XOTcl and get an amount
> of my XOTcl code errors, that there isn't such function as cset!.
>
>
> In http://media.wu-wien.ac.at/doc/ChangeLog I saw:
>
> 2001-09-16 Uwe Zdun <uwe.zdun_at_uni-essen.de>
> ...
> - eliminated "cset" on Object and from the distribution, seems to
> be nearly unused
>
> ...
>
>
> How did you estimate the unuseness!? :))
>
> On my mind, it was very usefull one,,, at last for me...

Well, here is the definition of cset.

Object instproc cset {vn arg} {
  if {![[self] exists $vn]} {
    [self] set $vn $arg
  }
}

 we tried to keep the core definitions small,
 so it was dropped. sorry, if this hit you.

 there are recently some discussions about more
 powerful versions of set in the tcl community,
 so i expect something more general to appear sooner or
 later. so, if this tiny cset will be around in the
 xotcl-core, more and more applications will depend on
 it, and it should be made consistent with the more
 powerful set methods....

 A simple approach is to define a package named cset and import
 it via "package require", but somehow this seems
 like an overkill as well....

 what are the general opinions:
  - add it again to the predefined set
  - add it as a separate package
  - do nothing (hope for better "set" methods)
  - others?

 any comments?

-gustaf

>
> thanks,
> Andriy.
>
> _______________________________________________
> Xotcl mailing list - Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Thu, 20 Jul 2006 18:08:15 +0300

In the online reference manual, the volatile method is documented
under Class, meaning it would be a class procedure. However the way
it is demonstrated is:

Object new -volatile

Which would mean the object's [volatile] method is called. If
[volatile] was actually a class procedure, then the object instance
would not see it. In fact, it makes little sense that it would be a
class procedure instead of one that can be applied to any object. Or
have I missed something here?

In a similar vein, can [volatile] be called at any point, not just
during object instantiation? I might be getting an object returned
from somewhere else and, in that proc, I may want to make it volatile
so as to not have to worry about the point of destruction.

            / http://www.fishpool.com/~setok/

From: Stefan Sobernig <stefan.sobernig_at_wu-wien.ac.at>
Date: Sat, 04 Apr 2009 14:50:09 +0200

(sorry for double posting, forgot about digest mode)

Jeff,

> Message: 2
> Date: Fri, 03 Apr 2009 11:29:34 -0700
> From: Jeff Hobbs <jeffh_at_activestate.com>
> Subject: Re: [Xotcl] XOTcl packages
> To: Victor Mayevski <vitick_at_gmail.com>
> Cc: xotcl_at_alice.wu-wien.ac.at
> Message-ID: <49D6558E.200_at_activestate.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> On 03/04/2009 11:24 AM, Victor Mayevski wrote:
>> I really like that XOTcl is being included with ActiveState
>> distribution, and even updates via teacup are working. But there is
>> one issue - why is it that the rest of XOTcl packages (comm,
>> serializer etc) are not being included?
>
> The teapot is designed for individual packages (though they can have
> dependencies). In building, it goes through the usual configure / make
> / install steps. XOTcl only packages up the core library when it does
> that. The other packages would be best handled separately somehow.

Couldn't teacup provide the "--with-all=yes" configure flag so that the
accompanying infrastructure is included?

//stefan

From: Uwe Zdun <uwe.zdun_at_wu-wien.ac.at>
Date: Mon, 12 May 2003 20:04:11 +0200

Looking through this code again, the ::xotcl::lib is not really used in
XOTcl's code anymore ... and given the fact that you can create some setup,
where something goes wrong in searching for the xotcl lib, I would propose
to remove the warning message ... that would require the following patch (for
1.0.3) in generic/predefined.xotcl:

_at_@ -351,7 +351,7 @@
     }

     if {![info exists success]} {
- puts stderr "Cannot locate the XOTcl library on your system!"
- return 0
+ #puts stderr "Cannot locate the XOTcl library on your system!"
+ return
     }

The thing that happens then, if the lib is not found, is that it is reset to
the compiled-in default ... which is ok, I think.

--uwe

On Monday 12 May 2003 19:20, MichaelL_at_frogware.com wrote:
> I'm using XOTcl under both Tcl 8.4.2 and AOLServer. Here's my Tcl 8.4.2
> setup.
>
> $auto_path is {d:/appsdev/tcl/lib/tcl8.4 d:/appsdev/tcl/lib} both before
> and after
>
> package require XOTcl 1
>
> xotcl is installed under d:/appsdev/tcl/lib/xotcl-1.0.2.
>
> In that dir is a pkgIndex.tcl file with the following:
>
> package ifneeded XOTcl 1.0 [list load [file join $dir
> win/Release/xotcl1.0.dll] XOTcl]
>
> xotcl1.0.dll is under d:/appsdev/tcl/lib/xotcl-1.0.2/win/Release.
>
> I've also tried placing the dll in the bin directory and adjusting the
> pkgIndex.tcl file accordingly, but it had the same result.
>
> As I said, the dll does in fact load, and I can use XOTcl (and all of its
> libraries and samples). The problem is just the message.
>
> Uwe Zdun <uwe.zdun_at_wu-wien.ac.at> wrote on 05/12/2003 11:28:52 AM:
> > hmm ... Can you provide a bit more detail? where have you installed
>
> xotcl?
>
> > from where do you run it? what is the setting of the variable auto_path
>
> (
>
> > use: puts $auto_path at the beginning your program)?
> >
> > Uwe
> >
> > On Monday 12 May 2003 16:35, MichaelL_at_frogware.com wrote:
> > > With XOTcl 1.0.2 on Windows 2000 I get the "Cannot locate the XOTcl
> > > library on your system!" message despite the fact that the library is
> > > successfully found. I read the message in the archives on this, but a)
>
> the
>
> > > workaround didn't seem to work for me (if I understood it correctly)
>
> and
>
> > > b) it seemed like 1.0.2 was supposed to fix the problem (but obviously
> > > didn't in my case).
> >
> > --
> > Uwe Zdun
> > Department of Information Systems, Vienna University of Economics
> > Phone: +43 1 313 36 4796, Fax: +43 1 313 36 746
> > zdun_at_{xotcl,computer,acm}.org, uwe.zdun_at_wu-wien.ac.at

-- 
Uwe Zdun
Department of Information Systems, Vienna University of Economics
Phone: +43 1 313 36 4796, Fax: +43 1 313 36 746
zdun_at_{xotcl,computer,acm}.org, uwe.zdun_at_wu-wien.ac.at

From: <jim_at_jam.sessionsnet.org>
Date: 29 Mar 2004 02:02:02 -0000

Hi,

When configuring xotcl in any way whatsoever, if the configure step determines
it should build with aolserver extensions, it assumes the only possible place
for aolserver is in /usr/local/aolserver, a mistaken assumption for the same
reason that it's possible to install cat or grep in any location on the
unix installation.

The right way to do this is to add a configure.in option which would include
a specification of where aolserver is located. Suggestion, this option could
be named --with-aolserver=<dir>. Also, there should exist --without-aolserver.

-Jim

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Fri, 29 Sep 2006 18:55:47 +0200

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

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Thu, 08 Sep 2005 11:13:55 +0200

Taral schrieb:

> Well, I will be in touch with you guys on further development on my side.

good. i'll send you soon a version of xotcl with the "...foward ...
expr..." problem resolved, if you
are interested.

> By the way, I can not resist myself asking you guys about testing done
> for XOTcl. I'm planning to use it for implantable Medical Device
> hard-real time firmware system where bugs are not allowed at all.
> Reading you note about the bug in expr method, do you mind giving me a
> small update on what type of testing is done on this library and how
> much stable is it from your experience?

we have a constantly growing regression test suite. in general i think
it is generally
perceived that xotcl has a very high stability. there is at least on
company that depends
on xotcl in their multi threaded mission critical product; we use xotcl
in our e-learning
environment, which is (based on publications) the most intensely used
e-learning
system on universities world wide (up to more than 4 mio requests from
registered
users per day). The OACS community has recentlyTIPed that xotcl should
become
part of every standard OACS installation.

before every release, we run all the regression test and complex systems
around and we
send pre-releases to core users. If you look at the changelog you will
see that most bugs
are either in "new features" or show up in "erroneous xotcl code". In
your situation i would
certainly do my own testing with my code and xotcl before burning the
code into proms.
The community will help you with problems, if you are interested in
commercial support,
we have founded recently a small company for providing support for
various of our
research products.

> Are there any plans to provide more of object relation management
> functionality in the library itself? When are you planning the next
> release?

in the next weeks.

> I was wondering about whom I'm talking to. You guys are obviously from
> Germany/Austria based on my guess from your email address. It would be
> nice to know you guys little more to help the communication. Do you
> guys have any personal webpage? I don't have one myself :( But now I
> feel like I should have one. So I will try to put up one sometime soon.

you will find my face (and uwe's) easily via google

best regards
-gustaf neumann

>
> On 9/5/05, *Gustaf Neumann* <neumann_at_wu-wien.ac.at
> <mailto:neumann_at_wu-wien.ac.at>> wrote:
>
> Taral schrieb:
>
> > Hello,
> >
> > I recently came across XOTcl and found it very very useful. I am
> > working on optimizing some legacy compiler code which is written in
> > TCL. I would like to make it object-oritented and so I started
> using
> > XOTcl. So far I have found aouut 90% reduction in execution time.
> > Overall I'm getting great performance by using XOTcl.
>
> wow, this is an impressive number; good to hear that.
>
> > I would like to Thank You guys for writing such a great library.
> >
> > Of course I have couple of questions for you. I will really
> appreciate
> > it if you can help me here.
> >
> > (1) Is there any way to all the objects or instances based on
> > parameter value? For example, I would like to request object
> names of
> > all objects where given parameter's value is equal to 5.
>
> There is no built-in support for this. a straigthforward approach
> is the
> following which might
> be sufficient in many situations:
>
> ===========
> # define method expr for all Objects, the operands are taken from
> # the instance variables
> Object instforward expr -objscope
>
> # define method select with some abitrary tcl expression. All objects,
> # for which the expression returns 1 are returned
> Class instproc select {expr} {
> set result_list [list]
> foreach o [my allinstances] {
> if {![catch {$o expr $expr} result]} {
> puts "$o expr {$expr} -> $result"
> if {$result} {
> lappend result_list $o
> }
> }
> }
> return $result_list
> }
> ===========
>
> so, now we define a view classes and objects with some instance
> variables
>
> Class C -parameter {{x 10}}
> Class D -superclass C
>
> C c1
> C c2 -x 11
> D d1 -x 100
> D d2
> D d3
> d3 unset x
>
> finally, we try it out with some demo queries
>
> foreach q {
> {$x > 10}
> {$x >= 10}
> {$x < 1}
> {[string match *00* $x]}
> } {
> puts "C select $q --> {[lsort [C select $q]]}\n"
> }
>
> Note that in this example, all instances of C are checked for the
> expression, if
> you use "... [Object select {$x > 10}]", all objects will be checked.
>
> This approach might be good enough for small examples and medium
> speed requirements. If you have larger number of objects, and you
> cant
> restrict the query to smaller classes, you should try to build an
> index
> based on associative arrays, which could replace the "allinstances"
> in the code above.
>
> > (2) Do you have more example code pieces? I would like to see more
> > sample implementation to help me with the syntax. I'm also learning
> > TCL language at the same time using XOTcl :)
>
> i am sure, you have seen the tutorial and the examples in xotcl*/apps
> and xotcl*/library. There are a few more on:
>
> http://mini.net/tcl/XOTcl
> http://wiki.tcl.tk/references/10971!
>
> > (3) Is there any way to represent relationship across two
> classes? For
> > example, Class A is related to Class B with one-to-many
> relationship.
>
> a few class/class relations and object/class relations are
> maintained
> by xotcl (e.g. superclass,
> class, mixins). A start point might be ::xotcl::Relations,
> which is
> used to implement a
> uniform interface to mixins (and instmixins ...), which allows to
> specify "... mixin add ...", #
> "... mixin delete ...", "... mixin set ...", etc. In principle, the
> same interface could be used
> for application level relations as well...
>
> In current applications, the classes use and maintain a list of
> related
> object/classes.
> Often, it is conveniant to use aggregations to express 1:1 or 1:n
> relationships.
>
> > (4) If there is a way to define relationship, is it possible to
> query
> > objects of classes in the relationship? For example, I would like to
> > get all the objects of Class B related to given object of Class A
> > (like a1) across given one-to-many relationship. In this case result
> > would be list of object handles of Class B that matches based on
> given
> > primary key (identifier) value between class A and B.
>
> a good key identifier is the object name. see the following snipplet,
> how such behavior
> could be obtained. We define class A, which maintains the relationship
> to some other
> objects. if an instances exists that relates e.g. to object c1, we
> could
> check there some
> properties with expr like above...
>
> Class A -parameter {relates_to}
>
> A a1
> A a2
>
> a1 set relates_to {c1 c2}
>
> foreach o [A allinstances] {
> catch {
> if {[lsearch -exact [$o relates_to] c2] > -1} {
> puts "could check $o"
> }
> }
> }
>
> hope theses examples help a little.
>
> -gustaf
>
> PS: when i was writing this mail i saw that the classtack information
> within methods called via the method "expr" is not correct. It will
> be fixed in the next release....
>
> >
> > Please provide some guidance to implement above functionality
> using XOTcl.
> >
> > Thanks a lot in advance.
> >
> > May be in future I would like to contribute to XOTcl. I wish to
> be in
> > touch with you guys.
> >
> > Regards,
> > Taral
>
>
>

From: Jeff Hobbs <jeffh_at_activestate.com>
Date: Fri, 27 Jul 2012 13:10:29 -0700

On 27/07/2012 12:50 PM, Stefan Sobernig wrote:
> Hey Jon!
>
> To clarify:
>
> http://next-scripting.org/xowiki/getstart states that
>
>> Note: As for the source distribution of the current public beta
>> release, our build environment has not been tested with any build
>> environment targeting Windows (MSYS/MinGW, Visual Express). This is
>> planned for the first stable release.
>
> This still holds for the b3 release.
>
> In the git HEAD version, however, we included and maintain the necessary
> fixes to build under MinGW/MSYS (both the default 32-bit and any of the
> 64-bit toolchain).
> We have not tested against any Visual C compiler, nor under cygwin. On
> top, we have not tested building against the ActiveState distribution of
> Tcl under Windows. We always compiled Tcl on our own.
>
> Right now, I am remote to my windows box but I will compile a note to
> publish on next-scripting.org, essentially outlining the following steps
> under MinGW/MSYS:
>
> Step 1: Install MinGW/MSYS default 32-bit toolchain
>
> http://www.mingw.org/wiki/Getting_Started
> https://sourceforge.net/projects/mingw/files/Installer/mingw-get-inst/
>
> Step 2:
> Fetch the tcl source distribution
>
> http://www.tcl.tk/software/tcltk/download.html (8.5.11)
>
> ... or from the fossil SCM:
> http://core.tcl.tk/tcl/
>
> Schritt 3:
>
> Fetch the git HEAD of nsf/nx using:
> http://msysgit.github.com/
>
> after having fired up the GIT Bash:
> follow the steps described in: http://next-scripting.org/xowiki/git
>
> Step 4: Install Tcl
>
> a) Open the MinGW Shell
>
> b) cd <tcl src folder>/win
> ./configure
> make
> make install
>
> Step 5: Install NSF/NX
> cd <NSF git directory>
> ./configure
> make
> make install
>
> Step 6: Run the NX shell
> nxsh myScript.tcl
> tclsh myScript.tcl
>
> Make sure that you turn off your antivir protection (especially
> filesystem guards) for the time of compilation as most scanners (e.g.,
> AntiVir) have been reported blocking the on-the-fly compilation into
> object code during the various configure tests. This is a must and might
> otherwise present a bunch of unexpected autoconf/Make voodoo behavior to
> you.
>
> As soon as I return to my office at the beginning of next week, I can
> checkout on the compilation procedure again.
>
>> I was using Activestate 8.5
>
> As I said, we have not tested against ActiveState installations (as an
> alternative to step 2 and 4 above). But if the git HEAD version builds
> as outlined above, it should do so under ActiveState. However, some
> tweaks might be necessary to get the various path settings right.
>
>> installed the compile tools, and ran configure, but it broke because I
>> apparently don't have a /usr/local/include/tcl8.5/tools/genStub.tcl ...
>
> From all I know, ActiveTcl does not provide a source installation
> including private headers, genStub.tcl & friends. But you got your
> answer already in
> https://groups.google.com/forum/?fromgroups#!topic/comp.lang.tcl/APlqIM_kyKY.

FWIW, ActiveTcl does include internal headers, and I have compiled
extensions using mingw against ActiveTcl without issue (though not tried
xotcl recently).

Jeff

From: Catherine Letondal <letondal_at_pasteur.fr>
Date: Mon, 22 Jan 2001 11:01:05 +0100

Gustaf Neumann wrote:
> >>>>> "CL" == Catherine Letondal <letondal_at_pasteur.fr> writes:
>
> CL> Hi,
>
> CL> Most of the time, I know what is going to be called when I peut a next
> CL> statement :
> CL> - the class instproc method if from a proc
> CL> - the mixin method if any
> CL> - the superclass method
> CL> etc..
>
> CL> My question is the following: I have sometimes the instproc
> CL> redefined at the instance level with a proc: this is to enable the
> CL> user to experiment a method on a given object without breaking all
> CL> the application (this is actually one the main reason for me to
> CL> use Xotcl). It's also a debug feature for more experimented
> CL> developpers.
>
> CL> However, I have the "next" problem in such case: it's the instproc
> CL> level which is called instead of either the mixin or superclass
> CL> method.
>
> Dear Catherine,
>
> why not letting the user to define mixin for the experimentation?
> you can still define other mixins/instmixins/etc. for your "own"
> purposes.
>
> what you seem to want is to change the onion shells of the next path
>
> filters mixins instmixins proc instprocs
>
> to something else, preferably starting with proc. note, that the
> onion shells are not atomic (with the exception of proc), but can
> be quite complicated (e.g. registering multiple cascaded filters),
> so simply "jumping" to a certain method of a certain Class won't let
> you to call there the "appropriate" method via next. changing or
> altering the order on the fly can lead to programs that are very hard
> to comprehend.

I don't really want to change this order - which indeed would make the program
much more complex to debug! I just want to be able to test whenever such
proc -> instproc behaviour happens and decide what to do about it - for instance
to have the instproc decide that the job is already done and to perform a next
for potential superclass calls.

I understand your suggestion of having user defining mixins. However
I think that the proc/instproc difference is much more simple to understand for
non-professional programmers.
During the discussions I have already had with biologists whom I have
shown my prototype, they understand this proc/instproc scheme at once.

Moreover, although I agree that mixin are a good tool to experiment - and intend to
explain this in a further step - mixins and proc do not really have the same
logical function and I prefer not to confuse them too much.


> We could implement a [[self] info next] or better a [self next] for
> introspection purposes (somewhat a generalization of "info
> calledproc"), but i am afraid, that this won't help you.

Oh yes, this would help a lot! :-)

--
Catherine Letondal -- Pasteur Institute Computing Center

From: Gustaf Neumann <neumann_at_wu.ac.at>
Date: Tue, 20 Jan 2015 21:21:28 +0100

Dear Victor,

below is a small improvement for the working suggestion:

- the first suggestion used the constructor to fix the superclass

- it is better, the change the default of the "superclasses" slot
   (inherited from nx::Class) from "nx::Object" to "nx::Class"

- this is a slot, that is not linked to a variable, but to a method
   altering the class. Therefore the definition of this slot is slightly
   more magic.

- This solution has the advantage, that one has not to care
   that further specializations of my::Class call in their
   constructor always "next". Furthermore, it should be
   slightly faster.

all the best
-gn

namespace eval my {

   Class create Object -superclasses nx::Object

   Class create Class -superclasses nx::Class {

       # create a slot container ...
       ::nx::slotObj [self]
       
       # ... and redefine slot "superclasses" with a different default
       # value, such we can write
       #
       # my::Class create Foo
       #
       # instead of
       #
       # my::Class create Foo -superclasses ::my::Object
       #
       ::nx::ObjectParameterSlot create [self]::slot::superclasses \
          -methodname "::nsf::methods::class::superclass" \
          -elementtype class -multiplicity 1..n \
          -default [namespace current]::Object
   }

   namespace export Object Class
}

#
# show parameter definition of "superclasses" with changed default
#
puts "parameter definition for '-superclasses': [my::Class info lookup parameters create super*]"



Am 20.01.15 um 11:28 schrieb Victor Mayevski:
> That's beautiful! Thank you!
>
> On Tue, Jan 20, 2015 at 1:11 AM, Stefan Sobernig
> <stefan.sobernig_at_wu.ac.at <mailto:stefan.sobernig_at_wu.ac.at>> wrote:
>
> A more complete solution (preserving any pre-existing superclass
> lists) is as follows:
>
> package req nx
>
> namespace eval ::vitick {
>
> Class create Object -superclasses nx::Object
>
> Class create Class -superclasses nx::Class {
> :method init {} {
> ##
> ## Rewire the default superclass
> ##
> if {[:info superclasses] eq "::nx::Object"} {
> :configure -superclasses [namespace current]::Object
> }
>
> }
> }
>
> namespace export Object Class
> }
>
> namespace import -force ::vitick::*
>
> puts [[Class create MyClass] info superclasses]; # default is:
> ::vitick::Object
> puts [[Class create AnotherClass -superclasses MyClass] info
> superclasses]; # ::MyClass
> puts [[Class create AnotherClass -superclasses MyClass] info
> superclasses -closure]; # ::MyClass ::vitick::Object ::nx::Object
>
> //stefan
>
> Hi Victor,
>
> > Any suggestions?
>
> As always, there are several options. One way of nursing our
> custom
> Object/Class is to use proper specializations of
> nx::Object/nx::Class:
>
> package req nx
>
> namespace eval ::vitick {
>
> Class create Object -superclass nx::Object
>
> Class create Class -superclass nx::Class {
> :method init {} {
> :configure -superclasses [namespace current]::Object
> }
> }
>
> namespace export Object Class
> }
>
> namespace import -force ::vitick::*
>
> This is less invasive and you have the benefit of monitoring any
> changes/additions to nx::Object/nx::Class for free.
>
> Cheers,
> Stefan
> _______________________________________________
>