Weblog Page

From: Gustaf Neumann <neumann_at_wu.ac.at>
Date: Thu, 22 Oct 2009 10:25:48 +0200

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
>

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Wed, 25 Apr 2001 13:14:56 +0200

On Tuesday 24 April 2001 20:25, Kristoffer Lawson wrote:
> On Tue, 24 Apr 2001, Gustaf Neumann wrote:
> 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.

 well, here is a quite a short and simple solution that might be sufficient
 for most situations:

====================================================================================
Class InheritClassProc
InheritClassProc instproc unknown {m args} {
  foreach c [[self] info heritage] {
    if {[info command ${c}::$m] != ""} {return [eval $c $m $args]}
  }
  next
}
Class instmixin InheritClassProc
====================================================================================

 one can add a ...if {![.. ismetaclass ...]} to avoid its call on the
 creation of classes.
 To test it in the originally posted problem, the following example calls
 for "B test ..." the proc of A, and creates a new object for "B test".

==================================================
Class A
A proc test {x y} {
  expr {$x*$y}
}
Class B -superclass A
puts result=[B test 47 11]
puts result=[B test1]
==================================================

 If you have a speed sensitive program, or you do not want to globber
 the space of object names, i would recommend to invoke the
 create method explizitly like "B create test1", or to create an
 instance of B named "test", use "B create test"

best regards
-gustaf

 

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Thu, 14 Oct 2010 09:29:00 +0200

  Dear Victor,

many thanks for the short example! i have compiled xotcl
1.6.6 with
my three test releases, the script runs fine in every version,
also valgrind did not report unusual happenings, but i tried
so far only with mac os x with 64bit.

i am slightly confused about the activestate version number
TCL 8.6.0.0b4. There was never a version of Tcl 8.6 b4 released
(or tagged on sourceforge). As you wrote, the tcl_patchLevel
is 8.6b1.2, which is the current HEAD release (and therefore
a moving target). Apparently, activestate uses its own tags.
Have you seen somewhere on activestate a source-release?

-gustaf neumann

On 14.10.10 08:21, Victor Mayevski wrote:
> 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
> _______________________________________________
> Xotcl mailing list
> Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl

From: Kurt Stoll <stoll_at_mac.com>
Date: Sun, 26 Feb 2006 08:39:54 -0800

(Sorry for the long post)

Well, I've perused the archives and can't find anything on this
topic. Nor can I find it in the tutorial or reference guide. So, I
must conclude that I am missing something. Either this is obvious,
and everyone has already figured this out. Or, there is no real need
for this type of a construct and I'm thinking about this incorrectly.

Many OO languages provide a means to make some methods be polymorphic
and some not. For example, C++ uses the virtual keyword to make a
function polymorphic; otherwise it's not. XOTcl on the other hand
appears to only support polymorphic methods. A call to a method from
a given level of the hierarchy starts from the class of the calling
object and works its way up (assuming next is used).

For example, a class Base provides an interface, then Sub1 and Sub2
(both subclasses of Base) provide a thin veneer on that interface.
The methods have the same name. And, in some cases, they rely on
Base to provide some of the functionality. But, Base provides its
own functionality by composing some of its own methods into more
complex methods. Now, when a method from Sub1 is called, it calls
that method in Base, and Base then calls another method within Base -
except that when it makes this call, it gets the version from Sub1.
In some cases, this may be the correct approach. But, there are
certainly cases where this is not desired.

We could try pushing some of the implementation from Base into Sub1,
but Sub2 wants similar functionality. This would mean duplicating code.

Another approach might be delegation, instead of inheritance. This
would work, but, all three classes (Base, Sub1, and Sub2) have
instances that share a common interface. Now, to add a new method to
that interface requires changing two different class hierarchies.
Again, this would work, but it just doesn't feel right.

I realize that this is a fairly abstract presentation of the issue.
I have attempted to come up with a simple example - for example,
geometric figures, with the base class rooting the centroid at the
origin to provide easy rotations. But, even here, this gets
complicated. and I'm afraid that the discussion will veer off to
trying to solve some particular quirk of the example. But, I have
run into this issue several times, and have found it frustrating.

The only solution that I have found is to provide both an "internal"
implementation and a public implementation of some methods (for
example, prefix the internal method name with an underscore). Then,
the implementation can decide whether it is wants to use the
polymorphic method or the non-polymorphic version. But, this doesn't
really solve the problem - I still have to be careful not to override
the internal version (because, I don't really have a non-polymorphic
method - I just have some conventions to avoid the polymorphism).
This could get truly complicated with a large class hierarchy, but
none of my constructs have reached the point (yet).

Actually, I can imagine a second potential solution, although I have
not tried it. I think it would work, but would be very ugly.
Nevertheless, I bring it up because I believe it might form the basis
of what I think would be an elegant solution to this problem. I
could temporarily change the class of the object to reflect where I
want the method search to begin from. Then, change it back when the
method returns. Artificially changing the class of an object makes
me cringe - I don't really like this approach.

But, it seems to me that if XOTcl can provide a way to force the
method search to begin at a particular class, this would fix the
problem. Maybe something like: [self as class] <method> <args>. In
fact, I think I can implement this as an Object method - simply copy
the class, change it, make the call, destroy the copy, and return the
result. I think this would work, and may try it. But, I still feel
like I must be missing something.

Any thoughts would be appreciated.

Thanks,
Kurt Stoll

From: Zoran Vasiljevic <zoran_at_archiware.com>
Date: Sun, 10 Mar 2002 13:18:23 +0100

Bugs in 0.9.3 and 0.9.4 for threaded (including AOLserver) builds.
The problem is that in Tcl, a strong marriage between the
Tcl interpreter and its accompaniyg thread exists.

Each time a new Tcl thread is starting, it may (AOLserver will!)
load the XOTcl_Init routine. This will patch couple of the
standard Tcl commands using the TclCommands function.
This function had an internal static counter, tracking
number of calls. On thread exit, this procedure was called
again and it did a reverse, replacing patched pointers with
original ones.


TclCommands(Tcl_Interp* in, int load) {
  int rc = TCL_OK;
  if (load) {
#ifdef USE_TCL_STUBS
    rc|= XOTclReplaceCommand(in, EXPR, 0, 0);
    rc|= XOTclReplaceCommand(in, INCR, 0, 0);
#endif
    rc|= XOTclReplaceCommand(in, SUBST, 0, SUBST_CMD);
    rc|= XOTclReplaceCommand(in, INFO, XOTcl_InfoObjCmd, 0);
    rc|= XOTclReplaceCommand(in, RENAME, XOTcl_RenameObjCmd, 0);
    rc|= XOTclReplaceCommand(in, UPLEVEL, XOTcl_UplevelObjCmd, 0);
    rc|= XOTclReplaceCommand(in, UPVAR, XOTcl_UpvarObjCmd, 0);
  } else {
    rc|= XOTclReplaceCommandCleanup(in, INFO);
    rc|= XOTclReplaceCommandCleanup(in, RENAME);
    rc|= XOTclReplaceCommandCleanup(in, UPLEVEL);
    rc|= XOTclReplaceCommandCleanup(in, UPVAR);
  }
  return rc;
}

>
> the results of the poll can be summarized as follows:
> - most people favored "names" instead of "symbols"
> for "selfDispatch"
> - the hottest favorite is "my". One can write now
>
> ...
> my instvar a b c
> my log
> ...
>
> instead of
> ...
> [self] instvar a b c
> [self] log
> ...
>
> the variant with [self] will continue to work
> forever..
> If someone is not happy with "my", please react
> soon.
>
> From the "volatile" front: we have now more-or-less Zoran
> suggestion implemented in C. Actually there is no need
> in general for using tcl-variables to implement volatile
> objects (we could handle this on a pop of stack frames),
> but at least for pure tcl-procs, var traces are the simplest
> implementation. The current implementation (purely in C)
> works as part of the "new" method:
>
> a) Object new ...
> b) Object new -childof ...
> c) Object new -volatile ...
> d) Object new -volatile -childof ...
>
> (a) creates "global" objects, not in the global
> namespace anymore, but in xotcl. (b) can be used
> to create objects as child of other objects (e.g. [self],
> the objects are deleted, when the specified object is deleted),
> (c) are "global" objects as in (a), but they are deleted,
> when the current tcl-proc/object-proc/instproc is left,
> and (d) is a combination of b and c.
>
> Needless to say, a-d works for classes as well as e.g.
>
> Class new -volatile
>
> in order to create "anonymoes" classes. The implementation
> of new is slightly faster than before, since i changed the
> nameing schema to be the same for all kind new ("__#122", ...),
> such that e.g.
> [Class new -volatile] new -volatile
> works as well. the disadvantage is that the neat
> classname derived names as in earlier versions have
> to be done by hand now...
>
> that was it for now
>
> best regrads
> -gustaf
> _______________________________________________
> Xotcl mailing list - Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl

From: Zoran Vasiljevic <zoran_at_archiware.com>
Date: Wed, 26 Sep 2001 17:24:27 +0200

On Wednesday 26 September 2001 17:19, Kristoffer Lawson wrote:
>
> Does this make sense at all?
>

I would say, yes, Yes, and YES!

Cheers
Zoran

From: Kristoffer Lawson <setok_at_scred.com>
Date: Tue, 18 May 2010 00:46:14 +0300

I've grown to hate all the web frameworks I've used (non-Tcl), and
OpenACS was always impenetrable for me, so I decided to create one
that reflects how I think a framework should operate. It's very early
development stuff, but it works and has some hopefully intriguing
ideas. And yes, it's all XOTcl. Check it out:

http://github.com/Setok/Spindle

-- 
Kristoffer Lawson, Co-Founder, Scred // http://www.scred.com/

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Mon, 05 Sep 2005 11:14:30 +0200

Taral schrieb:

> Hello,
>
> I recently came across XOTcl and found it very very useful. I am
> working on optimizing some legacy compiler code which is written in
> TCL. I would like to make it object-oritented and so I started using
> XOTcl. So far I have found aouut 90% reduction in execution time.
> Overall I'm getting great performance by using XOTcl.

wow, this is an impressive number; good to hear that.

> I would like to Thank You guys for writing such a great library.
>
> Of course I have couple of questions for you. I will really appreciate
> it if you can help me here.
>
> (1) Is there any way to all the objects or instances based on
> parameter value? For example, I would like to request object names of
> all objects where given parameter's value is equal to 5.

There is no built-in support for this. a straigthforward approach is the
following which might
be sufficient in many situations:

===========
# define method expr for all Objects, the operands are taken from
# the instance variables
Object instforward expr -objscope

# define method select with some abitrary tcl expression. All objects,
# for which the expression returns 1 are returned
Class instproc select {expr} {
  set result_list [list]
  foreach o [my allinstances] {
    if {![catch {$o expr $expr} result]} {
      puts "$o expr {$expr} -> $result"
      if {$result} {
    lappend result_list $o
      }
    }
  }
  return $result_list
}
===========

so, now we define a view classes and objects with some instance variables

   Class C -parameter {{x 10}}
   Class D -superclass C

   C c1
   C c2 -x 11
   D d1 -x 100
   D d2
   D d3
   d3 unset x

finally, we try it out with some demo queries

   foreach q {
     {$x > 10}
     {$x >= 10}
     {$x < 1}
     {[string match *00* $x]}
   } {
     puts "C select $q --> {[lsort [C select $q]]}\n"
   }

Note that in this example, all instances of C are checked for the
expression, if
you use "... [Object select {$x > 10}]", all objects will be checked.

This approach might be good enough for small examples and medium
speed requirements. If you have larger number of objects, and you cant
restrict the query to smaller classes, you should try to build an index
based on associative arrays, which could replace the "allinstances"
in the code above.

> (2) Do you have more example code pieces? I would like to see more
> sample implementation to help me with the syntax. I'm also learning
> TCL language at the same time using XOTcl :)

i am sure, you have seen the tutorial and the examples in xotcl*/apps
and xotcl*/library. There are a few more on:

  http://mini.net/tcl/XOTcl
  http://wiki.tcl.tk/references/10971!

> (3) Is there any way to represent relationship across two classes? For
> example, Class A is related to Class B with one-to-many relationship.

  a few class/class relations and object/class relations are maintained
by xotcl (e.g. superclass,
  class, mixins). A start point might be ::xotcl::Relations, which is
used to implement a
  uniform interface to mixins (and instmixins ...), which allows to
specify "... mixin add ...", #
  "... mixin delete ...", "... mixin set ...", etc. In principle, the
same interface could be used
  for application level relations as well...

 In current applications, the classes use and maintain a list of related
object/classes.
 Often, it is conveniant to use aggregations to express 1:1 or 1:n
relationships.

> (4) If there is a way to define relationship, is it possible to query
> objects of classes in the relationship? For example, I would like to
> get all the objects of Class B related to given object of Class A
> (like a1) across given one-to-many relationship. In this case result
> would be list of object handles of Class B that matches based on given
> primary key (identifier) value between class A and B.

a good key identifier is the object name. see the following snipplet,
how such behavior
could be obtained. We define class A, which maintains the relationship
to some other
objects. if an instances exists that relates e.g. to object c1, we could
check there some
properties with expr like above...

Class A -parameter {relates_to}

A a1
A a2

a1 set relates_to {c1 c2}

foreach o [A allinstances] {
  catch {
    if {[lsearch -exact [$o relates_to] c2] > -1} {
      puts "could check $o"
    }
  }
}

hope theses examples help a little.

-gustaf

PS: when i was writing this mail i saw that the classtack information
within methods called via the method "expr" is not correct. It will
be fixed in the next release....

>
> Please provide some guidance to implement above functionality using XOTcl.
>
> Thanks a lot in advance.
>
> May be in future I would like to contribute to XOTcl. I wish to be in
> touch with you guys.
>
> Regards,
> Taral

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Sat, 27 Nov 2010 14:50:53 +0100

Hi Victor,

you are most probably using a version of Tcl 8.6 with the
"saner NRE" patch of Miguel Sofer from end of Sept, which
changed the argument list of that function. It seems, that
someone has merged this patch to CVS head recently.
Currently Tcl 8.6b1 has no means to detect this version, but
it will change, once 8.6b2 is out.

Until then, please uncomment the line

   #define NRE_SANE_PATCH 1

in generic/nsfInt.h

-gustaf neumann


On 27.11.10 04:48, Victor Mayevski wrote:
> Hello Gustaf,
>
> I have the following problem when trying to compile NX on freshly
> installed Linux x86 system against latest TCL 8.6 from SourceForge
> CVS.
>
> ./generic/nsf.c: In function ‘MethodDispatchCsc’:
> ./generic/nsf.c:6959: error: too many arguments to function
> ‘tclIntStubsPtr->tclNRRunCallbacks’
> make: *** [nsf.o] Error 1
>
>
> Thank you
>
> _______________________________________________
> 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, 23 Jan 2001 01:17:34 +0200 (EET)

It's amazing how clever you get after you've just sent a vague bug report.
Here's the problem:


[~] package require XOTcl 0.81
[~] Class Foo
Foo
[~] Foo instproc init {} {
[self] destroy
safohasofhisa
}
[~] Foo ob
destroy failed (probably wrong # args?) or object called after physical
destroy while evaluating {Foo ob}

Ie. the Tcl bytecode should cause an error when it executes init because,
of course, safohasofhisa is not a valid command. This is apparently not
picked up by XOTcl. So I had an error in my callback method further along
the method, but I never received the error but just got that "destroy
failed" thing.

Am I right in believing this has something to do with the previous bug
report I sent with the funny inits and destroys that caused a segfault...?

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