Weblog Page

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Mon, 23 Dec 2002 02:04:15 +0100

 Dear XOTcl community,

 Something to add to the annoucement:
 for people using XOTcl with the aolserver,
 please obtain the xotcl-aolserver patch
 from the server (same name as before). The patch
 contains:
   - a slighly improved patch for the c-code of the aolserver
     (by Zoran)
   - a new namespace.tcl that
       * fetches the new Serializer
       * preserves global variables (many thanks to Oumung Mehrotra)
   - Serializer code.

 best regards
-gustaf neumann

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Tue, 22 May 2001 22:59:48 +0300 (EEST)

On Tue, 22 May 2001, Artur Trzewik wrote:

> So I give up. These two solution does not seems to be acceptable.
> Maybe futures version of tcl interpeters will offer more flexible
> type conversion solution. The new type should decide by itself
> how it can be converted to another type.

I suggest posting to comp.lang.tcl. They tend to be pretty helpful
there and as Jeff Hobbs reads it, you might get a solution you overlooked.
At the very least, you can suggest those fixes to Tcl. Who knows, maybe
something will arrive for 8.4 ;-)

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

From: Uwe Zdun <uwe.zdun_at_wu-wien.ac.at>
Date: Fri, 03 Sep 2004 10:24:11 +0200

Hi Artur,

it seems there are some flaws in the new namespace handling code
that we did not foresee. In the first example, for instance, the current
namespace "::O" is not correctly set, IMHO.
I suggest: don't change your code now, but wait for the next release,
because
we need to fix this behavior first. After a quick assessment, I think
either
some larger changes to this are necessary or we remove the new namespace
handling in the next release again. Here is a version of XOTcl
with the namespace handling code disabled:

http://wi.wu-wien.ac.at/~uzdun/resources/xotcl-1.3.1.tar.gz

can you please verify that this version works as intended for you?

I then also produce windows binaries for this version ans likely put it
on the web.

Uwe



Artur Trzewik wrote:

>Hi!
>
>XOTclIDE does not run with XOTclI 1.3.1 because
>of uncompatibility of the namespace handling.
>Thank to Michael Heca for noting it.
>
>I have played a little with xotcl and discovered following
>behavior incompatibility that make problems by XOTclIDE.
>
>Examples:
>
>package require XOTcl
>namespace import xotcl::*
>
>Object O
>Class O::B
>O::B instproc test {} {
> Class A
>}
>O::B create o
>o test
>
># XOTcl 1.2 returns ::A
># XOTcl 1.3 returns ::O::A
>
>using Class ::A solves the problem
>
>Another one should not occours by any XOTcl programm
>but by XOTclIDE this happened
>
>Object O
>Class O::A
>O::A proc test {} {
> A self
>}
>O::A create A
>O::A test
>
># XOTcl 1.2 returns ::A
># XOTcl 1.3 returns ::O::A
># using ::A solves the problem
>
>So probably even with XOTcl 1.3.2 XOTclIDE will not work
>out of the box and need some changes.
>So all XOTclIDE user be patience and wait for new version of XOTclIDE
>that supports XOTcl 1.3. I will need also some time to support
>new XOTcl functionality.
>
>Artur Trzewik
>
>_______________________________________________
>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: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Fri, 06 Oct 2006 11:48:49 +0200

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

 - the precedence order is defined by the order, classes are priorized
or shadow
   each other.
   Abbreviations: POM: per-object mixin, PCM: per-class mixin, C: Classes
   The order is: POM, PCM, C
   all of these are class hierarchies, where the contained classes are
linearized; when a
   class is mixed into a precedence order, where it is already present,
it has no effect.

- the method resolution order overlays the precedence order.
   it includes
    * filters (firstly per-object filters, then per-class filters),
dispatched "on top" (i.e. before
       the methods of the precedence order)
    * object specific methods (dispatched between PCM and C)
    * assertions (per default, turned off):
         + assertions are turned on/off on a per-object basis
         + assertions are lists of Tcl expressions
         + we distinguish between pre- and post-conditions and invariants
         + pre- and post-conditions are defined per-method (more precisely
            instproc and proc)
         + a precodintion is evaluated before every method dispatch
(method-specific)
         + a postcondition is evaluated before after method dispatch
(method-specific)
         + an invariant is evaluated before and after every method
dispatch for the object
         + these three types can be selectively activated/deactivated
     
Assertions are similar to the :before, :after, :around in CLOS, but all
three
types (as they are defined in current XOTcl) do not change the result of a
method. Assertions, as we have these today, are specialized, but could
be generalized to something more CLOS-like.

Finally, "unknown" is an exception handler, invoked in case the method
to be dispatched
is not defined by the classes in the precedence order or by the object.
This means,
a mixin containing a certain method can prevent that unknown is called.
Also here,
it would make sense to develop "unknown" to a more general exception
handler.

> The only two mechanisms that I don't know where to put are assertions
and forwarders. Are these
> implemented using e.g. mixins? Or are they a special-purpose
mechanism? If so, where do they come in the > order?

Forwarders are c-implemented methods. They are pure conveniance and could
be implemented my the user as methods as well. If a class providing an
forwarder
to its instances is mixed in, the forwarders are mixed in as well.

Pre- and post-conditions can be implemented roughly with mixins, but
they cannot
measure the immediate effect of a single method call (mixins would
implement the
pre- and postconditions of an invocation of a next-chain).
All tree types can however be implemented by filters (which can alter
results).
It would be quite slow, and give no nice error traces. It will be some
work, but
it should be possible. It is hard to say, what on this level cannot
done with filters.

-gustaf neumann

From: Andreas Kupries <andreask_at_activestate.com>
Date: Tue, 12 Aug 2014 13:09:22 -0700

21'th Annual Tcl/Tk Conference (Tcl'2014)
http://www.tcl.tk/community/tcl2014/

[ It is 4 weeks to the deadline for Abstracts and proposals ... ]

November 10 - 14, 2014
Embassy Suites Downtown
Portland, Oregon, USA

Important Dates:

Abstracts and proposals due Sep 8, 2014
Notification to authors Sep 22, 2014
Author materials due Oct 20, 2014
Tutorials start Nov 10, 2014
Conference starts Nov 12, 2014

[[
        Registration is open.
]]

Email Contact: tclconference_at_googlegroups.com

Submission of Summaries

Tcl/Tk 2014 will be held in Portland, Oregon, USA from November
10 - 14, 2014. 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 DOT com> no later than August 5,
2014. Authors of accepted abstracts will have until September 2, 2014
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 25 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.
WIP slots can be reserved like any paper proposal. BOF slots will be
managed on-site. 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/tcl2014/) and will be published on
various Tcl/Tk-related information channels.

        Registration is open.

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

Clif Flynt Noumena Corp General Chair, Website Admin
Andreas Kupries ActiveState Software Inc. Program Chair
Brian Griffin Mentor Graphics Site/Facilities Chair
Arjen Markus Deltares
Cyndy Lilagan Nat. Museum of Health & Medicine, Chicago
Donal Fellows University of Manchester
Gerald Lester KnG Consulting, LLC
Jeffrey Hobbs ActiveState Software Inc.
Kevin Kenny GE Global Research Center
Larry Virden
Mike Doyle National Museum of Health & Medicine, Chicago
Ron Fox NSCL/FRIB at Michigan State University & CAEN Technologies
Steve Landers Digital Smarties

Contact Information tclconference_at_googlegroups.com


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

ActiveState Software Inc.
Buonacorsi Foundation
Mentor Graphics
Noumena Corp.
SR Technology
Tcl Community Association

From: Tibichte <zak_at_isa-software.com>
Date: Thu, 23 Jul 2009 09:51:35 +0200

Hello,

 

I am experimenting with the xotcl method forwarding.

 

1- if I create a method forwarding f1:

obj forward f1 list {%_at_end 13} %self

? { obj f1 1 2 3 } [list ::obj 1 2 3 13]

 

 

Question:

Why ::obj was inserted at the beginning but not at the end?

 

 

2- This forwarding method causes xotcl to crash:

obj forward f2 list {%_at_end 13} %self %1

? { obj f2 1 2 3 }

 

Regards,

 

Abderrazak Tibichte

 

 

From: <jim_at_jam.sessionsnet.org>
Date: 29 Mar 2004 02:26:37 -0000

Hi,

Sorry if this is a repeat, the first time didnt' seem to take.

When configuring xotcl to build with a tcl which is not the system tcl,
the configure step assumes the tclsh in the $PATH, which is a wrong
assumption.
 
The right assumption would be to choose the tclsh located in the tclConfig.sh.
      
Doing this would ensure the builder will get the tclsh which is in the
installation of tcl he/she specified.
 
-Jim

From: Victor Mayevski <vitick_at_gmail.com>
Date: Thu, 22 Oct 2009 00:37:12 -0700

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.

From: Shyamsundar, Purkayastha \(Purkayastha\)** CTR ** <shyamsundar_at_alcatel-lucent.com>
Date: Wed, 6 Jun 2007 20:06:20 +0530

Hi All

 

I have just started exploring XOTcl but I am unable to find the
documentation for XOTcl's C API.

 

Can anybody point me to any documentation available on the web or do I
have to explore the .h files to gather that

 

thanks

 

 

 

 

 

From: Catherine Letondal <letondal_at_pasteur.fr>
Date: Sun, 17 Dec 2000 23:13:34 +0100

Hi,

I have a very philosophical question :-)

I would like to replace inheritance by delegation for some classes' instances.

e.g:
        Class C -parameter {delegate} # instead of Class C -superclass D
        C c -delegate a

where a is an object of another class, say class A.

Delegation means that:
- next should call the delegate's proc/instproc
- set, instvar would give access to delegate's variables
(this is one of the classical delegation mechanisms/behaviour I believe?)

I have tried 3 methods, but neither work!

1) with a filter on C, which branch the methods calls to the appropriate location.
the filter is defined in init:
        C filter CFilter

C instproc CFilter args {
    ::set m [[self] info calledproc]
    [self] instvar delegate
    if { ([C info instprocs $m] != "") || ([[self] info procs $m] != "") } {
        puts "CFilter m=$m I do it myself"
        next
    } elseif { [info exists delegate] && ($m == "set" || $m == "instvar") } {
        puts "CFilter m=$m I delegate it to $delegate"
        eval $delegate $m $args
    } elseif {[info exists delegate] && [[$delegate info class] info instprocs $m] != ""} {
        puts "CFilter m=$m I delegate it to $delegate"
        eval $delegate $m $args
    } else {
        puts "I dont know (m=$m), I call next"
        next
    }
}

2) with a mixin on c
in init:
        [self] mixin [$delegate info class]

3) with both


=> problem with filter only (1) :
        - next does not work the way I want (it does not call the delegates)
        - set of delegates' variables works, but instvar don't

=> problem with mixin only (2)
        - as the delegate's class is the mixin, it's it's methods which are always
        called first (but I want the delegate's methods to be called only when
        not existing for the class or when calling next)
        - I need a method in the delegate's class for every method int the class
        - delegate's variables are not available, of course (since I only use the
        class of the delegate to inherit methods)

=> mixin+filter (3) (example below) :
        - instvar does not work


Does someone have ideas and opinions about this? Has someone already tried?
I don't remeber having found something about it in Xotcl's papers (maybe I'm wrong?).

Thanks!

-- 
Catherine Letondal -- Pasteur Institute Computing Center
+-------------------------------------------------------------------------------------
Example of code for solution (3):
# delegation with mixins+filter
# object a of class A will be used as delegate for C 
Class A
A instproc f1 args {
    puts "A f1 I am: [self] from class: [[self] info class]"
}
A instproc f3 args {
    puts "A f3 I am: [self] from class: [[self] info class]"
}
A a
a set x 10
Class C -parameter {delegate}
C instproc init args {
    [self] instvar delegate
    if {[info exists delegate] && [::Object isobject $delegate]} {
	puts "adding [$delegate info class] as a mixin for [self]"
	[self] mixin [$delegate info class]
	puts "adding CFilter as a filter for [[self] info class]"
	[[self] info class] filter CFilter
    }
}
C instproc f2 args {
    puts "C f2 I am: [self] from class: [[self] info class]"
}
C instproc f3 args {
    puts "C f3 I am: [self] from class: [[self] info class]"
    puts "calling next"
    next
}
C instproc CFilter args {
    ::set m [[self] info calledproc]
    if {$m == "CFilter"} {
	next
    }
    [self] instvar delegate
    if { ([C info instprocs $m] != "") || ([[self] info procs $m] != "") } {
	puts "CFilter m=$m I do it myself"
	next
    } elseif { [info exists delegate] && ($m == "set" || $m == "instvar") } {
	puts "CFilter m=$m I delegate it to $delegate"
	eval $delegate $m $args
    } elseif {[info exists delegate] && [[$delegate info class] info instprocs $m] != ""} {
	puts "CFilter m=$m I delegate it to $delegate"
	eval $delegate $m $args
    } else {
	puts "I dont know (m=$m), I call next"
	next
    }
}
C d -delegate a
d proc f4 args {
        [self] instvar x
        puts "f4 [self] x: $x"
}
Try:
d f1
d f2
d f3
d f4