Weblog Page

From: <vitick_at_gmail.com>
Date: Tue, 26 Oct 2010 14:23:01 -0700 (PDT)

Is it possible to have a non-positional argument that is optional and its variable is only set when it is present as the argument to the method. Otherwise, it is ignored, no error.
Basically, I want it behave like an option to the method but without specifying any value. Example:

myobj method m {-test} {
    if {[info exists test]} {
        puts "test exists";
    } else {
        puts "test does not exist";
    }

myobj m;#test does not exist
myobj m -test;#test exists

Or, it can even be a boolean, set to 1 if it was specified and set to 0 if not. That would be even better, shorter code.

Thank you

From: Schofield, Bryan \(GE Transportation\) <"Schofield,>
Date: Thu, 10 Jun 2004 08:51:16 -0400

For anyone that is interested, I've been working on the option handling stuff a little more. The original method of adding tk configurable options is still available, but is now done via the [tkoption addexplicit] command. The new [tkoption add] takes a type and a source object (XOTcl, TK, or other depending on the type) and a series of options. This allows options to be added more easily.

tk option add tkwidget $widgetpath.foo \
   -except { yscrollcommand xscrollcommand } \
   -translate { background listbackground }

As I'm thinking about this, I think it might be a good idea to extract the tk option handling code in to it's own class for better reusability, maybe ConfigurableOptionManager or something.

-- bryan

> -----Original Message-----
> From: Schofield, Bryan (GE Transportation)
> Sent: Tuesday, June 08, 2004 8:53 AM
> To: 'xotcl_at_alice.wu-wien.ac.at'
> Subject: XOTcl as a megawidget framework
>
>
> 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
>

From: Uwe Zdun <uwe.zdun_at_wu-wien.ac.at>
Date: Wed, 23 Apr 2003 14:15:50 +0200

an add-on to this variant: Gustaf mentioned that you need an overloaded create
method here, if you want to enforce the Singleton property:

A instproc create args {error "cannot create Singleton instance"}

--Uwe

On Tuesday 22 April 2003 22:17, Uwe Zdun wrote:
> Hi,
>
> I just had the idea for yet another Singleton variant that was not exactly
> planned for in the XOTcl design, but seems to work fine: an object that has
> itself as a class (and Class as a superclass so that it stays a class):
>
> % Class A -superclass Class -class A
>
>
> that means it can define instprocs on it and dispatch them directly:
>
> % A instproc aProc args {puts ****}
> % A aProc
> ****
>
> procs do also work:
>
> % A proc bProc args {puts ++++}
> % A bProc
> ++++
>
> and you can derive a subclass from the Singleton:
>
> % Class B -superclass A
>
> ::B
>
> % B b
>
> ::b
>
> % b aProc
> ****
>
> and it conforms to the "Singleton definiton" (a class that has just one
> instance).
>
> --Uwe
>
> On Tuesday 22 April 2003 21:21, Artur Trzewik wrote:
> > Hallo!
> >
> > As singleton objects I often use Objects directly derived from Object
> >
> > Object MySingleton
> > MySingleton proc doJob {} {
> > puts "This is my job"
> > }
> >
> > MySingleton doJob
> >
> > This is not singleton pattern but is same cases you do not need some
> > Java, C++ solution.
> > One disadvantage is that you can not use method inheritance.
> >
> > By the way.
> > The presented solution from G. Neumann.
> > That is to overwrite "new" method that returns singleton object
> > is the standard way to implements singleton in Smalltalk
> > (the singleton instance is saved in class variable Default).
> > That is XOTcl! "new" is just method not special operator and can
> > be overwritten.
> >
> > 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_{xotcl,computer,acm}.org, uwe.zdun_at_wu-wien.ac.at

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Fri, 17 Mar 2006 17:25:37 +0200

On 17 Mar 2006, at 16:33, Gustaf Neumann wrote:
>
> as pointed out earlier, move is a copy + destroy.
> If you want a copy alone, use copy and not move.

No, I do not want copy alone. It is just counter-intuitive that the
destructor is called on a move as movement is not generally
considered to be an act of desctruction. This would be the norm for
most things. Consider files for example. When a file is moved at no
point does

> As Artur pointed out, command names are the references to objects.
> if such a reference should be made invalid and the unneeded
> storage should be reclaimed at this time, destroy is the correct
> thing.

The matter of references is problematic. I am thinking that in fact
this reveals a downside to the namespace-tied model as handles do not
point to the object itself, but to the object's location within the
namespace universe. A move is not actually a matter of transferring
the ownership of an object to a new location and this slightly limits
the ways you can use XOTcl move functionality for data structures.

Of course one can set variables to detect this, as mentioned, but
this seems like a bit of a hack and fighting against what XOTcl is
doing. Perhaps the question should be asked: how is object movement
actually supposed to be used in XOTcl?

A double-reference would solve this. In that way the handle returned
by [new] and [self] would always be a valid command for the object,
throughout its whole lifetime. If it is moved to be a child of
another object the handle remains the same (or at least can be used),
but the ownership is changed. Whether this is workable in XOTcl or
not is, of course, something you would be better at deciding.

In any case, the destruction should be clearly mentioned in the
documentation as there seems to be a number of people who are
surprised by that.

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

From: Gustaf Neumann <neumann_at_wu.ac.at>
Date: Sun, 28 Apr 2013 02:35:02 +0200

Dear Troy,

The head version in the master branch in git runs the sample
scripts with MongoDB 2.4.4-pre (as distributed via mac
ports). The potentially bigger dependency is the C-driver.
I've updated it to the current version 0.7.1. The version
supports a cursor interface, where cursors might be open
with the -tailable flag. Note that -tailable requires capped
collections, see e.g. example-nsf-mongo.tcl (see [1]).

The nsf mongo driver supports a low level mongo interface
[1] (just tcl commands) and a oo interface in nx [2]. The
current API is [3]. Let me know in case you miss something.

best regards
-gustaf neumann


[1]
http://cvs.openacs.org/browse/nsf/library/mongodb/example-nsf-mongo.tcl?hb=true
[2]
http://cvs.openacs.org/browse/nsf/library/mongodb/example-nx-bi.tcl?hb=true
[3]
http://cvs.openacs.org/browse/nsf/library/mongodb/mongoAPI.decls?hb=true



On 27.04.13 00:24, Troy Heron wrote:
> Hello,
>
> Before I look at using the NSF Mongodb driver, I'd just like to know if the
> driver compatible with the latest mongodb (2.4)? Also, does it support
> tailable cursors?
>
> Thanks,
> Troy
> _______________________________________________
> Xotcl mailing list
> Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl

From: Uwe Zdun <uwe.zdun_at_wu-wien.ac.at>
Date: Mon, 06 Sep 2004 16:32:48 +0200

Hi Kristoffer,

this looks like a bug, but it does not seem to be related to the
problems reported before.
I've checked: it was already present in earlier XOTcl versions (1.1).
I've to look deeper
into it to come up with a solution idea.

Uwe



Kristoffer Lawson wrote:

>
> This could be related to what others have reported but:
>
> [~/svn/codebase/trunk/tcl] package require XOTcl
> 1.3
> [~/svn/codebase/trunk/tcl] namespace import xotcl::*
> [~/svn/codebase/trunk/tcl] namespace eval foo {
>
>> Class Foo
>> Foo instproc blah {} {puts jou}
>> Foo proc bar {} {puts bar}
>> }
>
> [~/svn/codebase/trunk/tcl] namespace delete foo
> called Tcl_FindHashEntry on deleted table
> Abort
>
>
> / http://www.fishpool.com/~setok/
> _______________________________________________
> 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: Kristoffer Lawson <setok_at_scred.com>
Date: Wed, 7 May 2008 21:32:00 +0300

On 7 May 2008, at 21:25, Matthew Smith wrote:

>
> How do I call the methods like push and pop?

Assuming:

set s1 [Stack new]

$s1 push foo
$s1 pull

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

From: Marc Spitzer <mspitze1_at_optonline.net>
Date: Sat, 29 Nov 2003 20:05:31 -0500

Thanks.

marc

On Sun, 30 Nov 2003 01:49:45 +0100
Gustaf Neumann <neumann_at_wu-wien.ac.at> wrote:

> On Sunday 30 November 2003 00:45, Marc Spitzer wrote:
> > Now the files that are "missing" are in /usr/local/include/tcl8.4:
> >
> > bogomips# cd ../tcl8.4
> > bogomips# ls
> > generic tcl.h tclDecls.h tclPlatDecls.h unix
> > bogomips# ls *
> > tcl.h tclDecls.h tclPlatDecls.h
> >
> > generic:
> > regcustom.h tclDecls.h tclMath.h
> > regerrs.h tclIO.h tclPlatDecls.h
> > regex.h tclInitScript.h tclPort.h
> > regguts.h tclInt.h tclRegexp.h
> > tcl.h tclIntDecls.h
> > tclCompile.h tclIntPlatDecls.h
> >
> > unix:
> > tclUnixPort.h tclUnixThrd.h
> >
> > so how hard would it be to add a --with-tclinclude ?
>
> this is not hard. i will send you a version with that option with
> separate mail.
>
> > Also I would need to do this for tclsh and wish(do I need to do wish?),
>
> there is no need for wish
>
> > on freebsd they are both shell scripts that tel you what you have installed
> > not the real tclsh, like so: bogomips# tclsh
> > In FreeBSD, tclsh is named with a version number. This is because
> > different versions of tclsh are not compatible with each other and
> > they can not all be called "tclsh"! You may need multiple versions
> > installed because a given port may depend on a specific version.
> >
> > On your system, tclsh is installed under at least the following names:
> >
> > tclsh8.3
> > tclsh8.4
>
> this is not unusual. the name of the tclsh is deterimined by
> configure throught the configure macro SC_PROG_TCLSH.
> on my system, the tclsh is determined as
>
> TCLSH_PROG = /usr/bin/tclsh8.4
>
> One can use an arbitraty shell my invoking
>
> make "TCLSH_PROG=XXXXXXXXXXXXX" ...
>
> Greetings
> -gustaf
> --
> Univ.Prof. Dr.Gustaf Neumann
> Abteilung für Wirtschaftsinformatik
> WU-Wien, Augasse 2-6, 1090 Wien
> _______________________________________________
> Xotcl mailing list - Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl

From: Sheik Yussuff <sheik_at_carib-link.net>
Date: Mon, 17 Dec 2001 21:05:49 -0400

Is there a way to intercept all messages to objects
of a Class? I am not thinking of a combination of filters
and unknown or using a designated intercepting message.

Thanks for any help.

Regards,
sheik

From: Vasileios Anagnostopoulos <fithis2001_at_gmail.com>
Date: Wed, 04 Jan 2012 11:01:22 +0200

Hi,

I downloaded the nsf2.0b2 and tried to compile under latest msys/mingw
on WINDOWS XP SP3.

The only showstopper was on nsfAPI.h where I included nsfInt.h

and a correction

in line 227 of nsfInt.h where

#ifndef __WIN32__

should be replace with

#if (defined __WIN32__) && !( defined __GNUC__)

The resulting binary executed (after setting TCLLIBPATH) the samples on
the site.

One more question, will we see XotclIDE love with XoTCL 2?