Weblog Page

From: <MichaelL_at_frogware.com>
Date: Mon, 12 May 2003 17:27:19 -0400

I don't know if this helps, but my approach was to add the following in
xotcl-1.0.2/pkgIndex.tcl:

set _dir_ $dir
foreach {subdir} {
    library/actiweb
    library/comm
    library/lib
    library/patterns
    library/rdf
    library/registry
    library/serialize
    library/store
    library/xml
} {
  set dir [file join $_dir_ $subdir ]
  source [file join $dir pkgIndex.tcl]
}
set dir $_dir_
unset _dir_

This isn't as elegant as it could be--for example, the list of subdirs
could obviously be dynamically generated--but it does use the existing
package loading mechanism (including the default pkgIndex.tcl files in the
subdirs).

Gustaf Neumann <neumann_at_wu-wien.ac.at> wrote on 05/12/2003 04:14:52 PM:

> The background of this code is as follows:
> - tcl searches the libraries in auto_path and the subdirs of that.
> - with xotcl i would like the get one more level to organize the
> xotcl packages more nicely.
> - therefore the xotcl library is added to the auto_path.

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Mon, 20 Dec 2010 09:03:58 +0100

On 19.12.10 21:37, Victor Mayevski wrote:
> Although your examples do seem to work on Object objects, the Class
> instances do not work right.
They work "right", but maybe not as you expected.
You original question was:

> Is there any way to add meta-data to parameters during parameter
> creation? Specifically I would like to add a time stamp to the the
> parameter so I can list parameters in the order they were created.

The following code snippet adds meta-data to every
"attribute" (similar
to "-parameters" in XOTcl) when it is created. More
technically, the method
"attribute" creates a slot-object on the class or object, on
which it is created.
These slot objects are extended in this example by an
additional instance
variable named "timestamp".
> nx::Class create C {
> # Create attributes "x" and "y" and script the initialization of
> # these attributes.
> :attribute x {
> set :timestamp [clock clicks]
> }
> :attribute y {
> set :timestamp [clock clicks]
> }
> :create c1
> }
Note, that the slot objects are created at the time, when
the method
"attribute" is called, in the code above at the time, when
class "C" is
created, before the object c1.

Slot objects provide common meta-data for all their managed
instance
variables. Typical examples for such meta-data are a default
value,
a value checker, a linkage to a database table/attribute,
the sql-type of the attribute, a label for pretty printing,
a widget
for data entry, .....). If an attribute is defined on a
class, it is
created per-class, not per class instance (that would be too
costly in most situations).
> if I do [C create c2] and then [print_slots_and_timestamps c2], the
> actual output is still for instance c1, not c2,
of, course, if one creates two instances of C (such as c1
and c2),
these will share the same slot objects (in the example
above, the slot
objects are named C::slot::x and C::slot::y; normally, the names
of the slot objects won't interest you).

If you want to create unique timestamps per attribute value,
i would recommend to combine a timestamp from the object
creation time with the a timestamp from the slot object
creation (see below)

best regards
-gustaf neumann

========================================
proc print_slots_and_timestamps {obj} {
   foreach slot [$obj info lookup slots] {
     if {[$slot eval {info exists :timestamp}]} {
       puts "$obj has attribute [$slot name] \
          timestamp [$obj T].[$slot eval {set :timestamp}]"
     }
   }
}
nx::Class create C {
   :attribute x {set :timestamp [clock clicks]}
   :attribute y {set :timestamp [clock clicks]}
   :attribute {T "[clock clicks]"}
   :create c1
   :create c2
}
print_slots_and_timestamps c1
print_slots_and_timestamps c2

From: Uwe Zdun <uwe.zdun_at_wu-wien.ac.at>
Date: Tue, 16 Sep 2003 16:26:11 +0200

On Tuesday 16 September 2003 15:20, MichaelL_at_frogware.com wrote:
> Great, thanks! I didn't know about "xotcl::interp."
>
> Can you say anything more about 1.1--when it's coming and what it
> contains?
>

I hope soon ... we still have to sort out some problems.
It contains a new, simplified configure/build system (mainly for unix),
mixinguards (similar to filterguards), uses the TCLLIBPATH environment
variable to find the XOTcl so/dll lib, transitive instmixins (working like
superclasses of mixins), and a few minor issues/bug fixes.

--uwe

From: <uwe.zdun_at_uni-essen.de>
Date: Tue, 21 Nov 2000 14:36:57 +0100 (CET)

Hi Zoran,

we have an mailing list set up for XOTcl ... I'll cross-post this
mail to the list, because it might be of general interest. Perhaps you
like to CC general questions/comments to the list and/or subscribe:

  http://wi.wu-wien.ac.at/mailman/listinfo/xotcl

We will announce the list publicly with 0.83 ...


here, is some example code that shows two ways how to retrieve all
instances, classes, and metaclasses in the system:

--Uwe


###################################################################

# set up some classes for testing

#
# some meta classes
#
Class Meta -superclass Class
Class Meta2 -superclass Meta
Class Meta3 -superclass Meta2
#
# some classes
#
Class X
Class Y
Meta Z
Meta2 A
Meta2 B
#
# some objs
#
X x
Object o
Y y1
Y y1
A a1
A a2

#
# if you only use the global namespace it is quite simple to retrieve
# the instances, like:
# (you can also traverse the namespaces ... but then the
# variant down below is more elegant)
set objects ""
foreach c [info commands] {
  if {[Object isobject $c]} {lappend objects $c}
}
puts "Global Objects are: $objects"



#
# we can also go along the class hierarchy
#
# we define a separate class that computes the instances (could
# also be instprocs on Object ... but then we won't have the ability
# to use the code on a subclass)
#

Class InstanceRetrieval

InstanceRetrieval instproc getAllSubClasses cl {
    set result ""
    set sc [$cl info subclass]
    foreach c $sc {
        lappend result $c
        set result [concat $result [[self] getAllSubClasses $c]]
    }
    return $result
}

InstanceRetrieval instproc getAllInstances {} {
    set result ""
    # get all subclasses of this class
    set subclasses [[self] getAllSubClasses [self]]
    # now get the instances of every subclass
    foreach sc $subclasses {
        set result [concat $result [$sc info instances]]
    }
    return $result
}

# now we register that class on Object as a mixin
# -> we can all instances of the object class (including the
# nested objects

Object mixinappend InstanceRetrieval
set allObjs [Object getAllInstances]
puts "All objects are: $allObjs"

#
# with isclass and ismetaclass we can additionally sort out the
# classes and metaclasses
#

foreach o $allObjs {
    if {[Object isclass $o]} {
        lappend classes $o
        if {[Object ismetaclass $o]} {lappend metaclasses $o}
    }
}

puts "All classes are: $classes"
puts "All metaclasses are: $metaclasses"

###################################################################




>>>>> "ZV" == Zoran Vasiljevic <zoran_at_munich.com> writes:

ZV> Hi Gustaf and Uwe !
ZV> First of all, many, many thanks for your time and patience.
ZV> I think I'm getting the (XOTcl) picture slowly.

ZV> I could need a helping hand again, though, 'cause I'm stuck
ZV> a little bit.

ZV> -------
ZV> Given an initialized interpreter I would like to generate
ZV> a script to re-make *all* classes/objects found there.
ZV> But how to get them ? I would not like to resort to
ZV> "namespace is a object/class" assumption....

ZV> Consider this:

ZV> % Class TC
ZV> % TC tobj

ZV> Now get all defined classes ...

ZV> % Class info instances
ZV> ::Class::Parameter ::Class ::Object ::Object::CopyHandler ::TC

ZV> Fine. The "TC" is there.

ZV> % Object info instances
ZV> ::_at_

ZV> Where is my "tobj" ? What am I doing wrong ?
ZV> I cannot find the "tobj" anywhere.

ZV> Also, If I somehow manage to properly collect all classes
ZV> (and objects) I should somehow follow the class graph,
ZV> when recreating classes, right ? Using (super/sub)class info
ZV> and traversing the class tree/graph, right ?
ZV> I think I could use some example, if you have some lying arround.

ZV> Sincerely,
ZV> Zoran Vasiljevic.


ZV> ______________________________________________
ZV> FREE Personalized Email at Mail.com
ZV> Sign up at http://www.mail.com/?sr=signup

-- 
Uwe Zdun
Specification of Software Systems, University of Essen
Phone: +49 201 81 00 332, Fax: +49 201 81 00 398
zdun_at_xotcl.org, uwe.zdun_at_uni-essen.de

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Wed, 15 Mar 2006 11:17:50 +0100

mail_at_xdobry.de schrieb:
> Hi Scott!
>
> Indeed move in XOTcl is copy+destroy and it is implemented in XOTcl itself.
>
> ...
> After I have discovered, what indeed move is, I have changed the implementation.
> I think it is a little trap in XOTcl, because many user thinks it is magic fast and do not really destory objects. Indeed it is quite expensive.
>
note, that there is no "namespace rename" command in tcl as well. Since
xotcl uses tcl namespaces, in the general case a rename command requires
to handle all references (and pointers in C) to namesspaces (including
traces,
tcl-command names, aliases, namespace imports, nested namespaces, ...),
when a namespace (with all its children) is renamed.
Therefore in general, a "namespace rename" is much more expensive than
a "command rename". note, that tcl has no "variable rename" command
as well. So, adding such a functionality would require some amount
of C hacking and quite a strong coupleing with the tcl internals.

The implementation of move as copy+destroy is a compromise between
simplicity and functionality. I can imagine cases, where one wants
to have more or less the equivalent to a copy constructor when
copy occurs and maybe something different when a move happens.
However, since all methods are equal in xotcl, it is quite simple
for a poweruser of xotcl to overload copy/move and add applicaton
specific addtional behavior to it. if one does not like the side-effects
of destroy in a move, a custom move operation can set in instance
variable "__during_move__" and query this from the destroy
method to change its behavior.

hope, this helps...

-gustaf neumann

> Artur
> _______________________________________________
> 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, 21 Dec 2000 03:11:44 +0200 (EET)

Attached to this post I have a slightly fixed version of xodoc. I did the
following corrections/additions:

- Added space between the different "sections" of class
descriptions. Ie. as in the following case:

_at_ Class Foo {
  description {blah}
  errors {foo}
}

It would just stick 'description' and 'errors' on to the same line.


- Added functionality to handle optional procedure arguments. Ie. as in
thee following case:

_at_ Foo instproc {arg1 {arg2 ""}} {}

Now it marks arg2 as optional with the standard Tcl syntax, and also
automatically specifies the default value along with the description.


- Added some special handling for the section 'errorCodes' in a
class. These error codes are the things you can give with the
[error] command to give a code to the error, so catching is
easier. Ie. the following:

_at_ Class Foo {
  description {blah}
  errorCodes {
    MyAppError {
      Used for sending errors my application specifically
      creates.
    }
  }
}


What I didn't do:

I was going to add an extension facility so that applications could
specify their own handler-objects for certain special sections. Like in
Class Foo above I might have a section {Attribute Aliases} in addition to
errorCodes (as I do). I would like to specify a AttrAliasDocHandle object,
for example, which would have the method "toHtml" (if outputting HTML)
that gets called when the section {Attribute Aliases} is encountered, with
the data passed to it as an argument. This would then return a nice HTML
table documenting my aliases.

The syntax to create an extension might be something like this:

_at_ @DocExtension Class {Attribute Aliases} AttrAliasDocHandle

I would have done this myself but it's already late (3am) and I really
desperately need to continue my real work. If anyone feels like
implementing that, then feel free... Otherwise I'll just have to get back
to it at some later time :-(

         - ---------- = = ---------//--+
         | / Kristoffer Lawson | www.fishpool.fi|.com
         +-> | setok_at_fishpool.com | - - --+------
             |-- Fishpool Creations Ltd - / |
             +-------- = - - - = --------- /~setok/

From: <h8853209_at_wu-wien.ac.at>
Date: Tue, 04 May 2004 12:44:14 +0100

More info is in attach

From: Mads Linden <ml_at_electronicfarm.com>
Date: Sat, 25 Jun 2005 12:00:22 +0200

Thanks

I guess I just have to get my head around things like that, a bit dangerous
I feel to call methods before contruct.

It would be ok if it was "procs" that worked like that insode the classs,
but not instprocs :(

Mads

-----Original Message-----
From: Kristoffer Lawson [mailto:setok_at_fishpool.com]
Sent: 25 June 2005 11:49
To: Mads Linden
Subject: Re: [Xotcl] xo beginner


On 25 Jun 2005, at 04:08, Mads Linden wrote:


> i am trying to learn XO....... so be nice :)
>

Hi, always nice to see that interest in XOTcl is growing (from a user's
point of view).


> #####
>
> Class Project
>
> Project instproc init {} {
> puts "INIT"
> }
>
> Project instproc getarg {value} {
> puts "getarg : $value"
> }
>
>
> Project .p -getarg 1
>
> #####
>
> Since xotcl allow method call in the same line as the creation of the
> instance I offcourse tried that out ==
>
> This gives me
>
>
>
>>> getarg : 1
>>> INIT
>>>
>>>
>
> I expected it to call the constructor (init) before method.
>

Actually the -dash methods are called first. There was actually a reason for
this, but I cannot quite remember what it was. Something to do with wanting
to initialise things before the actual init method. If you want to be sure
to call init first do:

Project .p -init -getarg 1

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

From: Marc Spitzer <mspitze1_at_optonline.net>
Date: Sun, 30 Nov 2003 11:30:15 -0500

On Sun, 30 Nov 2003 10:14:12 +0100
Gustaf Neumann <neumann_at_wu-wien.ac.at> wrote:

>
> Hi Marc,
>
> to honor --with-tkinclude, a special rule in unix/Makefile.in was
> needed for the compilation of tkAppInit, which is in turn needed for
> building xowish, which is deprecated and only in the distro to keep
> our "old" users happy. The recommended loading of xotcl is to use:
>
> package req XOTcl
> namespace import ::xotcl::*
>
> This is for the tclsh and for wish the same.

That solves my problem.

Thanks

marc


>
> My guess is that your interest was not in particular to compile
> xowish, but to check, whether everything compiles correctly on your
> system, and therefore you used --with-all in confiigure. Maybe we
> should overthink the setup of this rule in future versions.
>
> anyhow, i have imply updated the xotcl-1.1.0 tar file on
> www.xotcl.org since this build change does not effect most users.
>
> all the best
> -gustaf
>
> PS: from today noon until monday evening, i'll be in germany in a
> meeting
> with no or bad internet access.
>
> On Sunday 30 November 2003 02:42, Marc Spitzer wrote:
> > I have attached a log of my build, just incase I am missing
> > something. The --with-tkinclude=/usr/local/include/tk8.4/generic
> > from configure does not seem to be getting to the CC line as a -I
> > directive:
> >
> > cc -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\"
> > -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DVERSION=\"1.1\"
> > -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1
> > -DHAVE_STDLIB_H=1-DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1
> > -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1-DHAVE_UNISTD_H=1
> > -DCOMPILE_XOTCL_STUBS=1
> > -DTCL_SHLIB_EXT=\".so\"-I/usr/ports/lang/tcl84/work/tcl8.4.4/generi
> > c-I/usr/ports/lang/tcl84/work/tcl8.4.4/unix -I"./../generic"
> > -I"./../unix"-I/usr/local/include/tcl8.4/generic -O -fPIC -g
> > -DXOTCLVERSION=\"1.1\"-DXOTCLPATCHLEVEL=\".0\" -c `echo
> > ../unix/tkAppInit.c` -o o/tkAppInit.o../unix/tkAppInit.c:19: tk.h:
> > No such file or directory gmake: *** [o/tkAppInit.o] Error 1
> >
> > Thanks
> >
> > marc
>
> --
> Univ.Prof. Dr.Gustaf Neumann
> Abteilung für Wirtschaftsinformatik
> WU-Wien, Augasse 2-6, 1090 Wien
> _______________________________________________
> Xotcl mailing list - Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl

From: Robert <sigzero_at_gmail.com>
Date: Tue, 26 Sep 2006 22:55:20 -0400

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

Robert