Weblog Page

From: Murr, Florian <florian.murr_at_siemens.com>
Date: Fri, 13 Oct 2006 10:34:32 +0200

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

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Thu, 05 Aug 2010 11:11:59 +0200

Am 05.08.10 10:38, schrieb Kristoffer Lawson:
> Yes, this is also true for setting a parameter:
>
> Car new -doors $amount
>
> If $amount contains a dash, it'll do a method call.
>
Well, "contains" is too strong,
"starts with a dash followed by alpha" is precise.

With XOTcl 2.0 (as now in git) the following cases work as expected

    package req XOTcl 2.0; namespace import ::xotcl::*

    Class Car -parameter {{doors 4}}
    Car c1 -doors -2
    Car c2 -doors a-b
    Car c3 -doors -b

with XOTcl 0|1.*, case "c3" was leading to the problem.

With XOTcl 2.0, one would most probably use

    Class Car -parameter {{doors:integer 4}}
    Car c1 -doors -2
    Car c2 -doors a-b

to trigger an error on "c2", or better define your own checker "posint"

     Class Car -parameter {{doors:posint 4}}

to get already errors on c1.

-gustaf

From: Zoran Vasiljevic <zv_at_archiware.com>
Date: Tue, 27 Sep 2005 10:18:18 +0200

Am 26.09.2005 um 19:40 schrieb Jeff Hobbs:

>
> TIP #257: Object Orientation for Tcl
> http://www.tcl.tk/cgi-bin/tct/tip/257
>

First of all, this is a step in the right direction which
should have been done *years* ago already. Many thanks to
the creators of the TIP for their courage to open this
can of worms again. I believe there will be many kudos
*and* resistance from the user base of (all) OO systems
luring arround in the Tcl community.

We are using XOTcl in a commercial MT-app already 5 years
and, personally, I doubt that a (new) piece of software
can reach the stability, performance and functionality
of XOTcl in a reasonable time. Hey, since the proposal
is based on XOTcl, why just not adopt XOTcl codebase?
This would save lots of time and effort. I do understand
that from syntactical point of view, some XOTcl pieces
may/should be ommited or changed to satisfy C#/C++/Java
folks, allright, but I believe this is easier done by
taking the XOTCl codebase and tweak it, rather to write
all from scratch.

I have skipped thru the TIP in fast forward mode (more
detailed sweep is on the todo list) and one things jumped
into my face:

    Class::volatile: This feature is ommited

WHY FOR HEAVENS SAKE?

Seriously, the auto-garbage collection of objects is *crucial*
for any serious use. It saves you awkward and error-prone
constructs. Anybody doing any serious OO programming knows
how complex the garbage-collection can be. I cannot imagine
to live w/o this feature.

So, as said, more to come as I get more time to read the TIP
in depth.

Cheers
Zoran

From: <michael.heca_at_email.cz>
Date: Fri, 03 Sep 2004 12:49:30 +0200

Start from http://wiki.tcl.tk/11431

Use modified config.vc.

Please add $(INSTALLDIR) to $(TCLSH) .\installWin.tcl call in Makefile.vc


Michael Heca
 

From: Nico L'INSALATA (UniPI) <"Nico>
Date: Tue, 03 Jul 2007 16:48:44 +0200

Hi everybody,
my name is Nico and I'm new to XOTcl.

After spending few weeks in understanding the basic concepts of the
language, I decided to use it to model one component of the software I'm
developing as part of my PhD project (basically, configuration of
complex digital hardware macrocells). I've been attracted by XOTcl due
to its "aspect oriented" features which are today very common in the
hardware design industry.

I need some clarifications regarding the use of Class parameters and
Class slots (I will refer to v.1.5.2 of the XOTcl tutorial).
Parameters are used throughout the introduction of the tutorial to model
Class attributes, then slots are introduced in a later section. Are
slots and parameters actually the same thing? Is there some reason to
prefer one over the other?

Anyway, I've started using slots and I got lost using the -initcmd feature.
This is a "simplified" version of the code that "doesn't work" (i.e.
I'm not able to make it work :-) )

Class my_class \
-slots {
    Attribute one -type integer -default { 0 }
    Attribute two -type integer -default { 0 }
   Attribute three -type integer -initcmd {
       if { [my one] > [my two]} {
       set _ 100
      } else {
       set _ 101010
      }
   }
  }

The code doesn't work (of course!!) since [self] within initcmd has
value "::my_class::slot::three". So, the question is: how do I refer to
other attributes of the same class from within -initcmd { }?

And secondarily, is it possible to associate -initcmd with an instproc
of the class in which the attribute is being defined? e.g. an instproc
of Class my_class

Note that, to ensure things work properly, when instances of my_class
are created both attributes "one" and "two" are initialized, while
attribute "three" will also be refereed in a subsequent part of the
script. This behavior is bizarre and potentially unsafe, but is dictated
by another software components over which I have no control.

Thank you very much for your attention!

Nico

From: Jamie Rasmussen <jrasmuss_at_sbcglobal.net>
Date: Wed, 25 Oct 2006 00:44:42 -0700

Hello,
   I have a binary installer of AOLserver 4.5 for Win32, and I'd like to
add XOTcl 1.5.2 to it, since I know OpenACS 5.3 will require it. While
running some load tests on the binaries I built I saw a crash in
XOTclAddIMethod. I'm not worried about that crash yet, since I think it
might have been caused by a bad interaction with the nstclprof module.
   But to investigate further, I tried to compile a debug version of
XOTcl, and I've run into some problems. The compiler is Visual Studio
6, and the command line I was using is:
nmake /f Makefile.vc DEBUG=1
   * I am trying to compile against TCL 8.4.14, which was compiled with
the threads and thrdalloc options. The first problem I had was with
the values of TCLIMPLIB and TCLSH in Makefile.vc, which didn't reflect
that the threaded build includes a 't' in the filename before $(DBGX)
for the .lib and tclsh. This applies to
\library\store\XOTclSdbm\Makefile.vc too.
   * The -WX compiler option (error instead of warning) is specified for
DEBUG=1, so compilation aborts because of this warning:
..\generic\xotcl.c(5271) : warning C4018: '==' : signed/unsigned mismatch.
   * I also noticed XOTCL_RELEASE_LEVEL=.0 and not .2 - is that intentional?
Any suggestions? I'm new to XOTcl, but I already like it - thanks.

Jamie

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Sat, 29 Jan 2005 22:33:27 +0200 (EET)

This feature of the [next] command is not documented in the reference
guide. Thought it'd be good just to mention it :-)

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

From: Jeff Hobbs <jeffh_at_activestate.com>
Date: Tue, 28 Nov 2006 18:41:26 -0800

ActiveState is pleased to announce the release of ActiveTcl 8.4.14.0
and 8.5.0.0 Beta 6, the quality-assured distribution of Tcl, available
for AIX, HP-UX, Linux, Mac OS X, Solaris and Windows.

New in ActiveTcl 8.4.14.0:

   * Mac OS X distribution is now a Universal binary
   * Tcl/Tk core updated to 8.4.14
   * Teacup client of the TEApot repository system added
   * Updated:
     - OraTcl 4.4
     - Sqlite 3.3.8
     - Tcllib 1.9
     - Tile 0.7.8
     - Tklib 0.4.1
     - XOTcl 1.5.3
     - Bwidget 1.8
     - Thread 2.6.5 (Windows, OS X only)

New in ActiveTcl 8.5.0.0 Beta 6:

   * Mac OS X distribution is now a Universal binary
   * Tcl/Tk core updated to 8.5a5
   * Teacup client of the TEApot repository system added

To download ActiveTcl 8.4.14.0, click here:
        http://www.ActiveState.com/ActiveTcl/download

For more information or to download the 8.5 beta, click here:
        http://www.ActiveState.com/ActiveTcl

Enjoy!

The Tcl Team, ActiveState
http://www.ActiveState.com

From: Uwe Zdun <uwe.zdun_at_wu-wien.ac.at>
Date: Mon, 06 Sep 2004 15:53:16 +0200

Hi Kristoffer,

I'm not pretty sure, what you want to reach here. The "eval" method
provided by XOTcl does nothing
else then a Tcl eval in the context of the object's namespace. This is
not meant for evaluating
methods, though it accidently works for local methods (procs), because
they are defined
in the same namespace. In the example below, I would define the "
commands" such as 'format', 'short', 'object'
as objects. Then you can use Tcl's eval to send messages to these
objects, and define the first argument
as method or use "unknown".

Uwe

Kristoffer Lawson wrote:

>
> It states that object-local variables are accessible as normal Tcl
> variables inside the script, but what about methods? I noticed the
> following:
>
> % package require XOTcl
> 1.1
> ::ob
> % ob proc pomous {} {puts pomous}
> % ob eval pomous
> pomous
> % xotcl::Class JOu
> ::JOu
> % JOu instproc uoah {} {puts jeah}
> % JOu ob
> ::ob
> % ob eval uoah
> invalid command name "uoah"
>
> Is that guaranteed to work at all? Is there any proper way to get what
> I want to do?
>
> The reason I'm doing this is because I'm implementing a type of binary
> reading command which looks something like this:
>
> buynary::scan $clusterDat {
> option endian little
>
> format {
> object root {
> short objNum
> short $objNum objIDs
> }
>
> object * children {
> short 3 cellID
>
> short addObjNum
> short $addObjNum addObjIDs
>
> short rmObjNum
> short $rmObjNum rmObjIDs
> }
> }
> }
>
> It uses XOTcl to build a representation of the binary data as objects.
> I made a version which parses the format manually, but for performance
> reasons I'd like Tcl to do that. Ie. to have, in a particular context,
> commands such as 'format', 'short', 'object' etc. Then I could just
> [eval] the whole nonsense and get all the performance benefits that
> has to offer.
>
> One could always do this using namespaces, but that would be really
> annoying as I've started off with XOTcl for this.
>
> / http://www.fishpool.com/~setok/
> _______________________________________________
> Xotcl mailing list - Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl

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

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Mon, 11 Jun 2001 17:03:55 +0200

 Dear XOtcl community,

 there was a small glitch in 0.85p1. The modification date
 of predefined.xotcl was newer than the date of predefined.h
 due to a checkin in the version management system. Therefore
 "make" tried to rebuild predefined.h using the xotclsh from
 xotcl in the source tree. If the tar archive is freshly
 expanded, there is no xotclsh, therefor make stopped with
 an error message.

 The simplest correction would have been "toch src/predefined.h".

 I have fixed the tarfile of 0.85p1 on friday such it contains
 reasonable modification times...

 sorry for the unconvenience
-gustaf