Weblog Page

From: Uwe Zdun <uwe.zdun_at_uni-essen.de>
Date: Tue, 25 Sep 2001 17:40:19 +0200

On Monday 24 September 2001 11:26 pm, you wrote:
> On Mon, 24 Sep 2001, Uwe Zdun wrote:
> > in the forthcoming XOTcl release will be several new filter features ...
> > I've already reported on the obj-filters. Another feature we have ready
> > are "filter guards". A filter guard is a condition whether a filter will
> > be executed or not. It is registration-centric, thus you can append the
> > conditions to the filter registration, example:
> >
> > A instfilter {filter-1 {filter-2 {[self calledclass] ==
> > "::FigureElement"}}}
>
> I wonder if it would make sense to allow filters to be objects? In that
> way filters could become semi-independent entities that can used
> in various different places by attaching them to other objects, and
> filtering specific methods. In that way they might more closely follow the
> direction taken by AOP concepts. Or would mixins be better for this kind
> of design?
>
> Haven't given it much thought. I'm just rambling :-)

Without having given that too much thought either, I think there are three
possible paths to make filters objects:

a) make everything in XOTcl an object including procs and instprocs =>
filters are objects as well

b) make filters special objects which have a method (proc) on them which is
the filter. This would be a substantially different model to what we have
now. Filter search would have to take place on these objects, filters would
not be inherited, linearization of filters would be different, etc. But, of
course, we could combine different filters on these objects. This would be
closer to cross-cutting concerns in AOP.

c) we could (optionally) return objects by the info methods of a filter which
are linked to the filter. Thus the filters would stay what they are, but they
can be queried using an object. This is more or less the lightweight object
idea discussed on this list before. E.g. there could be a modifier for info,
such as:
  set fi [X info -obj instfilter]
  puts [$fi set filters]
  puts [$fi set guards]
whereas:
  X info instfilter
returns the usual list. We could as well provide such links to other
interesting infos, as for instance the filter callstack info (callingobject,
etc.)

--uwe

PS: we have reduced the minimum per-object size to 48 bytes so that such
lightweight object become quite feasible ...

-- 
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: Jim Lynch <jim_at_jam.sessionsnet.org>
Date: Sat, 10 Apr 2004 22:24:44 -0700

Hi Gustaf and group,

On Sat, 10 Apr 2004 22:52:39 +0200
"Gustaf Neumann" <neumann_at_wu-wien.ac.at> wrote:

> On Tuesday 06 April 2004 16:06, Jim Lynch wrote:
>

(this is actually Gustaf talking here, I think)
 
> > > Therefore, i have named the configure switch
> > > --with-aolserver3=AOL_INCLUDE_DIR
> > > where you have to specify the include directory.
> >
> > Suggestion, howbout the prefix dir instead? That way, any time you add
> > dependendency on another kind of thing, you already planned for the
> > stem dir.
>
> there might be cases, where the prefix of xotcl is not the same
> as the aoldirectory. On my system, i have for tcl and xotcl
> --prefix=/usr and for the aolserver (the default) /usr/local
>
> > Besides, if this switch is to represent the include dir, it
> > is misnamed, and should be named something like --with-aolserver-inc=.
>
> well. by using --with-aolserver3 you tell xotcl, that it should build the
> aolserver 3.* type c module, and you tell it at the same time, where
> to find the includes. therefor i think --with-aolserver3 is still better.

Well, of course I meant the aolserver prefix :) The includes should be
right there, in <the-aolserver-prefix>/include. Do you not also need
the aolserver libs? It's feasible you might in the future.

> > > well, can you be more specific, where this happens?
> > > XOTcl uses in configure.in SC_PROC_TCLSH
> > > and uses in all the Makefiles $TCLSH_PROG as far i can see.
> > > What version of xotcl are you working with?
> >
> > I'm using xotcl-1.2.0; my situation is I'm building using a tcl
> > I built specifically for an aolserver4. It's not the system tcl
> > and its bin dir is not in my path.
>
> if you only want to build xotcl, you need no tclsh at all (tclsh is used
> only for doc generation, testing, installing). If you build for aolserver 4
> you need in the minimal version
> # cd xotcl-1.2.0/unix
> ./configure --enable-threads \
> --prefix=/usr/local/aolserver \
> --with-tcl=/usr/src/tcl8.4.5/unix
> # make libxotcl1.2.so
> # make install-aol
>
> everything including "make libxotcl1.2.so" should be fine without
> a tclsh. the "make install-aol" uses a tclsh to load xotcl (for a minor
> purpose, to rebuild the pkgIndex files). If you comment out
> the last line of the "libraries:" rule in unix/Makefile,
> you should be fine.

See though, the whole point is not having to edit anything... Having to
do so implies C-based clue, which while you could assume it 20 years
ago, is just not the case among unix-alike users anymore, and note
carefully that this group especially includes people who want to use
xotcl.

I want to give them at least two things:

one, an ability to compile xotcl in more situations than is now possible
due to the fact that the configure process only half-works;

and two, where it isn't possible in a particular situation, I want to
issue a meaningful error message so that they will know the real
problem.

One requirement for this, is to find problems as early as when and where
they originally occured; it is there that the most information on
whatever problem might exist would be available: once you throw the
error up the call chain, you lose everything in the stack frame... if an
error which should stop the configure process is overlooked, the
configure step could appear successful, and might stop the make or some
step the make invokes.

> -gustaf

-Jim

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

From: Catherine Letondal <letondal_at_pasteur.fr>
Date: Tue, 06 Feb 2001 16:15:56 +0100

Gustaf Neumann wrote:
>
> Catherine, you seem to be quite happy with your Tk integration. Can
> you post a small but complete introductory example. Do you use Tk
> features like "-command"?
>

Yes I do, as well as -variable -textvariable and bindings.
I use [incr tk] as well (for which I have to help the Xotcl widgets
tree to correspond to the actual tk tree).

The aim was to be able to keep the actual tk creation/layout code that you can
borrow in books, ftp sites, application examples, ... it's very important
to me to keep such examples usable without any adaptation.

Another aim is to be able to have a memory image of the Tk widgets state, for
I want my application to be persistent, or just to be able to edit or clone objects
with their tk widgets.

A 3rd goal is to keep advantages of the composite pattern.
For instance, as the general idea of the application (very influenced by the Self
environment although much more modest) is to have a graphical handle for application
objects (I don't mean all XOtcl objects, but application level ones), I need to be
able to find this object from a menu which may be posted from any location in the GUI.

So I will try to summarize a small example - it's impossible to make
it complete though, there is too much code and it's not ready for
distribution - at all.

# -----------------------------------------------------------------------------
# composite pattern

[... same as in the Xotcl paper...]
Composite AbstractNode
AbstractNode filter compositeFilter
AbstractNode abstract instproc iterate v

# -----------------------------------------------------------------------------
# GraphObject is the general graphical object class

GraphObject instproc draw args {
    [...]

    # generic frame for all graphical objects

    set frame ${object_name}_frame
    widgets build $frame {
        frame $path -borderwidth 2 -relief sunken
    }
    widgets layout $frame {
        pack $path -expand 1 -fill both
    }

    # location for custom widgets (as in [incr tk])
    [self] instvar childsite
    set childsite ${frame}::widgets
    [...]
}

# -----------------------------------------------------------------------------
# example: a field object
# (containing an entry widget and a button)

Class Field -superclass GraphObject

Field instproc init args {
    [...]
    [self] draw
}

Field instproc draw args {
    next

    [self] instvar childsite
    set path [$childsite set path]
    widgets build $childsite {
        frame $path
    }
    widgets layout $childsite {
        pack $path -expand 1 -fill both
    }

    # -------------------------------------------------------------
    # 1st tk widget: an entry

    [self] instvar data
    # datavar contains the name of a global variable
    set datavar [$data set datavar]
    widgets build ${childsite}::datafield {
        entry $path.datafield -textvariable $datavar
    }
    widgets layout ${childsite}::datafield {
        pack $path.datafield -side top -expand 1 -fill x
    }
    ::bind $path.datafield <Return> {
        set object [names object %W]
        # MVC protocol
        [$object set data] update
    }

    # -------------------------------------------------------------
    # 2nd tk widget: a button

    widgets build ${childsite}::doit {
        button $path.doit -command [list [self] do_something] -text "DoIt"
    }
    widgets layout ${childsite}::doit {
        pack $path.doit -side left
    }

    # -------------------------------------------------------------

    # connect all widgets to the current graphical object
    $childsite iterate setObjectName [self]

    # bind button3 to a "meta" menu for all the widgets hierarchy
    $childsite iterate bindMetaButton

}

# -----------------------------------------------------------------------------
# Widgets

Class Widgets -superclass AbstractNode
Class Widget -superclass Widgets

Object widgets

widgets proc build {widget body} {

    # XOtcl Widget creation
    uplevel Widget $widget

    # actual tk creation
    if [catch {set path [uplevel $body]} err] {
        global errorInfo
        puts stderr "widgets (build) err:$err\n$errorInfo"
    } else {
        [self] setwidget $widget $path
    }
}

widgets proc setwidget {widget path} {

    # data structure initializations
    $widget set path $path
    $widget set type [string tolower [winfo class $path]]
    $widget set options [[self] buildoptions $path]
}

widgets proc layout {widget body} {

     # actual layout
    if [catch {uplevel $body} err] {
        global errorInfo
        puts stderr "Widget (layout) err:$err\n$errorInfo"
    } else {

       # data structure initializations...
       $widget set layout [[self] buildlayout [$widget set path]]
    }
}


# -----------------------------------------------------------------------------
# visitors for widgets hierarchy

Class TreeVisitor
TreeVisitor abstract instproc visit objectName

# menu for graphical objects

TreeVisitor bindMetaButton
bindMetaButton proc visit args {
    set node [lindex $args 0]
    set path [$node set path]
    if [::winfo exists $path] {
        ::bind $path <ButtonPress-3> {
            set object [names object %W]
            ${object}::menu display $object [$object set commands] %x %y %X %Y %W
            break
        }
    }
}

TreeVisitor setObjectName
setObjectName proc visit args {
    set node [lindex $args 0]
    set obj [lindex $args 1]
    $node instvar object
    if { $obj != "" } {
        set object $obj
    }
    if { [names object [$node set path]] == "" } {
        names object [$node set path] $obj
    }
}


# -----------------------------------------------------------------------------
# names: name server (alias, graphical objects, widgets,...)

Object names

# bind graphical objects and tk widgets
names proc object {widget {object ""}} {
    [self] instvar objects
    if {$object == ""} {
        if [info exists objects($widget)] {
            [self] set objects($widget)
        }
    } else {
        [self] set objects($widget) $object
    }
}

--
Catherine Letondal -- Pasteur Institute Computing Center

From: jim <jamesmc_at_localnet.com>
Date: Tue, 9 Dec 2003 05:58:02 -0500

Hello Uwe,
 
i sent a reply to the mail list that i had solved this but it didnt go
through. It told me i wasnt a list member and i had to wait for the
moderator.
I am trying again so no one else answers.
 
 
thank you,
marvin

From: Jim Lynch <jim_at_jam.sessionsnet.org>
Date: Thu, 5 Oct 2006 12:37:01 -0700

Gustaf,

How much effort would be involved in creating a -extensively- annotated
refactoring of xotcl and tcl which includes your counterproposed extension?

Could there also be another extension refactored to "plug into" tcl +
your extension, to show flexibility and otherwise proving the concept?

-Jim

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

From: Ben Thomasson <ben.thomasson_at_gmail.com>
Date: Fri, 21 Jul 2006 13:58:44 -0400

For now this project is a place to collect the various tools that have been
created by the community. There will
be multiple versions of several tools that xotclers have created. Some time
in the future we can merge/select
the tools to form a more coherent set.

Anyone wanting to contribute code, let me know.

Ben



> I have some stuff which might be useful for that, like a profiler
> tool and a debug output library which is useful both for with Tcl and
> XOTcl.
>
> / http://www.fishpool.com/~setok/
>
> _______________________________________________
> 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: Fri, 13 Jul 2001 16:48:45 +0200

 Dear XOTcl community,

 on www.xotcl.org, you will find a patch release p2 of xotcl 0.85.

 The main fixes are:

   - propagation of special return codes (e.g. ... return -code continue ...)
     which is needed for Tk event maps, as catherine pointed out

   - first version of custom setter/getter methods for -parameter
     (see for now: apps/scripts/parameter.xotcl)
     The documented part in parameter.xotcl is intended to stay, some
     more features might be added.

 Preview for the next major release:
 Uwe has rewritten a good deal of the filters/mixins code, which is running
 through our regression test already. Among other things, this will introduce
 per object filters; this will complete our matrix of orthogonal features below:
 
            per object per class
    filter filter instfilter
    mixin mixin instmixin

 This is, however, a major change in the code, it will require some more
 testing etc, and it will go into the next major release.

 best regards
 -gustaf neumann

From: Victor Mayevski <vitick_at_gmail.com>
Date: Tue, 24 Aug 2010 13:07:05 -0700 (PDT)

Hello Gustaf,

Any hints about a stable release of XOTcl 2.0/Next 1.0? Date? Inclusion with ActiveTcl?

Thanks

From: Matthew Smith <chedderslam_at_gmail.com>
Date: Fri, 16 May 2008 10:04:51 -0500

I response to a forum post, someone wrote the code below, which creates an
xowiki object. I am trying to work with the code but am not sure what some
of it means. Here is the code, with questions below.
-------------------------------------------------------------------------
# -*- tcl-*-
# Sample prototype page to show different output formats
# Gustaf Neumann, May 2008
::xowiki::Object new -title "Multiple Output Types" -text {

  my initialize -parameter {
    {-format "text"}
  }

  proc content {} {
    my get_parameters

    switch $format {
      xml {
        set content_type text/xml
        set content {
            <districts>
                <district>
                    <COE_DISTRICT_NAME>VICKSBURG</COE_DISTRICT_NAME>
                    <DISTRICT_ABBREVIATION>MVK</DISTRICT_ABBREVIATION>
                </district>
                <district>
                    <COE_DISTRICT_NAME>NEW ORLEANS</COE_DISTRICT_NAME>
                    <DISTRICT_ABBREVIATION>MVN</DISTRICT_ABBREVIATION>
                </district>
                <district>
                    <COE_DISTRICT_NAME>ST. PAUL</COE_DISTRICT_NAME>
                    <DISTRICT_ABBREVIATION>MVP</DISTRICT_ABBREVIATION>
                </district>
            </districts>
        }
      }
      csv {
        set content_type text/csv
        ns_set put [ns_conn outputheaders] Content-Disposition
"attachment;filename=sample.csv"
        set content {
          VICKSBURG,MVK
          NEW ORLEANS,MVN
          ST. PAUL,MVP
        }
      }
      json {
        set content_type text/plain
        set content "
            \{
                districts:\{
                    district:\[
                        \{
                            coe_district_name:'VICKSBURG',
                            district_abbreviation:'MVK'
                        \},
                        \{
                            coe_district_name:'NEW ORLEANS',
                            district_abbreviation:'MVN'
                        \},
                        \{
                            coe_district_name:'ST. PAUL',
                            district_abbreviation:'MVP'
                        \}
                    \]
                \}
            \}
        "
      }
      default {
        return [[my info parent] description]
      }
    }
    ::xo::cc set_parameter master 0
    ::xo::cc set_parameter content-type $content_type
    return $content
  }
} -description {
  I am just a sample service that can return its content in different
  formats. <br>Call me e.g. with format
  <a href='multiple-output-types?format=xml'>xml</a>,
  <a href='multiple-output-types?format=csv'>csv</a>, or
  <a href='multiple-output-types?format=json'>json</a>.
}
---------------------------------------------------------------------
in the lines:
    ::xo::cc set_parameter master 0
    ::xo::cc set_parameter content-type $content_type
what does the "::xo::cc" mean?

If the object is being created, how do I reference the object? For
instance, I would like to set a variable to "content". How would I do
this?

Thank you for any help.

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Mon, 12 May 2003 18:39:44 +0200

On Monday 12 May 2003 17:36, Uwe Zdun wrote:
> This corresponds to the idea of making filters etc themselves objects.
> I like this idea from a conceptual point of view. Implementation-wise
> it could be a larger undertaking ... the problem is that these
> "collections" manage different things at the C-code level (Tcl_Obj*s, Cmds,
> etc) in lists and hashtables and that some parts are not under control of
> XOTcl's C code (children are managed by Tcl in Namespaces). So really a 2.0
> issue :)

 same opinon here; we had already some discussion some time ago about
 transforming e.g. methods into objects, etc. We did a big step in this direction when
 we implemented our "light-weight objects", which require namespaces
 etc on demand (please note, that lightweight is relative; see also
 http://media.wu-wien.ac.at/download/mem.log). But still, objects
 are costly in terms of time and memory.

 I am pondering since a while about a simple thing: transforming
 xotcl parameters into objects. Conceptually, this is quite simple, but
 has disadvantages from benchmarks etc, whenmultiple objects are created
 on the fly, in situations where the users expects one class/object to be created.
 Maybe we are able to provide object facades, or to create these interface
 objects on demand, while keeping low-fat memory strucutures....... but this
 will take a few releases...

 greetings
-gustaf

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