Weblog Page

From: Edmond Ho <edmondho_at_gmail.com>
Date: Mon, 10 Mar 2008 13:06:12 -0400

Hello Gustaf,

Thanks for your reply!

The recommended way to check, if an object is of a certain
> type (is a direct/indirect instance of a certain class) is to
> use "istype".
>

I replaced all of my calls to "Object info class ?pattern?" to "Object
istype ?pattern?" and it works well. Out of curiosity, is the "istype"
method new to 1.6.0?


The old interface matches only with the
> superclass elements, when pattern is specified.
> There are essentially two options to proceed:
>
> (a) "info class ?pattern?" could be fixed to match
> with the current class and the superclasses, but then
> it should return always empty, when the pattern
> does not match, as it is now in accordance to
> other cases, where ?pattern? is used.
>
> (b) It is as well possible to remove the ?pattern?
> argument from "info class", since there is as well
> istype. Note that there is as well
> "info precedence ?pattern?", which returns the
> resolution order including mixins and superclasses.
>
> approach (a) makes it easy to query the classes either
> with or without mixins, but to get the full list,
> one should use "[f info class] info superclass -closure",
> or we implement as well a "info class -closure".
>
> Or in the case (b) "info precedence" could get
> an option to list only intrinsic classes (classes
> which are no mixins). One can use a single
> method to get a full or partial list, and one can
> use ?pattern? to filter the list in a uniform way.
>
> Opinions?


To me, option (b) seems clearer. Type checking is simplified to the use of
"istype", while "info" is focused on more advanced introspection. However,
I'm new to XOTcl, so I may not be thinking ahead to interaction with the
advanced features. I'm sure you guys will make the best decision!

The only thing I'll ask for here is the updated documentation on the
website. I also think that there should be documentation for each major
version of XOTcl on the website, so that it's clearer as what the
differences are between versions. Just my two cents.

Thanks again!

Cheers,
Edmond

From: Michael Schlenker <schlenker_at_isn-oldenburg.de>
Date: Thu, 20 Jul 2006 11:16:29 +0200

Gustaf Neumann schrieb:
> Bernd,
>
> to be sure, i just built xotcl 1.4.0 against 8.4.13, and it worked
> without a glitch.
> Can it be that configure picks up a wrong version of tcl? The function
> TclIncrVar2
> has its prototype in tclIntDecls.h, which does not seem to be used in
> your case
> (... implicit declaration ...)
>
> To be sure, use the switches like in:
>
> http://www.openacs.org/xowiki/pages/en/xotcl-core#install
>
> if this does not help, what is your build environment (OS and cc)?

I saw the same error when compiling XOTcl 1.4 against Tcl 8.5 from cvs
head, where TclIncrVar2 is commented out in the internal stubs table for
tclIntDecls.h.
(on SUSE 10.1 x86-64)

So should XOTcl compile against both 8.4 and 8.5?

Michael

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Tue, 19 Dec 2000 18:55:27 +0200 (EET)

On Tue, 19 Dec 2000 uwe.zdun_at_uni-essen.de wrote:

> we could also merge components that are split across files into one
> documentation file. I'm not sure which solution is the best one ...
> what do you think?

I think the best behaviour would be a combination of the two given
possibilities:

Each code file does get its own documentation file, but there is one
package documentation file that lists which files are part of the
packages. This document file would then link to the per-file document
files.

> KL> On another issue we have made Debian packages of XOTcl (0.82, but 0.83 is
> KL> on the way) if someone is interested.. They're not extensively tested but
> KL> they seem to work on the machines here. Probably candidates for merging
> KL> into the official Debian system at some later time.
>
> great! if you like to maintain Debian packages & have a web page for
> them, we can link this page with the XOTcl download page?

Yeah, we should still test them on a clean machine and if that works
then we can stick them up somewhere. I'll get back to you once we've
done that. There shouldn't be any major problems anyway. I just
did a "dpkg -i" for the 0.83 package and except for a minor issue with
pkgIndex.tcl it seems to be working.

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

From: Luc Rasson <luc_rasson_at_yahoo.com>
Date: Mon, 17 Mar 2008 07:34:26 -0700 (PDT)

Thanks for your responses ! Maybe I will prospect in direction of CLIPS + TclCLIPS ...
 
 In response to Mark: Unfortunately i'm quite new in XOTcl and really new to rules engines, RETE and so on ... My goal was to study them using Tcl/XOTcl (better I think ;) that I really prefer to java for quick development/tests/scripting (and many other good reasons ;) so hmm no ... I don't think I will plan to write an implementation of the RETE algorithm in XOTcl in a next future ... ;)
 
 Regards,
 Luc Rasson


Andreas Kupries <andreask_at_activestate.com> wrote: http://wiki.tcl.tk/8365
 Not for Xotcl, but general links and info. Better than nothing I guess.
 --
        Andreas Kupries <andreask_at_ActiveState.com>
         Developer _at_ http://www.ActiveState.com
         Tel: +1 778-786-1122
  
    -----Original Message-----
From: xotcl-bounces_at_alice.wu-wien.ac.at [mailto:xotcl-bounces_at_alice.wu-wien.ac.at]On Behalf Of Luc Rasson
Sent: Friday, March 14, 2008 7:24 AM
To: xotcl_at_alice.wu-wien.ac.at
Subject: [Xotcl] rules engine ?


Dear XOTcl community,

Maybe it is not the proper mailing list but I was wondering if any -business- rules engine based on the RETE algorithm exists for XOTcl ? (as for example Drools for Java) ?

If yes, all informations/links/resources are welcome :)

Thanks & regards,
Luc Rasson
      

---------------------------------
   Looking for last minute shopping deals? Find them fast with Yahoo! Search.

       
---------------------------------
Never miss a thing. Make Yahoo your homepage.

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Thu, 27 Sep 2001 21:35:12 +0200

 Dear XOTclers,

 here are some more or less useless benchmarks, which compare XOTcl with
 OTcl, ITcl, stoop and classytcl. everything was done on the same machine
 with tcl 8.3.2 and the forthcoming XOTcl 0.9 version.

 The short summary: XOTcl compares very well with OTcl, methodcalls are
 faster than in itcl, but object creation is still slower. For the memory
 consumption for objects, XOTcl is now better than itcl or OTcl.
 The xotcl numbers are with uwe's new "namespace on demand" code,
 where the namespace is only allocated when needed (e.g. when procs or
 children are added).

 The first benchmarks are from http://www.bagley.org/~doug/shootout.
 Methcall measures the speed of the method invocation, objinst creates
 objects and does a few operations on it. The reported times are from the
 unix time command (user/system/elapsed time)

XOTcl
  methcall: 0.700u 0.000s 0:00.70 101.4% 0+0k 0+0io 282pf+0w
  objinst: 2.390u 0.010s 0:02.40 100.0% 0+0k 0+0io 282pf+0w
OTcl
  methcall: 1.370u 0.000s 0:01.36 100.7% 0+0k 0+0io 330pf+0w
  objinst: 3.090u 0.000s 0:03.09 100.0% 0+0k 0+0io 330pf+0w
itcl
  methcall: 1.060u 0.000s 0:01.06 100.0% 0+0k 0+0io 285pf+0w
  objinst: 2.010u 0.020s 0:02.03 100.0% 0+0k 0+0io 286pf+0w
stooop
  methcall: 2.350u 0.010s 0:02.57 91.8% 0+0k 0+0io 259pf+0w
  objinst: 4.780u 0.010s 0:04.81 99.5% 0+0k 0+0io 259pf+0w
classytcl
  methcall: 1.040u 0.030s 0:01.07 100.0% 0+0k 0+0io 284pf+0w
  objinst: 2.990u 0.050s 0:03.07 99.0% 0+0k 0+0io 284pf+0w


These folowing numbers compare the speed and memory consumption
for creating 10000 objects. The memory consumption is not only
the XOTclObject structure, but as well everything allocated
by Tcl as well. The test compares the memory size reported
by ps before and after the creation of 10000 objects.

        Memory per object creation time
itcl 299 33
OTcl 277 72
XOTcl 210 40
ClassyTcl 175 16
Stooop 124 96


 all the best

-gustaf neumann

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Thu, 16 Feb 2006 21:26:24 +0100

Michael, use

foreach t $tracks {
        set m [::wings::model::TrackModel new]
        $m dbRead $t
        my lappend tracks $m
}

or shorter:

foreach t $tracks {
        my lappend tracks [::wings::model::TrackModel new -dbRead $r]
}



Michael Schlenker schrieb:

>Hi all,
>
>i used the autoname instproc to create object instance names and was
>surprised that autonames can conflict.
>
>Basically i have two objects of the same class, which both get rows from
>a database and create objects for each row:
>
>Something like this:
>
>PM instproc dbRead {program_id} {
> # some things ommited
>my set tracks ""
>set tracks [::MOD select list program_tracks {track_id} program_id
>$program_id]
>foreach t $tracks {
> set m [::wings::model::TrackModel [my autoname TrackM]]
> $m dbRead $t
> my lappend tracks $m
>}
>}
>
>After i create two objects of this class, i see the TrackM autonames
>used by both objects starting from 0, basically the second object
>overwrites my autonamed objects from the first one.
>
>I fixed it by adding:
>
>my instproc autoname {args} {
>set name [next]
>while {[llength [info commands $name]]} {set name [next]}
>return $name
>}
>
>to the class, but wondered if this is expected behaviour of autonames.
>
>Michael
>
>
>
>
>
>
>
>
>
>
>
>_______________________________________________
>Xotcl mailing list
>Xotcl_at_alice.wu-wien.ac.at
>http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
>
>

From: Gustaf Neumann <neumann_at_wu.ac.at>
Date: Thu, 05 Aug 2010 19:59:30 +0200

Hi Kristoffer,

i just saw a buch of mails from you, i guess, you have answered by now
most of your questions.
Your example is perfectly fine. The reader should be aware, that you
traded in "new"
object parameterization against arguments to init, which is (in my
opinion) bad.

In the example with just "new"
> Class SafeInit
> SafeInit instproc new {args} {
> return [next [concat [list -init] $args]]
> }
>
> # Mix safer [new] and [new-with] into every class
> Class instmixin SafeInit
>
> # Test:
> Class Foo -parameter {
> {animal horse}
> }
>
you have lost all means to pass a value for "animal", except when you
pass it to init (i know "new-with" is different). One can can certainly
say, the first argument passed to init is the "animal", then default
handling is ugly (in the general case) and you have to deal with ugly
positional arguments. This technique does not scale:
What, if one inherits additional parameters from a superclass
(of Foo), or when the superclass is extended? If every argument
to init corresponds to a parameter, one has to extend the signature
of the involved init methods. Adding arguments is not really an
option when the parameters are provided via mixins, or when
the object-class and class-class relationships can changed dynamically.
Another issue is passing arguments of init to superclasses via next.
If the inits of the superclasses have different signatures, the
code becomes error prone.

My hypothesis is, that arguments for init are the poor men's
approach for object parameterization, if one has nothing better.
Arguments to contructors come more often into discussion
when porting c++ style programs to xotcl, rather than
from intrinsics needs when coding in xotcl.

Guess, you will like the next xotcl release. The new object system
has scripted initialization (quite similar to your "new-with" example)
while preserving parameterization (highly orthogonal object and
method parameterization, same code for scripted methods and
c-implemented methods).

Below is an example to define a classical stack in the new syntax...

all the best
-gustaf neumann

*Class create* Stack {

    *:method init* {} {
      *set* :things ""
    }

    *:method* push {thing} {
       *set* :things [*linsert* ${:things} 0 $thing]
       *return* $thing
    }

    *:method* pop {} {
       *set* top [*lindex* ${:things} 0]
       *set* :things [*lrange* ${:things} 1 end]
       *return* $top
    }
}

-- 
Univ.Prof. Dr. Gustaf Neumann
Institute of Information Systems and New Media
WU Vienna
Augasse 2-6, A-1090 Vienna, AUSTRIA

From: Gustaf Neumann <neumann_at_wu.ac.at>
Date: Thu, 19 May 2011 19:30:05 +0200

Am 18.05.11 19:52, schrieb Victor Mayevski:
> Hello Gustaf,
>
> NX will not compile against the latest 8.6 TCL from fossil on 32 bit
> Ubuntu. Here is the error (after "./configure"):
fixed in git. Sorry for the inconvenience, i am still primarily
developing under 8.5.

-gustaf

-- 
Univ.Prof. Dr. Gustaf Neumann
Institute of Information Systems and New Media
WU Vienna
Augasse 2-6, A-1090 Vienna, AUSTRIA

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Sun, 12 Aug 2001 19:26:54 +0300 (EEST)

On Sun, 12 Aug 2001, Zoran Vasiljevic wrote:

>
> without extra knowledge about what are
> "foo" and "bar" actually.
> The "foo" may be an instproc whereas
> the "bar" may be a per-instance proc
> or vice versa. Correct?

Yes, exactly. I also believe that kind of introspection is quite
natural for an object syste. While inheritance is naturally useful,
I still like to think of objects as independent entities. Thus to do
the above feels useful.

> I would, for example, override the "info"
> method with some custom code which tries
> the per-instance proc first and if it does
> not find any, goes to the instproc.
> This should't be difficult to implement.

It is possible to do (I think), but I'm wondering if this is an oversight
in the info functionality provided by XOTcl? It is a bit messy to first
test for if a procedure exists in the object, and then search the class,
and then any possible mixin class. The same must be done again for getting
a list of available methods. And then up to the superclasses.

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

From: Mark Janssen <mpc.janssen_at_gmail.com>
Date: Mon, 18 Sep 2006 23:26:52 +0200

After having some of list discussion with Gustaf Neumann [GN] a solution has
been found which will be part of the 1.5.1 release. Below a summary of the
discussion.

MJ:

I have had the same problem witch Tcl 8.5a4 so I don't think it is specific
to a5. I have downloaded 8.5a5 from tcl.sourceforge.net CVS.
It does seem to be a windows only problem.

I have done some more investigation and tried to compile XOTcl for myself.
Linking fails on TclIncrObjVar2 that is being used by AutonameIncr.
TclIncrObjVar2 is part of the private Tcl API and therefore not included in
the stubs dll.
Same goes for TclIncrVar2 for the <8.5 builds

This means that AutonameIncr will call a function that is not enabled in the
stubs table and that is probably why it crashes with 8.5a4/5.
Using the code below, I can compile XOTcl on windows against Tcl85a5 and
autoname seems to work as it should.

#ifdef PRE85
  valueObject = TclIncrVar2(in, XOTclGlobalObjects[XOTE_AUTONAMES], name, 1,
flgs);
#else
  valueObject = Tcl_ObjGetVar2(in, XOTclGlobalObjects[XOTE_AUTONAMES],name,
flgs);
  if (valueObject != NULL ) {
    Tcl_GetLongFromObj(in, valueObject,&autoname_counter);
    autoname_counter++;
    if (Tcl_IsShared(valueObject)) {
      valueObject = Tcl_DuplicateObj(valueObject);
    }
    Tcl_SetLongObj(valueObject,autoname_counter);
  }
#endif


GN:

many thanks! looks good ... i've as well removed the PRE85 case, use
this code always...

Regards,
Mark

On 9/18/06, Gustaf Neumann <neumann_at_wu-wien.ac.at> wrote:
>
> Dear Mark,
>
> where did you get tcl 8.5a5 from? From CVS? The website
> http://www.tcl.tk/software/tcltk/downloadnow85.html
> lists still 8.5a4.
>
> i have tested 8.5a4 with Mac Os X and Linux without these problems.
> Can you determine from the debugger, where the crash happens?
>
> -gustaf neumann
>
>
>