Weblog Page

From: Sheik Yussuff <sheik_at_carib-link.net>
Date: Sun, 15 Jul 2001 16:45:40 -0300

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.
.........................................................

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
    }
}

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Sun, 30 Nov 2003 10:14:12 +0100

 Hi Marc,

 to honor --with-tkinclude, a special rule in unix/Makefile.in was needed for the
 compilation of tkAppInit, which is in turn needed for building xowish, which is
 deprecated and only in the distro to keep our "old" users happy. The recommended
 loading of xotcl is to use:

    package req XOTcl
    namespace import ::xotcl::*

 This is for the tclsh and for wish the same.

 My guess is that your interest was not in particular to compile xowish,
 but to check, whether everything compiles correctly on your system,
 and therefore you used --with-all in confiigure. Maybe we should overthink
 the setup of this rule in future versions.

 anyhow, i have imply updated the xotcl-1.1.0 tar file on www.xotcl.org since this
 build change does not effect most users.

 all the best
-gustaf

PS: from today noon until monday evening, i'll be in germany in a meeting
 with no or bad internet access.

On Sunday 30 November 2003 02:42, Marc Spitzer wrote:
> I have attached a log of my build, just incase I am missing something.
> The --with-tkinclude=/usr/local/include/tk8.4/generic from configure does
> not seem to be getting to the CC line as a -I directive:
>
> cc -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\"
> -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DVERSION=\"1.1\"
> -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1
> -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
> -DHAVE_UNISTD_H=1 -DCOMPILE_XOTCL_STUBS=1 -DTCL_SHLIB_EXT=\".so\"
> -I/usr/ports/lang/tcl84/work/tcl8.4.4/generic
> -I/usr/ports/lang/tcl84/work/tcl8.4.4/unix -I"./../generic" -I"./../unix"
> -I/usr/local/include/tcl8.4/generic -O -fPIC -g -DXOTCLVERSION=\"1.1\"
> -DXOTCLPATCHLEVEL=\".0\" -c `echo ../unix/tkAppInit.c` -o o/tkAppInit.o
> ../unix/tkAppInit.c:19: tk.h: No such file or directory
> gmake: *** [o/tkAppInit.o] Error 1
>
> Thanks
>
> marc

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

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Mon, 13 Aug 2001 21:10:40 +0300 (EEST)

On Mon, 13 Aug 2001, Gustaf Neumann wrote:

>
> hmm. you mentioned here twice "args" and "body"; you should not use
> these for inherited methods, use instead "instargs" and "instbody".

That's the point, the method-generator should know be concerned with
whether the template methods are inherited or not!
>
> i am still confused. Are you trying to use the instprocs as templates
> for procs? if i paraphrase the example from the wiki, this would be
>
> Class C
> C instproc fooTemplate <argument> <body>
>
> C c1
> useTemplate c1 fooTemplate foo -msg1 Hi -msg2 bye
>
> where the object c1 has afterwards a proc foo, and fooTemplate could
> be a proc or an instproc.
>
> i do not think, that this is a good solution, but this is an example
> where i would like to ignore the differences between procs and instprocs.
> is this similar to what you are working on?

This is pretty much exactly what I am doing, albeit with metaclasses
and classes.

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

From: Stefan Sobernig <stefan.sobernig_at_wu-wien.ac.at>
Date: Thu, 05 Jun 2008 12:25:20 +0200

> BTW, have you or somebody else already considered to make an XOTcl
> implementation for Jacl (Tcl on Java)?

Well, there is a cool piece of (on-going) work which is an
amalgam of Tcl/XOTcl + Hecl/Jacl, mastered by Uwe Zdun:

see http://frag.sourceforge.net/

From: Catherine Letondal <letondal_at_pasteur.fr>
Date: Fri, 02 Mar 2001 20:44:32 +0100

On Thu, 1 Mar 2001, Artur Trzewik wrote:
>
> I wrote the first Browsers now. It is the first attempt but it can
> be already used for developing (or browsing Xotcl)
> I named the application XotclIDE

This looks very interesting indeed - I am actually developping a programming environment
as well: its name is biok (Biology Interactive Object Kit).

This tool is more aimed at end-users, i.e biologists who are able to
program small pieces of code but not whole applications.
So the idea is more to let them customize an already existing application by using
introspection also and directly from the user interface. But there are certainly
common features: GUI builder (for instance you may copy/paste a whole graphical object,
copy an object into another one, ...) ; the class/objects browsers is far more simple
than yours: the idea is just to be able to "grasp" an object/instance with its
method(s) from the graphical representation (it's called PITUI: "Programming in the user
interface" as in Self).
Another of the "end-user programming" features is the dataflow/spreadsheet mechanism.

I'm still in the prototyping phase - I'm actually using participatory design techniques
(http://www-alt.pasteur.fr/~letondal/These/links-ihm.html#pd) with end-users to design
the tool, so the software is really too messy to be distributed!
(and the tool is a biology analysis workbench - not a programming environment - or rather
it's both).

Here are some screen images:

1) This one shows the biological editor (for comparing molecular sequences and visualizing
their features) plus how to browse current/pointed object's methods:
http://www-alt.pasteur.fr/~letondal/EUD/pitui1.gif

2) This one is just a source code editor to (re)define an instproc at the instance level:
http://www-alt.pasteur.fr/~letondal/EUD/pitui2.gif
You see that there are fonctions like setting breakpoints or tracing methods' calls (this
is done with filters of course).

3) this image show that a shell may be opened for objects, in order to try its methods:
here, the user is calling 'setcolsize' to change some columns' sizes
http://www-alt.pasteur.fr/~letondal/EUD/prot-shell.gif
You also see that it's possible to search for a method by selecting its
name in the text (by introspection).

4) This is a tag editor (the tool uses tktable for implementing this spreadsheet-like tool):
http://www-alt.pasteur.fr/~letondal/EUD/tagedit-attr.gif
there a "GUI" feature in the editor: small menus may be used to select among graphical
attributes and their values.

5) a very simple class browser (it's actually implemented with cascade menus but I was not
able to grab them with xv so they are teared off):
http://www-alt.pasteur.fr/~letondal/EUD/tagclass.gif
the "main" menu enables also to browse objects or classes.

6) the message stack display shows here the some methods calls for update
cells value in a spreadsheet (also shown on top of the trace window):
http://www-alt.pasteur.fr/~letondal/EUD/trace.gif

7) some GUI building features: you may create buttons, entry fields, choice lists,
whatever, ... in assemble them into panedwindows or tabnotebooks:
http://www-alt.pasteur.fr/~letondal/EUD/gui.gif
you may also edit graphical attributes (I'm not happy with this editor, it's too slow):
http://www-alt.pasteur.fr/~letondal/EUD/grapheditor.gif

8) this is a very short presentation of the underlying ideas:
http://www-alt.pasteur.fr/~letondal/EUD/

So I would be very interested to discuss "IDE" features with you!

The main problems I have for the moment are:
- persistence - this is rather difficult to achieve since there are many dependencies
between objects and you have to decide what to save
- performance
- a lot of design (application and IDE features - I'm trying to enable a sort of seamless
programming for end-users: they should be able to program methods as easily as a cell
formula...).

--
Catherine Letondal -- Pasteur Institute Computing Center

From: Jeff Hobbs <jeffh_at_activestate.com>
Date: Mon, 11 Dec 2006 15:32:55 -0800

Scott Gargash wrote:
> xotcl-bounces_at_alice.wu-wien.ac.at wrote on 11/28/2006 07:41:26 PM:
>
> > ActiveState is pleased to announce the release of ActiveTcl 8.4.14.0
> > and 8.5.0.0 Beta 6, the quality-assured distribution of Tcl, available
> > for AIX, HP-UX, Linux, Mac OS X, Solaris and Windows.
>
> Is there any way to get the xotcl c-interface files (the .h/.lib files)
> that correspond to the version of XOTcl that ships with the ActiveState
> release? They're not present in the distribution.

Hmmm, well, we don't keep those around. With the number of binary
extensions in ActiveTcl, we made a decision a few years ago to save
space by not keeping around the dev bits. I understand that they would
be useful to a small percentage of users, but we haven't figured out any
way to easily automate the handling of dev bits separate from user bits.

Jeff

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Wed, 12 Apr 2006 17:58:19 +0300

Are there any plans to have a real public interface for building
methods and objects in C sometime in the near future? Like
XOTCL_STUBS or whatever. As projects increase in size and complexity
there are points when it would be increasingly beneficial to be able
to move bits to C, mainly for performance reasons.

I realise there are interfaces that offer this functionality, but it
is my understanding that they are still under development and not set
in stone, so it is natural to be wary about them.

            / http://www.fishpool.com/~setok/

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Tue, 10 Dec 2002 13:28:29 +0100

On Tuesday 10 December 2002 01:44, Jeff Hobbs wrote:
> > - the choice of ALLOCA is not good vor Visual C/C++ 5.0. Choosing MALLOC
> > seems to be good and should be good for all IBM compilers
>
> No, alloca != malloc. alloca uses stack and auto-frees. alloca should
> also be available on AIX by including either -lc or -lbsd.

 Jeff, let me explain a possible misunderstanding.
 XOTcl needs frequently a variable number of temporary
 objects for the scope of a procedure. The XOTcl implementation
 uses three different approaches to achive this in a timely manner:
 
   1) use variable sized arrays
   2) use alloc
   3) use malloc

 Since not every c-compiler supports (1) we defined (2) and
 (3) as fallbacks (in this preference order). Per default
 (1) is used, when USE_ALLOCA is defined (2), when USE_MALLOC
 is defined, strategy (3). I think Adrian was refering to the
 choice between (2) and (3).

> > - the compilers were formerly versioned with hex codes now they are with
> > decimal codes which regrettably sabotages any scalar comparison so #if
> > __IBMC__ >= 0x306 won't work. This makes it hard to distinguish between
> > various IBM C compilers. If you insist compare only with = not with > or
>
> <.
>
> Ack, except for compiler bugs, what would want want to care about the
> version of the compiler for?
>
> > - the shared library configuration is not correctly used in the
> > makefiles. see description below
>
> It would probably help if someone upgraded this to TEA2 build system.
> It isn't a big modification, but it does have notable improvements like
> not requiring that the extension be built with the same compiler setup
> as Tcl itself was. This is important on "odd" platforms like AIX, where
> gcc and xlc/cc can greatly disagree.

 this are good news. we are planing to make a patch release with
 a few small patches before christmas available. I won't be able
 to work on the TEA->TEA2 migration over the next weeks, i am not
 sure, whether uwe will be able to do this before christmas...

 in the worst case, this change will not be included in the patch
 release....

 greetings,
 -gustaf


>
> Jeff Hobbs The Tcl Guy
> Senior Developer http://www.ActiveState.com/
> Tcl Support and Productivity Solutions
>
> _______________________________________________
> 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: Tue, 03 Oct 2006 13:55:41 +0200

Kristoffer Lawson schrieb:
> I need to know if the current procedural context is inside a method
> (isntproc, proc, whatever) or not.
can you explain in more detail, what the problem is?
Note, that one can calls tcl procs from within xotcl methods, one can
have evals, uplevels, etc.

> What is the best way to do this? I used [self] to check by catching
> the error, but that doesn't work particularly well if another package
> happens to define the command [self].
use ::xotcl::self

"self" can be used to check whether the xotcl callstack is non-empty.

without promising to much, a sucommand"ismethod" for "self" retuning 0
or 1 depending whether the
current stackframe is an xotcl method should be doable with little effort.

-gustaf

From: Matthew Smith <chedderslam_at_gmail.com>
Date: Thu, 8 May 2008 08:11:56 -0500

>
> Putting in:
> s1 push a
> results in an error, however I can do:
>
what is the error? this indicates that you have not defined the method push
correctly

I get:
 invalid command name "s1"
for:
s1 push 1
I get the same for:
xotcl::s1 push 1

On Thu, May 8, 2008 at 2:27 AM, Gustaf Neumann <neumann_at_wu-wien.ac.at>
wrote:

> Matthew Smith schrieb:
>
>> Thank you, Gustaf. Makes sense.
>>
>> Is there anyway to call a method besides doing a "puts".
>>
> sure.
>
>>
>> Putting in:
>> s1 push a
>> results in an error, however I can do:
>>
> what is the error? this indicates that you have not defined the method push
> correctly.
>
> puts [s1 pop]
>>
>> I would think that there would be a way to call a method without
>> outputiing. Is there one?
>>
> sure:
>
> set a [s1 pop]
>
> The method pop returns a value. The question is, what do you want to do
> in your application with the value. Technically, "s1" is a Tcl command
> (which happens to be an XOTcl object) that returns a value. By placing
> the tcl command between square braces, you will be performing
> "command substitution", which means "replace the command with
> the result of the command" during evaluation. Same mechanism as
>
> set x [expr {1+2}]
>
> or
>
> puts [expr {1+2}]
>
> hope this helps
>
> -gustaf neumann
>
>