Weblog Page

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Fri, 19 Oct 2001 13:57:46 +0300 (EEST)

On Fri, 19 Oct 2001, Gustaf Neumann wrote:

>
> the xotcl binaries are built with tcl 8.3.2.
> therefore it should work without compiling only with
> 8.3.

Shouldn't stubs remove this problem? Or have you not yet been able
to move the code to use only stubs?

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

From: Gustaf Neumann <neumann_at_wu.ac.at>
Date: Fri, 23 Oct 2009 14:44:35 +0200

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
>

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Sun, 26 Feb 2006 19:52:11 +0100

You are right with your observeration, all methods in xotcl are polymorphic.
This is important for orthogonality, especially, when methods
invocations are
interceptable as with mixin classes or filters. Here is a small example,
which
i think demonstrates your argument. correct me, if you have
something different
in mind.

============
Class Base
Base instproc foo {} {
  puts "[self class] [self proc]"
  my bar a b
}
Base instproc bar {x y} {
  puts "[self class] bar $x $y"
}

Class Sub -superclass Base
Sub instproc bar {x y} {
  puts "[self class] [self proc]"
}

Sub b1
b1 foo
============

the invocation of "b1 foo" calls Base->foo, the invocation of "my bar a
b" calls Sub->bar,
your question is, how to call Base->bar instead (like for c++
non-polymorphic methods)

As you pointed out, there are many ways to tweak the behavior. The
important point
is, how should/could some kind of non-polymorphic call lead to some
"defensible
semantics", esp. how should it behave it should behave in cases of e.g.
next, or
with the presence of interceptors.

The most rude apporach is to use tcl-functions instead of methods and bypass
this way the xotcl dispatcher. Since every xotcl method is a tcl proc, this
is doable with some little magic:

==============
proc myown {proc args} {uplevel ::xotcl::classes[self class]::$proc $args}
...
Base instproc foo {} {
  puts "[self class] [self proc]"
  myown bar 1 2
}
...
==============

Here, myown calls Base->bar, not Sub->bar.
This is the archetype of a monoporphic call.

The downside is that the invocation of the method happens in the same
xotcl frame. You might or might not be concerned about this. "logically",
"bar" is invoked in Base->foo, and does not leave the callframe. Queries
and calls based on the xotcl stack will reflect this, a [self proc] in bar
will still return "foo", a next will call shadowed methods of "foo".
By bypassing the xotcl dispatcher, filters and mixins will not be able
to intercept the invocation of "Base->foo".


Another approach, as you indicated is to alter the relation between
the class and the object temporarily.

==============
proc as_my_instance args {
  set __oldclass [my info class]
  my class [uplevel self class]
  set r [uplevel my $args]
  my class $__oldclass
  set r
}
....
Base instproc foo {} {
  puts "[self class] [self proc]"
  as_my_instance bar 1 2
}
...
==============

while this is something which looks strange to somebody with
a c++ background, this is not so far fetched, if one keeps in mind
that the relation between an object and a class is just an
association (like a pointer in c). The semantics are less
wierd than these of the first approach: The invocation of
"as_my_instance" means that everything dispatched behaves
as if the object would be an instance of the current class.
This will work nicely all other constructs like "next", etc.
One should actually put a catch around the invocaton of
the method....
 

Finally, the question should be adressed, whether or
not the non-polymorphic call is needed. Who should
call "bar" aside from "foo"? If this is something special
to this class, why not model this as a proc of Base:

==============
Class Base
Base instproc foo {} {
  puts "[self class] [self proc]"
  [self class] bar 1 2
}
Base proc bar {x y} {
  puts "[self ] [self proc] $x $y"
}

Class Sub -superclass Base
Sub proc bar {x y} {
  puts "[self class] [self proc]"
}

Sub b1
b1 foo
==============
If the behavior of "bar" needs inheritance etc,
meta-classes or mixinclasses can be used. Again,
there is no strange intererence with other xotcl
mechanisms.

all the best
-gustaf neumann

From: Murr, Florian <florian.murr_at_siemens.com>
Date: Wed, 1 Mar 2006 09:02:20 +0100

In XOTcl (1.3.8) there seems to be no initialisation of parameters
during dynamic class change.
See code below: a1 and a2 behave differently.

Is this the intended behaviour?

- regards, Florian



package require XOTcl
namespace import xotcl::*
eval [string map {INFO {[self] [info level 0] : [my info class] : [my
info vars]}} {
    Class A -parameter {
        {p 0}
    }
    A instproc pp {} { puts "A INFO"; next }
    
    
    Class B -superclass A -parameter {
        {q 0}
    }
    B instproc pp {} { puts "B INFO"; next }
}]

proc main {} {
    set strich
"--------------------------------------------------------------"

    puts $strich
    A create a1 -p a1
    a1 class B
    #a1 init
    a1 pp
    #puts "a1 q = [a1 q]" ;# should this be an error?

    puts $strich

    A create a2 -p a2
    a2 class B
    a2 q xx
    a2 pp
    #puts "a2 q = [a2 q]"
    puts $strich
}
main

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Mon, 5 Feb 2001 22:58:48 +0200 (EET)

[~] Class Foo
[~] Foo instproc init {arg} {
puts "arg: $arg"
}
[~] Foo instproc whatever {system} {
puts "sys: $system"
}
[~] Class Bar -superclass Foo
[~] Bar instproc init {} {
next myArg -whatever niceSystem
}
[~] Bar ob
called "next" with too many arguments

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

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Sun, 30 Nov 2003 01:49:45 +0100

On Sunday 30 November 2003 00:45, Marc Spitzer wrote:
> Now the files that are "missing" are in /usr/local/include/tcl8.4:
>
> bogomips# cd ../tcl8.4
> bogomips# ls
> generic tcl.h tclDecls.h tclPlatDecls.h unix
> bogomips# ls *
> tcl.h tclDecls.h tclPlatDecls.h
>
> generic:
> regcustom.h tclDecls.h tclMath.h
> regerrs.h tclIO.h tclPlatDecls.h
> regex.h tclInitScript.h tclPort.h
> regguts.h tclInt.h tclRegexp.h
> tcl.h tclIntDecls.h
> tclCompile.h tclIntPlatDecls.h
>
> unix:
> tclUnixPort.h tclUnixThrd.h
>
> so how hard would it be to add a --with-tclinclude ?

 this is not hard. i will send you a version with that option with
 separate mail.

> Also I would need to do this for tclsh and wish(do I need to do wish?),

there is no need for wish

> on freebsd they are both shell scripts that tel you what you have installed
> not the real tclsh, like so: bogomips# tclsh
> In FreeBSD, tclsh is named with a version number. This is because
> different versions of tclsh are not compatible with each other and
> they can not all be called "tclsh"! You may need multiple versions
> installed because a given port may depend on a specific version.
>
> On your system, tclsh is installed under at least the following names:
>
> tclsh8.3
> tclsh8.4

 this is not unusual. the name of the tclsh is deterimined by
 configure throught the configure macro SC_PROG_TCLSH.
 on my system, the tclsh is determined as

    TCLSH_PROG = /usr/bin/tclsh8.4

 One can use an arbitraty shell my invoking

  make "TCLSH_PROG=XXXXXXXXXXXXX" ...

 Greetings
-gustaf

-- 
Univ.Prof. Dr.Gustaf Neumann
Abteilung für Wirtschaftsinformatik
WU-Wien, Augasse 2-6, 1090 Wien

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Mon, 28 May 2001 12:18:45 +0200

On Sunday 27 May 2001 02:16, you wrote:
> I'm proposing an object method "createAsChild", or something similar. The
> syntax would be:
>
> createAsChild <class> ?arg0 arg1 ...?
>
> This would basically be a convenience method to do the equivalent of
> creating an object as a child of another with the normal aggregation, plus
> using autoname. Ie the following two cases would be the same:
>
> set nm [MyClass autoname MyClass]
> MyClass ${ob}::$nm foo bar
>
> and
>
> $ob createAsChild MyClass foo bar
>
> Thus making it much easier to use aggregation with automatically created
> names. I'm not saying this is necessarily the best possible syntax
> for that: maybe it would be better to do "MyClass newAsChild $ob foo bar"?
> Anyway I only use autonaming myself for making instances of classes so
> this would be quite useful. Of course, with XOTcl I'm allowed the
> possibility of adding to the Object or Class objects myself which is
> fabulous. Just that it might be useful as a core element of the language.

 Dear Kristoffer,

 are you aware of the predefined methods "new" and "newChild" (the first one
 simplifies only the call to autoname, while the second one creates a new
 autonamed object as an aggregated child object). These convenience methods are defined
 in the langRef. the definition of newChild is below...

 best regards
-gustaf

Class instproc newChild args {
  ::set name [[self] autoname -instance [namespace tail [self]]]
  ::eval [self] create [self callingobject]::$name $args
}
>
> As a matter of interest, how many people here only use objects created
> with autoname?
>
> - ---------- = = ---------//--+
>
> | / Kristoffer Lawson | www.fishpool.fi|.com
>
> +-> | setok_at_fishpool.com | - - --+------
>
> |-- Fishpool Creations Ltd - / |
>
> +-------- = - - - = --------- /~setok/
>
>
> _______________________________________________
> Xotcl mailing list - Xotcl_at_wi.wu-wien.ac.at
> http://wi.wu-wien.ac.at/mailman/listinfo/xotcl

From: Scott Gargash <scottg_at_atc.creative.com>
Date: Tue, 15 Aug 2006 08:46:22 -0600

Scott Gargash schrieb:
>
> I've run into an interaction with threads and the XOTcl exit handler
> that I don't understand.
>
> I create a thread from within an object, and release that thread in
> the object's destructor. If I destroy the object directly,
> everything's fine, but if I destroy the object through "Object
> setExitHandler", I get an error. Am I treading into undefined
> behavior? Is there well-defined way to shut down multiple threads?
>
the thread and exit code is a tricky and sensitive area, especially if
it is supposed to work with tcl and the aolserver. below is the somewhat
simplified code (btw., your example works on mac os x without a
problem). In general. there is no need to destroy the objects by hand,
since these are destroyed automatically and the appropriate destroy
methods are executed. also, the destroy order is not completely trivial
in order to be able to execute the destroy methods correctly. i would
not do this by hand.

isn't the default beavior sufficient?

Unfortunately, the default behavior is not sufficient. My example was simplified from my real
problem. In the real problem, I have essentially a directed graph of objects that I serialize out
upon destruction. Since the default behavior doesn't destroy objects in a defined order, when the
root object goes to serialize out, some nodes that it needs to serialize may already be destroyed.
This is undesireable.

So I inserted my own exitHandler and that works in a single thread, but when I have multiple
threads, things get confused.

BTW, the failure was on WinXP. Given that the behavior is different on different platforms, it does
seem like I've treaded into undefined behavior. Is there any way to wrangle it back into something
defined?

      Scott

From: <akupries_at_shaw.ca>
Date: 14 Jun 2016 20:53:22 -0700

Hello XOTcl Developers, fyi ...

23rd Annual Tcl/Tk Conference (Tcl'2016)
http://www.tcl.tk/community/tcl2016/

November 14 - 18, 2016
Crowne Plaza Houston River Oaks
2712 Southwest Freeway, 77098
Houston, Texas, USA

Important Dates:

[[ Attention!
   Registration is open. Please have a look at
        http://www.tcl.tk/community/tcl2016/register.html

   The tutorials are known. See
        http://www.tcl.tk/community/tcl2016/tutorials.html
]]

Abstracts and proposals due September 12, 2016
Notification to authors September 19, 2016
WIP and BOF reservations open August 22, 2016
Author materials due October 24, 2016
Tutorials Start November 14, 2016
Conference starts November 16, 2016

Email Contact: tclconference_at_googlegroups.com

Submission of Summaries

Tcl/Tk 2016 will be held in Houston, Texas, USA from November 14, 2016 to November 18, 2016.

The program committee is asking for papers and presentation proposals
from anyone using or developing with Tcl/Tk (and extensions). Past
conferences have seen submissions covering a wide variety of topics
including:

* Scientific and engineering applications
* Industrial controls
* Distributed applications and Network Managment
* Object oriented extensions to Tcl/Tk
* New widgets for Tk
* Simulation and application steering with Tcl/Tk
* Tcl/Tk-centric operating environments
* Tcl/Tk on small and embedded devices
* Medical applications and visualization
* Use of different programming paradigms in Tcl/Tk and proposals for new
  directions.
* New areas of exploration for the Tcl/Tk language

Submissions should consist of an abstract of about 100 words and a
summary of not more than two pages, and should be sent as plain text
to tclconference_at_googlegroups.com no later than September 12, 2016. Authors of accepted
abstracts will have until October 24, 2016 to submit their final
paper for the inclusion in the conference proceedings. The proceedings
will be made available on digital media, so extra materials such as
presentation slides, code examples, code for extensions etc. are
encouraged.

Printed proceedings will be produced as an on-demand book at lulu.com

The authors will have 30 minutes to present their paper at
the conference.

The program committee will review and evaluate papers according to the
following criteria:

* Quantity and quality of novel content
* Relevance and interest to the Tcl/Tk community
* Suitability of content for presentation at the conference

Proposals may report on commercial or non-commercial systems, but
those with only blatant marketing content will not be accepted.

Application and experience papers need to strike a balance between
background on the application domain and the relevance of Tcl/Tk to
the application. Application and experience papers should clearly
explain how the application or experience illustrates a novel use of
Tcl/Tk, and what lessons the Tcl/Tk community can derive from the
application or experience to apply to their own development efforts.

Papers accompanied by non-disclosure agreements will be returned to
the author(s) unread. All submissions are held in the highest
confidentiality prior to publication in the Proceedings, both as a
matter of policy and in accord with the U. S. Copyright Act of 1976.

The primary author for each accepted paper will receive registration
to the Technical Sessions portion of the conference at a reduced rate.

Other Forms of Participation

The program committee also welcomes proposals for panel discussions of
up to 90 minutes. Proposals should include a list of confirmed
panelists, a title and format, and a panel description with position
statements from each panelist. Panels should have no more than four
speakers, including the panel moderator, and should allow time for
substantial interaction with attendees. Panels are not presentations
of related research papers.

Slots for Works-in-Progress (WIP) presentations and Birds-of-a-Feather
sessions (BOFs) are available on a first-come, first-served basis
starting in August 22, 2016. Specific instructions for reserving WIP
and BOF time slots will be provided in the registration information
available in August 22, 2016. Some WIP and BOF time slots will be held open
for on-site reservation. All attendees with an interesting work in
progress should consider reserving a WIP slot.

Registration Information

More information on the conference is available the conference Web
site (http://www.tcl.tk/community/tcl2016/) and will be published on
various Tcl/Tk-related information channels.

To keep in touch with news regarding the conference and Tcl events in
general, subscribe to the tcl-announce list. See:
http://code.activestate.com/lists/tcl-announce to subscribe to the
tcl-announce mailing list.


Conference Committee

   * Andreas Kupries Hewlett Packard Enterprise
   * Arjen Markus Deltares
   * Brian Griffin Mentor Graphics
   * Clif Flynt Noumena Corp
   * Gerald Lester KnG Consulting LLC
   * Joe Mistachkin Mistachkin Systems
   * Ronald Fox CAEN Technologies
                     NSCL _at_ Michigan State University
   * Steve Landers Digital Smarties

Contact Information tclconference_at_googlegroups.com

Tcl'2016 would like to thank those who are sponsoring the conference:

   * Mentor Graphics
   * Tcl Community Association

From: Zoran Vasiljevic <zv_at_archiware.com>
Date: Fri, 6 Oct 2006 11:53:42 +0200

On 06.10.2006, at 11:48, Gustaf Neumann wrote:

> Neil Madden schrieb:
>> Is this description correct?
> Mostly yes, let me try to explain:

_Most_ useful explanation deserving to be added
as "XOTcl in a Nutshell" topic in the documentation.

Zoran