Weblog Page

From: Patrick F. Proché <h8853209_at_wu-wien.ac.at>
Date: Wed, 6 Nov 2002 11:22:44 +0100

Hallo,

ich habe XOTcl auf einen Win2000-Rechner am Institut installiert - schauen
Sie mal an einem Nachmittag vorbei, meine DW ist 4466.

Grüsse, Patrick Proché
  -----Ursprüngliche Nachricht-----
  Von: xotcl-admin_at_alice.wu-wien.ac.at
[mailto:xotcl-admin_at_alice.wu-wien.ac.at]Im Auftrag von Arthur Fleischmann
  Gesendet: Dienstag, 5. November 2002 18:42
  An: xotcl_at_alice.wu-wien.ac.at
  Betreff: [Xotcl] Probleme bei XOTcl unter Windows


  Hallo!

  Da ich leider zuhause kein Linux installiert habe, wollte ich die
Win-Version von XOTcl installieren...
  Hat das irgendjemand geschafft? Bei mir haut's leider nicht ganz hin. Ich
kann zwar mit Startmenü-Ausführen-xotclsh bzw. Startmenü-Ausführen-tclsh die
jeweiligen Shells aufrufen, das gleiche funktioniert aber leider nicht aus
dem DOS-Fenster (Eingabeaufforderung), obwohl die PATH-Variablen richtig
gesetzt sind.Das wäre aber notwendig, um ein *.tcl Programm aus dem
DOS-Fenster auszuführen.

  Die eigentliche Installation hat gaube ich funktioniert, bin so
vorgegangen, wie auf der Homepage beschrieben, zuerst Tcl (ActiveTcl
8.3.4.4) installiert, dann XOTcl runtergeladen + entpackt, dann InstallWin
ausgeführt: es öffnet sich ein Fenster "InstallWin" ohne Inhalt (?) aber
xotclsh.exe befindet sich danach im Verzeichnis C:\Programme\Tcl\bin - das
sollte also passen.

  Kann mir vielleicht irgendjemand weiterhelfen - vielleicht gar der
geschätzte LV-Leiter? :)

  Danke, mfG,

  Arthur

  PS: Windows Version ist Win2kPro

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Tue, 29 Mar 2005 16:41:19 +0200

ben,

performing the mapping in a single step as in your mail is certainly
possible,
with the restriction that one needs a heuristic to locate object references.
A pretty simple approach is the following, but objects references might
contain
spaces, the references might be embedded in strings or composed on
the fly.

proc references o {
  set refs [list]
  foreach v [$o info vars] {
    foreach val [split [$o set $v]] {
      if {[string match ::* $val] && [::xotcl::Object isobject $val]} {
    lappend refs $val
      }
    }
  }
  return $refs
}

Another approch is to locate references to autonamed objects
with the an regexp containing "::__#" .

The more complicated issue is when one implements a persistent
object store that tries to maintain references to autonamed objects,
where some references are to autonamed persistent objects and others
are to non-persistent objects. In this case, multiple serialized strings
are maintained in a database and recreated on the fly. Say:
===============================
set n0 [Object new]
set n1 [Object new]
set n2 [Object new]

$n0 set x $n1
$n1 set x $n2
$n2 set x $n0

set s1 [Serializer deepSerialize $n0]
set s2 [Serializer deepSerialize $n1]
set s3 [Serializer deepSerialize $n2]
===============================
where $n0 and $n2 are in the persistent store, the user creates in his
program arbitrary new objects and wants to recreate $n0 and $n2
at some arbitray time in some arbitrary order. Here the mapping table
from "persistent autonames" to actual autonames has to be maintained
in some variables.

A suitable approach could be to follow Zoran's ttrace: One could
map object references to some special persistent autonames and usr
an unknown handler to create these instances on demand on the fly.
To create these persistent autonames, one would not need some
heuristics, but could use a tailored "new" method for persistent
objects. This "new" can already maintain the mapping dictionary.

-gustaf
PS: indepent from this, we need a "new" that does not overwrite
existing autonamed objects.

Ben Thomasson schrieb:

>Gustaf,
>
>It is possible to handle autogenerated names, but maybe not in an
>efficient way. The serializer can walk the object-graph of
>associations and build a list of objects that exist in that graph.
>With this list you can provide a mapping from one "reference-space" to
>another. I have written a prototype serializer that handles
>associations in this fashion. It uses an intermediate
>reference-space. Ex.
>
>original -> intermediate -> new reference-space
>::xotcl::__#0 -> ::xoserialize::serial0 -> ::xotcl::__#5
>
>However walking the object graph is somewhat inefficient as I am
>looking through the
>data for references to objects. It would be much faster if Object provided an
>info associations, but I am not sure how this could be implemented.
>
>Because Tcl lacks explicit pointers or references and instead uses
>handles which are just strings, serializiation using associations will
>be very inefficient. However can the included serializer which
>supports composition handle an arbitrary object graph? Or am I
>restricted to tree structures?
>
>Thanks,
>
>Ben
>
>
>On Tue, 29 Mar 2005 11:36:24 +0200, Gustaf Neumann
><neumann_at_wu-wien.ac.at> wrote:
>
>
>>Dear Aamer,
>>
>>the general problem is quite tricky, when one serializes and saves some
>>objects
>>(e.g. containing ::xotcl::__#0), ends and restarts xotcl, creates again
>>global
>>objects with 'new' and restores the saved state containing the object
>>mentioned
>>above. 'Serialize all' does not save objects from the ::xotcl namespace,
>>but certainly
>>people can use -childof...
>>
>>The most simple solution is to remember the highest allocated id with the
>>saved state in serialize all, to provide a function to reset it and
>>leave the problem
>>to the programmer. But still, this is no good solution, if multiple save
>>states are
>>used and loaded in arbitary order.
>>
>>A better solution is to
>> a) check in 'new', whether an object with the generated autoname
>>exists already, and
>> b) provide a wrapper for loading the serialized code that extracts all
>>patterns
>> of autonames, and remaps some or all symbols if necessary (for
>>handling preexisting
>> objects with autonames). This could be done by searching for
>>autoname patterns
>> during serialization and using similar to the -map option of the
>>Serializer....;
>> but still, this only works, when the autonamed objects are
>>serialzed; for references
>> in variables we would need a global map table, which is still
>>depending on the
>> restore order of the serialized code if multiple pieces are saved.....
>>
>> What are you trying? would (a) be sufficient for you? It is slightly
>>slower than the
>> current version, but i don't think it is worth adding another option to
>>new for checking
>> on demand...
>>
>>best regards
>>-gustaf neumann
>>Aamer Akhter schrieb:
>>
>>
>>
>>>I just tried this with 1.3.6 and it appears to be working. Sort of
>>>related question, how do people handle the swizzling/unswizzling of
>>>autogenerated object names (eg ::xotcl__#0) when restoring an object?
>>>
>>>
>>>
>>>
>>_______________________________________________
>>Xotcl mailing list
>>Xotcl_at_alice.wu-wien.ac.at
>>http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
>>
>>
>>

From: Mykhaylo Sorochan <msorc_at_bigmir.net>
Date: Wed, 17 Dec 2008 10:02:21 +0200

Hello,

I'm going to use counted (http://wiki.tcl.tk/3137) in java2tcl
(http://wiki.tcl.tk/22102) as a garbage collection solution.
I will appreciate any feedback about issues/problems on counted usage with
XOTcl.

-- 
Regards,
Mykhaylo Sorochan

From: Uwe Zdun <uwe.zdun_at_uni-essen.de>
Date: Mon, 21 May 2001 19:00:47 +0200

Hi,

We think that it is (in some cases) a good idea to have something like that.
We're especially interested in having scoped objects, as your example down
below suggests. That is, objects that persist as long as the proc scope
persists. And -- like you -- we believe string based object referencing is a
great strength of XOTcl ... therefore, we wouldn't like to have a general
garbage collector (which would mean, no string refs anymore).

I'm not sure that Tcl_Objs are the best implementation variant for such a GC
scheme, because of (a) shimmering (which may cause at least heavy performance
problems) and (b) if some string with the same name exists, the object does
not get deleted.

Scoped objects could be quite easily done in XOTcl using the XOTcl callstack
in C. That is, reference the scoped objects on the XOTcl callstack and then
delete them in CallStackPop ... the disadvantage of this is that only XOTcl
procs and instprocs could have scoped objects, not Tcl procs as in the
example down below. Probably that won't hurt so much ...

Regarding our plans ... the next steps are:
- we work on the patch release (tomorrow ready, hopefully)
- I work on a re-implementation of the filter implementation ... we want to
have a better implementation & support per-object filter & linearization of
filters (as for mixins). This will take a while, since I'm travelling alot
these days ;)

Feel free to contact us, if you need any assistance.

--Uwe


On Sunday 20 May 2001 12:39, Artur Trzewik wrote:
> Hi
>
> The really problem of Xotcl is, it has no garbage collector.
> It means you must destroy your object yourself per destroy method.
>
> The garbage collector of such languages as Java, smalltalk, ruby work by
> tracking references to one object. if no reference point to object, this
> object is destroyed.
>
> This would not work by xotcl. Xotcl object are localized per name (string)
> and no reference. (And it is very flexible in most cases)
> It can by hardly changed.
> It is pity, if one consider that tcl has internal full garbage collector
> based on Tcl_Obj (structure) with references counter.
>
> This problem is no so dramatic if one use object aggregation.
> So the aggregated object is deleted automatically if parent object
> is to be destroyed.
> But is can be rather hard by using "short-live" object (for example by
> implementing special data structures in Xotcl).
>
> The solution of this problem can be to add new create method in Xotcl.
> To create object to use only as reference.
> It means object lives only so long if the reference exist.
> It will use internal standard tcl structures (as Tcl Stings, Integer,
> Arrays)
>
> example usage
>
> proc exampleScope {} {
> # create short-live Object for reference
> set ref [Object newReference]
> # using object
> $ref set var 11
> # be exit the object referenced by variable ref
> # will be deleted automatically
> }
>
> The best think is one can choose to use garbage collector
> or not.
>
> >Object newReference
>
> will for example create one object and destroy it immediately.
> So in such case the old method
>
> >Object new
>
> should be used.
>
>
> Internal implementation.
>
> The main thing is to tread Xotcl objects in the same way
> as other tcl objects (Stings, Interger, Array) and use tcl garbage
> collector I thing there should be a wrapper Tcl_Obj (new Type)
>
> Here only the main idea
> static Tcl_ObjType XOTclReferenceObjectType = {
> "XOTclReferenceObject",
> (Tcl_FreeInternalRepProc *) ourNewDestroyMethod,
> (Tcl_DupInternalRepProc *) NULL,
> UpdateStringOfXOTclObject,
> SetXOTclObjectFromAny
> };
>
> The newReference method must create such reference Tcl_Obj
> and return it as result. Of course newReference must be implemented
> in C in libxotcl.so.
>
> What do you think about it?
> I mean I can implement it but I am not sure how it would suite to another
> concepts or future plans.
> For example for xotcl objects created per newReference the destroy method
> make no sense.
> It can make also another problems that should be discused.
>
>
> =========================================
>
> Artur Trzewik
> http://www.xdobry.de
>
> =========================================
>
> _______________________________________________
> Xotcl mailing list - Xotcl_at_wi.wu-wien.ac.at
> http://wi.wu-wien.ac.at/mailman/listinfo/xotcl

-- 
Uwe Zdun
Specification of Software Systems, 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

From: Aamer Akhter <aakhter_at_gmail.com>
Date: Sun, 27 Mar 2005 02:17:43 -0500

Hello,

I seem to be missing something basic in the usage of Serializer:

package require XOTcl
namespace import ::xotcl::*
package require xotcl::serializer
set a [Object new]
$a set b hello
Serializer deepSerialize $a

the last command doesn't seem to return anything. I had expected the
creation and config code for $a. What am I missing?

-- 
Aamer Akhter / aakhter_at_gmail.com

From: Gustaf Neumann <Gustaf.Neumann_at_wu-wien.ac.at>
Date: Mon, 5 Feb 2001 22:55:57 +0100 (CET)

>>>>> "KL" == Kristoffer Lawson <setok_at_fishpool.com> writes:
KL> On Mon, 5 Feb 2001, Gustaf Neumann wrote:
>> Somehow, i have the feeling, that Kristoffer intended a class to the
>> method "whatever". Why not use:
>>
>> Class Bar -superclass Foo
>> Bar instproc init {} {
>> next myArg
>> [self] whatever niceSystem
>> }

KL> Because the "whatever" method should be called along with the object
KL> creation -- and specifically before it takes place. Just as if I had
KL> created an object of the superclass with -whatever in the init line.


 The "-methods" are not executed by init, but by create . The Class
 allocs the objects, obtains default values, calls the "-methods" and
 finally calls init (if it was not triggered by -init in the "-methods").

 If you say that the execution of "whatever" should happen before
 init, and you want to magically add "-methods", i would recommend to
 refine the create method....

 -gustaf

From: Andriy Tkachuk <ant_at_imt.com.ua>
Date: Wed, 17 Apr 2002 18:46:34 +0300 (EEST)

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.

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Thu, 18 Jan 2001 20:31:44 +0200 (EET)

On Thu, 18 Jan 2001, Uwe Zdun wrote:

>
> After an object has left the callstack once, it is in the responsibility of
> the application to care for correct destroys. If that ain't the case,
> probably we have a bug here? Its hard to tell with the given information ...
> if you could isolate a smaller script & send it to me, it would be easier to
> tell what the problem is & how to solve it.
>
> Unfortunately, its nearly never easy to spot problems with complex
> (asynchronous) object destroys ;)

Yes, this is exactly why explaining, and even reproducing the
problem is difficult. In any case, I do believe we probably have
found a bug, as a method is being run and while it is run at some point
it gets a message that [self] called after destroy, or something
like that. Thus we've had to work around this in a rather complex
fashion. I'll try to explain it as best I can:

A method "event" of object "ob" is called as a result of an external
event -- like user input. This object then reads protocol data from a
socket and acts on commands sent to it. These commands it executes
via another different object "ob2". In our case, one of these commands
happens to be a RM command, which after sending to this ob2 results in ob2
calling the destroy method for ob. After this calls to [self] inside the
"event" method (which is still running at this point) cause an immediate
error.

Do you think you can work that out? ;-)

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

From: Ben Thomasson <ben.thomasson_at_gmail.com>
Date: Fri, 30 Sep 2005 23:00:02 -0400

I recompiled tcl8.4.10 and xotcl1.3.6 for -DTCL_MEM_DEBUG=1 -g and -00 and
then run valgrind on the attached scripts. Unfortunately I couldnt find
anything in the debug outputs to pin point the problem. However I did find
that the scripts memLeakMixin and memLeakMultiMixin do increase memory over
time. memLeakClass does not increase memory over time.

It seems that the memory leak is related to the number of instmixins on the
class A. memLeakMulitMixin uses far more memory than does memLeakMixin.

Any suggestions where to go next?

Ben



On 30/09/05, Zoran Vasiljevic <zv_at_archiware.com> wrote:
>
>
> Am 30.09.2005 um 20:15 schrieb Jeff Hobbs:
>
> > We have
> > a copy that I have used many times. Valgrind comes close,
> > finds different things, but I still prefer Purify. Valgrind
> > is free though, so there's not excuse not to try that.
>
> Unfortunately (as you already know) ...
> Those will not report regular memory usage (C-wise) when
> you just expand an array, extend the list, flood the event
> loop, forget to destoy objects, etc. pp., indefinitetly.
> Hence, I found the Poor Man's Purify ([time] + glancing at
> the top display) equaly useful.
>
> What I believe, (under assumption that Ben is using only
> Tcl/XOTcl code) is that he's hitting something like the
> above. I had those problems en mass until I persuaded
> Gustaf to make the "-volatile" mechanism in XOTcl...
>
> Zoran
>
>

--
You know you have reached perfection of design not when you have nothing
more to add, but when you have nothing more to take away. --Antoine de Saint
Exupéry

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Wed, 28 Feb 2001 03:39:31 +0200 (EET)

(version: 0.83)

Class Foo

Foo instproc destroy {args} {
  puts "destroy args: $args"
  next
}

Foo instproc method {args} {
  puts "method args: $args"
  next
}

Foo instproc filterProc {args} {
  puts "filter args: $args"
  next
}

Foo filter filterProc

[~] ob method suk
filter args: suk
method arg: suk

[~] ob destroy blah
filter args: blah
destroy args:

Without the filter the arguments to destroy are sent as normal. So the
filter is having some effect on how destroy is handled. Also, I've
received the following error when playing around with this situation:

invalid command name "self"
    while executing "self"
    invoked from within "puts stderr "[self]: Error in instproc destroy
         $::errorCode $::errorInfo""
    invoked from within
"ob destroy data"

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