Weblog Page

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Wed, 04 Jan 2012 10:38:45 +0100

Dear Vasileios,

many thanks for the feedback. This was already fixed in the
master branch in git (mid december).

Concerning XOTclIDE: not sure, if Artur is listening here. I
conclude from your mail that it does not work out of the box.
I have not looked at the XOTclIDE code, just a guess: From a
low level perspective the primary difference in XOTcl 2 is
that Slots are now NX objects; I made similar adaptions in
OpenACS, it was no big deal there... If Artur is listening
he will know better the demands...

-gustaf neumann

On 04.01.12 10:01, Vasileios Anagnostopoulos wrote:
> 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?
> _______________________________________________
> Xotcl mailing list
> Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Fri, 24 Jan 2003 22:13:34 +0100

> I haven't really thought of volatile much, the
> following doesn't seem "right" somehow:
>
> Client instproc read {} {
> my instvar reader
> volatile msg [$reader getMessage]
> }

funny enough, i was rather thinking on something like:
===================
Object instproc objectref varname {
  uplevel [list trace variable $varname wu [list [self] objectref_cb]]
}
Object instproc objectref_cb {n1 n2 mode} {
  upvar $n1 name
  my instvar [list __last($n1,$n2) old]
  if {[info exists old]} {
    if {[my isobject $old]} { $old destroy }
  }
  if {[info exists name] && [string equal $mode "w"]} {
    set old $name
  }
}
=====================
where one can use it like:
=====================
Client instproc read {} {
  my instvar reader
  my objectref msg
  set msg [$reader getMessage]
}
====================
or combined to what the tie did before... this leads to some variable-declarations,
where we could also define parameters as references....
Class C -parameter {{a ""} {b -default "....."} {c -objectref} ...}

> What if you could specify after creation what happens to the object?
> Like:
>
> Client instproc read {} {
> my instvar reader
> set msg [$reader getMessage]
> $msg memmanagement refcount
> }
>
> I mean, in addition to the "-refcount" option with [new]. That way methods
> that should not know about the dynamics (like [getMessage]) can use normal
> [new] and let the caller decide what it wants to do with the object.

 this is a good idea, except in cases, where the characteristics have
 to be known at creation time. i will think about it....

-gustaf

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

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Sun, 16 Jul 2006 13:53:42 +0200

Kristoffer Lawson schrieb:

> 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).
no question, useful scenario. allthough, the notion of "everything"
might be different in various cases. sometimes, really all objects are
the scope of the checking, sometimes "user code", file scope, namespace
scope, class scope or object scope. the lowest common denominator is the
object. this looks to me as a good thing for a library function (package).
> 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.
i am not so convinced about the "inst" variant. "inst" means, provide
some resources for the instances of a class, usually the instances can
decide to override/extend it. what happens, if the inst rule turns
checking on/off but the instance turns if off/on, or sets different
values, etc. this is different to what we have discussed so far, and not
terribly important imho. A package makes more sense, which makes it easy
to extend/modify the behavior.
>
> Neither of our solutions are really the kind of thing basic coders
> would come up with.
providing a few general idioms makes the developer more productive on
the long range than one more built-in.

cheers
-gustaf
>
> / http://www.fishpool.com/~setok/
>

From: Zoran Vasiljevic <zv_at_archiware.com>
Date: Fri, 30 Sep 2005 12:47:03 +0200

Hi!

Seems like this one is broken :-(
Watch:

lexxsrv:nscp 1> DbsTree d
::d
lexxsrv:nscp 2> d mixin XXXTree
expected a class as mixin but got XXXTree
lexxsrv:nscp 3> d mixin XXXTree
lexxsrv:nscp 3>

The first time it broke, the second time it did.
All of the classes are loaded on demand by the
__unknown mechanism.

If I hoever do this:

lexxsrv:nscp 1> XXXTree
::XXXTree
lexxsrv:nscp 2> DbsTree d
::d
lexxsrv:nscp 3> d mixin XXXTree

all is fine.

I do not know when this crept in since we are still
using the 1.1 for our production server. I'm now
starting to move all to 1.3 and, peng!

Please help!
Zoran

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Tue, 5 Jun 2001 21:44:15 +0200

 Dear XOTcl community,

 If you have interest to get access to the current development
 version of XOTcl (which is exactly 0.85-p1) you can use bitkeeper to
 get the source tree. Bitkeeper (http://www.bitkeeper.com) is
 an open source version control system.

 Check for details on http://media.wu-wien.ac.at/download.html

 best regards
 -gustaf

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Mon, 13 Aug 2001 16:20:09 +0200

On Monday 13 August 2001 15:52, you wrote:
> On Mon, 13 Aug 2001, Gustaf Neumann wrote:
> > The right way to query instprocs is via "info instargs" and
> > "info instbody" rather than "info args" and "info body" or
> > the tcl counterparts...
>
> Well, as mentioned, this does not really work in my case. I do not know
> beforehand whether a proc is an instproc or a per-object proc. I am using
> meta-programming and using methods as templates for other dynamically
> built methods. When the API gets the name of the method, it asks for
> the body and arguments, so it can create another method with that
> information. When looking up that information it now assumes that the
> given method name is an instproc and asks the class -- but this is not
> a general solution.
>
> As pointed out by Artur, there are ways to do this, but they're pretty
> complex, so I am looking for a straightforward way of asking information
> about a method, without caring about whether it's inherited or not.

 sure. the point is, that we need both: an explicit interface for getting
 the details right and for distinguising as far as neccessary, and
 a high level interface, that hides part of this details for a user who does
 not care about these. for the latter case, an "info procs" or
 "info instprocs" is not the right way, since the names are not necessarily
 disjunct. a new thing called "info methods" that returns a list of
 method-objects (see last mail) could help here returning all the callable
 methods (which are procs, instprocs, mixins, filters).

 what is it, that would fit your needs best? what are you doing exactly?

 
 -gustaf

From: Kurt Stoll <kstoll_at_echelon.com>
Date: Tue, 12 Jun 2012 17:33:24 -0700

(I realize that this is probably not an XOTcl issue, but a ActiveState Komodo issue; however, I have not been able to find an answer through ActiveState, so I may have better luck here.)

Running on a Mac, using OSX V10.7.4.

I cannot get XOTcl to load properly with ActiveState Komodo V7. I do not have any problem with V6 of that tool. Also, loading XOTcl into tclsh when invoked from the Terminal works. All three environments (Komodo V7, V6, and Terminal / tclsh) are using the same version of Tcl (8.5) and the same version of XOTcl (1.6.6 - I know, down rev by one release). All three versions point to the same library file: /System/Library/Tcl/8.5/xotcl1.6.6/libxotcl1.6.6.dylib.

Yet, when I attempt to load XOTcl (using package require XOTcl) from Komodo V7, it gets stuck in an infinite loop:


Error in predefined code
         too many nested evaluations (infinite loop?)
    while executing
"DbgNub_infoCmd exists DbgNub(returnState)"
    (procedure "catch" line 11)
    invoked from within
"catch {set savedErrorInfo $::errorInfo}"
    (procedure "::unknown" line 18)
    invoked from within
...
"proc ::xotcl::myproc {args} {linsert $args 0 [::xotcl::self]}"
too many nested evaluations (infinite loop?)


I don't believe I have changed any relevant settings.

Any clues?

Thanks,
Kurt Stoll

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Tue, 14 Sep 2004 16:29:47 +0200

On Thursday 02 September 2004 20:27, Artur Trzewik wrote:
> Hi!
>
> XOTclIDE does not run with XOTclI 1.3.1 because
> of uncompatibility of the namespace handling.
> Thank to Michael Heca for noting it.

 The described problems all stem from cases where,
 objects are created in implicit namespaces. If the
 namespace is specified, they will disappear. While
 i see the example from Michael as a bug, i do not
 regard the examples below as such.

 between 1.2 and 1.3, there was a big - but i think important -
 change in the handling of namespaces in xotcl. while most of
 the programs are not affected (no change in my codebase of
 more than 25000 lines of xotcl code), some programs are.
 I still believe that the 1.3 behavior is much better, since
 it allows to use xotcl in packages without
  - without having the need to import xotcl globally,
  - or to write all xotcl commands with the xotcl
    prefix (such as ::xotcl::self) in the package
    implementation, as it was requited in 1.2 and earlier.
 Furthermore, the new version is more compliant to the
 tcl behavior.

 Look at the following example. Assume, you want to
 define a component test, that is defined in the "::test"
 namespace. Later, you want to use the component test
 and import from the test namespace, whatever you
 need. Whether or not the component test uses other
 components (such as xotcl) should not affect you.

 In other words, a programmer should not be required
 to import xotcl globally, only because he is using
 a component that uses xotcl.

 with 1.3, one can define the component

==================================
namespace eval test {
  package require XOTcl
  namespace import ::xotcl::*
  Class C
  C set i 0
  C proc new {} {
    [self] create c[my incr i]
    foreach i [[self] info instances] {puts -nonewline "$i "}
    puts ""
  }
  C instproc m {} {
    puts "[self]->[self proc] NS=[namespace current]"
  }
  namespace export C
}
==================================

and use it later with

==================================
namespace import test::*
C new
C new
C new
test::c1 m
==================================
 
differently to 1.2, we have now:
  - no globally imported xotcl commands
  - we can write xotcl code in a human friendly way (not prefixes)
  - the default namespace of the method m is "::test" (like in a tcl proc)
  - this default namespace is used when procs (or objects) are created

 therefore, the objects created by new are now in the namespace,
 in which the creating command was defined, namely "test".

 In the example below, subobjects are used. Since subobjects
 create their namespaces, the objects are created (and resolved)
 in these namespaces, similar as explained above.

 If one wants explitly a different namespace, it should be specified
 explicitely. Michael's example

   NS::Main proc m2 {} { namespace eval :: Object crash}

 can be simpler defined as

   NS::Main proc m2 {} { Object ::crash}

 which will work. Nevertheless, as i wrote above,
 the example above should not crash and must be fixed.

 If you have arguments against this change, or different
 proposals to get a similar behavior, please let me know.

 It should not be a big problem to make XOTclIDE work
 with the old and new behavior. as always, we are willing
 to help.....

 all the best

 -gustaf

>
> I have played a little with xotcl and discovered following
> behavior incompatibility that make problems by XOTclIDE.
>
> Examples:
>
> package require XOTcl
> namespace import xotcl::*
>
> Object O
> Class O::B
> O::B instproc test {} {
> Class A
> }
> O::B create o
> o test
>
> # XOTcl 1.2 returns ::A
> # XOTcl 1.3 returns ::O::A
>
> using Class ::A solves the problem
>
> Another one should not occours by any XOTcl programm
> but by XOTclIDE this happened
>
> Object O
> Class O::A
> O::A proc test {} {
> A self
> }
> O::A create A
> O::A test
>
> # XOTcl 1.2 returns ::A
> # XOTcl 1.3 returns ::O::A
> # using ::A solves the problem
>
> So probably even with XOTcl 1.3.2 XOTclIDE will not work
> out of the box and need some changes.
> So all XOTclIDE user be patience and wait for new version of XOTclIDE
> that supports XOTcl 1.3. I will need also some time to support
> new XOTcl functionality.
>
> Artur Trzewik
>
> _______________________________________________
> Xotcl mailing list - Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl

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

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Fri, 06 Jan 2006 13:37:18 +0100

Hi Koen,

the loop variable will be unset in the next release. it was the only one
set in predefined.xotcl.
Thanks for reporting!

-gustaf

Koen Danckaert wrote:
> Hello,
>
> The predefined.xotcl file uses a global variable "cmd":
> foreach cmd {array append lappend trace eval} ...
>
> Which may, of course, give unexpected results:
>
> tclsh
> % set cmd mycommand
> mycommand
> % package require XOTcl
> 1.3.8
> % set cmd
> eval
>
> Regards,
> Koen
> _______________________________________________
> Xotcl mailing list
> Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Wed, 15 Mar 2006 13:23:28 +0200

On 15 Mar 2006, at 12:17, Gustaf Neumann wrote:
>
> The implementation of move as copy+destroy is a compromise between
> simplicity and functionality. I can imagine cases, where one wants
> to have more or less the equivalent to a copy constructor when
> copy occurs and maybe something different when a move happens.
> However, since all methods are equal in xotcl, it is quite simple
> for a poweruser of xotcl to overload copy/move and add applicaton
> specific addtional behavior to it. if one does not like the side-
> effects
> of destroy in a move, a custom move operation can set in instance
> variable "__during_move__" and query this from the destroy
> method to change its behavior.

I am actually quite surprised to find that the move operation calls
the destructor. This is not mentioned on the reference manual and
does, in fact, seem counter-intuitive. A move is a move, nothing is
being destroyed, so why call the destructor? I understand that the
operation is actually quite expensive, due to current Tcl internals,
but is there any reason why a destructor should be called? If we want
a method called for a move operation, surely it would be simple to
define that a "beingMoved" method is then called.

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