Weblog Page

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Wed, 16 Aug 2006 11:06:18 +0200

Scott Gargash schrieb:
>
>
> Unfortunately, the default behavior is not sufficient. My example was
> simplified from my real problem. In the real problem, I have
> essentially a directed graph of objects that I serialize out upon
> destruction. Since the default behavior doesn't destroy objects in a
> defined order, when the root object goes to serialize out, some nodes
> that it needs to serialize may already be destroyed. This is
> undesireable.
>
one has to differantiate here more in detail. There is a defined order,
otherwise xotcl would
horribly crash (referencing freed memory).
The shutdown happens in two rounds.

a) The first round is the "soft" destroy, were all destroy methods are
called. In this state calling destroy
    does not make a physical destruction, no memory is freed. First
destroy is called for objects (making
    sure it is not called twice, then for all classes. The more detailed
order depends on the hash tables and
    is therefore undefined.
b) after this, gobal xotcl-allocated variables and structures are freed.
    the second round is the phyiscal destroy, where memory is actually
freed.
    first all objects not being classes and not having children are
deleted until
    none of these exist. Then classes except ::xotcl::Object and
::xotcl::Class
    are freed, that have no subclasses, no instances (for metaclasses),
and
    no children are deleted (in multiple rounds). finally
::xotcl::Object and
    ::xotcl::Class are freed. Finally the global namespaces are freed
and the
    destruction in is finished.

Before (a) and (b) the user exit handler is called. there a user is free
to define his deletion logic.
>
>
> So I inserted my own exitHandler and that works in a single thread,
> but when I have multiple threads, things get confused.
>
You have not told us, what "confused" means (other than: "i get an
error") since your
example works for me.

The shutown is differnt in the threaded case, since also tcl has and needs
different mechanisms here. in the single threaded case is only one exit
handler,
in the multi threaded case is as well an thread exit handler (in xotcl,
all threads
can have their own exit handler, defined by setExitHandler).

If you have multiple threads, and you want to control the order, in
which the threads exit
(and in which their exit handlers are called), you have to do this on
your own
as well (not using "exit", but your own shutdown command). Be aware of,
that tcl tries to shutdown your threads on exit as well.

>
> BTW, the failure was on WinXP. Given that the behavior is different
> on different platforms, it does seem like I've treaded into undefined
> behavior. Is there any way to wrangle it back into something defined?
>
i am not using windows. it is certainly possible that there is a
different behavior
on thread exit, but first one has to understand, what the problem in
your case is....

best regards
-gustaf neumann
>
>
> Scott
>

From: Aamer Akhter <aakhter_at_gmail.com>
Date: Tue, 27 Jul 2004 13:43:46 -0400

On Tue, 27 Jul 2004 13:18:23 -0400, Schofield, Bryan (GE
Transportation) <bryan.schofield_at_trans.ge.com> wrote:
> I had that problem at as well. I didn't care to make xowish or xotclsh, I ended up commenting portions of the make file out to get it to work. Specifically, I commented out "binaries", "install", and part of "libraries" target.

after staring it at it with several people it looks like the problem
is a bash parsing one for this piece of code:

 dir in $(subdirs) ; do \

the problem is that if $(subdirs) is "" then bash will try to parse
"dir in; do " , which is of course wrong. the if statement doens't
actually protect you from this (it's a parsing problem, not an
execution time one)

so i just changed $(subdirs) to ". $(subdir)" and that seems to make
bash happy-- it's not going to run it anyway.

>
> I don't mean to speak for Gustaf, but maybe give this version a try:
> http://media.wu-wien.ac.at/download/xotcl-1.2.1.tar.gz
>
> I don't think it's quite ready for primetime, since Gustaf & Co. are adding a few enhancements. But I think all that remains is documentation. I've been using it & testing out the new features for a about 2 months and consider it stable. That version also has a better build & configuration system and compiles with out complaint fine for me (which is the only reason I'm mentioning it, it was a painful to get the last publicly released version to compile on Solaris). I'm sure the XOTcl guys will correct me if I'm wrong.
>
> I noticed you posted a question on the IncrTcl mailing list earlier today about "unknown" handlers. I think you'll find that XOTcl's unknown handler is fantastic. I've used IncrTcl extensively, but over the last 6 months or so I've began using XOTcl instead. I now prefer XOTcl greatly to IncrTcl. After using it, I feel so constrained with IncrTcl by having to fully define my classes, and thus my object behavior, a head of time. The flexibility of XOTcl is phenomenal.

I agree. I went thru the manual last night, and was quite impressed
with options and features avaliable. It really is a shame that xotcl
isn't more widely distributed. One thing that popped into my mind was
how to do private variables and methods (i think this can be done via
the filters, but i haven't exactly figured them out yet)

Thank-you to the developers for maintianing xotcl.

>
> -- bryan
>
>
>
>
> > -----Original Message-----
> > From: xotcl-admin_at_alice.wu-wien.ac.at
> > [mailto:xotcl-admin_at_alice.wu-wien.ac.at]On Behalf Of Aamer Akhter
> > Sent: Tuesday, July 27, 2004 12:42 PM
> > To: xotcl_at_alice.wu-wien.ac.at
> > Subject: [Xotcl] build problem on solaris
> >
> >
> > Folks,
> >
> > I'm having a a makefile problem on solaris (the linux build went fine)
> >
> > gcc -pipe -shared -o libxotcl1.2.so so/xotcl.o so/xotclError.o
> > so/xotclMetaData.o so/xotclObjectData.o so/xotclProfile.o
> > so/xotclTrace.o so/xotclUtil.o so/xotclShadow.o so/xotclCompile.o
> > so/aolstub.o so/xotclStubInit.o
> > -L/auto/nsite-mmpls/users/aakhter/ats4.0/lib -ltclstub8.4
> > : libxotcl1.2.so
> > /bin/bash: -c: line 1: syntax error near unexpected token `;'
> > /bin/bash: -c: line 1: `if test ! "x" = "x" ; then for dir in ; do
> > if (cd $dir; make binaries) ; then true ; else exit 1 ; fi ; done;
> > fi;'
> >
> > which is (with make -d):
> >
> > Finished prerequisites of target file `binaries'.
> > Must remake target `binaries'.
> > Putting child 0x00068080 (binaries) PID 17840 on the chain.
> > Live child 0x00068080 (binaries) PID 17840
> > /bin/bash: -c: line 1: syntax error near unexpected token `;'
> > /bin/bash: -c: line 1: `if test ! "x" = "x" ; then for dir in ; do
> > if (cd $dir; make binaries) ; then true ; else exit 1 ; fi ; done;
> > fi;'
> >
> > makefile:
> >
> > binaries: $(BINARIES) $(XOTCLSH) $(XOWISH) pkgIndex.tcl
> > _at_if test ! "x$(subdirs)" = "x" ; then \
> > for dir in $(subdirs) ; do \
> > if (cd $$dir; $(MAKE) $_at_) ; then true ; else exit 1 ; fi ; \
> > done; fi;
> >
> >
> > has anybody run into this problem already?
> >
> > --
> > Aamer Akhter / aakhter_at_gmail.com
> > _______________________________________________
> > Xotcl mailing list - Xotcl_at_alice.wu-wien.ac.at
> > http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
> >
>

-- 
Aamer Akhter / aakhter_at_gmail.com

From: Mads Linden <ml_at_electronicfarm.com>
Date: Sat, 25 Jun 2005 03:08:40 +0200

hi all
 
i am trying to learn XO....... so be nice :)
 
the question:
 

#####

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.



Regards

Mads

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Thu, 19 Aug 2004 01:33:51 +0200

> I have to learn how to make separate build dirs work, or what the
> prevailing standard is, and make that work, so that people can do

 Hi Jim, yes, this is still an issue (see below), it effects only
 people configuring the subdirs (e.g. via --with-all or --with-actiweb).
 It is not an issue, if the default configuration is used.

> ...
> I would like to ask embedders of xotcl, if there is a chance you'd be
> able to use a tclsh where you do the package require of xotcl and
> other packages you need, rather than use xotclsh and xowish... it's
> been suggested that this might be the more portable approach, but
> I want to ask all of the embedders first before I ask Gustaf whether
> it'd be ok to deprecate them in favor of having the embedders prepare
> a plain tclsh.

Jim, xotclsh and xowish are already deprecated and are not
build by default. Techically there is no need to use xotclsh at all.
Note also, that xotclsh is a tclsh doing a "package req XOTcl" +
"namespace import" from the C-level. This means that if package require
does not work from a tclsh (e.g. due to paths), xotclsh would not
work as well. xotclsh is not used in the build/test/install cycle,
so i don't see the connection the subdir/build issue.
What do you mean by "preparing" a plain tclsh?

i have sent you with a separate mail a slightly updated version
of xotcl, where
   mkdir build
   cd build
   ../configure --with-all
   make
   make test
   make install
works. It is still not perfect, since the binaries of the configured subdirs
(sdbm/gdbm/expat) are still built in the source tree, not in the build tree.
maybe you have an idea how to get these into the build tree as well.

best regards
-gustaf
PS: i'll be on vacation for 14 days starting in the mid of next week.

-- 
Univ.Prof. Dr.Gustaf Neumann
Abteilung für Wirtschaftsinformatik und Neue Medien
Wirtschaftsuniversität Wien, Augasse 2-6, 1090 Wien

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Tue, 13 Dec 2005 12:38:47 +0100

Dear Florian,

whatever you define as parameter for a class C is defined as a method
for Class C. This method can be only be specialized by some other
classes. This is
the same for all methods, therefore there is no exception for parameters. My
feeling was, that your misconeption was that a parameter is something
magic (e.g. not a method), but this is not the case.

best regards
-gustaf neumann

Murr, Florian schrieb:

>Thanks a lot for your thorough explanation!
>
>I tend to think in "invariants" and I memorized that having a method
>specialized this way
>
> C instproc someMethod {args} { next }
>
> should leave my program invariant with respect to functionality.
>
>But this obviously has the exception of getter/setter methods.
>
>Regards,
> - Florian
>
>
>

From: <MichaelL_at_frogware.com>
Date: Mon, 12 May 2003 10:47:59 -0400

This is an item for the suggestion box.

XOTcl uses a number of collections: filters, mixins, children, etc. It may
perhaps make sense to introduce a real collection class or abstraction,
and implement those concepts directly *as* collections. Reading through a
lot of XOTcl code--eg, xoRBAC--you can see that the same themes appear
over and over again, such as checking to see if an object is already mixed
in. Right now "append"--and only "append"--is built into the list of
supplied Object methods (eg, "filterappend"). Rather than flooding Object
with more and more collection management procs it might be better to
expose the filter collection as an object that supports operations
directly (like "append" and "contains" and "remove").

This is more like a 2.0 change--and presupposes that there will be a 2.0.
:-)

From: <mail_at_xdobry.de>
Date: Mon, 04 Dec 2006 12:15:24 +0100

About complexity of XOTcl.

Many of XOTcl features are only interesting for special scenarios such as OO-frameworks or wrapping techniques.

For OO-Beginners these XOTcl-Features might be not interesting:
- method forwarding
- filters
- meta classes
- slots
- mixins
- assertions, pre/post condition
- non positional arguments
- object aggregation
I have ordered the features from most advenced to quite practical
in my opionion.

Although I have written many lines of XOTcl code I have rare used filters (only for debugging and IDE features) and never method forwarding.
I have also never implemented my own meta class.
Mixins can be practical to avoid big class hierarchies or in some special object lifecycle scenarios.
But I need some times to figure out when to use mixins.
Object aggregation is very usefull.

Also antother OO-Languages have some such specials features.
Examples for Java:
- anonym classes
- generics
- dynamic proxy
- reflection
- interfaces
- abstract classes

So you can use successful XOTcl without understanding some of its features.
The practical advice is to start with XOTcl and learn some additional features only If you feel you need it.

I think that it is historical reason that in XOTcl tutorials there is strong focus on new features of OO.
The authors wanted to describe new innovations for known problems in OO.
But these problems of OO are apparent only in bigger OO-Project and can be understood only by experienced OO-Programmers.
XOTcl has academic background, so the innovations are quite important.
But in comparison with another academic project it is practical usable for industry needs and standards.

On the other hand features like filters and mixins can be very useful to modify or extend system without to complete redesign it.
It helps to modify the system dynamically.
But you will never have such problems at the beginning of the project or by small projects.
So you will probably appreciate XOTcl in cases when other OO-Systems will let you down.

I use many OO-languages professional like: Java, C++, C# but some additional features of XOTcl, which I miss by Java and C#, and some base characteristic of Tcl are
for me perhaps the only reason why I still use XOTcl/Tcl.

Artur Trzewik

From: Catherine Letondal <letondal_at_pasteur.fr>
Date: Sun, 23 Sep 2001 12:08:50 +0200

Hi,

I guess there are interesting applications of XOtcl filters and
mixins to aspect oriented programming? Are there any
publications or work on this subject?

Thanks,

-- 
Catherine Letondal -- Pasteur Institute Computing Center

From: Zoran Vasiljevic <zoran_at_archiware.com>
Date: Mon, 4 Mar 2002 18:21:42 +0100

On Monday 04 March 2002 14:08, Gustaf Neumann wrote:

> From the "volatile" front: we have now more-or-less Zoran

Smile !

> suggestion implemented in C. Actually there is no need
> in general for using tcl-variables to implement volatile
> objects (we could handle this on a pop of stack frames),
> but at least for pure tcl-procs, var traces are the simplest
> implementation. The current implementation (purely in C)

It is not clear: does the C implementation use internal stack
for garbage collection or the Tcl-trace variable mechansim?
It is important to know when doing (or not doing!) such
constructs:

Class foo
foo instproc test args {}

[foo new -volatile] test ; # object leak ?

In case of volatile implementation with var traces,
one should do:

set bar [foo new -volatile]
$bar test
 
to be sure that when "bar" is unset, the object goes away.

So, which way is it?


Cheer's
Zoran

From: Victor Mayevski <vitick_at_gmail.com>
Date: Wed, 25 Jul 2012 07:48:45 -0700

Hello Gustaff,

What is the reason for following error/behavior:

ClassX create c1; #ClassX has several subclasses
c1 delete method m1
Error: ::c1: cannot delete object specific method m1

I get a similar error for "c1 delete property p1"
Why am I not able to delete object specific methods/properties?

Thanks