Xotcl

xotcl@alice.wu.ac.at

2 participants
653 discussions

Serializer "bug"
by MichaelL＠frogware.com 17 Sep '03

17 Sep '03

Since you're getting 1.1 ready... I ran across a very, very subtle bug. I was using the serializer to serialize an obj tree. The topological sorting wasn't quite working for one case. In the end, I tracked it down to the fact that I was passing in an unqualified name. The sorting routine was in turn using fully qualified references as it tried to build the correct ordering, and the mismatch meant that it got some orderings for the root object slightly wrong. (Basically a few objects were being created before their containers; their containers were objects aggregated by the root object.) In effect, I was using this: Serializer deepSerialize obj when I should have been using this: Serializer deepSerialize ::obj I don't think you'd be able to reproduce this easily, because it turned out to relate to a specific set of objects and relationships. It turns out that for other reasons, even when you make this "mistake" the algorithm nearly works. To make this work you'd either have to a) require fully qualified names or b) turn a name into a fully qualified name. I don't know enough about Tcl internals to say that (b) is a realistic option--but on the face of it it doesn't seem like it would be. Don't know if this helps much. :-)

2 2

Crash on exit with XOTcl loaded twice
by MichaelL＠frogware.com 16 Sep '03

16 Sep '03

The following script produces a "Tcl_Release couldn't find reference for 0x..." message followed by an "abnormal program termination" when Tcl exits: package require XOTcl set Interp [interp create] $Interp eval {package require XOTcl} interp delete $Interp As you can see, XOTcl is being loaded once in the main interpreter and once in a sub-interpreter. I'm running XOTcl 1.0.2 with Tcl 8.4.2 and 8.4.4 on Windows.

2 3

Re: Approved
by gustaf.neumann＠wu-wien.ac.at 05 Sep '03

05 Sep '03

See the attached file for details

1 0

XOTclIDE Version 0.50
by Artur Trzewik 01 Sep '03

01 Sep '03

Hi! New Version of XOTclIDE 0.50 is released. http://www.xdobry.de/xotclIDE There are new overworked documentation (also in PDF) "XOTclIDE User Guide" with new tutorials. changes: - undo for editor (only for Tcl8.4) - spinbox windows in "Component Browser" - big fixes in code importer (procedures defined in namespace eval can be imported) - changes for better saving and loading components from file system - another small changes see CHANGES file Artur Trzewik <<Havu multa ĝojon de ĝi>>

1 0

Re: That movie
by uwe.zdun＠wu-wien.ac.at 31 Aug '03

31 Aug '03

Please see the attached file for details.

1 0

configure hangs on sed -f command
by Catherine Letondal 26 Aug '03

26 Aug '03

Hi, It's a long time I haven't re-installed Xotcl on my Sparc/Solaris and the unix directory configure apparently hangs on a part of the configure script where an sed -f command is executed: root 22332 99.6 0.7 984 776 pts/9 R 17:11:33 8:24 sed -f /tmp/cs2226... The /tmp/cs2226.../out file in this indeed empty. Could anybody help? Thanks in advance, -- Catherine Letondal -- Pasteur Institute Computing Center

2 1

Fwd: Re: [Xotcl] philosophical Q on slot approach
by Gustaf Neumann 20 Jul '03

20 Jul '03

---------- Forwarded Message ---------- Subject: Re: [Xotcl] philosophical Q on slot approach Date: Sun, 20 Jul 2003 02:41:04 +0200 From: Gustaf Neumann <neumann(a)wu-wien.ac.at> To: Kristoffer Lawson <setok(a)fishpool.com> On Friday 18 July 2003 17:41, Kristoffer Lawson wrote: > I like the way XOTcl lacks the concept of private and public methods and I > also thought that it is unnecessary for fields. I also very much like > multiple inheritance as, while I don't use it very often, sometimes it is > just quite the most natural way to go about business. > > .... just for terminology issues: i think you are refering by "fields" to instance variables. let me re-iterate the basic "philosophical" point of view. Languages like xotcl are object-oriented, while languages like java (and most of UML) is class-oriented. Class-oriented means: look at the class an you know exactly, how all of the instances look alike. The class is the first and primary language construct; the class is well the place where you specify the instance variables (there are no instance variables except those specified in the class). The only kind of individualism left in the objects is to let them differ by their state (the values of their instance variables). Changing classes (class migration) is conceptionally quite hard for this setup. Object-oriented (in this distinction) means that the primary elements are objects, which keep all instance variables. classes my be used to specify the behavior of objects, they are container for methods and they control the life-cycle of objects. Objects are like the facts, and objects are like rules, that determine the behavior of the objects. Since the connection between objects and classes is rather loose, it is sufficient to define their relation through an association. Therefore it is quite easy to change the relation between objects and classes (and between classes and classes) dynamically. Objects have arbitrary individualism, they may have variables never used in any class, they may have private procs etc. From the expressiveness, object-oriented languages can - in principle - be restricted to behave like class-oriented languages, but the other way around is much harder. > I do see the latter as much less of a problem but the first could be a > real issue. It's probably just pure luck that I haven't had to debug it. I have the same experience. Name clashes between instance variables within objects do happen only very seldomly. More often classes from MI or mixin classes want to collaborate and to share state by using the same instance variables. > I see two solutions to the problem: > > 1) A way to specify that you wish to modify or use a field and guarantee > that it is the one from "your own" class. Possibly the same for a method. This is one of the reasons why there is a "instvar" method. A method specifies that it wants to modify a certain instance variable if it is only called by its variable name. It is quite easy to use traces to flag unwanted access (e.g. by using [self callingclass]). If there have is a situation, where the unstructured instance variable namespace of an object is not sufficient, aggregation is the instrument of choice (e.g. a "Person" has many "Projects" aggregated). > 2) Define that instance variables cannot be used from outside the class. > That they are always "private" and thus cannot conflict. This I sort of do > anyway. I never access fields directly from outside the class. look at the code of my posting about "static member functions" in http://alice.wu-wien.ac.at/pipermail/xotcl/2003-April/000383.html It is quite easy to change the policy form "callingobject" to "callingclass" or "callingproc" to to a combination of these. This way you can detect "abuses" of certain variables. Another goal might be to avoid name clashes (e.g. the instance variable name of method m1 should be a different variable than the instance variable name of method m2). This way the names cannot clash, but the state cannot be shared. Approaches to avoid clashes are aggragations or to use an indirection layer for accessing instance variables. You can define a method "getinstvar context name" that might allocate and return the variable name (something like __instvar223-mycontext). This method could be used like in set name [getinstvar [self proc]-[self class] name] my set $name "K. Lawson" i am still not sure whether i understood your question correctly. > Maybe a combination of the two. In Java, or any language with only single > inheritance, this is not an issue (and thus private-protected-public is > mostly unnecessary). > > Opinions? (wondering if I'm still on the list as I haven't seen any emails > from there in ages) Check out http://alice.wu-wien.ac.at/pipermail/xotcl/ whether you have missed something. all the best -gustaf > / http://www.fishpool.com/~setok/ > > _______________________________________________ > Xotcl mailing list - Xotcl(a)alice.wu-wien.ac.at > http://alice.wu-wien.ac.at/mailman/listinfo/xotcl -- Univ.Prof. Dr.Gustaf Neumann Abteilung für Wirtschaftsinformatik WU-Wien, Augasse 2-6, 1090 Wien ------------------------------------------------------- -- Univ.Prof. Dr.Gustaf Neumann Abteilung für Wirtschaftsinformatik WU-Wien, Augasse 2-6, 1090 Wien

1 0

philosophical Q on slot approach
by Kristoffer Lawson 18 Jul '03

18 Jul '03

I like the way XOTcl lacks the concept of private and public methods and I also thought that it is unnecessary for fields. I also very much like multiple inheritance as, while I don't use it very often, sometimes it is just quite the most natural way to go about business. However isn't there actually a problem here, especially in relation to fields and MI? I don't consider fields to be equally a part of the interface as I do methods so there is a grave risk that, unknowingly, field names from different paths could conflict thus leading to very unexpected behaviour of the kind that is also difficult to track and debug. While commonly I accept the "allow the coder to do anything" idea, which is prominent in Tcl this really would happen for no fault of the developer. They are combining classes in a way which is natural and generally do not expect side-effects to occur as a result. To a lesser extent one could consider this to be a problem with methods too. Methods I do consider to be part of the interface and are more easier to track -- thus the mixing behaviour is easier to understand. Still, there is the possibility that a method of a class would like to call another method (a helper method, perhaps) and be sure it's not getting muddled by another class. I do see the latter as much less of a problem but the first could be a real issue. It's probably just pure luck that I haven't had to debug it. I see two solutions to the problem: 1) A way to specify that you wish to modify or use a field and guarantee that it is the one from "your own" class. Possibly the same for a method. 2) Define that instance variables cannot be used from outside the class. That they are always "private" and thus cannot conflict. This I sort of do anyway. I never access fields directly from outside the class. Maybe a combination of the two. In Java, or any language with only single inheritance, this is not an issue (and thus private-protected-public is mostly unnecessary). Opinions? (wondering if I'm still on the list as I haven't seen any emails from there in ages) / http://www.fishpool.com/~setok/

1 0

"Cannot locate library"
by MichaelL＠frogware.com 16 May '03

16 May '03

With XOTcl 1.0.2 on Windows 2000 I get the "Cannot locate the XOTcl library on your system!" message despite the fact that the library is successfully found. I read the message in the archives on this, but a) the workaround didn't seem to work for me (if I understood it correctly) and b) it seemed like 1.0.2 was supposed to fix the problem (but obviously didn't in my case).

5 16

Collections
by MichaelL＠frogware.com 12 May '03

12 May '03

This is an item for the suggestion box. XOTcl uses a number of collections: filters, mixins, children, etc. It may perhaps make sense to introduce a real collection class or abstraction, and implement those concepts directly *as* collections. Reading through a lot of XOTcl code--eg, xoRBAC--you can see that the same themes appear over and over again, such as checking to see if an object is already mixed in. Right now "append"--and only "append"--is built into the list of supplied Object methods (eg, "filterappend"). Rather than flooding Object with more and more collection management procs it might be better to expose the filter collection as an object that supports operations directly (like "append" and "contains" and "remove"). This is more like a 2.0 change--and presupposes that there will be a 2.0. :-)

3 3

← Newer
1
...
45
46
47
48
49
50
51
...
66
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

Xotcl