Weblog Page

From: Stefan Sobernig <stefan.sobernig_at_wu.ac.at>
Date: Tue, 20 Jan 2015 09:15:30 +0100

Hi Victor,

> Any suggestions?

As always, there are several options. One way of nursing our custom
Object/Class is to use proper specializations of nx::Object/nx::Class:

package req nx

namespace eval ::vitick {

   Class create Object -superclass nx::Object

   Class create Class -superclass nx::Class {
     :method init {} {
       :configure -superclasses [namespace current]::Object
     }
   }

   namespace export Object Class
}

namespace import -force ::vitick::*

This is less invasive and you have the benefit of monitoring any
changes/additions to nx::Object/nx::Class for free.

Cheers,
Stefan

From: Damon Courtney <damon-xotcl_at_tclhome.com>
Date: Tue, 2 Nov 2004 13:22:53 -0600 (CST)

    Why does this not work?

package require XOTcl

::xotcl::Class Foo

Foo instproc bar {} {
    puts "SELF = [self]"
}

Foo foo
% Foo foo
::foo
% foo bar
invalid command name "self"


    But, if I "namespace import ::xotcl::*" and make the class with just
the Class command (not ::xotcl::Class), it works.

    Any ideas?

D

PS: Windows, Tcl 8.4.3, XOTcl 1.3.1

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Mon, 5 Feb 2001 23:44:14 +0200 (EET)

On Mon, 5 Feb 2001, Kristoffer Lawson wrote:

>
> Because the "whatever" method should be called along with the object
> creation -- and specifically before it takes place. Just as if I had

Correction: before the constructor is called.

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

From: Uwe Zdun <uwe.zdun_at_wu-wien.ac.at>
Date: Wed, 15 Sep 2004 12:02:02 +0200

Hi Bryan,

thanks for reporting this bug. I have fixed it and updated the snapshot at:

http://wi.wu-wien.ac.at/~uzdun/resources/xotcl-1.3.2.tar.gz

could you please check whether this one works as expected?

Uwe

Schofield, Bryan (GE Transportation) wrote:

>Hullo -
>
>I found a little bug with non-positional arguments & regular default arguments in version 1.3.1. Consider the following example:
>
> Object o
> o proc foo {{-a apple}} {{b banana}} {
> puts "FOO: [info locals]"
> puts "a: $a b: $b"
> }
>
>We have a method "foo" that has one optional argument, "b", and one option non-positional argument, "a". Now consider the possible ways to call this method:
> o foo
> o foo -a ack
> o foo bar
> o foo -a ack bar
>
>In the cases where we let "b" use it's default value of "banana", we will get the error:
> wrong # args: should be {{b banana}}
>
>In the cases where we specify "b", we will find that "b" is not valid variable in method scope. In fact, what is happening is that the variable "{b banana}" is being set. Should we try to use "$b", we will get the error:
> can't read "b": no such variable
>
>It would seem that ::xotcl::interpretNonPositionalArgs does not take in to account for default values on regular type arguments.
>
>Regards.
>-- bryan
>
>_______________________________________________
>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: Uwe Zdun <uwe.zdun_at_wu-wien.ac.at>
Date: Thu, 23 Sep 2004 14:24:02 +0200

Hi Ron,

I forward you email to our mailing list: Teemu Hukkanen
<mailto:tjhukkan_at_iki.fi> has provided the
debian package of XOTcl, but I don't know what the status of this
package is.
maybe someone else on the list knows?

Uwe


-------- Original Message --------
Subject: XOTcl and debian testing..
Date: Thu, 23 Sep 2004 07:19:12 -0400
From: Ron Fox <fox_at_nscl.msu.edu>
To: uwe.zdun_at_uni-essen.de



Contrary to the XOTcl web page, it appears that XOTcl has fallen off the
debian testing distribution (sarge) did you mean debian unstable?

Thanks,
Ron Fox
NSCL
Michigan State University
East Lansing, MI 48824-1321

"The knack of flying is learning how to throw yourself at the ground and
miss."

-- 
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: Zoran Vasiljevic <zoran_at_archiware.com>
Date: Thu, 21 Feb 2002 19:46:30 +0100

On Thursday 21 February 2002 18:17, Zoran Vasiljevic wrote:
>
> Class foo
> foo instproc init {args} {
> puts stderr "[self] comming"
> next
> }
> foo instproc destroy {args} {
> puts stderr "[self] leaving"
> next
> }
> foo instproc test {args} {
> puts "Hallo World"
> }
> proc dummy {args} {
> foo private fooVar ; # "private" might be a new constructor method
> $fooVar test
> return
> }
>
> When somebody calls "dummy" proc, a new "foo" object gets created
> (the "private" method" and automatically destroyed when proc returns.
> Can such thing be done with simple Tcl variable traces, hm?
>
>

Hm, what about this little baby:

proc ::xotcl::gc {name1 name2 op} {
    ::uplevel $name1 destroy
}

Class instproc private {varname args} {
  ::upvar $varname v
  ::set v $varname
  ::uplevel trace variable $varname u ::xotcl::gc
  ::eval [self] create $varname $args
}

Yields...

% Class foo
% foo private bar
% $bar
wrong # args: should be {bar message ?args...?}
% set bar
::bar
% unset bar
% ::bar
invalid command name "::bar"


Cheer's
Zoran

From: Murr, Florian <florian.murr_at_siemens.com>
Date: Wed, 2 Jan 2008 15:06:11 +0100

Dear XOTcl-guys!
The script below illustrates what I consider to be an XOTcl bug.
tested with:
   Tcl8.4.16 + XOTcl1.5.6
   Tcl8.5.0 + XOTcl1.5.6

regards
Florian

#
************************************************************************
******
puts "Tcl[set ::tcl_patchLevel]"
puts "XOTcl [package require XOTcl]" ;# XOTcl 1.5.6, 1.5.5
namespace import xotcl::*
#
########################################################################
######
Class X -slots {
    Attribute create q
}
#
************************************************************************
******
X instproc init {args} {
    next
    my trace add variable q {write unset} [list [self] trc]
}
#
************************************************************************
******
X instproc trc {args} { puts "[self] [info level 0]" }
#
************************************************************************
******
X instproc test1 {} {
    puts "[info level 0]"
    puts " trace info = [my trace info variable q]"
    my copy ::b
    puts " trace info = [my trace info variable q]"
    puts "'copy' kills the trace!"
}
#
************************************************************************
******
#
########################################################################
######
X create ::a -q hallo
::a test1

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Wed, 1 Dec 2004 00:47:14 +0100

> >
> > was this with gcc or cc? Is it possible to get a guest
> > account for the hpux machine?
>
> It didn't actually matter whether it was gcc or HP cc, both
> failed at the same spot. Unfortunately this machine is
> behind a firewall, so I couldn't give access regardless. I
> am still working on some other issues (just fixed the Windows
> doc building), so I haven't looked into this abnormality at
> this point. If you have an idea, I'll test it.

 hmm; it does not seem to get the right xotcl from
 from an uplevel command; try to change
    varFramePtr > top->currentFramePtr
 to
    varFramePtr != top->currentFramePtr
 in CallStackGetFrame().

> > > It's probably best to just take this patch directly and call it
> > > xotcl-1.3.4, unless you want to further clean up based on my other
> > > suggestions (like ALLOC stuff).
> >
> > We will do so,
>
> Actually, I have one more patch coming down the pipe - it
> only has more Makefile changes, but I will make it the same
> bulk-style patch as before. Actually, it changes makeDoc.xotcl
> as well to remove Windows-isms and be more error-sturdy.
>
> Should be done with that shortly.

jeff, many thanks for your efforts! integrating your full
patch with my new changes will be no problem

-gustaf

>
> Jeff

-- 
Univ.Prof. Dr.Gustaf Neumann
Abteilung für Wirtschaftsinformatik und Neue Medien
Wirtschaftsuniversität Wien, Augasse 2-6, 1090 Wien

From: Jeff Hobbs <jeffh_at_ActiveState.com>
Date: Sat, 7 May 2005 15:33:48 -0700

Lehmann, Eckhard wrote:
> > If you do not want to develop own XOTcl widget set there
> > are no reasen to rewrite BWidget to XOTcl. XOTcl code can
> > use all tcl packages (Even ITcl).
>
> It would be better to have a special XOTcl widget set, agreed
> (especially interresting for that is, that it could look like Gtk on
> Linux/GNOME, look like windows on Windows and look like Mac on Man,
> which isn't always true for the current Tk). But that's

That's not really the case with Tk. You can certainly
achieve native look and feel, although it usually does
require some platform specific coding (which can all be
wrapped in abstractions). See also modern widget sets
like Tile (which BWidgets can make use of).

> Combine the maturity and usability of Tk and Bwidget with the (very
> interresting) features of XOTcl, so that people can derive from and
> mixin XOBwidget classes and quickly get their jobs done with
> XOTcl/XOBwidget - and there will be many more users of XOTcl, XOTclIDE
> and Tcl itself (especially "old style Tcl'ers" are more
> likely to switch
> to XOTcl, I think). After or parallel to that it is still possible to
> start developing a special widget set for XOTcl.

I would in general agree. XOTcl could provide the basis
for a real megawidget solution, where others have had to
be band-aids or partial solutions. This would likely
require a few enhancements in Tk or at the C level still
(to really solve the megawidget problem).

  Jeff Hobbs, The Tcl Guy
  http://www.ActiveState.com/, a division of Sophos

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Sat, 15 Jul 2006 18:19:19 +0300

On 15 Jul 2006, at 18:02, Gustaf Neumann wrote:

>>
>> But would it be useful to have this kind of functionality in the
>> core too?
>>
> well, as long we can do such kind of things with a few lines of
> code in xotcl
> i see not need for hacking this into C. xotcl is sometimes
> criticised for having
> already a too large set of predefined methods...

Well yeah, I guess one needs to be careful with that. Certainly there
are areas where simplicity is a virtue, and perhaps there are some
overlapping areas, but I just thought of it as a pretty natural
extension of the current "check" functionality. To me it would feel
more natural for a "cover everything" check than for the current per-
object style. Usually one works on a development version where all
debug options and checks are turned on — you want to capture anything
as soon as it happens. Then you turn them off for a delivery version
(if for no other reason than to enhance performance). As with most
functionality in XOTcl there is the 'inst' methods, which are often
given to classes, and then the direct ones for objects. Thus it would
seem logical to have that for asserts as well.

Neither of our solutions are really the kind of thing basic coders
would come up with.

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