View · Search · Index
No registered users in community xowiki
in last 10 minutes

Weblog Page

Showing 1151 - 1160 of 1561 Postings (summary)

[Xotcl] XOTcl as a megawidget framework

Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM

From: Schofield, Bryan \(GE Transportation\) <"Schofield,>
Date: Tue, 8 Jun 2004 08:52:45 -0400

Hullo -

This is my first posting to this mailing list. I recently started playing around with XOTcl. I had been using IncrTcl for quite a while, but XOTcl has seemed to get a lot publicity in a few other mailing lists, so I decided to give it a try.

My first impression of XOTcl is very good. I'm finding myself growing very fond of how classes are defined in XOTcl and I'm loving the dynamic nature of classes and objects in general. Though I have to admit, the "instproc", "instvar", and "my" took a little getting used to and I do miss the protection levels available in IncrTcl, but only a little. Anyway, that's not the real reason I'm posting.

Has any work gone into making a TK megawidget framework with XOTcl? I spent a little time and came up with a couple of classes that make this possible. Even though this is just a prototype, I'd be very interested in getting some XOTcl'ers feed back on this.

I've attached a file called xowidget.tcl that contains the megawidget framework package and an example of using it, SearchableListbox.tcl.

This package, which I've cleverly been calling "xowidget", provides the ability to create an XOTcl object that behaves like a TK widget. It also provides Snit-like method & option delegation to the basewidget, subcomponents, and other objects. Furthermore, the method & option delegation can be multiplexed such that a method or option is propogated to multiple objects and/or tk widgets. I've tried to document how to xowidget in source file, but if something is missing or not clear, please feel free to ask me. Here is a small example of what the syntax is like.



WidgetClass LabeledButton \
   -tkwidget frame \
   -parameter { {foo bar} }
LabeledButton instproc init args {
   next
   my instvar widgetpath
   # create a label and button in the frame
   label $widgetpath.l
   button $widgetpath.b
   pack $widgetpath.l $widgetpath.b -side left

   # make the foo parameter an configurable option
   my tkoption add foo parameter -object [self]
   # add borderwidth & relief option for the basewidget
   my tkoption add frameborderwidth widgetproc \
      -object [self] -asoption borderwidth
   my tkoption add framerelief widgetproc \
      -object [self] -asoption relief
   # add option for the text on the label
   my tkoption add labeltext tkwidget \
      -widgetpath $widgetpath.l -asotion text
   # multiplex background option to the frame, label, and button
   my tkoption add background widgetproc -object [self]
   my tkoption add background tkwidget -widgetpath $widgetpath.l
   my tkoption add background tkwidget -widgetpath $widgetpath.b
   # wildcard all other options to the button
   my tkoption add * tkwidget \
      -widgetpath $widgetpath.b

   # make the foo parameter command available
   my tkcommand add foo
   # wildcard all other commands to the button
   my tkcommand add * "$widgetpath.b"
}
pack [LabeledButton .lb -labeltext Foo -text "Press me" -command doSomething]
puts [.lb configure]
.lb invoke
.lb foo "ack"



I'm very open to suggestions and comments, critical or otherwise. If there is some interest, I'd be open to enhancing this expiriment to something more.

Thanks in advance.

-- bryan



      [Xotcl] xotcl::nonposArgs

      Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM

      From: Michael Aram <michael_at_aram.at>
      Date: Wed, 15 Jul 2015 11:53:27 +0200

      Dear XOTcl/NSF community,

      in order to contrain the input of certain methods to allow only objects of
      a certain type/class, e.g.:

      Utility proc get_object_id_from_sourced_guid {
          -sourced_guid:sourced_guid
      } { ... }


      we have the following code in our code base:

      if {[info command ::xotcl::nonposArgs] ne ""} {
        ::xotcl::nonposArgs proc sourced_guid args {
          if {[llength $args] < 2} return
          foreach {name value} $args break
          if {![::xotcl::Object isobject $value]} {error "'$value' is not an
      object"}
          if {![$value istype ::foo::bar::SourcedGuid]} {error "'$value' is not
      of type SourcedGuid but [$value info class]"}
        }
        ::Serializer exportMethods {
          ::xotcl::nonposArgs proc sourced_guid
        }
      }


      This works with XOTcl 1.6, but we now see the following warnings when
      running the code under NSF:

      Warning: nsf: Could not find value checker type=sourced_guid defined on
      ::nx::methodParameterSlot


      What is the correct way to port this to XOTcl 2.0?

      Thank you for your help!
      Michael

      Re: [Xotcl] "tie" command

      Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM

      From: Kristoffer Lawson <setok_at_fishpool.com>
      Date: Fri, 24 Jan 2003 18:48:38 +0200 (EET)

      On Fri, 24 Jan 2003, Gustaf Neumann wrote:

      >
      > The caller can certainly do with the object whatever she wants.
      > if these are properties needed in the creation method they
      > have to be passed somehow there, or the object can be altered,
      > or one can put a mechanism on top of the creation to handle this.
      > I personally would not have a problem in using two different method
      > names for the different cases, like
      > set msg [$cmdReader getMessage]
      > set msg [$cmdReader getNewMessage]
      > or to use an option like in
      > set msg [$cmdReader getMessage -volatile]

      But that doesn't solve the issue. $cmdReader cannot create the object
      itself as volatile or bound to a variable as it will then be destroyed the
      minute getNewMessage returns! Or, of course it could always use uplevel
      and upvar but then every method that wants to return an object that may or
      may not be bound to a variable has to provide this extra functionality and
      argument checking. Ie. the methods need to be concerned with what the
      caller wants, and I don't believe this is necessary a good thing.

      Again, I'm not saying this feature is absolutely essential, but if one
      decides to add it I believe it should be done in the best possible way ;-)

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

      [Xotcl] XOTclIDE Version 0.35

      Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM

      From: Artur Trzewik <mail_at_xdobry.de>
      Date: Tue, 26 Nov 2002 19:15:32 +0100

      Hi!

      The Integrated/Interactive Development Environment for XOTcl
      The new version of XOTclIDE 0.35 is ready on
      http://www.xdobry.de/xotclide

      The Changes from last announced Version
      - code completion by XOTcl/Tcl code editing (for variables and methods names)
      - configuration maps can be stored in version system. New complex
      configuration browser (only with version system)
      - changes in GUI for more consistence
      - many small bug fixes and improvements

      By implementing configuration browser I have used some
      advanced techniques as event controlling (Modell-View-Controller)
      and objects-database mapping for n:m relationships (with garanted object
      identity and central objects cashing - mapping for ordered objects lists).

      have fun with it

      Artur Trzewik

      Re: [Xotcl] XOTcl 2.0 and NX

      Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM

      From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
      Date: Fri, 01 Oct 2010 08:44:58 +0200

        On 01.10.10 06:50, vitick_at_gmail.com wrote:
      > Dear Gustaf,
      >
      > What is the reason for having XOTcl 2.0 and NX at the same time?
      we will make a larger announcement in the near future
      explaining the background, relationships in detail.

      For now: we have a large XOTcl code base, for which it is
      unrealistic to switch to the new language in short time.
      Both, XOTcl 2.0 and our next scripting language are fully
      scripted (loaded via package require), so they are much
      easier to maintain.
      > In NX, method declaration is private by default where it seems to me that it is more natural for it to be public by default (since the majority method declarations will be public) and it is the private method that should be declared explicitly.
      many experiences and comments from 10+ years of xotcl were
      brought into the design of nx (e.g. issues about naming,
      large set of base methods, experiences from bug tracking,
      etc.). One experience from larger projects (more than
      500.000 tcl/xotcl code, larger and changing programmer team)
      is that forcing developer to declare interfaces helps to
      improve comprehensibility for starters. btw, nx has a weak
      form of protection, one can call protected methods via "obj
      eval .....", but these should be reminders to provide a
      public interface for that functionality. Furthermore, the
      default protection can be changed from the scripting level.

      -gustaf neumann

      XOTcl/NX mailing list by object move?

      Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM

      From: Scott Gargash <scottg_at_atc.creative.com>
      Date: Sun, 19 Mar 2006 04:57:52 -0700

      Thanks for your patience with me and my ignorance. I had inferred that XOTcl was using Tcl
      namespaces for storing object attributes (methods/variables/aggregations), but in my limited usage I
      didn't realize that that was (legally) being used to advantage (making plain tcl commands become
      xotcl methods via namespace import or the like). So far I've been assuming the only legal way to
      manipulate the object was through its handle (the object command).

      Given my assumption, my thought was that you could cleanly substitute Tcl's namespace mechanism with
      a hash-table lookup (attribute name -> Tcl_Obj *) for finding object attributes. Since each object
      would have its own table, so there's no problem with name collisions (a attribute name is scoped by
      the object you access it through, i.e., each object has its own set of slots), and if an object can
      only be accessed through its handle, the handle is the only thing that needs to be exposed to the
      interpreter. None of the attributes would be visible to Tcl at all (Except to the extent XOTcl
      exposed them. You could still have traces and whatnot, but you'd have to use the object handle to
      access them). And if the objects were always accessed via a level of indirection, the raw object
      handle (the true command name) is uninteresting too, so all objects be created with autonames in the
      same namespace. And that this sort of an implementation (using a custom attribute lookup mechanism
      instead of leveraging Tcl's) might potentially have some performance wins and/or new feature
      possibilities.

      But from your explanation, using Tcl namespaces to store object attributes is not just an
      implementation decision, it's really part of the interface, so my approach would break XOTcl in
      varied and uninteresting ways.

            Scott

      Gustaf Neumann <neumann_at_wu-wien.ac.at> wrote on 03/18/2006 06:52:25 PM:

      > Scott Gargash schrieb:
      > >
      > > Gustaf Neumann <neumann_at_wu-wien.ac.at> wrote on 03/18/2006 01:39:35 PM:
      > > >
      > > > I do not see much evidence of a speed increase when adding a layer of
      > > > indirection for every object access.
      > >
      > > Well, for example, it might be possible to get rid of namespaces in
      > > the implementation.
      > >
      > thinking about getting rid of namespaces is a different theme, this can
      > be done as well without "strongly aliased objects".
      >
      > namespaces are pretty essential in tcl. every command name lookup
      > works through a namespace. xotcl uses
      > tcl-namespaces for methods (procs and instprocs), for variables, and for
      > aggregations. certainly, this could be
      > implemented differently, frequently we have to fight with namespaces,
      > but the idea was to reuse concepts
      > from tcl in xotcl. Using tcl-namespaces has many advantages as well:
      > currently, we can rename tcl-procs
      > or tcl-commands to make it methods in xotcl; or we can namespace-import
      > procs/cmds from tcl as
      > methods/instmethods etc. into xotcl with the standard tcl-commands.
      > >
      > > If the access to the object is always through the reference and the
      > > true object was never visible, you might not have to create a new
      > > namespace (on demand or not)
      > >
      > i can't follow the argument.... what ist the relationship with the
      > visibility? namespaces are used for various purposes:
      > methods are tcl_procs or tcl-commands and have to "live" somewhere, in
      > tcl they live in namespaces.
      > one can certainly implement this differently as in tcl, as for example
      > using hash-tables only, but this is not
      > related to visibility. btw, if you never show the real name to the
      > application developer, it will be hard to create
      > multiple references other than by creating an alias of the alias.
      > > or ever move an existing object to make it a child of another object.
      > > The parent/subobject relationship could be inferred from the alias's
      > > location in the namespace, or even tracked in child/parent hash tables
      > > if you wanted to support object relationships beyond a tree (DAGs),
      > > but it would not be a property of the object's location. If objects
      > > never moved, everything could live in the same namespace, and just
      > > tracked via the object hashes.
      > >
      > > And is method dispatch done via a command lookup? If so, an invariant
      > > method location should allow command lookup to be elided.
      > >
      > whatever "same namespace" means (see above). note that we have multiple
      > identical method names in procs/classes,
      > they can't live in the same namespace. if the nesting relationship is
      > realized via the namespaces of the aliases,
      > these have to be created as well since they will most likely not exist.
      > This way, they namespaces are moved
      > out of the xotcl objects, but introduced at different places, where they
      > are more complicated to manage.
      > some interactions with namespaces will be even more complicated as they
      > are now: you have to
      > deal with cases, where e.g. someome deletes the alias (e.g. via "rename
      > myreference {}") or deletes
      > the namepace, where the alias lives in.
      > >
      > >
      > > Of course, since I'm the one who keeps asking "How do I do this?"
      > > questions, I'm probably completely wrong.
      > > BTW, does invocation via an alias have any overhead? I would guess
      > > not as it's (seems like) a string->Tcl_Obj mapping, the same as a
      > > native command lookup, but I don't know.
      > >
      > an "interp alias" has a certain overhead, since it is an additional
      > command invocation.
      > Try the following; if you increment the loop counter in the for loop to
      > e.g. 1000,
      > you will get a "too many nested evaluations" error. you will see, the
      > last test will be
      > the slowest by far.
      >
      > ==========================================================
      > proc t {cmd {txt ""}} {
      > set n 100000
      > set ms [lindex [time [list time $cmd $n] 10] 0]
      > puts "[format %7.4f [expr {$ms*1.0/$n}]]ms for $cmd ($txt)"
      > }
      >
      > proc x {} {set x 1}
      > interp alias {} myset {} set
      > interp alias {} myx {} x
      > interp alias {} myx1 {} x
      >
      > for {set i 1} {$i < 100} {incr i} {
      > set i1 [expr {$i+1}]
      > interp alias {} myx$i1 {} myx$i
      > }
      >
      > t {set x 1} "set"
      > t {myset x 1} "myset"
      >
      > t {x} "x"
      > t {myx} "myx"
      > t myx$i1 myx$i1
      > ==========================================================
      >
      > It is however possible to implement zero-overhead aliases
      > with the tcl c-api, at least in certain situations, when one does not
      > care about someone else replacing commands on the fly with
      > global effects. I have implemented such things by myself.
      >
      > best regards
      > -gustaf neumann
      >
      >

      > ForwardSourceID:NT00007E9E

      Re: [Xotcl] new feature idea

      Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM

      From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
      Date: Thu, 30 Sep 2010 09:56:08 +0200

      Dear Victor,

      yes, this looks nice. It is premature to add it to the set
      of builtins, i have not had much uses cases for this functionality.
      But as you say, it can be easily scripted (see below)....
      or provided as and optional package.

      > This functionality is even more enhanced with mixins and
      > superclasses where each chained method would be passed to a
      > mixin/superclass via [next].

      one could pass in the list of methods as well per-object
      mixins,
      which could be added before and removed after the invocation.
      however, this would make invocation less elegant, and i doubt
      that there are many use cases for this.

      It is not fully clear what's the best way to return the results
      or errors of the multiple method invocations. The small
      implementation below returns a list of results of the
      individual methods, and does nothing about errors.

      we plan on the new web site a community space, where can
      place some implementation studies like this one.

      Btw., the "opposite" problem is to call a single method with
      a set of argument vectors (the method is called repeatedly
      with each element of the set). There is an implementation
      of that in the new regression test using the tcl8.6 function
      apply (similar in length to the example below).

      -gustaf neumann

      =================================
      package require nx

      nx::Object public method chain args {
         set methods [lrange $args 0 end-1]
         set arguments [lindex $args end]
         set result [list]
         foreach m $methods {
           lappend result [$m {*}$arguments]
         }
         return $result
      }

      Class create MyClass {
         :method a {x y z} {
           return "a $x"
         }
         :method b {x y z} {
           return "b $y"
         }
         :create m1
      }

      puts [::m1 chain :a :b {1 2 3}]

      [Xotcl] Debugging in Expect with XOTCL

      Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM

      From: Jegan Kumar Somi Ramasamy Subramanian -X \(jsomiram - HCL at Cisco\) <jsomiram_at_cisco.com>
      Date: Fri, 23 Jun 2006 16:03:14 +0530

      Hi all,
       
      I have few questions in debugging of XoTcl with expect/tclsh.
       
      1) How can we do debugging from expect? I am not able to use edprocs in
      xoTcl. I usually do "edprocs <proc name>" from expect and I will do
      necessary changes without changing the actual file. Do we have any such
      option in xoTcl?
       
      2) Also, is there any direct way to print or get the variables defined
      in a class in expect? As of now, I am creating a simple procedure in the
      expect under the required class and I am retrieving the values using
      that procedure by calling them with the corresponding object.
       
      3) In case of TCL, while doing debugging we do some changes in the .tcl
      file and we just source it in the expect prompt to get the changes. But
      in case of xoTcl, I am now coming out of expect and again opening a new
      one and giving a "package require <package name>" to get the updated
      information. Is there any simple way to do this as I need to reset many
      of my environment while doing this process?
       
       
      Thanks,
      Jegan.

      [Xotcl] Re: [Xotcl] Re: [Xotcl] Widgets

      Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM

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

      Gustaf Neumann wrote:
      > RH> Or wrap every tk command in my xotcl object.
      >
      > Sometimes, this is a straight forward solution to keeps the
      > XOTcl objects and the tk widget in separate trees. Architecturally,
      > this is not a beauty.

      How do you then implement the composite pattern for widgets trees as
      explained in:

      G. Neumann, U. Zdun: Filters as a Language Support for Design Patterns in Object-Oriented
                                Scripting Languages, in: Proceedings of COOTS, San Diego, California, USA, May, 1999.

      In my application, every Tk widget creation is wrapped in a method:

          widgets build ${frame}::widgets::panel {
              frame $path.panel
          }

      where widgets is of class Object.

      Then you may store informations concerning the widget, in order to be able to
      save it, clone it, or whatever.

      The composite pattern is very convenient indeed for tk widgets. I use it to
      make recursive Tk bindings, or to build a graphical attribute editor for all the
      widget tree.

      --
      Catherine Letondal -- Pasteur Institute Computing Center
      

      [Xotcl] XOTcl 1.1.0 publically available

      Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM

      From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
      Date: Sat, 29 Nov 2003 23:50:36 +0100

      Dear XOTcl community,

      XOTcl 1.1.0 is now available from www.xotcl.org!
      Below is the full announcement text!

       best regards
      -gustaf neumann

      ========================================================================

      Announcing XOTcl 1.1.0
      **********************

      WHAT IS XOTCL?

        XOTcl is an object-oriented extension of Tcl that was derived from
        OTcl. In short, XOTcl tries to provide a highly flexible,
        reflective, component-based, and object-oriented environment. It
        integrates language support for high level concepts which are not
        found in other languages, with reasonable performance. It prevails
        the Tcl programming style and the dynamic/introspective nature of
        the language, rather than introducing other language's styles and
        rigidness (such as C++) into Tcl.


      CHANGES relative to 1.0.2 are:

        - New functionality and improvements:

           * Transitive instmixins (thanks to a suggestion of Neophytos Demetriou):
             The new version supports a tree of mixins (mixins of mixins);
             when a mixin-class X has instmixins Y registered, and X is
             registered as instmixin for a class C, the mixin classes Y are
             applied to C as well.

           * Conditional mixins (thanks to a suggestion of Neophytos Demetriou):
             mixins and instmixins can have now guards similar to filters
             that define when they should be applied

           * New composition strategy for (filter- and mixin-)guards:
             when a guard is defined more than once for the same interceptor
             the most specific guard is used, the others are overridden.

           * Creation of sub-objects via parameter:
             XOTcl's parameter method supports now a switch named "-Class"
             which can be used to create and configure sub-objects (see
             tutorial for details)

           * New predefined method: __unknown
             This method is called, whenever XOTcl references a class,
             which is not defined yet (e.g.: Class C -superclass UNKNOWNCLASS)
             This method is used for Zoran's wonderful ttrace package
             (for aolserver and tcl-Threads)

           * Improved documentation:
              - extended tutorial (Meta-Classes, Tk, ...)
              - beautified tutorial (style files, distinction between
                literals and placeholders, ...)
              - fixed hundreds of typos

           * some speed improvements


        - fixes:
       
           * New build system:
              - per default no shells are built
              - new configure switches eg. --with-xotclsh, -with-actiweb
                --with-all

           * Fixes for https in connection with some versions of IE

           * Fixed a few issues with purify and mt (many thanks to Zoran!)
       
           * Fixes for proc-scoped variable in connections with mixins

           * Fixed passing of error codes from constructors

           * various small fixes and code cleanup
             - with newer versions of autoconf
             - various fixes for stubs
             - improved build under windows
             - starkit compliance (many thanks to MichaelL_at_frogware.com)


       For more details, please consult the ChangeLog

      MORE INFO
        General and more detailed information about XOTcl and its components
        can be found at http://www.xotcl.org


      Best regards,

      Gustaf Neumann
      Uwe Zdun


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

      Next Page