Weblog Page

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Tue, 26 Apr 2011 14:54:16 +0200

Just to provide a short addon to stefan's long response:
  - some tests in xotcl/nx are indeed legacy of otcl
(testo.xotcl).
  - the first generation of regression tests were written in
the otcl style (testx.xotcl).
  - these tests are in part "designed", but also in part
tricky cases derived from bug reports.
    Many of these tests are rather integration tests than
unit tests, testing interdependencies of language features.
 From the debugging point of view these are a mess, since it
might take quite some time to find the source of a
misbehavior. At the same time, these are real-world examples
and they are valuable for the project, since these are
testing simultaneously several complex features, so i'll
leave these for the time being.

The newer generation of tests (package nx::test) are built
just around the needs of xotcl/nx, for making testing more
convenient. nx::test is an
  - oo-based test environment with
  - automated cleanup for the objects created in a test run,
  - provides error/exception handling and
  - simple means for speed comparison,
  - triggers routines for internal (c-level) consistency
checking, and
  - provides a simple syntax


Writing test environments in Tcl is very simple and quite
straightforward, but depending on your needs, different
approaches are reasonable.

In case, you are in an environment where you are using
already many xUnit tests for several other languages, and
you are using eclipse, you might find xounit from Ben
Thomasson useful (some more pointer in addition to Stefan's)
http://xotcllib.sourceforge.net/xounit.html
which seems to be integrated via plugin into eclipse.dltk
http://dev.eclipse.org/viewcvs/viewvc.cgi/org.eclipse.dltk/xotcl/plugins/org.eclipse.dltk.xotcl.testing.xounit/?root=Technology_Project&sortby=author
http://download.eclipse.org/eclipse/pde/apitools/eclipse-galileo-rc4/api-html/org.eclipse.dltk.core/org.eclipse.dltk.xotcl.testing.xounit/org.eclipse.dltk.xotcl.testing.xounit.html

some people seem to like tclTkUnit (which disappeared from
the public pages a few years ago) which is as well modeled
close to JUnit:
http://classic-web.archive.org/web/20080822172425/http://park.ruru.ne.jp/ando/work/tclTkUnit/

-gustaf neumann

From: Lehmann, Eckhard <eckhard.lehmann_at_roche.com>
Date: Wed, 27 Apr 2005 09:39:32 +0200

> Example. You can use method-forwarding feature in XOTcl for
> delegating calls to objects to underlying widget.

That's what I mean...

> If you do not want to develop own XOTcl widget set there
> are no reasen to rewrite BWidget to XOTcl. XOTcl code can
> use all tcl packages (Even ITcl).

It would be better to have a special XOTcl widget set, agreed
(especially interresting for that is, that it could look like Gtk on
Linux/GNOME, look like windows on Windows and look like Mac on Man,
which isn't always true for the current Tk). But that's nothing I can do
- I don't have enough time and experience with developing widget sets, I
am only a user of these things. That's why I started to use Tcl/Tk some
time ago... because I need to solve "real world problems" quick and
painless.
I am looking for a quick and usable way to get things work. The BWidgets
are around there for some time, they are tested and mature, and many
people use them now with "plain old Tcl" in real world applications.
Okay, having a wrapper for Bwidgets in XOTcl is maybe an "only half way
solution" of the widget-problem, but it is still good enough for almost
all people who want to develop XOTcl and are searching for a set of
widgets which makes full use of the XOTcl features (like the windows
operating system: Its only a half way good operating system but it's
enough for almost all people :-)).

Combine the maturity and usability of Tk and Bwidget with the (very
interresting) features of XOTcl, so that people can derive from and
mixin XOBwidget classes and quickly get their jobs done with
XOTcl/XOBwidget - and there will be many more users of XOTcl, XOTclIDE
and Tcl itself (especially "old style Tcl'ers" are more likely to switch
to XOTcl, I think). After or parallel to that it is still possible to
start developing a special widget set for XOTcl.

That's only my opinion and I know it is better discussed on the xotcl
mailing list. That's why I post a CC to the list as well.


Eckhard ;)

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Sun, 13 Nov 2005 11:32:21 +0100

Kristoffer,

the arguments to the constructor are preceding in the call the values
passed to
configure. All the arguments of the call not strting with a dash are taken
as arguments for init. So in:

  Class C
  C c1 ene mene moo -f 1 2 3 -g drausst bist du

the arguments "ene mene moo" are passed to init, "1 2 3" to f,
and "drausst bist du" to g.

the position of the arguments to init are not arbitrary.
the argument parses does not try to check the signatures of
the functions to be called to determine the number of arguments.
This won't be cheap, the handling of "args" and
default values makes it unclear what to pass as argument...

-gustaf

Kristoffer Lawson schrieb:

> This is with XOTcl 1.3.6, but I couldn't find if 1.3.8 fixes it. The
> following code does not appear to work as expected:
>
> package require XOTcl
> namespace import xotcl::*
>
>
> Class A
>
> A instproc init {test} {
> puts "init: $test"
> }
>
> A instproc foo {text} {
> puts "foo: $text"
> }
>
> A instproc bar {text} {
> puts "bar: $text"
> }
>
> A new "on taas" -foo jou -bar blah
> A new -foo jou -bar blah "on taas"
>
> The first will work, but the latter will not. The error is:
>
> wrong # args: should be "bar text"
> ::xotcl::__#1 ::A->bar
> ::xotcl::__#1 ::xotcl::Object->configure
> ::A ::xotcl::Class->create
> ::A ::xotcl::Class->new
> invoked from within
> "A new -foo jou -bar blah "on taas""
> (file "dashCreateTest.tcl" line 23)
>
> / 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: Jim Lynch <jim_at_jam.sessionsnet.org>
Date: Fri, 9 Apr 2004 08:05:19 -0700

Hi,

Subject says it all (xowish always generated even if --without-tk)...

Can't fix today.

-Jim

--
Jam sessions community web site: http://jam.sessionsnet.org

From: Donal K. Fellows <donal.k.fellows_at_manchester.ac.uk>
Date: Thu, 29 Sep 2005 08:47:47 +0100

Gustaf Neumann wrote:
> The follwing paragraph in the section "Precedence Order" in the tutorial
> is supposed to describe linearization. Sorry, if this is not clear enough:
>
> Filters as well as classes (mixins and ordinary classes) are linearized.
> That means, each filter and each class can be only once on a precedence
> order list. If a filter or class can be reached more than once, the
> last occurrence is used.

Hmm, I must have missed that somewhere. Please put this whole discussion
down to trying to understand the linearization algorithm. Thanks for
your patience!

Donal.

From: Gustaf Neumann <Gustaf.Neumann_at_wu-wien.ac.at>
Date: Mon, 5 Feb 2001 23:40:00 +0100 (CET)

>>>>> "KL" == Kristoffer Lawson <setok_at_fishpool.com> writes:

KL> Yes, maybe that would be the best option. The issue stems from
KL> the problem that I have a few different ways to create an instance
KL> (and as I can only have one constructor I must do it some other way). This
KL> is fine normally, but in this particular case a sub-class can only be
KL> created in one manner and thus it should make an instance of itself
KL> using one particular initialisation procedure of its super-class.
KL> So if you have suggestions for that, I'd like to hear them. Overriding
KL> create is one way, if nothing else.

 i have to admit, that i do not fully understand the problem.
 the following seems to satisfy your needs:

  Class GeneralClass
  Class NormalClass -superclass GeneralClass
  Class SpecialClass -superclass GeneralClass

  GeneralClass instproc init1 ....
  GeneralClass instproc init2 ....

  NormalClass instproc init ... { .... init1 ....}
  SpecialClass instproc init ... { .... init2 ....}
  

 the other approach is to make init more clever. i read a hint from
 your mail, that you want to have different constructors for different
 parameters ("overloading similar to c++"). What's wrong with a switch
 in init handling these cases:

   Class C -parameter situation
   C instproc init {} {
      next
      switch [[self] set situation] {
         green { .... init1 ....}
         red { .... init2 ....}
         default .....
      }
   }

   C c1 -situation green
   C c1 -situation red


 -gustaf

From: Victor Mayevski <vitick_at_gmail.com>
Date: Wed, 13 Oct 2010 23:21:21 -0700 (PDT)

Thank you Gustaf,
I am using the ActiveState binary and XOTcl is version 1.6.6, not NX. I don't know where to get the source code for TCL 8.6.0.0b4, it is not available anywhere yet.

I think I have zeroed in where the crash happens. Here is the sample code that causes the crash for me:

tcl_patchLevel 8.6b1.2
tcl_platform(byteOrder) = littleEndian
tcl_platform(machine) = x86_64
tcl_platform(os) = Linux
tcl_platform(osVersion) = 2.6.35-22-generic
tcl_platform(pathSeparator) = :
tcl_platform(platform) = unix
tcl_platform(pointerSize) = 4
tcl_platform(threaded) = 1
tcl_platform(user) = root
tcl_platform(wordSize) = 4

####################################
Object o
Object o::o
[o::o info parent] info children

Segmentation fault
#####################################

I have also installed the 32bit version of the same ActiveState binary (the latest one, 8.6.0.0b4, tcl_patchLevel 8.6b1.2) and it will crash right at [package req XOTcl]

Hope that helps




----- Original Message -----
From: "Gustaf Neumann" <neumann_at_wu-wien.ac.at>
To: xotcl_at_alice.wu-wien.ac.at
Sent: Wednesday, October 13, 2010 6:56:00 PM GMT -08:00 US/Canada Pacific
Subject: Re: [Xotcl] troubleshooting

  Hi Victor,

our typical test setup is to run the regression test with
8.5.9, tcl 8.6b1,
and with 8.6head version (where i have applied the
SANE-NRE-patch
from Miguel). i just double-checked, for me all three test
settings
work fine.

does the regression work on your installation with tcl 8.6b4
(run: make test)?
If they run fine, and you experience a crash with your
application,
the following works probably best:

Strategy a: try to isolate and pinpoint the problem from the
tcl layer
    by simplifying your script. if the problem can be
reproduced with
    a few lines of code, send it to me.

Strategy b: mostly for c-literate developers: use gdb.

   - compile tcl and nsf with -g enabled (e.g. add it to
     the compile flags in the Makefile and recompile with
     "make clean" and "make")

   - start the tcl shell under gdb, like e.g.
        gdb /usr/local/src/tcl8.5.9/unix/tclsh

   - start your application from gdb using
        run ..../yourapp.tcl

   - when it crashes, type in
        where
     an you will get the backtrace.
     maybe what you see makes sense to you.
     if not, send it to me, i'll try me best on it.

all the best
-gustaf

On 14.10.10 00:33, Victor Mayevski wrote:
> I have just tried my application on latest TCL 8.6b4 and it crashes (Segmentation fault). The same application works just fine in TCL 8.5.9. Any idea how I can troubleshoot it? Tools, techniques etc?
>
> Thank you
> _______________________________________________
> Xotcl mailing list
> Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl

_______________________________________________
Xotcl mailing list
Xotcl_at_alice.wu-wien.ac.at
http://alice.wu-wien.ac.at/mailman/listinfo/xotcl

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Tue, 25 Sep 2001 00:26:17 +0300 (EEST)

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 :-)

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

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Wed, 19 Nov 2003 18:55:51 +0100

On Wednesday 19 November 2003 16:53, Jim Russell wrote:
> Uwe:
>
> Thank you so much for the very lucid explanation. I was hoping that
> I could use the trace mechanism to implement a garbage collection
> scheme. I was storing the XOTcl object name in an ordinary Tcl variable
> upon which I placed the unset trace. When the variable goes out of
> scope, the unset callback is called, and I had hoped to dereference the
> variable to call the XOTcl object's destroy method. However, this
> doesn't appear to be a good approach. Do you have any suggestions?

Jim, i have simplified your example by deleting the trace calls and your
replacemented of "new" and added simply "-volatile". When an object
is created with "new -volatile" it will be destroyed automatically,
when the current tcl-proc/object-proc/instproc is left.

So, after main is processed, all instances of factorial are deleted.

Was this, what you were looking for?

#########################################
xotcl::Class factorial
factorial instproc compute { rhs } {
     puts "rhs = $rhs"
     if { $rhs > 1 } {
         set f [ factorial new -volatile ]
         set lhs [ $f compute [ expr $rhs - 1 ] ]
     } else {
         set lhs 1
     }
     set product [ expr $lhs * $rhs ]
     return $product
}

proc main { value } {
     set f [ factorial new -volatile]
     puts "${value}! = [ $f compute $value ]"
}

main [expr [ llength $argv ] ? [ lindex $argv 0 ] + 0 : 3 ]
################################################


 Another simple approach for some kind of "garbarge collection" in xotcl
 is to put your temporary objects into a container and delete that when
 appropriate.

 best regards
-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: Sat, 11 Nov 2006 17:49:20 +0100

Shishir Ramam schrieb:
> I must be missing something here - but are non-positional arguments
> not permitted on the init proc?
> A transcript of my attempts below...
Dear Shishir,

The recommendation is, not to use nonposargs in init, since providing
values in the
"-" syntax conflicts syntactically with object configuration.

You can use nonposargs in "init" it with some more syntax
like in the following example e.g. in factory methods:

   Class foo -parameter {{-a "apple"}}
   foo instproc init {{-a "apple"} args} { puts a=$a}
   foo f
   foo f [list -init -a "banana"]

See as well:

http://groups.google.at/group/comp.lang.tcl/browse_frm/thread/26b2e0ac8edfab7c/00c29863925990bc?lnk=st&q=xotcl+jima&rnum=3&hl=de#00c29863925990bc

best regards
-gustaf neumann