Weblog Page

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Fri, 24 Sep 2004 16:32:42 +0300 (EEST)

On Fri, 24 Sep 2004, Kristoffer Lawson wrote:

> I'm getting a segmentation fault in relation to XOTcl. I believe the
> situation that causes it is as follows:
>
> * I have an object C which has a child M.
> * M has a fileevent callback.
> * On receiving complete message, M calls a method in C.
> * If that is an empty message, C destroys itself and closes the socket in the
> destructor (M is still in fileevent callback).

For what it's worth, here's some more information from the debug output:

Client connected.
  * init: MsgHandler init called
  * destroy: next
  * destroy: destroy MsgHandler
  * destroy: CmdHandler destroy
    * destroy: close socket
  * destroy: ClientConn destroy
  * destroy: destroy MsgHandler
  * destroy: destroy MsgHandler
  --var-- ::::readData: data: ,
  * MsgHandler readData: return
Segmentation fault

MsgHandler is the M object I was talking about, and is a child of
ClientConn and has a fileevent callback. The funny thing here is that
apparently the MsgHandler destructor gets called three times. Only one
MsgHandler object is created here (as can be seen: the init is only called
once). I guess this is something to do with the delayed destruction model,
or something?

The segmentation fault thus occurs after all the destructors have been
called and the event handler returns (the readData method of MsgHandler).

Hope this helps.

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

From: Victor Mayevski <vitick_at_gmail.com>
Date: Wed, 13 Apr 2011 16:52:45 -0700

The following (incorrect) usage will cause a crash:

*****
% o attribute {a v}
::o::a
% o::a #Incorrect usage
Segmentation fault
*****

The next one, however, does not crash:

*****
% Object create o
::o
% o attribute {a v}
::o::a
% o a # Correct usage first
v
% o::a # Incorrect usage
can't read "o::a": no such variable
    while executing
"o::a"
%
*****

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Sat, 10 Apr 2004 22:52:39 +0200

On Tuesday 06 April 2004 16:06, Jim Lynch wrote:

> > concerning (a) you are right, determining to build with AOLserver
> > from the `pwd` is not pretty, also the hardwired path to the
> > AOLserver include directory. i have changed that
> > right now. note, that making an aolserver module is only an issue
> > for AOLserver 3.*, the AOLserver 4* series does not require this
> > at all. Therefore, i have named the configure switch
> > --with-aolserver3=AOL_INCLUDE_DIR
> > where you have to specify the include directory.
>
> Suggestion, howbout the prefix dir instead? That way, any time you add
> dependendency on another kind of thing, you already planned for the
> stem dir.

 there might be cases, where the prefix of xotcl is not the same
 as the aoldirectory. On my system, i have for tcl and xotcl
 --prefix=/usr and for the aolserver (the default) /usr/local

> Besides, if this switch is to represent the include dir, it
> is misnamed, and should be named something like --with-aolserver-inc=.

well. by using --with-aolserver3 you tell xotcl, that it should build the
aolserver 3.* type c module, and you tell it at the same time, where
to find the includes. therefor i think --with-aolserver3 is still better.
 
> > well, can you be more specific, where this happens?
> > XOTcl uses in configure.in SC_PROC_TCLSH
> > and uses in all the Makefiles $TCLSH_PROG as far i can see.
> > What version of xotcl are you working with?
>
> I'm using xotcl-1.2.0; my situation is I'm building using a tcl
> I built specifically for an aolserver4. It's not the system tcl
> and its bin dir is not in my path.

 if you only want to build xotcl, you need no tclsh at all (tclsh is used
 only for doc generation, testing, installing). If you build for aolserver 4
 you need in the minimal version
          # cd xotcl-1.2.0/unix
          ./configure --enable-threads \
              --prefix=/usr/local/aolserver \
              --with-tcl=/usr/src/tcl8.4.5/unix
          # make libxotcl1.2.so
          # make install-aol
 
 everything including "make libxotcl1.2.so" should be fine without
 a tclsh. the "make install-aol" uses a tclsh to load xotcl (for a minor
 purpose, to rebuild the pkgIndex files). If you comment out
 the last line of the "libraries:" rule in unix/Makefile,
 you should be fine.
 
 -gustaf

-- 
Univ.Prof. Dr.Gustaf Neumann
Abteilung für Wirtschaftsinformatik
WU-Wien, Augasse 2-6, 1090 Wien

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Tue, 25 May 2004 10:43:07 +0200

On Monday 24 May 2004 22:57, Neil Madden wrote:
> Hello all,
>
> Small feature request: could XOTcl be made to automatically [namespace
> import] the ::xotcl::* commands into every object it creates?
> ...
> 1) Fully qualify everything - lots of xotcl::my, xotcl::self etc
> everywhere
> 2) Import xotcl namespace manually into each object namespace.
>

 or 3) do a gobal namespace import.

> 2 is better than 1, but is still a bit of a pain to remember to do, and
> I seem to remember trying it and it not always working (I could be
> wrong about that).

 (2) does not help too much, since xotcl is "namespace transparent",
 which means that it simply keeps the current namespace.
 This means that if you do a "namespace eval xxx {o m}"
 the method is evaled in the namespace xxx (and not o}.

 As a sidenote: not every xotcl obj creates a namespace, since
 tcl namspaces are quite large in memory. Namespaces are
 only created when an object has child objects or procs. You
 can measure the difference on your system (the following works
 for linux, ps might be different on other OSes)

==============================================
::xotcl::Class Mem -instproc init {} {
  set r [exec ps -xv | fgrep [pid]]
  ::xotcl::my set m [lindex $r 6]
}

set n 1000
Mem m1

set ts [time {for {set i 0} {$i<$n} {incr i} {
  ::xotcl::Object create a$i}}]
Mem m2
set mem1 [expr {([m2 set m]-[m1 set m])*1024/$n}]

set ts [time {for {set i 0} {$i<$n} {incr i} {
  ::xotcl::Object create b$i -requireNamespace}}]
Mem m3
set mem2 [expr {([m3 set m]-[m2 set m])*1024/$n}]

puts "consumption/obj without ns: $mem1, with ns: $mem2"
==============================================

> So, my feature request would be that all Objects [namespace import] the
> xotcl namespace automatically.[1]

 we had something like this in earlier versions of xotcl, but it was quite
 a pain, where it was quite easy to run into inifine loops, since
 procs of objects were resolved without the object name. To be on
 the safe side, every reference to a gobal tcl command had to be
 prefixed by a :: (eg: ::set x 1), otherwise an "obj proc set .."
 was overruling the tcl command. Note that we have multiple
 command sets in xotcl, not only in the procs, but in the instprocs
 of classes (superclasses, mixins) as well.

 you can do the following as other alternatives:
 a) you can import the xotcl commands into your
     components workspace, and do a namespace eval
     there
 b) you can eval the object in the ::xotcl namespace
 
 here are such code snipplets:
==================================
namespace eval myns {
  namespace import ::xotcl::*

  Class MyClass
  MyClass instproc test {} {
    puts stderr "in [xotcl::self] current namespace [namespace current]"
    puts "unprefixed: [self] [self class]"
  }
  MyClass o

}

puts =========
namespace eval myns { o test }

puts =========
namespace eval xotcl {myns::o test}
puts =========

==================================

 if you have a component with a slim interface, you can
 simply do a namespace eval once on the top calling level, this
 does not cost much performance.

 ... and, you can write a global unknown handler, but that is not
 better than importing xotcl (or at least self+my) globally, what
 still looks like the best option to me.

-gustaf

-- 
Univ.Prof. Dr.Gustaf Neumann
Abteilung für Wirtschaftsinformatik
WU-Wien, Augasse 2-6, 1090 Wien

From: Kristoffer Lawson <setok_at_scred.com>
Date: Sun, 25 Apr 2010 19:15:39 +0300

On 25 Apr 2010, at 11:15, Gustaf Neumann wrote:

>> Foo is a class, Bar is a class, but Foo's
>> actual fully qualified name is ::Foo, so if I wanted an exact search
>> it should be against ::Foo, but will it also match 'Foo' (as
>> desired)?
>>
>>
> yes. both commands
>
> Foo info subclass Bar
> Foo info subclass ::Bar
>
> return "::Bar"

OK, thanks for the clarification. Perhaps this should be made even
clearer: in that case it is not acting as a pattern. I mean:

Class Foo

Class Bar -superclass Foo
Class FuBar -superclass Foo

I hope that the following returns only one element:

Foo info subclass Bar

Is that correct?


I am using XOTcl 1.2 as that is what comes with OSX Leopard. As a
general note, though, I think changes like this which cause backwards
compatibility issues should cause the major version number to change,
as per Tcl's normal package versioning scheme. Now my scripts will
break when I upgrade XOTcl.

-- 
Kristoffer Lawson, Co-Founder, Scred // http://www.scred.com/

From: Uwe Zdun <uwe.zdun_at_uni-essen.de>
Date: Mon, 12 Mar 2001 14:10:01 +0100

Announcing XOTcl 0.84.
**********************

WHAT IS XOTCL?

  XOTcl is object-oriented extension of Tcl that was derived from
  OTcl. In short, XOTcl tries to provide a highly flexible,
  reflective, component-based, and object-oriented environment. It
  integrates language support for high level concepts which are not
  found in other languages, with reasonable performance. It prevails
  the Tcl programming style and the dynamic/introspective nature of
  the language, rather than introducing other language's styles and
  rigidness (such as C++) into Tcl.

RECENT CHANGES IN VERSION 0.84
  The most important changes relative to 0.83 are:
  - Object recreation scheme (instead of destroying object on overwrites;
    the semantics of recreation can be configured now).
  - Enhanced destroy and create logic (much more customizable).
  - Heavily improved compilation support for Windows versions + full
    test suite running on Win with nmake.
  - Improved test suite.
  - XOTcl wrapper for various persistent stores, including Gdbm,
    Sdbm, TextFile, Mem. These are transparently used for object
    persistence.
  - All stores have a new interface resembling the interface
    to (non-persistent) objects (e.g. set-method writes an entry
    into the persistent store, unset deletes it from there, etc.).
  - New static and dynamic analyzer packages for _at_ metadata and
    self-documentation facility.
  - Hierarchical package naming, like xotcl::store::gdbm,
    xotcl::comm::httpAccess, ...
  - New package for serialization of workspace contents (either whole
    workspace, or certain classes/objects) to Tcl file.
  - Moved callstack information (calledproc, callingproc,
    callingobject, etc.) into ``self'' command (WARNING:
    potential incompatibility esp. for filters).
  - New callstack information ``self next''.
  - Search process for XOTcl packages improved (see ChangeLog file).
  - ::xotcl namespace for runtime information.
  - htmllib by Antti Salonen: HTML Builder for HTML documents.
  - XOTcl is now thread-savvy. It can be used in Tcl8.3.2+ with
    tclthread2.2+ extension w/o modifications. However, at the moment,
    interp memory is freed, when the thread exists, not when the
    interp is deleted (due to Tcl lacking a proper hook).
    If somebody needs assistance in bringing it to work with AOLserver
    3+, contact Zoran Vasiljevic <zoran_at_archiware.com>.
  - Speedup for xotcl primitives bwtn. 5% (typically) and 55% (next)
  - Bug fixes & more documentation.

MORE INFO
  General information about XOTcl and its components can be found at
  http://www.xotcl.org

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

Best regards,

Gustaf Neumann
Uwe Zdun

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Tue, 13 Mar 2001 00:16:56 +0100

On Monday 12 March 2001 23:44, you wrote:
> Hello all.
>
> I was having some trouble understanding basic things about XOTcl. I found
> an old TicTacToe program written in OTcl (by Gustaf?) and translated it so
> it would run on Tk rather than Mofe.
 
 no, the program was implemented by Ralf Goertzen, who was
 teaching assistent in my former department in Essen. The only
 piece of code of this example is the pseudo-random number
 generator....


> It's self-contained, involves several
> cooperating objects, and has a simple domain. Maybe some other beginner
> would find going through it useful.
>
> I have attached the script to this mail message.

 What you did is a very straightforward translation from
 OTcl to XOTcl and does therefore not use any new functionality
 of xotcl. One example are the names of the objects.
 In OTcl, all object names have to be global, XOTcl supports
 aggregation. I would recommend to create the engine, the
 gameport, etc. into the game object. This will make it possible
 to create e.g. 2 instances of the game, without interfering with
 each other, or this will allow you to remove a game instance
 with everything that belongs to it by a single command...

 best regards
 -gustaf

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Fri, 24 Sep 2004 16:15:47 +0300 (EEST)

I'm getting a segmentation fault in relation to XOTcl. I believe the
situation that causes it is as follows:

* I have an object C which has a child M.
* M has a fileevent callback.
* On receiving complete message, M calls a method in C.
* If that is an empty message, C destroys itself and closes the socket in
the destructor (M is still in fileevent callback).

After that I get a segmentation fault. But.. this only happens if I have
my debug outputs turned on! They are just normal Tcl [puts] stuff, wrapped
around in other things. The thing is I am unable to recreate this with a
trivial piece of code so I'm finding it very difficult to pinpoint the
exact cause (even, indeed if it is XOTcl at fault or if I have found a Tcl
bug).

Sorry for the very vague report. I wish I could be more specific. If it's
any help, at one point, instead of a segmentation fault, I got:

alloc: invalid block: 0x81264a0: b0 8 ef
Aborted

My guess, something is being freed before it should. Let me know if
there's anything more I can do to help find this problem.

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

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Mon, 01 Aug 2005 12:46:42 +0200

Dear all.

The best fix is to remove twice the word "static" before
XOTcl_ThreadExitProc.
I've fixed this some time ago, when Tiger came out.. we should release most
probably a maintenance release soon.

best regards
-gustaf neumann

Stefan Sobernig schrieb:

> Dear all,
>
> When using a recent gcc-compiler of the 4.x family, xotcl fails to
> compile due to a compatibility issue with respect to declaring nested
> functions *static*. xotcl.c, however, currently contains one static
> nested function and therefore breaks when using gcc4. The following
> error is reported back by make:
>
> ############## snip ##############
> ./generic/xotcl.c: In function ‘XOTcl_ThreadExitProc’:
> ./generic/xotcl.c:10791: error: invalid storage class for function
> ‘XOTcl_ExitProc’
> ./generic/xotcl.c:10792: error: ‘XOTcl_ExitProc’ undeclared (first use
> in this function)
> ./generic/xotcl.c:10792: error: (Each undeclared identifier is
> reported only once
> ./generic/xotcl.c:10792: error: for each function it appears in.)
> make: *** [xotcl.o] Error 1
> ############## snip ##############
>
> To resolve the issue, the nested function XOTcl_ExitProc has to be
> moved to the top level. A patch is attached to the email. The patched
> version compiles perfectly and passes the entire bunch of tests.
>
> regards,
>
> //stefan
> --
>
>Stefan Sobernig
>Department of Information Systems and New Media
>Vienna University of Economics
>Augasse 2-6
>A - 1090 Vienna
>
>Phone: +43 - 1 - 31336 - 4878
>Fax: +43 - 1 - 31336 - 746
>Email: stefan.sobernig_at_wu-wien.ac.at <mailto:stefan.sobernig_at_wu-wien.ac.at>
>PubKey: http://julia.wu-wien.ac.at/~ssoberni/0x5FC2D3FA.asc <http://julia.wu-wien.ac.at/%7Essoberni/0x5FC2D3FA.asc>
>
>

From: Uwe Zdun <uwe.zdun_at_uni-essen.de>
Date: Tue, 25 Sep 2001 17:40:19 +0200

On Monday 24 September 2001 11:26 pm, you wrote:
> On Mon, 24 Sep 2001, Uwe Zdun wrote:
> > in the forthcoming XOTcl release will be several new filter features ...
> > I've already reported on the obj-filters. Another feature we have ready
> > are "filter guards". A filter guard is a condition whether a filter will
> > be executed or not. It is registration-centric, thus you can append the
> > conditions to the filter registration, example:
> >
> > A instfilter {filter-1 {filter-2 {[self calledclass] ==
> > "::FigureElement"}}}
>
> I wonder if it would make sense to allow filters to be objects? In that
> way filters could become semi-independent entities that can used
> in various different places by attaching them to other objects, and
> filtering specific methods. In that way they might more closely follow the
> direction taken by AOP concepts. Or would mixins be better for this kind
> of design?
>
> Haven't given it much thought. I'm just rambling :-)

Without having given that too much thought either, I think there are three
possible paths to make filters objects:

a) make everything in XOTcl an object including procs and instprocs =>
filters are objects as well

b) make filters special objects which have a method (proc) on them which is
the filter. This would be a substantially different model to what we have
now. Filter search would have to take place on these objects, filters would
not be inherited, linearization of filters would be different, etc. But, of
course, we could combine different filters on these objects. This would be
closer to cross-cutting concerns in AOP.

c) we could (optionally) return objects by the info methods of a filter which
are linked to the filter. Thus the filters would stay what they are, but they
can be queried using an object. This is more or less the lightweight object
idea discussed on this list before. E.g. there could be a modifier for info,
such as:
  set fi [X info -obj instfilter]
  puts [$fi set filters]
  puts [$fi set guards]
whereas:
  X info instfilter
returns the usual list. We could as well provide such links to other
interesting infos, as for instance the filter callstack info (callingobject,
etc.)

--uwe

PS: we have reduced the minimum per-object size to 48 bytes so that such
lightweight object become quite feasible ...

-- 
Uwe Zdun
Institute for Computer Science, University of Essen
Phone: +49 201 81 00 332, Fax: +49 201 81 00 398
zdun_at_{xotcl,computer,acm}.org, uwe.zdun_at_uni-essen.de