Weblog Page

From: Uwe Zdun <uwe.zdun_at_wu-wien.ac.at>
Date: Tue, 04 Jan 2005 16:52:32 +0100

Hi,

you call "Dummy destroy" which means that you destroy the object "Dummy"
(which happens to be a class). Thus in its class' method destroy
the *instance* that is destroyed is Dummy. "self" is used to refer to
the current instance. Thus:

Class create ::xotcl::_destroyer -instproc destroy {args} {
   puts "DESTROY '[self]'"
   next
}

prints:

DESTROY '::Dummy'

--uwe



Zoran Vasiljevic wrote:

>Hi!
>
>What I want to achieve is to get informed each time a Class is getting
>destroyed. I do need to know the name of the class and its calling
>environment (namespace).
>
>What I did is:
>
>Class create ::xotcl::_destroyer -instproc destroy {args} {
> puts "DESTROY '[self class]'"
> puts "DESTROY '[self calledclass]'"
> puts "DESTROY '[self callingclass]'"
> next
>}
>Class instmixin ::xotcl::_destroyer
>
>Now...
>
>Class Dummy
>Dummy destroy
>
>... gives ...
>
>DESTROY '::xotcl::_destroyer'
>DESTROY '::xotcl::Object'
>DESTROY ''
>
>
>What I expected to get was "DESTROY 'Dummy'" or "DESTROY '::Dummy'"
>but this does not happen. Why?
>
>Thanks,
>Zoran
>
>
>_______________________________________________
>Xotcl mailing list
>Xotcl_at_alice.wu-wien.ac.at
>http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
>
>

-- 
Uwe Zdun
Department of Information Systems, Vienna University of Economics
Phone: +43 1 313 36 4796, Fax: +43 1 313 36 746
zdun_at_acm.org, uwe.zdun_at_wu-wien.ac.at

From: Victor Mayevski <vitick_at_gmail.com>
Date: Fri, 4 Feb 2011 20:28:23 -0800

Wow, that was quick. The leak is gone. Thanks a lot Gustaf.

Victor


On Fri, Feb 4, 2011 at 7:10 PM, Gustaf Neumann <neumann_at_wu-wien.ac.at> wrote:
> Should be fixed in git.
> -gustaf
>
> On 05.02.11 01:14, Victor Mayevski wrote:
>>
>> 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
>> _______________________________________________
>> 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: Shishir Ramam <sramam_at_gmail.com>
Date: Tue, 7 Nov 2006 19:36:32 -0800

I must be missing something here - but are non-positional arguments not
permitted on the init proc?
A transcript of my attempts below...

thanks in advance for any help.
-shishir

% Class foo -parameter {{-a "apple"}}
::foo
% foo instproc init {{-a "apple"} args} {}
% foo f
::f
% foo f -a "banana"
::f: unable to dispatch method 'a' during '::f a'
% foo f a "banana"
::f
% foo instproc init {{-a "apple"} args} { puts "a=$a args=$args" }
% foo f a "banana"
a=apple args=a banana
::f
% foo f -a "banana"
::f: unable to dispatch method 'a' during '::f a'
% foo instproc init {{a "apple"} args} { puts "a=$a args=$args" }
% foo f a "banana"
a=a args=banana
::f
%

-- 
The point of living and of being an optimist, is to be
foolish enough to believe the best is yet to come.
  - Peter Ustinov

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Sun, 23 Oct 2011 11:44:53 +0200

On 23.10.11 11:11, Luc Rasson wrote:
> Hi all,
>
> Sorry for that stupid question but what is NX ? I know what is XOTcl about (that's why I'm on the so called mailing list ;-) but nothing about NX, and I've made some searchs on the web and nothing at all :-( So please don't let me in the dark ;-)
NX is a descendant of XOTcl. To be more precise XOTcl 2 is
based on a new Tcl package, called "Next Scripting
Framework", and XOTcl 2 and NX are purely scripted object
systems. We will present the Framework and NX at the Tcl
conference next week in Virginia:

http://www.tcl.tk/community/tcl2011/schedule.html
> Oh by the way I have few more questions:
> - is it possible to call some functions written in tcl/xotcl from python ?
|
Tkinter.Tcl()| seems to support this.

http://stackoverflow.com/questions/2519532/example-for-accessing-tcl-functions-from-python

> I'm using a lot some great tools (such WikiPad which is simply excellent, try it you will see ! ;-) that can be extended but I'm not sure I want to spend too much time to learn a new language ...
> - is there some functions in tcl/xotcl to encode/decode urls ? I don't find such tools in unix what is (for me) obvious (it seems that's possible in perl for example but I dislike perl ;-)
There are multiple implementations for this. For example,
aolserver/naviserver provide c-based implementations, but
these are part of the http server c code base. For a simple,
tcl based implementation, see e.g.:

http://wiki.tcl.tk/14144
> - long time ago I have been talking about the RETE algorithm that is used for example in CLIPS ... My question was about "is there such a thing in tcl/xotcl". Gustaf told me "write it by yourself" ;-) but after a lot of search I didn't find the algorithm itself ... Any issues about that ? (google if you don't know what I'm talking about ... I think that for some applications the Rete is simply genious) ... I know that it what ported in some languages for example java, but what about tcl/xotcl ?
Franz Wirl did some work on that. I'll poke him about this.

best regards
-gustaf neumann

PS: The posting about the "NX memory leak" of yesterday was
from a spammer, reusing a posting of a few months ago and
appending SPAM to it. Sigh.

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Tue, 24 Apr 2001 21:25:23 +0300 (EEST)

On Tue, 24 Apr 2001, Gustaf Neumann wrote:

> What is the opinion of the community? Do you need/want such
> an extended "inheritable proc" or a new language-consttruct?
> Did you face this problem already, and if yes, was it hard/inelegant
> to solve?

Personally I've never had the need for it (per-object procs were fine).
Usually I'd always want to keep a language as simple as possible. Of
course if I had a need for such a structure then maybe I would change
my stance, but until it becomes very common I'm probably content with
the current system.

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

From: Stefan Sobernig <stefan.sobernig_at_wu-wien.ac.at>
Date: Sun, 06 Apr 2008 14:18:05 +0200

Victor,

Kristoffer already provided you with a primer ...

> I've been looking everywhere and can't find the info.

I am wondering why you are looking for that concept in the XOTcl-verse?
Out of curiosity? Or, because you assemble your arsenal against your
Java, C#, C++ background?

There is a prior thread on this issue which provides a pretty precise
picture on that matter:

http://alice.wu-wien.ac.at/pipermail/xotcl/2000-December/004148.html

To sum it up, you won't find a direct equivalent of "abstract class" as
you might know it from languages cited above. But the key message of the
thread by Uwe Zdun is that you can approximate and, finally, build it on
your own ...

Abstract class can take the following semantics which are not mutually
inclusive (!):

~ A class object that, at least partially, consists of /abstract
methods/. Abstract methods do not provide an implementation (method body).

~ A class object that is constraint to participate only in
superclass-subclass relationships, i.e. participate only as
superclass/subclass in an object system. In other words, a class that
can not be instantiated.

~ A class object that requires its subclasses to provide
implementations (method bodies) for the set of its abstract methods.

Any of the three aspects may be approximated in XOTcl (as shown in the
thread), but still, the concept will differ. Many issues blur the
picture, for instance, time of enforcement of the abstract class
constraints (there is no compile time in XOTcl!).

        The notion of "abstract class" comes with many connotations, but its
purpose has been prominently linked to their use in terms of OO
frameworks as promoted by Ralph Johnson & Co. This is inherently linked
to the need of /integrating/ a framework into a final application with
integration meaning completion. Completion, in turn, realises as
refining "abstract classes" into concrete subclasses provided by the
framework.

        Another perspective is considering the need for a /type hierarchy/, on
the one, and an /implementation hierarchy/, on the other hand. Note,
that type here not necessarily means "behavioural type" in the Liskov
sense of the term. Type hierarchies are commonly realised by the
well-known "interface" constructs in languages such as Java and C#, and
the importance of interface-oriented programming gained some momentum in
recent years (while it was the default in years of CLU and Emerald, but
anyway). Implementation hierarchies, on the contrary, are commonly
realised by class-based inheritance hierarchies. The trade-offs of using
inheritance for realising both type and implementation hierarchies is
widely discussed in literature. Abstract classes somehow settle in the
middle. With abstract classes meaning collections of abstract methods,
methods that comes without a method body (=implementation), you can
approximate the idea of interfaces (as member of a type hierarchy).

        Finally, at a higher level, abstract classes may help realise valuable
forms of OO design, the most prominent example being the GoF TEMPLATE
METHOD pattern.

Hope it helps to clarify the picture a bit ...
//stefan

-- 
Stefan Sobernig
Institute for Information Systems and New Media
Vienna University of Economics	
Augasse 2-6
A - 1090 Vienna
`- +43 - 1 - 31336 - 4878 [phone]
`- +43 - 1 - 31336 - 746 [fax]
`- stefan.sobernig_at_wu-wien.ac.at <mailto:stefan.sobernig_at_wu-wien.ac.at>
`- ss_at_thinkersfoot.net <mailto:ss_at_thinkersfoot.net>

From: Zoran Vasiljevic <zoran_at_munich.com>
Date: Wed, 13 Dec 2000 05:09:13 -0500 (EST)

------Original Message------
From: <uwe.zdun_at_uni-essen.de>
To: Zoran Vasiljevic <zoran_at_munich.com>
Sent: December 13, 2000 9:55:56 AM GMT


> 2. However, in the "mixin" case we could enable argument passing,
> because "mixin" has just one argument? The rest could be passed > to
"init". any objections?

obj mixin Foo arg1 arg2 arg3

would pass arg1-arg3 to init of Foo. Right?

obj mixin [list Foo Bar] arg1 arg2 arg3

would pass arg1-arg3 to init of Foo AND of Bar. Right again?

Is so, then I think it should be done, if possible. 0.85 ? 0.9 ?

Cheer's,
Zoran


______________________________________________
FREE Personalized Email at Mail.com
Sign up at http://www.mail.com/?sr=signup

From: Artur Trzewik <mail_at_xdobry.de>
Date: Tue, 13 Jul 2004 17:17:09 +0200

Hi

There is new version 0.61 of XOTclIDE ready on:
http://www.xdobry.de/xotclIDE

Changes:
- new plug-in. I18N (Internationalization) Helper that can scan sources after
msgcat-library expresions, helps by translation and produce msg-catalogs.
- support of Oracle and MS Sql Server as version control database
- small bug-fixes
- requires Tcl8.4

Xdobry (database tool) in version 0.40 contains new features:
- can be used as database schema creation and manipulation tool
- can migrate data between all supported databases
- can dump databases to xml-dump and import it to every supported database.
- many bug fixes and refactoring
- supports: MS Access, Oracle, MS SQL Server
- updated documentation
- requires Tcl8.4
- deployed also as starkits for windows and linux.

Artur Trzewik

From: Uwe Zdun <uwe.zdun_at_wu-wien.ac.at>
Date: Wed, 7 May 2003 10:33:49 +0200

Hi,

as far as I know, nobody has implemented a Metakit Wrapper with the Storage
classes yet, but you are right, it would be an interesting addition.
Perhaps you would like to volunteer? Feel free to contact me if you need any
help. basically it would be necessary to write forwarders into metakit
with the given Storage.xotcl interface ... having said that, it should also
be said that metakit is more powerful than this interface which is largely
that of the GDBM tcl mapping; thus it might require some thoughts to find a
good mapping.

Uwe




On Wednesday 07 May 2003 09:54, Michael Schlenker wrote:
> Hi,
>
> i looked at the persistence example and saw that there is no Metakit
> storage class yet. This would be a nice addidition especially if using
> XOTcl with tclkit (that has metakit already embedded).
>
> What has to be done to implement metakit storage? Just provide the few
> abstract instprocs from /library/store/Storage.xotcl ?
>
> Michael Schlenker
>
> _______________________________________________
> Xotcl mailing list - Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl

-- 
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: Gustaf Neumann <neumann_at_wu.ac.at>
Date: Sat, 24 Oct 2009 19:40:09 +0200

Dear Victor,

The bug is fixed in the xotcl git repository. As described before,
the bug existed only when XOTcl was compiled against Tcl 8.4
and loaded into some 8.5 or newer version of Tcl. The bug was located
in the XOTcl var resolver (introduced in XOTcl 1.6.3) and damaged
in the above constellation the reference count of variables.

The problem affects primarily the user of the binary ActiveState packages,
since all other distros i know compile extensions against the same version
of the library.

I will release XOTcl 1.6.5 soon (most likely within a week).
Users having compiled XOTcl against the same major
release (e.g. 8.4. or 8.5) won't have to upgrade.

Best regards
-gustaf neumann

Gustaf Neumann schrieb:
> Dear Victor and all
>
> A small update:
> - the problem has nothing to do with 64 bit
> - the problem has nothing to do parametercmd, but with
> namespaced variables (even worse)
> - the problem does not show up, when both xotcl and tcl are compiled
> against tcl 8.4.* or tcl 8.5.*
> - the problem shows only up, when xotcl is compiled against tcl 8.4 and
> loaded into a tclsh compiled with tcl 8.5
> - the problem is related to varReform, tcl refuses to delete the variables
> when TclDeleteVars() is called. It is not a tcl bug, but most likely
> related with the "forward-compatible" mode of xotcl (tcl 8.5
> variables are quite different to 8.4, but at the time xotcl is compiled
> against tcl 8.4, it does not know anything about the new variable
> structures/semantics; it tries hard to behave correctly, but obviouly,
> not hard enough).
>
> normally, i would be inclined to say "please take a matching version"
> (use xotcl compiled for 8.5 with a tclsh compiled with 8.5, etc),
> but since it is getting more and more likely, that xotcl 2.0 will require
> tcl 8.5 or newer, i'll try to look into the problem further, probably over
> the weekend
>
> all the best
> -gustaf neumann
>
> Gustaf Neumann schrieb:
>
>> Hmm,
>>
>> a quick test shows that it runs in constant memory (1.8 MB) with xotcl
>> 1.6.3 and
>> xotcl 1.6.4 under Mac OS X Leopard with Tcl 8.5.7. i just modified the
>> script
>> slightly to make it a complete script (see below).
>>
>> will check tomorrow on more platforms.
>>
>> -gustaf neumann
>>
>>
>> ==========================
>> set i 0
>> time {lappend ::parameter_list parameter[incr i]} 100
>>
>> Class X
>> X instproc init args {
>> my requireNamespace; ### I need that
>> foreach p [set ::parameter_list] {
>> my parametercmd $p
>> my $p {}
>> }
>> next
>> }
>>
>> time {X x; x destroy} 1000000
>> ==========================
>>
>> Victor Mayevski schrieb:
>>
>>
>>> Hello,
>>>
>>> I am using XOTcl 1.6.3, on 64bit Linux platform, with ActiveState
>>> 8.6.b2 distribution. The distribution itself is 32bit. I also tried
>>> and have the same problem with 32bit ActiveState 8.5.7 version.
>>>
>>> The simplest way to reproduce the problem is to do the following:
>>>
>>> Class X;
>>>
>>> set parameter_list {parameter1 parameter2 .... parameter100}; ### 100
>>> or so values
>>>
>>> X instproc init args {
>>> my requireNamespace; ### I need that
>>> foreach p [set ::parameter_list] {
>>> my parametercmd $p;
>>> my $p {};
>>> };
>>> next;
>>> };
>>>
>>> #then run the following
>>>
>>> time {X x; x destroy} 1000000
>>>
>>>
>>> ### the above line eats up a lot of memory and it is not being
>>> released during destruction of an instance.
>>>
>>>
>>> Thanks.
>>> _______________________________________________
>>> 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
>>
>>
>
> _______________________________________________
> Xotcl mailing list
> Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
>