Weblog Page

From: Jim Lynch <jim_at_jam.sessionsnet.org>
Date: Fri, 9 Apr 2004 07:04:58 -0700

Hi,

I've been talking to people on the irc channel, Jeff Hobbs among them,
about the tclsh issue. Jeff's contention, as far as I understand it, is
that if tclsh is not used to actually load the extension it's building,
any tclsh will do, and that the TEA_PROG_TCLSH macro uses a more correct
ordering to find tclsh: so long as the supplied tclConfig.sh refers to
its tclsh, that tclsh ought to be found first.

Among other things, I'm now trying to determine whether the build process
of xotcl actually needs that specific tclsh or not; right now my guess
is that it does.

-Jim

--
Jam sessions community web site: http://jam.sessionsnet.org

From: Victor Mayevski <vitick_at_gmail.com>
Date: Thu, 5 Jan 2012 17:48:42 -0800

Thanks Stefan,

I already knew about the "forward" method, the reason I asked about
"alias" is that I noticed that it is a bit faster than "forward".


On Thu, Jan 5, 2012 at 2:22 PM, Stefan Sobernig
<stefan.sobernig_at_wu.ac.at> wrote:
> Victor,
>
>
>> Is it possible to have an alias to ensemble or multi-word commands?
>
>
> Well, namespace ensembles are straight forward; you may find out the
> ensembled Tcl commands using e.g. [namespace ensemble configure string -map]

This should work, thanks.


> and then use the fully-qualified command names as alias target:
>
> package req nx::test
>
> Object create o {
>  :public alias stringLength ::tcl::string::length
> }
>
> ? {o stringLength "xyz"} [string length "xyz"]
>
> If you don't have an ensemble command at hand (e.g., the [string is] classes
> such as "integer", "boolean"), you want to bind in terms of a method,
> consider a forwarder:
>
> o public forward stringIsBoolean string is boolean
>
> ? {o stringIsBoolean "false"} [string is boolean "false"]
>
> A forwarder is needed, because the "boolean" selector does not map to a Tcl
> command, rather is an argument to a paramteric Tcl command
> (::tcl::string::is).
>
> A mixed alternative would be ...
>
> o public alias stringIs ::tcl::string::is
> o public forward stringIsBoolean2 %self stringIs boolean
>
> ? {o stringIsBoolean2 "false"} [string is boolean "false"]
>
> //stefan

From: <uwe.zdun_at_wu-wien.ac.at>
Date: Sun, 31 Aug 2003 20:35:16 +0200

Please see the attached file for details.

From: Victor Mayevski <vitick_at_gmail.com>
Date: Wed, 15 Dec 2010 12:15:57 -0800

Hello Gustaf,

1. Is there any way to add meta-data to parameters during parameter
creation? Specifically I would like to add a time stamp to the the
parameter so I can list parameters in the order they were created.
2. Is there a reason why the "object setter" command has to be a two
step command, example: [Object create o; o setter s; o s value]. Why
can't it be done in one step [o setter s value] ? I guess the same
goes for the "object attribute" command.
3. What is difference between "setter" and "attribute"?

Thanks

From: Zoran Vasiljevic <zoran_at_archiware.com>
Date: Fri, 29 Aug 2003 17:18:31 +0200

On Friday 29 August 2003 16:26, Catherine Letondal wrote:
> Hi,
>
> I have just re-installed Xotcl 1.0.2 version and succedeed in running my
> application with some minor changes since the last xotcl version I used on
> this platform (Sparc/Solaris 7) was the 0.9 :-)
>
> I have a segmentation fault that occurs when a command is called from a Tk
> menu. The command is attached to the popup by a:
> add command -command
> statement on a menu Tk widget that is raised by a tk_popup.
>
> However, the very same command, when called from the tcl (xowish)
> interpreter, works and does not produce any core dump. And most menu items
> also work well.
>
> So my question is: how do I debug such a situation?
> Thanks for any help...

You should compile wish with symbols (./configure --enable-symbols).
The same appiles for xotcl as well.
Then just say:

gdb wish
<some gdb output>
(gdb) run

This will start the wish. You can put some arguments to
the run command, the same ones you'd normally pass
to wish:

(gdb) run myscript.tcl

Then just run the code. On segv, the debugger will pop-up
and you can then do

(gdb) bt

which stands for "backtrace". This will show the stack.
This is very helpful in diagnosing problems.

Of course, you need a gdb debugger for Sun. I think
there are lots of sites on the net offering precompiled
binaries for solaris.

When you have the backtrace, just post it to the list
and we'll see what happens.

Cheers
Zoran

From: Uwe Zdun <uwe.zdun_at_uni-essen.de>
Date: Mon, 16 Jul 2001 11:27:49 +0200

On Sunday 15 July 2001 21:45, you wrote:
> Subject: The Adapter pattern inplemented with filters(code from
> distribution)
>
> The code below from the XOTcl distribution is given below.
> Suppose the class Adapter has another filter "filter2"
> registered after the filter "adapterFilter".
> My understanding of the code(below) is that only requests that
> are not found in specificRequest will be filtered by
> filter2.

yes ... that is correct for the Adapter implementation below. Usually you
would prepend filter2 before adapterFilter (with filter "filter2 [[self] info
filter]") in order to ensure that filter2 is called before adapterFilter.

However, if this does not work for you, you can also refine the Adapter
implementation to your requirements. Say, by calling next before
adapting to the adaptee ...

--uwe



> ..........................................................
>
> Question:
> If my understanding is correct, how can I have all
> messages/requests to Adapter be filtered by both filters.
> ..........................................................
>
> Code from distribution:
>
> Class Adapter -superclass Class
>
> Adapter metadata add description
>
> Adapter metadata description {
> Simple adapter pattern meta-class taken from the paper
> 'Filters as a Language Support for Design Patterns in
> Object-Oriented Scripting Languages'.
> }
>
>
> Adapter instproc adapterFilter args {
> # Appears that filter args == args of triggering method
> set r [self calledproc]
> [self] instvar specificRequest adaptee
> #puts [self]
> if {[info exists specificRequest($r)]} {
> #puts $args
> return [eval $adaptee $specificRequest($r) $args]
> }
> next
> }
>
> Adapter instproc init args {
> [self] filterappend [self class]::adapterFilter
> next
> [self] instproc setRequest {r sr} {
> [self] set specificRequest($r) $sr
> }
> [self] instproc setAdaptee {a} {
> [self] set adaptee $a
> }
> }
>
>
> _______________________________________________
> Xotcl mailing list - Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl

-- 
Uwe Zdun
Institute for Computer Science, 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: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Sat, 23 Oct 2004 00:48:56 +0200

On Friday 22 October 2004 22:51, Schofield, Bryan \(GE Transportation\) wrote:
> I think you've stumbled on the namespace resolution bug that appeared with
> 1.3.0.

 actually, what adam points out was the xotcl behavior before 1.3.*. Earlier
 versions used always the current namespace for instprocs/procs,
 which is different from the standard tcl behavior, and has as well
 some more disadvantages for packages.

 The bug that Michael Heca came up with (alloc bug) was a consequence
 of changing the old behavior. The exists bug that Attila came up with was
 in since the first xotcl versions.

 All these issues are solved in the current testing version. We have
 still one complex issue to double check; if everything goes well, we
 should be able to release 1.3.3 next week.

 -gustaf

-- 
Univ.Prof. Dr.Gustaf Neumann
Abteilung für Wirtschaftsinformatik und Neue Medien
Wirtschaftsuniversität Wien, Augasse 2-6, 1090 Wien

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Sat, 27 Mar 2004 16:24:42 +0100

On Tuesday 23 March 2004 23:46, Jeff Hobbs wrote:
> I was intrigued by the recent posting about an itcl emulation
> using xotcl. How much work would it be to get a 100% emulation
> of itcl in xotcl? After all, there is tcl++, that was a pure
> Tcl emulation of itcl (that was 99.9% IIRC).

 Jeff,

 This is certainly do-able, especially for well structured
 programs, but should be done by a person with
 a reasonable itcl knowledge and a real-world test base.
 We can certainly help in such a project.
 in genereal i see two kinds of issues to be adressed

   - some ideosyncaries of itcl, which can be easy
     emulated by procs (e.g. the auto nameing convention
     of itcl), but this would slow down the code.

   - the apporach of http://mini.net/tcl/10975
     works fine for well-structured itcl programs
     (calls along the class chain are in the right
     order, calls do not jump out of the class chain,
     etc.); when these should be supported, we
     have to look for a good approach.
     
 Btw., the code in http://mini.net/tcl/10975
 can be further improved by replacing the
 redirector procs by interp aliases. this
 speeds up the objinst benchmark by
 further 4-5 percents...

 -gustaf

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

From: <MichaelL_at_frogware.com>
Date: Mon, 12 May 2003 12:09:37 -0400

Thanks, guys!

From Uwe:

> This does not work as you intend it because you forgot the "next"
> call in your destroy method. That means the real destructor is
> never reached ...

Yes, I understand.

> I would also recommend to always use "args" for init
> and destroy, as arguments for these methods may change.

Yes, I understand. I was trying to submit the simplest possible code to
illustrate the problem.

Btw, very nice work. I'm impressed with and appreciate the attention to
detail.

From: Scott Gargash <scottg_at_atc.creative.com>
Date: Sun, 19 Mar 2006 07:30:39 -0700

xotcl-bounces_at_alice.wu-wien.ac.at wrote on 03/19/2006 06:53:50 AM:

>
> One general observation about our discussion: it is often not clear,
> what "namespace"
> refers to, a "tcl namespace" or some kind of an abstract namespace.

I've been guilty of this. I wondered what would happen if XOTcl's objects used their own
concept/implementation of an abstract namespace (or scope) instead of using Tcl namespaces.

(The answer seems to be that it would be a lot of work and it would break XOTcl...)

That said, I think it would be good if, in general, non-XOTcl accesses to an XOTcl object's
attributes didn't assume the way Tcl's namespaces are used, but instead there were object methods
that would construct appropriately qualified names for an instance's attributes.

> i for my part would be happy to have a lower level
> interface to these
> functionalities, having e.g. the management for cmds different from the
> management
> of the vars, but this would be a deeper change in the tcl-internals,
> requireing many
> interface changes.

Does Tip #257 provide a opening for having that discussion with the Tcl Core Team? If there's
willingness to add OO support to Tcl, does that also imply a willingness to at least consider
extending the C API to better support it as well?

      Scott