Weblog Page

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Sat, 15 Jul 2006 17:46:25 +0300

On 15 Jul 2006, at 17:21, Gustaf Neumann wrote:

> Kristoffer Lawson schrieb:
>>
>> Except that this only works 'afterwards'. So it doesn't actually
>> help, as I'd still have to apply it after I create objects etc.
> i thought you want to turn on checking for all objects (which means
> existing objects).
>> when really I just want to turn it on at the top of the
>> application and leave it at that.
>>
>> For the moment I managed this with a filter that is called every
>> time an object is initialised, but I would imagine this the kind
>> of thing that should be handled elegantly by the XOTcl core?
> Why a filter?

Hm, well, it was the first thing that came to mind :-) And easy to do
anyway.

> in order to turn an checking for objects as you create these, you
> might
> use something like the following:
>
> Object instmixin [Class new -instproc init args {my check all;
> next}]

Yeah, giving that some thought, that should work too.

But would it be useful to have this kind of functionality in the core
too?

Something like:

Class instcheck all

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

From: Gustaf Neumann <neumann_at_wu.ac.at>
Date: Mon, 02 Nov 2009 09:52:07 +0100

Dear Mykhaylo,

The "slots" method changes the namespace to
make it convenient for the user to write
"Attribute name" and not
"Attribute test1::Test::slot::name".

The following snipped shows a simple solution,
but this is not nice either. With Tcl 8.5,
one could use instead of the "namespace import ..."
"namespace path ::xotcl" before "Attribute...".

namespace eval ::test1 {
    namespace import ::xotcl::*
    Class Test -slots {
      namespace import ::xotcl::*
      Attribute name
    }
    namespace export Test
}

This solution works, but is not nice either.
If you include the "contains" method below
in your script, your original example will
work as expected. I am planning to use this
definition in the 1.6.5 release.

best regards
-gustaf neumann


==============================
::xotcl::Object instproc contains {
  {-withnew:boolean true}
  -object
  {-class ::xotcl::Object}
  cmds} {
    if {![info exists object]} {set object [::xotcl::self]}
    if {![::xotcl::my isobject $object]} {
      $class create $object
      $object requireNamespace
      namespace eval $object {namespace import ::xotcl::*}
    }
    if {$withnew} {
      set m [::xotcl::ScopedNew new \
                 -inobject $object -withclass $class -volatile]
      ::xotcl::Class instmixin add $m end
      namespace eval $object $cmds
      ::xotcl::Class instmixin delete $m
    } else {
      namespace eval $object $cmds
    }
  }
==============================

Mykhaylo Sorochan schrieb:
> Hello,
>
> Why in the following code launched from tclsh I get the error:
> invalid command name "Attribute" during '::test1::Test slots'
>
> ######
> package provide test1 0.1
> package require XOTcl
>
> namespace eval ::test1 {
> namespace import ::xotcl::*
> Class Test -slots {
> Attribute name
> }
> namespace export Test
> }
> namespace import ::test1::*
> ######
>
> XOTcl 1.6.4, works ok from xotclsh and when 'namespace import ::xotcl::*'
> comes right after 'package require XOTcl' and not within test1 namespace.
>
> Thanks.
>
>

From: Victor Mayevski <vitick_at_gmail.com>
Date: Mon, 11 Apr 2011 12:59:20 -0700

I am beginning to learn and use test driven development in my
projects. I've noticed that NX does not use the standard "tcltest"
package in Tcl but instead provides it's own "nx::test". Is there a
specific reason for that?

Thanks,

Victor

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Fri, 18 Jul 2003 18:41:46 +0300 (EEST)

I like the way XOTcl lacks the concept of private and public methods and I
also thought that it is unnecessary for fields. I also very much like
multiple inheritance as, while I don't use it very often, sometimes it is
just quite the most natural way to go about business.

However isn't there actually a problem here, especially in relation to
fields and MI? I don't consider fields to be equally a part of the
interface as I do methods so there is a grave risk that, unknowingly,
field names from different paths could conflict thus leading to very
unexpected behaviour of the kind that is also difficult to track and
debug.

While commonly I accept the "allow the coder to do anything" idea, which
is prominent in Tcl this really would happen for no fault of the
developer. They are combining classes in a way which is natural and
generally do not expect side-effects to occur as a result.

To a lesser extent one could consider this to be a problem with methods
too. Methods I do consider to be part of the interface and are more easier
to track -- thus the mixing behaviour is easier to understand. Still,
there is the possibility that a method of a class would like to call
another method (a helper method, perhaps) and be sure it's not getting
muddled by another class.

I do see the latter as much less of a problem but the first could be a
real issue. It's probably just pure luck that I haven't had to debug it. I
see two solutions to the problem:

1) A way to specify that you wish to modify or use a field and guarantee
that it is the one from "your own" class. Possibly the same for a method.

2) Define that instance variables cannot be used from outside the class.
That they are always "private" and thus cannot conflict. This I sort of do
anyway. I never access fields directly from outside the class.

Maybe a combination of the two. In Java, or any language with only single
inheritance, this is not an issue (and thus private-protected-public is
mostly unnecessary).

Opinions? (wondering if I'm still on the list as I haven't seen any emails
from there in ages)

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

From: Krzysztof Frukacz <frukacz.krzysztof_at_gmail.com>
Date: Mon, 10 Jan 2011 16:15:50 +0100

Hello,

I attach a few files that will demonstrate the problem. Just run tester.tcl
On my PC the effect is that I get an error message:

::tmp1: unable to dispatch method 'testA'
     while executing
"tmp1 testA"

The problem is that tmp1 is of class B and should be able to call testA,
which is defined its superclass - A.

I have found that the problem is source command, which includes file
a.xotcl several times in several different files. I don't understand
however why the message from interpreter says that it cannot find proc
testA - this doesn't make sense.

Is there a "nice" method to avoid this? Like in C we use #define and #ifndef

-- 
Krzysztof Frukacz

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Tue, 27 Mar 2001 19:44:46 +0300 (EEST)

On Tue, 27 Mar 2001, Catherine Letondal wrote:

> Is there a debian package for the 0.84 release of XOtcl?
> Or even a 0.83?

Yes, to both (I use them). I forwarded your mail to Teemu Hukkanen,
who has made a debian package, which should hopefully end up in the
actual Debian distribution at some point...

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

From: Stefan Sobernig <stefan.sobernig_at_wu.ac.at>
Date: Fri, 27 Jul 2012 21:50:11 +0200

Hey Jon!

To clarify:

http://next-scripting.org/xowiki/getstart states that

> Note: As for the source distribution of the current public beta release, our build environment has not been tested with any build environment targeting Windows (MSYS/MinGW, Visual Express). This is planned for the first stable release.

This still holds for the b3 release.

In the git HEAD version, however, we included and maintain the necessary
fixes to build under MinGW/MSYS (both the default 32-bit and any of the
64-bit toolchain).
We have not tested against any Visual C compiler, nor under cygwin. On
top, we have not tested building against the ActiveState distribution of
Tcl under Windows. We always compiled Tcl on our own.

Right now, I am remote to my windows box but I will compile a note to
publish on next-scripting.org, essentially outlining the following steps
under MinGW/MSYS:

Step 1: Install MinGW/MSYS default 32-bit toolchain

http://www.mingw.org/wiki/Getting_Started
https://sourceforge.net/projects/mingw/files/Installer/mingw-get-inst/

Step 2:
Fetch the tcl source distribution

http://www.tcl.tk/software/tcltk/download.html (8.5.11)

... or from the fossil SCM:
http://core.tcl.tk/tcl/

Schritt 3:

Fetch the git HEAD of nsf/nx using:
http://msysgit.github.com/

after having fired up the GIT Bash:
follow the steps described in: http://next-scripting.org/xowiki/git

Step 4: Install Tcl

a) Open the MinGW Shell

b) cd <tcl src folder>/win
./configure
make
make install

Step 5: Install NSF/NX
cd <NSF git directory>
./configure
make
make install

Step 6: Run the NX shell
nxsh myScript.tcl
tclsh myScript.tcl

Make sure that you turn off your antivir protection (especially
filesystem guards) for the time of compilation as most scanners (e.g.,
AntiVir) have been reported blocking the on-the-fly compilation into
object code during the various configure tests. This is a must and might
otherwise present a bunch of unexpected autoconf/Make voodoo behavior to
you.

As soon as I return to my office at the beginning of next week, I can
checkout on the compilation procedure again.

> I was using Activestate 8.5

As I said, we have not tested against ActiveState installations (as an
alternative to step 2 and 4 above). But if the git HEAD version builds
as outlined above, it should do so under ActiveState. However, some
tweaks might be necessary to get the various path settings right.

> installed the compile tools, and ran configure, but it broke because I
> apparently don't have a /usr/local/include/tcl8.5/tools/genStub.tcl ...

 From all I know, ActiveTcl does not provide a source installation
including private headers, genStub.tcl & friends. But you got your
answer already in
https://groups.google.com/forum/?fromgroups#!topic/comp.lang.tcl/APlqIM_kyKY.

//stefan

From: Zoran Vasiljevic <zv_at_archiware.com>
Date: Tue, 22 Nov 2005 11:17:12 +0100

Hi!

What I need to do sometimes is to be able to cache
classes because their creation (in our case) might
be a costly operation.

For example:

    Class HeavyClass
    set hc [HeavyClass new]
    $hc whatevermethod

can be quite time consuming. What I'd like to do
is to "cache" "things" created by "new" or even
for:

   HeavyClass hc
   hc whatevermethod

What would be the best way to achieve this caching?

Thanks for help.
Zoran

From: Schofield, Bryan \(GE Transportation\) <"Schofield,>
Date: Tue, 14 Sep 2004 13:08:32 -0400

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

From: Stefan Sobernig <stefan.sobernig_at_wu.ac.at>
Date: Tue, 18 Jan 2011 16:20:28 +0100

Krzysztof;

> I need an example of implementation of a getter.
> I have an attribute in a class which now needs a customized getter.
> Class A -slots {
> Attribute attr -proc get {domain var} {
> #how to get attr value here? if I do [my attr] I get recursive call.
> $attr says that there is no such variable
> }
> }

Remember: in get(), you are in the object scope of the managing object
(the attribute slot) and *not* the managed object which is the actuall
value store, e.g.:
Class A -slots {
   Attribute attr -proc get {domain var} {
     #
     # NB: Here, you are in the scope of the managing object, the value
     # needs to be retrieved from the managed one, i.e. the domain
     # object!
     #
     # $domain instvar $var
     # if {[info exists $var]} {
     # return [incr $var]
     # }
     set value [next]
     return [incr value]
   } -valuecmd {
     #
     # whenenever /domain/.attr is accessed (read), this script is
     # evaluated and the object variable is (re-) set to its return
     # value, i.e.: 0
     #
     set return 0; # do not use "return"!
   }
}

A create a -attr 1
a attr; # yields '1', though one might expect '2'; interaction of
valuecmd + get()
a attr 10
a set attr; # yields '0' --> valuecmd only

Depending on what kind of "refinement" you want to achieve, you may
either replace the original (provided) get() or you go for a method
combination by using [next].

> Another question: should I use -proc get or -proc valuecmd? valuecmd
> does seems to be not called at all.

well, hard to tell as I don't know exactly what you are after. But, my
uneducated guess is that get() is your friend.

valuecmd() & co. are hook methods which are invoked upon in certain
phases of object state access or mutation. while at first sight they
might appear idempotent, they are not:

1. get() is invoked only when you access an object's state through the
attribute interface, e.g.: [a attr]. valuecmd is fired always, whenever
trying to access the object variable, whether through [a attr] or [a set
attr].

2. valuecmd, in contrast to get(), is most importantly a *mutator*, it
will *always* perform a state change, i.e. the result of the valuecmd
script becomes the value of the object variable. well, frankly, you
could write a refining get() in a way that is changes the state, but
this is up to you ;)

while there are more subtle differences (e.g., valuecmd is an [eval]'ed
script, not a proc; the two do interact, as shown above; valuecmd does
not now about its surrounding context, i.e. the domain object, unless
being tricked into), this should get you started, i hope ...

//stefan