Weblog Page

From: Jeff Hobbs <jeffh_at_ActiveState.com>
Date: Wed, 1 Dec 2004 10:03:56 -0800

> Maybe start a SourceForge project for xotcl so you have
> access to SourceForge's compile farm?
> http://sourceforge.net/index.php
> http://sourceforge.net/docman/display_doc.php?docid=762&group_id=1

Unfortunately, as noted in the host list above, HP-UX and
other old-school linux variants (AIX, IRIX) are not
available in their list. You can get HP-UX test accounts
through the HP/Compaq testdrive center.

In any case, this was one issue that seemed to be a
x-platform issue that only arose seriously on HP. I find
that is actually a good advantage to many platforms - this
would not be the first general bug that was highlighted by
slight mem mgmt or other differences of a single platform.
In fact, the extra 'break' issue I highlighted yesterday
was also found by the Solaris Forte compiler as a general
warning, but gcc missed it. I don't have IRIX anymore, but
I recall the SGI compiler to have been very good about
pointing out possible bugs as general warnings.

Jeff

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Sun, 23 Apr 2006 21:06:32 +0200

Kurt Stoll schrieb:
>
> Note that with parametercmd we can make this slightly cleaner to use:
>
> Class create Car -parameter { {doors {[[self class] doors]}} }
> Car parametercmd doors
>
> Car doors 8
> Car create limo
> limo doors ; # ==> 8
> Car doors 5
> Car create minivan
> minivan doors ; # ==> 5

In order to get this still better working, i would recommend to create
a metaclass called Vehicle, which sets for every instance class the
default number of doors and provides as well the "parametercmd".

    Class Vehicle -parameter {{doors 4}} -superclass Class

    Vehicle create Car -parameter { {doors {[[self class] doors]}} }

    Car create sedan
    puts [sedan doors] ; # ==> 4

    Car create limo -doors 8
    puts [limo doors] ; # ==> 8

    Car create minivan -doors 5
    puts [minivan doors] ; # ==> 5

 you can do as well

    Car doors 20
    Car create choo-choo-train
    puts [choo-choo-train doors] ; # ==> 20

 but i am not whether you will really want this...

 I have developed a major overhaul of "parameter" and friends, it will
be certainly
 feature compatible at this level.

 Currently one can only specify a value or a command to be invoced at
instantiation
 time of the object (as in the example above). In general there are
several situations
 where the command should be executed e.g. the first time the variable
is accessed
 or on each access of the variable. This is e.g. important, when only a
few instance
 variables are used during lifetime of an object, and the the
instantiation command
 is rather expensive (e.g. a database query), or when one wants live
updates on
 the instance variables...

 The new parameter replacement (called slots) is very flexible and much more
 powerful, in many situations, it will be faster as well. It is as well
possible
 to use the same idioms for mixins/filters (... add, delete) as well for
other
 object/class relationsshipts (e.g. class, superclass) and for
user-values as well.
 Stay tuned. Currently, i am still unsure whether to use and extend
 the old interface (based on "parameter"), or to use for the more powerful
 cases the new interface. i have still a lot of integration and testing
in front
 of me. My intention is certainly to keep the suff described above
compatible,
 even with the new implementation.

-gustaf neumann

From: Scott Gargash <scottg_at_atc.creative.com>
Date: Mon, 11 Dec 2006 16:47:01 -0700

Jeff Hobbs <jeffh_at_activestate.com> wrote on 12/11/2006 04:32:55 PM:

> Scott Gargash wrote:
> > Is there any way to get the xotcl c-interface files (the .h/.lib files)
> > that correspond to the version of XOTcl that ships with the ActiveState
> > release? They're not present in the distribution.
>
> Hmmm, well, we don't keep those around. With the number of binary
> extensions in ActiveTcl, we made a decision a few years ago to save
> space by not keeping around the dev bits. I understand that they would
> be useful to a small percentage of users, but we haven't figured out any
> way to easily automate the handling of dev bits separate from user bits.

Perhaps it would make sense to break the download into two parts, a runtime environment and an SDK.
I'm unsure what other extensions have a binary interface, but for XOTcl (at least) all that needs to
be shipped is a couple of headers and the stubs lib. It seems equivalent to Tcl proper. In fact,
perhaps even the base Tcl libs/headers ought to be in an SDK package. I'd think than many, perhaps
even a majority of, users don't need the Tcl headers & libs.

But if it's not there, it's not there. Oh well, back to building my own version.

      Scott

From: Victor Mayevski <vitick_at_gmail.com>
Date: Tue, 26 Oct 2010 13:37:03 -0700 (PDT)

Thank you Gustaf, that makes sense. I have also found that I can still do attribute settings the old - "dash" way, so, most of my code should be fine.


----- Original Message -----
From: "Gustaf Neumann" <neumann_at_wu-wien.ac.at>
To: "Victor Mayevski" <vitick_at_gmail.com>
Cc: xotcl_at_alice.wu-wien.ac.at
Sent: Tuesday, October 26, 2010 4:20:48 AM GMT -08:00 US/Canada Pacific
Subject: Re: NX question

Hi victor,

also with nx, one can call methods during the object creation,
very similar to "eval":

    # create class
    nx::Class create Foo {
      :public method bar {} {return 1}
      :public method baz {} {return 2}
    }

    # create object
    Foo create f1 { :bar; :baz; :destroy }

Calling methods during creation is very common, and happens
as well in the example above during the creation of the
class Foo.

The example above can be written as well more compact via

     # create new class and object and cleanup everything
     nx::Class new {
       :public method bar {} {return 1}
       :public method baz {} {return 2}
       :create new { :bar; :baz; :destroy }
       :destroy
     }

In this example, the class is created with new, during
initialization, the methods "bar" and "baz" are created,
then an instance of the class is created (and calls
"bar" and "baz", and destroys itself), and finally the
class is deleted. If you want to run theses examples,
please update from git).

The problem with the dash ("-") commands is that they support
variable number of arguments. Unless one puts dash-commands
into a list (which is not usually done), and e.g. a variable
v has
the content "-foo", an invocation "... create f1 -x $v -y 1"
will try
to call a method foo. The security problem comes in, when
one has untrusted variable contents (e.g. provided via web).
It is certainly possible (and recommended) to validate
untrusted
content, or to use the list notation "... create f1 [list -x
$v] -y 1"
but in practice, this is often not done (by oversight,
non-awareness,
laziness, ...)

Finally, the standard xotcl answer: eveything can be configured.
Since nsf supports XOTcl 2.0 (and both, nx and xotcl2
are fully scripted), it is certainly possible to reconfigure nx
to get the good old dash-processing again to your scripts.

-gustaf neumann

On 26.10.10 06:36, Victor Mayevski wrote:
> Hello Gustaf,
>
> I have been playing with NX, so far I really like it, the speed, the clean interface, everything is very nice. One thing I miss though, which I have been using often in XOTcl, is invocation of methods during object creation. Example "MyClass create myobject -dowork1 -dowork2 -finalize -destroy". I know that you mentioned in the git log somewhere that this was security concern and NX will not have this capability. However, you did say that this can be scripted in. Can you give an example of how to do it? Is it really such a security issue?
>
> Thanks
>

From: jim <j_marvin_at_localnet.com>
Date: Thu, 11 Mar 2004 02:48:58 -0500

hi-
 
i am looking to start scripting on the web with tcl.
i like the looks of the rivet product because i used php before and the
xhtml
embedded in the page with tags looks familiar. i wonder if i can use
xotcl
when i script with rivet. i get confused on how one would add an
extension. isnt the
web host in control of this. i have to wait for rivet to release the
windows binaries.
while i am waiting i could read my tcl scripting manual.
 
i am a total beginner when it comes to tcl web scripting so any input
you can
provide is very helpful.
 
i have enjoyed tinkering with the xotcl ide so far. it is feature rich.
 
thanks,
marvin
 
 
 

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Thu, 29 Sep 2005 19:26:48 +0200

Dear Koen,

thanks for the report, this was a fresh error introduced by fixing
another bug.
Below is the fix. seems as a good idea to come out with 1.3.8 soon.

best regards
-gustaf neumann
==========================================================

--- generic/xotcl.c-1.3.7 2005-09-27 00:49:25.000000000 +0200
+++ generic/xotcl.c 2005-09-29 19:23:15.000000000 +0200
_at_@ -7976,7 +7976,6 @@
   XOTclObject *obj = (XOTclObject*)cd;
   Tcl_Obj **ov;
   int i, oc, result = TCL_OK;
- char *varname = 0, *alias = 0;
   callFrameContext ctx = {0};
 
   if (!obj) return XOTclObjErrType(in, objv[0], "Object");
_at_@ -7993,6 +7992,7 @@
  
   for (i=1; i<objc; i++) {
     if ((result = Tcl_ListObjGetElements(in, objv[i], &oc, &ov)) ==
TCL_OK) {
+ char *varname = 0, *alias = 0;
       switch (oc) {
       case 0: {varname = ObjStr(objv[i]); break;}
       case 1: {varname = ObjStr(ov[0]); break;}

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Mon, 12 Feb 2001 23:54:43 +0200 (EET)

Just for interest I implemented one of the OO tests from Doug's shootout
(http://www.bagley.org/~doug/shootout/) in XOTcl to see how it would
fare. Specifically it was the method call speed test
(http://www.bagley.org/~doug/shootout/bench/methcall/). I have attached my
code to this email.

According to my own tests, it didn't do terribly well, but it's difficult
to say whether this is a limitation of Tcl (which doesn't do very well in
several of those speed tests) or just a sign that there might be some room
for optimisation in XOTcl itself. Now what would be interesting would
be a comparison with iTcl -- but as I don't know it I'll leave that for
someone else. Any comments?

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

From: Gustaf Neumann <neumann_at_wu.ac.at>
Date: Sun, 29 Aug 2010 14:09:37 +0200

  ... forgot to mention:
You have to return the result of "next" as return of the filter (in the
case of your example $r).

all the best
-gustaf neumann

Am 29.08.10 13:54, schrieb Gustaf Neumann:
> Dear Kristoffer,
>
> many things went wrong. It is true, there is a bug in all XOTcl 1.*
> releases,
> which is there most likely since many years (8+).
>
> the bug:
>
> - when a filter chain comes to its end without finding the method
> (e.g. "ob foo"), xotcl records its fact, but this affected as well
> the method invocations from the filter after the "next".
>
> - The call "$targetclass info ..." was then letal especially
> with the standard unknown handler of the metaclass:
> xotcl belived incorrectly that "info" is unknown, and
> since an "unknown" call on a class (here $targetclass)
> creates an object, it was creating the object "info"
> as instance of that class, and the nightmare turned
> even worse.
>
> I have fixed the bug in 1.6.6, you can obtain it via
>
> git clone git://alice.wu-wien.ac.at/xotcl
>
> best regards
> -gustaf neumann
>
> Am 29.08.10 03:02, schrieb Kristoffer Lawson:
>> Take a look at this code:
>>
>> package require XOTcl 1.6
>> namespace import xotcl::*
>>
>> Class Foo
>>
>> Foo instproc hello {} {
>> puts hello
>> }
>>
>> Foo instproc myfilter {args} {
>> puts "\nme: [self]"
>> ::set targetclass [my info class]
>> puts "targetclass: $targetclass"
>> puts "calledproc: [self calledproc]"
>> ::set r [next]
>> puts "back from next"
>> puts "paramcmds: [$targetclass info instparametercmd]"
>> }
>>
>> Foo instfilter myfilter
>>
>> Foo ob
>> ob hello
>> ob foo
>>
>>
>> So first I have a filter installed which does nothing but print some
>> information, and checks something using the [info] method afterwards.
>> I call an instantiated object with [hello] (an existing method) and
>> again with [foo] (a non-existing method). The latter is when things
>> get interesting. Check the output:
>>
>>
>> me: ::ob
>> targetclass: ::Foo
>> calledproc: configure
>> back from next
>> paramcmds:
>>
>> me: ::ob
>> targetclass: ::Foo
>> calledproc: init
>> back from next
>> paramcmds:
>>
>> me: ::ob
>> targetclass: ::Foo
>> calledproc: hello
>> hello
>> back from next
>> paramcmds:
>>
>> me: ::ob
>> targetclass: ::Foo
>> calledproc: foo
>> back from next
>>
>> me: ::alloc
>> ::alloc: unable to dispatch method 'info'
>> while executing
>> "my info class"
>> (procedure "cleanup" line 4)
>> ::alloc ::Foo->myfilter
>> ::Foo ::xotcl::Class->recreate
>> ::Foo ::xotcl::Class->create
>> ::Foo ::xotcl::Class->unknown
>> ::Foo ::xotcl::Class->create
>> ::Foo ::xotcl::Class->unknown
>> ::Foo ::xotcl::Class->create
>> ::Foo ::xotcl::Class->unknown
>> invoked from within
>> "$targetclass info instparametercmd"
>> (procedure "foo" line 9)
>> ::ob ::Foo->myfilter
>> invoked from within
>> "ob foo"
>> (file "filtertest.tcl" line 24)
>>
>> me: ::alloc
>> targetclass: ::Foo
>> calledproc: destroy
>> back from next
>> paramcmds:
>>
>> me: ::info
>> targetclass: ::Foo
>> calledproc: destroy
>> back from next
>> paramcmds:
>>
>> me: ::ob
>> targetclass: ::Foo
>> calledproc: destroy
>> back from next
>> paramcmds:
>>
>> ...
>> So while the [hello] method works as expected, things get totally
>> weird for [foo]. The first thing we notice is that it doesn't jump
>> out at [next] (which should give an error as it does not exist). It
>> continue execution of the filter after [next]. This may or may not be
>> intended, I don't know. The documentation is not clear on this.
>>
>> More interesting still, we end up with a totally unexpected error.
>> The thing I believe is happening is that, for some reason or other
>> [$targetclass info instparametercmd] is not ending up calling [info]
>> for $targetClass, but creating an object called ::info (and thus
>> overriding the original Tcl command). How [alloc] gets involved in
>> the filter chain too, I am not sure. My guess is that the "unknown
>> method" that resulted from [foo] is being interpreted by the XOTcl
>> $targetclass C implementation as an error that occurred there, and
>> that a new instance called "info" or possibly "alloc" should be created.
>>
>> This causes major havoc as soon as an unknown method is called. Does
>> the filter code look correct?
>>
>> This happens with 1.6.2. I had a quick look at CHANGES for later
>> versions and while there was some mention of memory leaks in [info] I
>> wasn't sure if there was anything that would have fixed this.
>>
>> Any ideas?
>>
>
>

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

From: Gustaf Neumann <neumann_at_wu.ac.at>
Date: Wed, 25 Jul 2012 18:43:10 +0200

Am 25.07.12 16:48, schrieb Victor Mayevski:
> Hello Gustaff,
>
> What is the reason for following error/behavior:
>
> ClassX create c1; #ClassX has several subclasses
> c1 delete method m1
> Error: ::c1: cannot delete object specific method m1
the message says that it cant delete the method "m1", probably because
it does not exist


    package req nx::test

    nx::Class create ClassX
    ClassX create c1

    ? {c1 delete method m1} {::c1: cannot delete object specific method
'm1'}

    # define a method m1 and check, if it exists
    c1 public method m1 {} {...}
    ? {c1 info methods} "m1"

    # delete the method, does no raise an exception
    ? {c1 delete method m1} {}

> I get a similar error for "c1 delete property p1"
> Why am I not able to delete object specific methods/properties?
The following is supposed to work:

    c1 property foo
    ? {c1 info methods} "foo"
    ? {c1 delete property foo} {}
    ? {c1 info methods} ""

-gustaf neumann

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

From: Jeff Hobbs <jeffh_at_ActiveState.com>
Date: Thu, 2 Feb 2006 15:24:03 -0800

Gustaf Neumann wrote:
> Kristoffer Lawson schrieb:
> > When XOTcl exits, it seems that the [destroy] method is called on all
> > objects. The first question is whether this is wise .. possibly.
>
> well, it was some work to do so, and i think this is
> important from the oo-point-of-view.

Some work to enable? The general deletion of a Tcl interpreter
will call any associated deletion callback for AssocData and
commands. The one exception is for the last interpreter in a
"common" shell environment, which doesn't get deleted normally
(unless exit is undefined or you compile with -DPURIFY).

> If one allocates "external resources" (e.g. temp-files, register on a
> whiteboard, etc)
> and deallocates these resources in a destructor, the
> deallocation should certainly
> happen, when the program exists gracefully.

The graceful deallocation argument is mostly spurious, as the OS
cleans things up on program exit, but freeing of external
resources is important. This is why I'm considering fixing that
"last interp" exception above.

Jeff