Weblog Page

From: Stefan Sobernig <stefan.sobernig_at_wu.ac.at>
Date: Tue, 26 Apr 2011 12:40:14 +0200

Victor,

> I am beginning to learn and use test driven development in my
> projects. I've noticed that NX does not use the standard "tcltest"
> package in Tcl but instead provides it's own "nx::test". Is there a
> specific reason for that?

I can't give you the full story, only some observations of mine. To some
extent, nx::test and especially its predecessors (xotcl::test) are a legacy:

OTcl had its own testing environment, not using or not building upon
tcltest, and so had XOTcl; see e.g.
http://otcl-tclcl.cvs.sourceforge.net/viewvc/otcl-tclcl/otcl/lib/test.tcl?view=markup

test migration vs. test continuity so is the issue here. also: nx::test
& friends have always been used to test core functionality of the
language system, rather than application testing. for your XOTcl/nx
application, tcltest is certainly a viable option (coming with nice
helpers actually missing in nx::test). another answer along these lines
is probably that a home-brewed testing evironment is usually one of the
first prototype applications written by the language authors in their
language.

as for application testing, however, an object-aware testing environment
comes handy; you can refine your test suites occasionally through
mixins; or nx::test traces object lifecycles during test execution to
maintain a prestine testing sandbox to avoid unwanted test interactions.
however, that does not mean that you could not realise all of this using
tcltest.

some further pointers, especially when it comes to TDD (which is, by the
way, something different than merely writing and executing tests in the
sense of tcltest or nx::test):

Two or three years ago, I had a look at a xUnit framework for XOTcl:
http://xotcllib.cvs.sourceforge.net/viewvc/xotcllib/xounit/

While it gave me a xUnit environment, it found it incomplete and its
implementation rather clumsy (including its usage of Exception objects
ontop of Tcl's error control flow mechanism).

More recently, Mark published on a scenario-driven approach and
prototype framework (STORM) which I successfully used in one or two dev
projects of mine. It comes with essentials concepts for applying a
test-first development approach:

http://wi.wu-wien.ac.at/home/mark/publications/se2011-extended.pdf

I don't know whether the prototype implementation (the XOTcl script) is
publicly available, but you could most certainly talk Mark into
providing it to you :)

//stefan










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

-- 
Institute for Information Systems and New Media
Vienna University of Economics and Business
Augasse 2-6, A-1090 Vienna
`- http://nm.wu.ac.at/en/sobernig
`- stefan.sobernig_at_wu.ac.at
`- ss_at_thinkersfoot.net
`- +43-1-31336-4878 [phone]
`- +43-1-31336-746 [fax]

From: Victor Mayevski <vitick_at_gmail.com>
Date: Fri, 4 Feb 2011 16:14:34 -0800

Hello Gustaf,

I am using the latest Tcl 8.6 from SourceForge and latest NX on 32bit
Linux. I am experiencing a pretty bad memory leak when using NX
objects with attributes. Example code:

time {Object create o; o attribute "[clock clicks] [clock clicks]";o
destroy} 1000000

Within like 3 minutes the memory usage grows to around 300meg.

Thanks,

Victor

From: Neil Madden <nem_at_cs.nott.ac.uk>
Date: Wed, 19 May 2004 16:14:16 +0100

Just a random thought, not totally paying attention to this thread:

Is there a reason why the filter/mixin lists could not just be normal
object/class variables? Seems XOTcl already has plenty of flexibility
to deal with these. E.g.:

instead of:

Object mixin ....

do:

Object set mixins [list ... ]

or something like that (not completely familiar with the current
syntax). The old methods could be setup to just be wrappers around
these new variables. Or is there some reason why these lists are
treated specially?

Cheers,

Neil.


On 19 May 2004, at 16:03, Adam Turoff wrote:

<discussion on how to handle mixins/filters>

From: Vasiljevic Zoran <zv_at_archiware.com>
Date: Thu, 10 Feb 2011 14:52:28 +0100

On 10.02.2011, at 14:27, Krzysztof Frukacz wrote:

>
> What would be the proper way to "register" the object myObject (which already exists) in another thread?

No way. You need to ask Gustaf to give you serialisation-code
that you can use to replicate your object/classes blueprints
from one thread into others as a matter of thread inits.
IIRC there must be a sample Serialize class somewhere in the
distribution.
Even then, an instantiated object cannot be shared/moved across
threds. You need to instantiate it in the target thread.

Cheers
Zoran

From: Scott Gargash <scottg_at_atc.creative.com>
Date: Thu, 16 Mar 2006 05:15:32 -0700

xotcl-bounces_at_alice.wu-wien.ac.at wrote on 03/15/2006 04:23:28 AM:

>
> On 15 Mar 2006, at 12:17, Gustaf Neumann wrote:
> >
>
> I am actually quite surprised to find that the move operation calls
> the destructor. This is not mentioned on the reference manual and
> does, in fact, seem counter-intuitive. A move is a move, nothing is
> being destroyed, so why call the destructor?

I agree. A move operation didn't imply object destruction to me, either.

> I understand that the
> operation is actually quite expensive, due to current Tcl internals,
> but is there any reason why a destructor should be called? If we want
> a method called for a move operation, surely it would be simple to
> define that a "beingMoved" method is then called.

I'm guessing that xotcl::object's "destroy" method does all the heavy lifting (cleaning up the
source of the move). What would happen if the default move implementation was to change the source
object's class to xotcl::object before invoking destroy? This way it would continue to use the
xotcl::object's "destroy" implementation for cleanup purposes without invoking all of the subclass
destroy methods, and derived classes wouldn't perceive move as a destroy operation. Would this have
bad side-effects?

> > it is quite simple
> > for a poweruser of xotcl to overload copy/move and add applicaton
> > specific addtional behavior to it. if one does not like the side-
> > effects
> > of destroy in a move, a custom move operation can set in instance
> > variable "__during_move__" and query this from the destroy
> > method to change its behavior.

While I'm no poweruser, I did get the guard mechanism to work. Here it is for completeness sake.
(Is there an easy way to search the mail archives? Maybe this will help someone else...)

# move doesn't do what I expect. It's not simply a move, it's
# actually a deep copy followed by a destroy. I want to reclaim the
# object on destroy, but not the imputed destroy from the move
# operation. So flag that the destroy is happening because of a move
# so the destroy reclamation doesn't happen, and then reset the flag
# in the new copy.
TrackingMixin instproc move {dest} {
  my set _ismoving_ 1
  next
  $dest unset _ismoving_
}
TrackingMixin instproc destroy {args} {
  if {[my info vars _ismoving_] eq ""} {
    # true destroy, do true destroy things...
  } else {
    next
  }
}


      Scott

From: Jeff Hobbs <jeffh_at_activestate.com>
Date: Mon, 4 Dec 2006 11:08:00 -0800

> 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.

Method forwarding (aka delegation) is an absolute must and common feature for
megawidget development (fwiw).

Jeff

From: Schofield, Bryan \(GE Transportation\) <"Schofield,>
Date: Fri, 15 Oct 2004 13:48:57 -0400

Ack! What a shame. I've been working on six utility packages that are very close to being ready for public consumption. I'm just waiting on 1.3.3 to make sure everything works well with the finalized namespace scoping implementation. It has all been written against the 1.3 feature set. So far I have the following packages:

xow - A megawidget framework. This is a package that allows xotcl objects to be megawidgets.

xol - Yet another logging framework. But since this is object oriented, this package provides some features that are not available in other packages. Foremost, the ability to use "Formatter" and "Receiver" objects. For example, the following simple line:
  $logger warn "Ack! Foo"
could be able to log to file or console, package the message up as XML and send it over the network, or even feed an RSS stream depending on the formatter & receiver the logger is using. So far, I've only written a simple formatter and output channel receiver, but this is all possible.

xtend - a collection of "singleton" objects that extends the basic functionality of tcl, tk, and xotcl. This package provides various string, list, tk, and xotcl utilities.

xact - an "action" framework package. If you are not familiar with the "action" concept in ui programming, it is a very powerful tool that simplifies programming chores. wiki.tcl.tk has some information available. This package can also be used in a non-tk environment.

xcentuate - a theme engine for tk. This isn't all that important on windows, but on unix tk often needs a little help looking good. This package provides a very simple method of defining and changing the look of tk apps. It can even do it on the fly.

xout - a unit testing framework. I know, I know, tcl already provides one, tcltest. But I found tcltest to be too cumbersome and clunky. I'd write some tests, but maintaining those tests often was neglected because of the amount of programming overhead needed to write complex test cases. xout (X Out) simplifies unit tests. xout is only a framework, so I wrote graphical utility "xam" (think Exam) that puts xout to work. It is what I'm using these days to run my unit tests.


I mention all of this because if other have some handy xotcl packages, I'd be interested in creating a formal xotcllib project. Perhaps something at sourceforge. I'll be making these available soon either way.

-- bryan


> -----Original Message-----
> From: xotcl-bounces_at_alice.wu-wien.ac.at
> [mailto:xotcl-bounces_at_alice.wu-wien.ac.at]On Behalf Of Gustaf Neumann
> Sent: Friday, October 15, 2004 1:03 PM
> To: xotcl_at_alice.wu-wien.ac.at
> Subject: Re: [Xotcl] xotcllib?
>
>
> On Friday 15 October 2004 18:47, Schofield, Bryan \(GE
> Transportation\) wrote:
> > Does xotcllib, or some other collection of XOTcl utility
> packages exist?
> just the library that comes with the source in xotcl*/library
> -gustaf
>
> --
> Univ.Prof. Dr.Gustaf Neumann
> Abteilung für Wirtschaftsinformatik und Neue Medien
> Wirtschaftsuniversität Wien, Augasse 2-6, 1090 Wien
> _______________________________________________
> Xotcl mailing list
> Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
>

From: Ben Thomasson <ben.thomasson_at_gmail.com>
Date: Mon, 4 Apr 2005 13:31:57 -0400

Jeff,

Considering there is a safe interp in Tcl, there should be extensive
unit testing
that can be run in regression to make sure any new functionality like this
does not break the security model. Does Tcl have regression tests
(tcltest or other) that exercise the ability of safe interp to stop
dangerous code? If there is,
then these tests could be run in at least Object eval to whether this simple
approach would work. If not, there should be. Or is the security model based
on proving the safety of an interp by analysis of the code? If you take this
second approach them much more work must be done before xotcl includes
this code for the safe interp.

Ben

ps ( In open source projects, is it the person who comes up with the
idea who is the person to implement it? Dang. )

On Apr 4, 2005 1:13 PM, Jeff Hobbs <jeffh_at_activestate.com> wrote:
> Gustaf Neumann wrote:
> > Since xotcl uses ordinary tcl interps, i would assume, it
> > inherits the safetiness of save tcl interps. Since xotcl does
> > not do any socket handling, file-i/o, exec's, etc., i would
> > think, this is a good start. If you see commands that we
> > should deactivate in safe interps, please let me know.
>
> You have to be careful with anything you add at the C level for
> safe interps. Whatever you create in Tcl in safe interps is by
> definition safe (if you aren't aliasing into the master), because
> of the model. However, in C you can expose anything. While you
> might not directly expose exec, IO, etc., you have to consider
> how you might indirectly expose that functionality and how a user
> might exploit that. I'm not saying that xotcl does, but you
> should just consider the implications of each C-based command
> individually. You also have the Tcl_IsSafeInterp C API for
> variant behavior in safe interps.
>
> Jeff Hobbs, The Tcl Guy
> http://www.ActiveState.com/, a division of Sophos
>
>

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Tue, 14 Aug 2007 20:35:48 +0200

Jeff Hobbs schrieb:
>> + provided compatibility with Tcl 8.5
>> (currently, this requires the verison of Tcl 8.5
>> from CVS head, including the changes for VarReform
>
> From what I understand of the patches, this is all done for
> source-level compatibility. IOW, you compile with 8.4, it works with
> only 8.4. You compile with 8.5, it works only with 8.5.
when xotcl is compiled with an 8.4 version of tcl, the binaries will
only work with 8.4,
when compiled with 8.5 the binaries will require the tcl 8.5 stub lib.
>
> This represents a problem for distro developers (such as myself)
> because we base our extension compiling on 8.4. The ActiveState
> teapot is populated with 8.4-built extensions, all working on the
> assumption that stubs is our friend.
if xotcl is compiled with 8.4, it continues to work in the 8.4 distro as
before. xotcl uses only what's exported via stubs.
>
> I know that some extensions poke deeper (especially OO ones), but we
> were able to maintain binary compat with itcl.
the stubs of tcl 8.5 are not the same as tcl 8.4. What i have seen, itcl
requires the same new interfaces that xotcl uses. do you expect that tcl
8.5 extensions work for tcl 8.4 and vice versa?

-gustaf

From: Uwe Zdun <zdun_at_acm.org>
Date: Fri, 19 Apr 2002 19:52:38 +0200

Hi Andriy,

this was a little bug. We have closed down the filter chain upon the "msg"
method but the filter was not done with its own next. I'll attach an xotcl.c
file that should fix the problem (the fix will also be in the next xotcl
release ... but as this is a quite unusual case we don't produce a full patch
release for this fix). Simply replace the xotcl.c file in the distribution
and re-compile ...

--uwe


On Wednesday 17 April 2002 05:46 pm, Andriy Tkachuk wrote:
> Hello! :)
>
> How it must works, when in pre/post part of filter
> object calls his procs that calls next?
> Situation like here:
>
> Class A
> A instproc msg msg {
> puts "puts: $msg"
> }
>
> Class B -superclass A
> B instproc msg msg {
> next
> }
>
> B instproc my_filter args {
> my msg "before next in filter"
> next
> }
>
> B b
>
> b filter my_filter
> b msg bb
> puts: before next in filter
>
> that's all!: there is no "puts: bb".
>
> if filter like this:
>
> B instproc my_filter args {
> my msg "before next in filter"
> next
> my msg "after next in filter"
> }
>
> then:
> "too many nested calls to Tcl_EvalObj"
>
> Thank you.
>
> _______________________________________________
> Xotcl mailing list - Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl