Weblog Page

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Wed, 27 Oct 2004 23:54:19 +0200

Dear Bryan,

> I'm afraid I found a bug that will generate an "unable to dispatch" error
if the argument list & body of an >instproc are both empty. You will notice
that as long as either contain something, it's ok. Notice the body of >"Bar
notpuke", it's just a single comment. See the code below:

we have a behavior in xotcl that we inherited from otcl: when instproc is
invoked
with an empty argument list and an empty body, this instproc is deleted.
Most probably, we should do the following:
  a) produce an error, when someone tries to delete a non.existing
proc/instproc
  b) document this behavior somewhere more visible.

-gustaf

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Wed, 26 Sep 2001 16:46:56 +0300 (EEST)

On Wed, 26 Sep 2001, Uwe Zdun wrote:

> no, in principal not ... to clarify things, what you mean is:

Well, as mentioned, I haven't given it any serious thought. I was just
speculating to myself out loud.

> - what are potential benefits to a Class

Actually this is a valid point. As classes can naturally be dynamically
added and removed, the whole AOP logic can be implemented by classes
which are just brought into the inheritance chain, and which
provide the required filters. In that case I cannot immediately see
any benefit in providing the filter as a separate object.

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

From: jim <j_marvin_at_localnet.com>
Date: Thu, 11 Dec 2003 03:47:18 -0500

i still wonder if there is a way to wrap some xotcl files into the exe
so i dont have to rely
on having the whole xotcl install on the users machine . since i am
using just the very basic
features of xotcl right now it seems that i wouldnt need all of those
files.

i have some documentation now with freewrap that explains this process
i'm wondering about
and i might be able to get it to work but dont know what xotcl files
need to get wrapped.

if you might know which files i'm after to wrap into the exe, please let
me know.

i can live with having the freewrap on the users machine so if it is
lots of explaining and
you dont think others would benefit from an explanation that is ok too.

i'm lucky i got as far as i did.

thanks,
marvin

From: Artur Trzewik <mail_at_xdobry.de>
Date: Thu, 2 Jan 2003 13:35:54 +0100

Hi!

The new version of XOTclIDE 0.36 is ready on
http://www.xdobry.de/xotclide

The Changes from last announced Version
- the often used function are available also as pop-down menus
- all menus items support context-dependent disablement
- there are tclkit and starkit package for xotclIDE for Windows (thanks to
Michael Schlenker for suggestions and help). It is possible to run XOTclIDE
from one file on Windows without any installation.
- additional small changes (see CHANGES files)

have fun with it

Artur Trzewik

PS.

I have also tried to wrap XOTcl into tclkit on linux
I have got the message by loading.
-- undefined symbol: tclIntStubsPtr
It seems that tclkit for linux was compiled in another way as standard tcl.
Any ideas how get it work?

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Mon, 3 Mar 2003 20:28:36 +0200 (EET)

On Mon, 3 Mar 2003, Gustaf Neumann wrote:

> The long answer where i am not going into details is, why
> des XOTcl need tclInt.h. In short, XOTcl needs it because
> its needs access to internal of several tcl structures that
> are not public available. Examples are the structures
> Command, Namespace, Interp. Certainly it will be possible

Command and interp too? I can understand the need for namespace, and I
still find it strange that these functions are not available publicly.
But what exactly is needed from command and interp that is not already
publicly available? OK, I guess I could delve into the source code
to find out ;-)

I was just wondering because I remember asking this before and I vaguely
remember someone saying there would be progress in that for the future.
This was back in the 0.8? days.

Anyway, just compiles 1.0 there for Ants and I noticed some changes
to the filter interfaces and whatever, but other than that no problems
yet. It's always such a joy to use XOTcl again :-)

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

From: Neil Madden <nem_at_cs.nott.ac.uk>
Date: Thu, 08 Sep 2005 13:48:49 +0100

Kristoffer Lawson wrote:
>
> That is two fine. I would prefer to have lots of related classes being
> part of the same Tcl package. For that, I have to build a stub package
> which then includes the rest in the appropriate order (or using some
> kind of sub-packaging).

You should be able to handle this with a custom pkgIndex.tcl file. I
would personally opt for the fine-grained packaging mechanism though,
for more flexibility.

Cheers,

-- Neil

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Wed, 07 Nov 2007 09:06:29 +0100

Shishir Ramam schrieb:
> Hi,
> I have a need to represent a directed graph in XoTcl.
Here are two small examples for representing graphs

In version one, edges are lists of references to nodes stored
as attributes of nodes. By specifying "-multivalued true", it
is possible to "add" or "delete" elements from the list.
By using "-type Node" the code ensures, that only instances
of Node may be added to the list, otherwise an error is thrown.

   Class Node -slots {
     Attribute connects_to -multivalued true -type Node
   }

  Node n1
  Node n2
  Node n3

  n1 connects_to add n2
  n1 connects_to add n3

  puts [n1 connects_to]

A "destroy" of a nodes automatically destroys the
edges as well, by refining the destroy method, one
could as well destroy the referenced edges (similar
to aggregation (nesting objects), but one has to be
care about cyclical edges.

Another approach is to define Edges as objects
which makes it possible to provide methods for
Edges and to store attributes in it.

   Class Edge -slots {
     Attribute from -type Node
     Attribute to -type Node
   }

   Edge e1 -from n1 -to n2
   Edge e2 -from n1 -to n3

Simarly as above, when a dynamic graph
is to be maintained, the destroy method of Node
should care about deleting references in Edges
to ensure referencial integrity.
The easiest way is to check in the destroy method
of Node all Edges with [Edge info instances], if
their "form" or "to" attributes contain the node.
One could as well build an index to make this
operation faster for large graph via a constructor
of Edge, which maintains e.g. a list of referenced
edges per node (e.g. via multivalued attribute
"references", similar to approach 1)


-gustaf neumann

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Sun, 03 Dec 2006 13:09:53 +0100

Kristoffer,

The parameter (in newer versions slots) applicable to an object are
determined
by the classes associated with the object. When one wants to serialize the
complete behavior of an object, it is necessary to serialize its classes
with
their dependencies. Since xotcl 1.5.* the old parameter interface is
replaced
by the slots (but keeping the old interface). The definitions of the
slots are
subobjects/subclasses of the class-definitions where they belong to.
Therefore, when a class is serialized via a deep operation,
all "parameter" definitions are automatically included in the serialized
code.

Have a look in xotcl*/library/serialize/Serializer.xotcl

all the best
-gustaf neumann

ps: It is quite trivial to collect all parameter definitions by looping
over the list of associated classes returned by "<obj> info heritage".
However, the parameter definition themselves are pretty useless
without the class definitions.

Kristoffer Lawson schrieb:
> I noticed [info parameters] only returns the parameters for the direct
> class object on which it is called. This actually makes sense and is
> probably the expected behaviour. I just wonder if it might be useful
> to have something in there to request all parameters belonging to a
> certain object, from all its classes and superclasses?
>
> Doable in script, of course, but might be handy for serialisation?
>
> / http://www.fishpool.com/~setok/
>
> _______________________________________________
> Xotcl mailing list
> Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl

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

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
>

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Sat, 18 Mar 2006 10:45:12 +0200

On 18 Mar 2006, at 02:48, Gustaf Neumann wrote:

> so, now we can test the aliased content. it behaves in many respects
> the same, but when it comes to refer to "self" or to namespaces
> one would notice a different behavior:

Could this kind of system be used throughout XOTcl and thus have
[self] return the alias too, instead of the actual instance? As
mentioned, this could potentially solve the issue with object movement.

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