Weblog Page

From: Gustaf Neumann <neumann_at_wu.ac.at>
Date: Fri, 24 Jul 2009 10:21:04 +0200

# - if I create a method forwarding f1:
#
# obj forward f1 list {%_at_end 13} %self
#
# ? { obj f1 1 2 3 } [list ::obj 1 2 3 13]
# Question:
#
# Why ::obj was inserted at the beginning but not at the end?

The definition of f1 is an example is from the XOTcl tutorial
and registers a forwarder method named "f1" for the
object "obj". When "obj f1 <someactualargs>" is invoked,
it constructs a new Tcl command starting with "list",
adds an argument with the value of "13" to
the end of the argument list and the fully qualified
name of the object as first argument. So, the invoked
command will be "list ::obj <someactualargs> 13".

Concerning your question:
Since the forwarder was defined to add "13" at the end of
the actual argument list, is does so. If you want a forwarder
adding the object name to the end, use:

   obj forward f1 list {%_at_end %self}

and a call "obj f1 1 2 3" will return a list "1 2 3 ::obj".

 

> 2- This forwarding method causes xotcl to crash:
>
> obj forward f2 list {%_at_end 13} %self %1
>
> ? { obj f2 1 2 3 }

There is a bug in the current xotcl versions when both
%_at_end and %1 is used, which will be fixed in the next release.
The %1 means that the first argument from the provided
argument list (here "1") will be placed at the given
position. The argument is consumed and the remaining
arguments (here "2" and "3") are appended to the arguments
from the forward definition. So, effectively,
"f1" and "f2" will have the same output.

Thanks for reporting!
-gustaf neumann

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Wed, 30 May 2001 17:01:07 +0200

On Wednesday 30 May 2001 16:55, Kristoffer Lawson wrote:
> On Wed, 30 May 2001, Uwe Zdun wrote:
> > We would propose a new:
> >
> > Class instproc newChildOf {obj args} {
> >
> > ::set name [[self] autoname -instance [namespace tail [self]]]
> > ::eval [self] create ${obj}::$name $args
> >
> > }
> >
> > which would be almost identical to newChild, but allows for specifying an
> > object name...
>
> Yes, that sounds good. If you think that will be the syntax for the next
> XOTcl release then I'll change what I currently use to do the above.

 it is already like proposed in the current development version...
-gustaf

From: Gustaf Neumann <neumann_at_wu.ac.at>
Date: Fri, 10 Feb 2012 19:07:10 +0100

Dear Arthur,

the call protection of NX is object-centric defined, which is a strong
form of protection. A protected method can be only called if the caller
and the callee are the the same object. In the examples below, caller
and callee differ. In the first case, the caller is an instance, the
callee is the class object, in the seconds case, caller and callee are
two different instances.

So, protection is in nx quite different to class centric approaches
(e.g. Java/C++); it is as well different to ruby protection (where
different instances of the same class can all protected methods).

So, the current behavior is as intended; in general, when you have
convincing evidence, we are always open to relax the nx policy.

-gustaf neumann

Am 10.02.12 11:45, schrieb Arthur Schreiber:
> Hello Gustaf,
>
> Is not being able to call protected class methods from instances intended
> behaviour?
>
> Here is a very simple test case:
>
> package require nx
>
> nx::Class create Greeter {
> :class protected method say_hi {} {
> puts "Hello!"
> }
>
> :public method say_hi {} {
> [:info class] say_hi
> }
> }
>
> [Greeter new] say_hi
>
> Also, protected methods can not be called from instances of the same class,
> e.g.:
>
> package require nx
>
> nx::Class create Greeter {
> :public method say_hi { other_greeter } {
> $other_greeter protected_say_hi
> }
>
> :protected method protected_say_hi { } {
> puts "Hello!"
> }
> }
>
> set g1 [Greeter new]
>
> [Greeter new] say_hi $g1
>
> Kind Regards,
> Arthur
> _______________________________________________
> Xotcl mailing list
> Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl

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

From: Catherine Letondal <letondal_at_pasteur.fr>
Date: Mon, 14 May 2001 11:06:17 +0200

Catherine Letondal wrote:
>
> Hi,
>
> I have a filter on Object which purpose is to register the called procs
> of every class in my application, for debugging purpose.
> The list of called procs is then displayed in a graphical component where
> it can be selected to be traced (http://www-alt.pasteur.fr/~letondal/biok/Images/tracegui.gif).
>
> I would like to have also mixin procs registered, but apparently, the
> calledclass in the filter, when called on the mixin, does not return
> the mixin class, but the actual called class.
> Is there a way to know that the mixin proc was called - in the filter scope
> I mean ?
>
> This filter is put on every class during a given period:
> Object instproc spyFilter args {
> set proc [self calledproc]
> set class [self calledclass]
>
> # debug is an Object doing debugging tasks and registering
> # trace/debug informations
>
> debug instvar calledprocs
> lappend calledprocs($class) $proc
> }

I should maybe add that this is not the complete filter procedure
code (there is of course a next statement and other bookkeeping statements).


>
> Class UpdateMixin
> UpdateMixin instproc update args {
> ...
> }
>
> UpdateMixin filter actually displays spyFilter, but the filter
> does not "see" the UpdateMixin as the calledclass, but rather the
> class the mixin is associated with.
>
> Thanks for your help,
>
> --
> Catherine Letondal -- Pasteur Institute Computing Center
>
>
>
>
> _______________________________________________
> Xotcl mailing list - Xotcl_at_wi.wu-wien.ac.at
> http://wi.wu-wien.ac.at/mailman/listinfo/xotcl

--
Catherine Letondal -- Pasteur Institute Computing Center

From: Proche, Patrick <patrick.proche_at_kpmg.co.at>
Date: Wed, 7 Mar 2001 16:12:58 +0100

Hallo,

Xotcl on Linux runs great so far, but I have problems with installing it on
my Windows machine (NT4.0, SP 6a). Though earlier postings helped a lot (the
"libtclgdbm.dll"-problem that Mr LeBlanc posted in January), the example
"Counter.xotcl" still doesn´t work.

After starting the xotcl HTTP server, I get the message "couldn´t find
procedure Tclgdbm_Init". I looked into the sources but couldn´t find it
either.

Does anybody know a solution to this?

Thanks,

Patrick Proché

From: Jeff Hobbs <jeffh_at_ActiveState.com>
Date: Tue, 30 Nov 2004 12:46:14 -0800

I have updated my patch from yesterday. This has been tested
across a much more elaborate set of platforms. My guess is
that xotcl has not been compiled against anything but gcc, or
installed on non-linux systems.

This patch builds and installs on the following variants:

* Windows-x86 (cygwin/MSVC build)
* Linux-x86 and x86_64 (gcc)
* HP-UX 11 pa-risc (gcc and cc)
* HP-UX 11 ia64 (cc)
* AIX 4.3.3 (xlc)
* Solaris 2.8 (gcc and cc)

test-core fails on HP-UX 11 pa-risc with:

FAILED: FAILED - UpLevel Test 2
Got: ::o
Expected: ::s
0 g='::o' e='::s'
make: *** [test-core] Error 255

and on some other platforms it can fail on exit (bad cleanup?),
but this gets things a lot further.

I don't think the ALLOC checks are being done properly, as I
said before - there is too much expectation that gcc-isms can
be the default, which isn't correct, IMO.

Part of this patch is the for loop break fix in xotcl.c that
I mentioned in my last message - that seems to have no effect
on the test-core for the platforms.

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).

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

From: Aamer Akhter <aakhter_at_gmail.com>
Date: Sat, 18 Feb 2006 13:41:24 -0500

On 2/16/06, Gustaf Neumann <neumann_at_wu-wien.ac.at> wrote:
> Aamer Akhter schrieb:
>
> >Critcl allows us to easily create tcl callable C procs. Is there
> >something similar avaliable for xotcl?
> >
> >Is there any C api documentation?
> >
> >
> There is as well a simpler way, defining e.g. a cinstproc similar to the
> cproc:
>
> ===============================================================
> lappend auto_path .
> package require critcl
>
> Class instproc cinstproc {name arglist returntype body} {
> critcl::cproc $name $arglist $returntype $body
> catch {$name} ;# there must be a better way forcing the compile!
> rename $name ::xotcl::classes[self]::$name
> }
> ===============================================================
>
> now one can define a Class and a cinstproc and use it.
>
> ===============================================================
> Class C
> C cinstproc triple {int i} int {
> return i * 3; /* this is C code */
> }
>
> C c1
> puts "three times 123 is [c1 triple 123]"
> ===============================================================
>
> this might be already sufficient for you. Two things should be done
> more beautiful:

Thank-you, this certainly gives ideas. I'll have to play around with
it and look at the existing code sent out earlier to understand the
API a bit better.

>
> a) the compilation in criticl seems to be forced through unknown.
> my approach with the catch is rather crude. but i am sure, there must
> be an option.

I have been doing the catch/compile myself- don't know if there is
another way for runtime use. Personnally, it comes in usefull as it
allows for doing falback to tcl-only versions.


>
> b) It would be nice to generate the command in the right namespace.
> i found as well no nice approach to do this.

I've been using the critcl::ccommand inside a namespace eval to place
the command in the right namespace. That appears to work. eg:

package require critcl;

namespace eval ::ip {

critcl::ccode {
#include <stdlib.h>
....
}

critcl::ccommand prefixToNativec {clientData interp objc objv} {
    int elemLen, maskLen, ipLen, mask;
        int rval,convertListc,i;
        Tcl_Obj **convertListv;
        Tcl_Obj *listPtr,*returnPtr, *addrList;
        char *stringIP, *slashPos, *stringMask;
        char v4HEX[11];
        
        uint32_t inaddr;
 ....
 }

}; #namespace eval
>
> Aamer, if you have some experience here, feedback would be welcome,
>
> -gustaf
>
> >
> >
> >--
> >Aamer Akhter / aakhter_at_gmail.com
> >
> >_______________________________________________
> >Xotcl mailing list
> >Xotcl_at_alice.wu-wien.ac.at
> >http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
> >
> >
>
>

--
Aamer Akhter / aakhter_at_gmail.com

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Sat, 25 Nov 2006 00:50:36 +0100

Dear XOTcl Community,

i am pleased to announce XOTcl 1.5.3. This is an unplanned bugfix release,
which is necessary due to certain changes in Tcl 8.4.14, which can lead
to memory corruption in certain applications when xotcl is used. In
particular,
installations of OpenACS/DotLRN using Tcl 8.4.14 are required to upgrade to
XOTcl 1.5.3.

Major changes relative to 1.5.2 are:

      + provided compatibility with Tcl 8.5

      + provided compatibility with Tcl 8.4.14

         (fixed a nasty bug caused by a change in tcl 8.4.14, could
         led to a crash due to freed Tcl_Objs in OpenACS, allthough
         the xotcl regression test passed correctly)

      + reduced calling overhead of methods with nonpositional
         arguments by about 10 percent by avoiding shimmering.

      + fixed handling of "return -code break" from xotcl methods
         (thanks to Artur Trzewik for the bug report)

      + library/comm/Access.xotcl: fixed handling of chunked encoding

 For more details about the changes, please consult the ChangeLog.

MORE INFO
  General and more detailed information about XOTcl and its components
  can be found at http://www.xotcl.org


Best regards,

Gustaf Neumann
Uwe Zdun

From: Jeff Hobbs <jeffh_at_ActiveState.com>
Date: Tue, 19 Oct 2004 09:00:08 -0700

Schofield, Bryan (GE Transportation) wrote:
> Didn't Gustaf whip up something that was itcl compatible, at least to some
> degree? And does it need to be 100% itcl or 100% itcl/itk?

Yes, because TIP #50 specifies adding itcl to the core, but it
doesn't say specifically how. If xotcl can provide that same
functionality, the itcl users won't care, and we get the best
of both OO worlds for those who prefer xotcl style OO.

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

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Tue, 01 Jan 2008 19:26:08 +0100

Dear all,

first, a happy new year to everybody!

Eckhard Lehmann schrieb:
> Especially I look for a way to execute a proc before *every* statement
> inside an instproc. [trace] can do this via the "enterstep" and
> "leavestep" operators to [trace add execution]. Is this possible with
> filters and filterguards?

Here is a small example for tracing the calls within a method ("doit"),
which is somewhat similar to enterstep. Given is the following sample
script:

==========================
Class A
A instproc foo {} {
  my set f 2
}
A instproc doit {args} {
  my set a 3
}
Class B -superclass A
B instproc doit {args} {
  my set x 1
  my foo
  next
  my set y 4
}
B b1
==========================

for this script, we can define a filter, which uses call stack introspection
(self callingproc) to check, whether the current execution is within the
method "doit".

==========================
Class F
F instproc traceFilter args {
  if {[self callingproc] eq "doit"} {
    puts "Call: [self] [self calledproc] $args"
    set r [next]
    puts "Exit: [self] [self calledproc] $args => $r"
    return $r
  } else {
    next
  }
}
==========================

we add the method via mixin and register the filter to
to all instances of Class B and call the method,

==========================
B instmixin F
B instfilter {{traceFilter}}
b1 doit
==========================

The output is as follows:

Call: ::b1 set x 1
Exit: ::b1 set x 1 => 1
Call: ::b1 foo
Exit: ::b1 foo => 2
Call: ::b1 set a 3
Exit: ::b1 set a 3 => 3
Call: ::b1 set y 4
Exit: ::b1 set y 4 => 4

Note, that it just traces on the level of doit. This is not the same, what
tcl command traces provide (which is more of a debugging tool), but
filters are
in some respects more general: one can use traces as glueing code between
invocations, restrict the traces to certain objects or instances of classes,
one can stack multiple filters, or can provide different guard conditions
for different subclasses, etc.

tcl command traces just know about tcl-commands and nothing about
OO concepts, they allow to register other tcl commands to be executed
at certain checkpoints (e.g. one command before the invocation,
another command after invocation), but it does not provide e.g. means
to pass information between the before and after calls. that is much
easier with the "next" metapher in xotcl, which is uniform to all
other supported concepts.

i have not felt so far the need for tcl command traces, but i understand,
that for people used to it there is a change in the method-set and thinking
involved to move from command traces towards filters/mixins.

Allthough all xotcl methods are commands, with the current framework,
the tcl command traces are not called autmatically, since the basic
invocation mechanisms (with inheritance, filters, mixins) are handled
by xotcl. Without looking into the details, i think it should be possible
with moderate effort to incorporate tcl command traces in xotcl. But
one has to convince the developers, that adding yet another interception
mechanism to xotcl adds more benefits than causing confusion.

-gustaf neumann

PS: The example above can be implemented nicer of filterGuards,
but unfortuantely, there is a bug in the current release (most likely
since ever) within the evaluation of callstack introspection commands
from within a guard. This bug will be removed in the forthcoming
release, where one can write:

F instproc traceFilter args {
  puts "Call: [self] [self calledproc] $args"
  set r [next]
  puts "Exit: [self] [self calledproc] $args => $r"
  return $r
}

B instfilter {{traceFilter -guard {
  [self callingproc] eq "doit"
}}}