Weblog Page

From: Uwe Zdun <uwe.zdun_at_uni-essen.de>
Date: Tue, 30 Jan 2001 10:21:38 +0100

---------- Fwd ----------
Subject: [tcl_announce] ANNOUNCE: 2nd European Tcl/Tk User Meeting
Date: 23 Jan 2001 18:49:44 -0000
From: Carsten Zerbst <zerbst_at_tu-harburg.de>
To: tcl_announce_at_egroups.com


Second European Tcl/Tk User Meeting

                   Hamburg-Harburg, 7th and 8th June 2001


Announce:

I'm please to announce the First European Tcl/Tk User Meeting, held in
Hamburg on Thursday and Friday, 7 -- 8 June 2001.

The First European Tcl/Tk User Meeting should provide a plattform to
* bring together Tcl/Tk researchers and practitioners
* publish and present current work involving Tcl/Tk
* learn about the latest developments in Tcl/Tk
* plan for future Tcl/Tk related developments

This is the first announcement, for more information look at the meetings
homepage http://www.tu-harburg.de/skf/tcltk.

If you like to contribute, please read the Call for Papers

For more infos on the Tcl/Tk user meeting look at
http://www.tu-harburg.de/skf/tcltk

Contact Carsten Zerbst
        Technische Universit=E4t Hamburg-Harburg
        AB 3-06 mailto:zerbst_at_tu-harburg.de
        21073 Hamburg phon: +49 40 428 32 3146
        Germany fax: +49 40 428 32 3335

Hope to see you in Hamburg, Carsten Zerbst

[[Send Tcl/Tk announcements to tcl-announce_at_mitchell.org
  Send administrivia to tcl-announce-request_at_mitchell.org
  Announcements archived at http://www.egroups.com/list/tcl_announce/
  The primary Tcl/Tk archive is ftp://ftp.neosoft.com/pub/tcl/ ]]

-------------------------------------------------------

-- 
Uwe Zdun
Specification of Software Systems, University of Essen
Phone: +49 201 81 00 332, Fax: +49 201 81 00 398
zdun_at_xotcl.org, uwe.zdun_at_uni-essen.de

From: Victor Mayevski <vitick_at_gmail.com>
Date: Sat, 27 Nov 2010 20:23:57 -0800

Everything is now compiling and installing nicely, but I get another
error when using NX or XOTcl 2.0:

package req nx
nx::Class create C
C destroy
      can't read "__default_superclass": no such variable

From: Koen Danckaert <koen_at_retarget.com>
Date: Mon, 20 Mar 2006 11:10:28 +0100

> Snit has a "myvar" method that returns the fully qualified name of a
> snit member variable. Perhaps something similiar (a method that
> returned a "reference" to an instance variable) would be useful in XOTcl?

I use the following two global procs for that:

    proc myproc {args} {linsert $args 0 [uplevel 1 self]}
    proc myvar {var} {return [uplevel 1 self]::$var}

The procs are global (not instprocs on "Object") because otherwise I would have to write "my myvar" or "my myproc". Now I can simply use them in the following way inside xotcl (inst)procs:

    button $x -command [myproc show 1 2 3]
    ...
    trace add variable [myvar status] write [myproc statusevent]
    ...
    vwait [myvar done]


(Note: in fact the "uplevel" in the definition of myproc/myvar is not even necessary. It seems that [self] always refers to the last Xotcl object on the callstack.)

Koen

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Thu, 08 May 2008 09:27:16 +0200

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

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Sat, 25 Jun 2005 15:17:07 +0300

On 25 Jun 2005, at 12:59, Mads Linden wrote:

> Thanks
>
> I guess I just have to get my head around things like that, a bit
> dangerous
> I feel to call methods before contruct.
>
> It would be ok if it was "procs" that worked like that insode the
> classs,
> but not instprocs :(

Well, you can ask the developers for the reason. I remember stumbling
across it myself at one point. However, I also remember there was a
fairly sensible reason for that. -dash calling is meant for
initialisation so in a sense you can think of it as belonging to the
init. It is, after all, the method used for initialising parameters.

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

From: Will Duquette <will_at_wjduquette.com>
Date: Mon, 26 Sep 2005 21:20:31 -0700

On Sep 26, 2005, at 6:04 PM, Neil Madden wrote:

> Will Duquette wrote:
>
>> The point of [define] is simply that we want to be able to
>> create objects which have a limited set of subcommands. Note
>> that there's a distinct difference between writing an OO-API
>> using a particular OO-framework for other users of that
>> framework, and writing an object-style API for general users,
>> many of whom might not care about the OO-framework at all.
>> In the first case, you want to include all of the OO-framework's
>> bells and whistles, because you expect your users to want to
>> take advantage of them. In the latter case, you want to keep
>> the API simple, clean, and easily documented.
>>
>
> That's certainly a good goal.
>
>
>> [define] lets us do both. With [define] "instproc" and its
>> siblings aren't subcommands of our objects--but at the same time,
>> "instproc" and its siblings are available to every user who
>> cares about them.
>>
>
> OK. The essential thing being done here then is to break down the
> grab-bag of methods defined in Class and Object into a bunch of
> different interfaces, so that clients of an object don't have to
> worry about a bunch of extra "proc" and "filter" etc methods that
> have nothing to do with their problem domain. I can sympathise
> with that. However, I'm not sure [define] is the right solution,
> as it just creates another bag of methods elsewhere (somewhat like
> [info] has become). We could simply change the methods to be class-
> methods of [class] and [object] (i.e. procs that expect an explicit
> self argument, rather than instance-methods). That way by default
> objects don't get lots of public methods that aren't needed by
> clients, but you can still do, e.g.:

Actually, I don't mind [info]. Yes, it's a bag of methods; but it's
nice to have a rug to sweep things under, and it's even nicer to
know *which* rug without having to think too much about it.

My only argument against this notion of yours and in favor of [define]
involves implementing oo::snit on top of oo::. snit::types have
typemethods, and just as I want a clean interface for my objects, I'd
like a clean interface for my types as well.

If we abolished [define] and defined its methods as you describe,
then oo::snit types would no longer have a clean interface. I could
work around that by using an oo::object as a proxy for an underlying
oo::class; I'd give the oo::object a create method that forwarded to
the class, and then make the oo::object forward any user-defined
typemethods as well.

The difficulty here is that an oo::snit::type wouldn't be an oo::class,
then. And that's a problem, because Snit's two big problems are
speed and lack of inheritance. If I'm going to go to the trouble
of reimplementing Snit on top of oo:: I'd like to get both.

Other than that, I could go with your scheme. I kind of like
[define], though. But then, naturally, I would. :-)

Will

>
> class method myclass someproc {args} { ... }
> object method myobj ...
> object mixin myobj ...
>
> This also somewhat reduces the need for self.method/method (or
> instproc/proc) distinction. Likewise, you could also use it for
> the script-style of define:
>
> class define myclass {
> method foo ...
> method bar ...
> }
>
> where these are interpreted as [class method myclass ...] and not
> [object method myclass ...].
>
> It sort of clashes with previous XOTcl usage, where [class
> instproc] means define an instproc on the object "class", but if we
> change the name to "method" anyway then this is less of an issue.
> You could even leave access to the methods using the form:
>
> myclass class method someproc ...
> myobj object method ...
>
> which leaves only one top-level method in objects (two in classes).
> That seems a bit more OO-y, but I don't know if it really adds much.
>
> -- Neil
>

-------------------------------------------------------------
        will -at- wjduquette.com | Catch our weblog,
http://foothills.wjduquette.com | The View from the Foothills

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Fri, 24 Jan 2003 16:54:15 +0100

On Friday 24 January 2003 15:44, Kristoffer Lawson wrote:
> On Fri, 24 Jan 2003, Gustaf Neumann wrote:
> > we could provide an option -bind <varname> to the new instproc to allow
> > the user to specify a local or a per-object or global variable name, but
> > this does not provide reference counting at all. i have started some
> > time ago
>
> Oh, I meant to say that an option to [new] is not necessarily the best.
> Often (at least in my case) it is a method of an object which creates
> an instance and returns it, like:
>
> set msg [$cmdReader getNewMessage]
>
> So at the level where I want the automisation I don't directly call new.
> Naturally this could be changed to accommodate the use of new, but then
> my interface wouldn't be as cleanly split up.

 i don't get your point: getNewMessage has to create the Object,
 so it can use certainly new (with all variants). is your argument:
 the caller of newmessage should decide, whether the created
 object should be dynamically reclaimed or not?

 anyhow, it is not hard to do it one or the other way....

 -gustaf

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

From: Zoran Vasiljevic <zoran_at_archiware.com>
Date: Sun, 12 Aug 2001 17:37:42 +0200

On Saturday 11 August 2001 23:07, Kristoffer Lawson wrote:

> > AFAIK, the "ob info procs|args|body" is ment to be used
> > with per-object resources (procs), like for example:
>
> Yes, that what it appears to do, but as such it's limited. I would like
> a uniform way of asking information about inherited procs and per-instance
> procs. In fact I might even say that to separate those on this level is
> confusing the object model.
>

I do understand now what you mean.
You'd like a general introspection
interface, w/o needing to know wether
you're dealing with a per-instance
proc or an instproc. Seems logical.

So you'd say:

ob info body foo
ob info body bar

or

ob info args foo
ob info args bar

without extra knowledge about what are
"foo" and "bar" actually.
The "foo" may be an instproc whereas
the "bar" may be a per-instance proc
or vice versa. Correct?

I think such behaviour can be implemented
with some XOTcl wrappers using existing
introspection capabilities of the system.
I might be wrong of course. Maybe Uwe and/or
Gustaf can say something about it?

I would, for example, override the "info"
method with some custom code which tries
the per-instance proc first and if it does
not find any, goes to the instproc.
This should't be difficult to implement.

Cheers
Zoran

From: Gustaf Neumann <neumann_at_wu.ac.at>
Date: Tue, 31 Jul 2012 10:07:20 +0200

On 30.07.12 21:28, Rene Zaumseil wrote:
> So try to remove the dir and start again. You should have a copy
> of the zlib1.2.3/* files insisde the build*/<package> dir.
removing the directory and retrying does not help. As said
before, the
contents are under buildWindowsNT/zlib1.2.3-static, but
under an additional
subdir "zlib".

> The line in kbs.tcl Package zlib1.2.3-static, Configure script is:
> eval file copy [glob [Get srcdir]/*] .
not sure, what the supposed current dir and srcdir should
look like.
A side note: since the script required tcl8.5, you should
consider to use

    file copy {*}[glob [Get srcdir]/*] .

instead of the eval.

Anyhow, the plain built
1) obtaining tcl, make, make install
2) obtaining nsf, make make install
is working nicely (as stefan wrote).

-gn

From: Gustaf Neumann <neumann_at_wu.ac.at>
Date: Sun, 29 Aug 2010 13:59:24 +0200

  Am 28.08.10 05:11, schrieb Victor Mayevski:
> Dear Gustaf,
>
> Do you have any instruction on how to pull the latest XOTcl 2.0 code using git. Recently, git started to fail. After I deleted everything and started from scratch, git is pulling XOTcl 1.6 instead of XOTcl 2.0
> I am using the following command:
>
> git clone git://alice.wu-wien.ac.at/xotcl 2.0.0-develop
>
>
by using the command above, you will obtain a checkout of
the head branch of xotcl, which is 1.6 (but you placed it
into a directory named 2.0.0-develop).

In order to build the 2.0 version, you have to use the
2.0 branch. In detail, use:

    git clone git://alice.wu-wien.ac.at/xotcl 2.0.0-develop
    cd 2.0.0-develop
    git branch 2.0.0-develop origin/2.0.0-develop
    git checkout 2.0.0-develop

best regrads
-gustaf neumann

-- 
Univ.Prof. Dr. Gustaf Neumann
Institute of Information Systems and New Media
WU Vienna
Augasse 2-6, A-1090 Vienna, AUSTRIA