View · Search · Index
No registered users in community xowiki
in last 10 minutes

Weblog Page

Filtered by date 2017-01-02, 821 - 830 of 1541 Postings (all, summary)

[Xotcl] XOTcl Slides from Tcl 2009 conference

Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM

From: Gustaf Neumann <neumann_at_wu.ac.at>
Date: Fri, 02 Oct 2009 20:53:40 +0200

Dear community,

you might be interested in the attached slides about xotcl 2.0
presented at the "Sixteenth Annual Tcl/Tk Conference (2009),
Portland, Oregon", a few minutes ago

all the best
-gustaf neumann

PS: In case, the mailing list strips the attachment, get the slides form
here:
http://nm.wu-wien.ac.at/research/publications/b802.pdf

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

[Xotcl] Re: [Xotcl] Re: [Xotcl] Garbage Collector in Xotcl

Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Mon, 21 May 2001 20:37:33 +0300 (EEST)

On Mon, 21 May 2001, Uwe Zdun wrote:

> I'm not sure that Tcl_Objs are the best implementation variant for such a GC
> scheme, because of (a) shimmering (which may cause at least heavy performance
> problems) and (b) if some string with the same name exists, the object does
> not get deleted.

I believe shimmering will actually be quite a small problem as in Tcl
objects the string version of an object is kept anyway and if this
does not change, no shimmering should occur at any point. At least
this is how I think it happens.

(b) is also not really a problem. With GCed objects the names should
also be generated and unique and thus not conflict with other objects. Hm,
Tcl should probably provide a way of creating objects which are not shared
on the basis of their string content... Maybe this was one of the changes
Feather was going to make.

By far the most difficult problem is the fact that many callback systems
take strings as scripts and Tcl strings are not currently structured in
any way. So for example:

after 1000 {[MyObject new] dostuff}

This will not work with GCed objects. The new MyObject will be GCed
immediately after the call to "after". OK, this is contrived, but there
are more dangerous situations where this can occur. This was one major
problem with the systems in Feather and has to be taken into account. The
only long-term solution I can think of is for Tcl to structure strings
into trees (sometime in the future) and thus keeping references to objects
even when they become a part of another string (and do not exist
elsewhere).

I do agree that GCed objects would be a good thing. GC simply makes a lot
of things much much easier. I'm not quite sure how critical the above
problems are, but it's worth considering. Object aggregation actually
removes a lot of the need for GC, but it's not perfect either.

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

Re: [Xotcl] [self class] inside [eval]

Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM

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

Dear all,
i just returned from vacation and i am slowly digging through my mail.

> That's fine, just so I know that's not the intended use. Though I still
> think it may be interesting to have a method that would allow access to
> methods and everything in that fashion, but that may not be feasible.

the method eval is defined in predefined.xotcl through instforward.

# provide some Tcl-commands as methods for Objects
foreach cmd {array append lappend trace eval} {
  ::xotcl::Object instforward $cmd -objscope
}

the option -objscope means, that the instvars of the object
are in the current scope of evaluation and can be reached
without any prefix. one can do

~/scripts> Object o
::o
~/scripts> o set x 1
1
~/scripts> o incr x
2
~/scripts> o eval regexp b abc y
1
~/scripts> o info vars
x y
~/scripts> o set y
b

See the documentation of 1.3 for more details about
the forwarding stuff

accessing methods in general only through the namspace
is not possible, since we have procs+instprocs (of several
classes) with the same name. you certainly can call
a proc of the object via the eval method

~/scripts> o proc x {} {puts hu}
~/scripts> o eval x
hu

but not instprocs. The following explanation is only for advanced
readers:
<techyspeak>
  in XOTcl, instprocs are defined as Tcl-procs within class-specific
  namespaces. Therefore we can have a method with the same
  name in various classes, which are linked via the next-path.

  the class specific namespace for the methods of ::xotcl::Object
  is ::xotcl::classes::xotcl::Object. you can see the instprocs of
  ::xotcl::Object via:

     ~/scripts>info procs ::xotcl::classes::xotcl::Object::*

  If one defines a method in a class
     ~/scripts> Object instproc y {} {puts ho-[self]}
  it shows up there as well
    ~/scripts> info procs ::xotcl::classes::xotcl::Object::y
    ::xotcl::classes::xotcl::Object::y

  if for some reason, one has to call the instproc directly,
  one could use the forwarder

     ~/scripts> Object instproc y {} {puts ho-[self]}
     ~/scripts> o eval y
     ho-::o
 
 or e.g. the approach in "Itcl in XOTcl" http://mini.net/tcl/10975
 where itcl methods are called just by their names
 (i have somewhere a slightly faster version using "interp alias").
</techyspeak>

I would not recommend this for the general usage, since
- as uwe pointed out - this is bypassing the xotcl dispatcher
an can lead to unexpected behavior (it is a defined behavior,
but different from the variant without eval).

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

XOTcl/NX mailing list by class creating

Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Mon, 13 Oct 2003 09:41:18 +0200

On Sunday 12 October 2003 11:29, Artur Trzewik wrote:
> Hi!
>
> I have noticed some problems by passing parameters by class creating
>
> Example
>
> % Class A -parameter par
>
> ::A
>
> % A create a -par -e
> Can't find result of parameter par during '::a par'

 Artur, check out Changelog and documentation,
 this was changed early this year. Use [list] to
 help configure:

     A create a [list -par -e]

 best regards
-gustaf neumann

=======================================
2003-01-09 Gustaf.Neumann_at_wu-wien.ac.at
        * configure methods can be placed into a list to avoid
          ambiguity of "-". This character is used as a metachar to
          denote method names, but it has to be used in values as well.
          Example:
             Class Book -parameter {title author}
             Book b1 -title "--the title--" -author a.b.c
          has to be written as
             Book b1 [list -title "--the title--"] -author a.b.c
          Note, that XOTcl allows us to provide multiple arguments
          to methods called via configure. Note, that xotcl
          supports via this method calling methods with 0,
          1 or more arguments.

=======================================
> %
>
> # This one was OK.
>
> % A create a
>
> ::a
>
> % a par -e
> -e
>
> It seems it is imposible to pass any parameter value beginning with '-' by
> creating some instance.
> Is there any workaround for this problem?
>
> 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
WU-Wien, Augasse 2-6, 1090 Wien

Re: [Xotcl] Checking to see if a class is defined

Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM

From: Uwe Zdun <uwe.zdun_at_wu-wien.ac.at>
Date: Fri, 25 Jun 2004 16:19:16 +0200

Adam,

you can ask any XOTcl object (e.g. Object) if another identifier is the
name of an
object. e.g.:

% Object isobject MyClass
0

You can also ask any object whether it is a class:

% Class create MyClass
::MyClass
% Object isobject MyClass
1
% MyClass isclass
1
%

an object would return 0 in this example:

% Object create m
::m
% Object isobject m
1
%m isclass
0

see langRef for more details ...

--Uwe


Adam Turoff wrote:

>I'm creating a test suite for an XOTcl class I'm writing, and I want to
>test this sequence:
>
>(1) MyClass is undefined (initial state)
>--- package require MyClass succeeds
>(2) MyClass is defined (expected state after loading the package)
>(3) MyClass isa ::xotcl::Class
>(4) MyClass has methods x, y, z
>
>However, I am not having any luck in testing #1 and #2. Is there any
>kind of introspection that can help me determine if a class is defined?
>Using [info exists MyClass] doesn't seem to work.
>
>Thanks,
>
>-- Adam
>_______________________________________________
>Xotcl mailing list - Xotcl_at_alice.wu-wien.ac.at
>http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
>
>

Re: [Xotcl] why Attribute is not imported?

Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM

From: Stefan Sobernig <stefan.sobernig_at_wu.ac.at>
Date: Mon, 02 Nov 2009 09:29:10 +0100

Mykhaylo,

> XOTcl 1.6.4, works ok from xotclsh and when 'namespace import ::xotcl::*'
> comes right after 'package require XOTcl' and not within test1 namespace.

This behaviour is due to an interaction between the implementation
strategy for slots as implemented in XOTcl 1.5+ and the standard
namespace/command resolution rules of Tcl.

(::xotcl::)Attribute is declared and resolved for the scope of a
per-object namespace ::test1::Test::slot. This namespace is acquired
upon calls to the slot method of ::xotcl::Class. You may find out by
inspecting the return value of [namespace current] (see below). While
this is merely an implementation detail and should not concern the XOTcl
developer, it interferes with the way Tcl resolves relatively-qualified
command (and variable) names. While slightly more complex at second
sight, generally speaking, the command name (e.g., Attribute) is first
searched for in the current ns (::test1::Test::slot) and then in the
global one (::):

see Section "NAME RESOLUTION" at
http://docs.activestate.com/activetcl/8.5/tcl/TclCmd/namespace.htm#M18

Intermittent ones are skipped (e.g., ::test1, ::test1::Test). Hence the
behaviour you are observing. This also explains why a [namespace import
::xotcl::*] in the /global/ ns (e.g., following [package req XOTcl]) is
a valid fix.

You may also consider:

1. fully-qualified command names: ::xotcl::Attribute
2. a preceding [namespace import ::xotcl::*] in the '-slots' block (see
below)
3. use of [namespace path] starting with 8.5 (see below)

//stefan

######
package provide test1 0.1
package require XOTcl

# ::test1
namespace eval ::test1 {
   #
   # [namespace current] -> ::test1
   #
   namespace import ::xotcl::*
   # alternatively: namespace path ::xotcl
   Class ::test1::Test -slots {
     #
     # [namespace current] -> ::test1::Test::slot
     #
     namespace import ::xotcl::*
     # alternatively: namespace path ::xotcl
     Attribute name
   }
   namespace export Test
}
namespace import ::test1::*

######

[Xotcl] Re: [Xotcl] RE: [Xotcl] Re: [Xotcl] Object mixin with passing init args ?

Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM

From: <uwe.zdun_at_uni-essen.de>
Date: Wed, 13 Dec 2000 11:39:02 +0100 (CET)

>>>>> "ZV" == Zoran Vasiljevic <zoran_at_munich.com> writes:

ZV> ------Original Message------
ZV> From: <uwe.zdun_at_uni-essen.de>
ZV> To: Zoran Vasiljevic <zoran_at_munich.com>
ZV> Sent: December 13, 2000 9:55:56 AM GMT


>> 2. However, in the "mixin" case we could enable argument passing,
>> because "mixin" has just one argument? The rest could be passed > to
ZV> "init". any objections?

ZV> obj mixin Foo arg1 arg2 arg3

ZV> would pass arg1-arg3 to init of Foo. Right?

yes

ZV> obj mixin [list Foo Bar] arg1 arg2 arg3

ZV> would pass arg1-arg3 to init of Foo AND of Bar. Right again?

yes

ZV> Is so, then I think it should be done, if possible. 0.85 ? 0.9 ?

if there are no objections we can include this right now (and
officially in 0.84) ... its just a little change ... Just exchange
the appended XOTclOMixinMethod in xotcl.c and re-compile to test it:

#################################################
Class A
A instproc init args {puts [self class]--$args;next}
Class C
C instproc init args {puts [self class]--$args;next}

Class B
B instproc init args {puts [self class]--$args;next}

B b
# every thing works
puts ++++++++++++++++++++++++++
b mixin A arg1 arg2 arg3
puts ++++++++++++++++++++++++++
b mixin {A C} arg1 arg2
puts ++++++++++++++++++++++++++
b mixin {A C} arg1
puts ++++++++++++++++++++++++++
b mixin {A C}

# but here we have to add the args ... because "mixin"
# is called before "init"
puts ++++++++++++++++++++++++++
B b2 a1 a2 a3 -mixin {A C}
puts ++++++++++++++++++++++++++
B b2 a1 a2 a3 -mixin {A C} a1 a2 a3

#################################################

--Uwe

-- 
Uwe Zdun
Specification of Software Systems, University of Essen
Phone: +49 201 81 00 332, Fax: +49 201 81 00 398
zdun_at_xotcl.org, uwe.zdun_at_uni-essen.de
########################################################################
static int
XOTclOMixinMethod (ClientData cd, Tcl_Interp* in, int objc, Tcl_Obj *objv[]) {
  int oc; Tcl_Obj** ov;
  XOTclObject* obj = XOTclAsObject(in, cd);
  int i, result = TCL_OK;
  XOTclClass     *mcl=0;
  Tcl_ObjCmdProc *mproc = 0;
  Command        *mProcInfo =0;
  ClientData     mcp;
  int isDestroyed = 0;
  if (!obj) return XOTclObjErrType(in, obj->cmdName, "Object");
  if (objc < 2)
    return XOTclObjErrArgCnt(in, obj->cmdName, "mixin <classes> ?args?");
  if (Tcl_ListObjGetElements(in,objv[1], &oc, &ov)!= TCL_OK) return TCL_ERROR;
  MixinRemoveList(&obj->mixins);
  obj->mixinDefined = XOTCL_MIXINS_INVALID;
  for (i = 0; i < oc; i++) {
    char* av = ObjStr(ov[i]);
    XOTclClass* mixin = XOTclGetClass(in, av);
    if (!mixin)
      return XOTclErrBadVal(in, "a list of classes", ObjStr(objv[1]));
    if (!XOTclIsClass(in, (ClientData) mixin))
      return XOTclVarErrMsg(in, "Mixin for ", ObjStr(obj->cmdName),
				 " must be class, got: ", av, (char*)0);
    MixinAdd(in, &obj->mixins, mixin);
  }
  MixinComputeDefined(in, obj);
  /*
   * call "init" on the mixin
   */
  MixinStackPush(obj);
  obj->mixinStack->mixinInit = 1;
  obj->mixinStack->mixinChainOn = 1;
  mProcInfo = MixinSearchProc(in, obj, "init",
			      &mcl, &mproc, &mcp);
  if (mproc) {
    int oc = objc-1;
    DEFINE_NEW_TCL_OBJECTS_ON_STACK(oc,ov);
    ov[0] = global_objects[INIT];
    memcpy(ov+1, objv+2, sizeof(Tcl_Obj *)*(oc-1));
    /* set flag to prevent calling a mixin/the class constructor twice */
    result = callProcCheck(mcp, in, oc, ov, mProcInfo,
			   obj, mcl, "init", 0, 1 /*isMixinEntry*/, &isDestroyed);
    
    FREE_TCL_OBJECTS_ON_STACK(ov);
  }
  if (!isDestroyed && obj->mixinStack)
    MixinStackPop(obj);
  return result;
}

[Xotcl] NX unknown method

Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM

From: Victor Mayevski <vitick_at_gmail.com>
Date: Thu, 17 Feb 2011 17:05:47 -0800

Hello Gustaff,

I am having a problem with unknown in NX, where, if I define my own
"unknown" method, in which I just check for presence of some argument,
if that argument does not exist, I pass processing further on via
[next] to the built-in "unknown" processor, well, at least that's what
I would like to do. What I find is that there is no further processing
done, [next] does not do anything, the unknown method just returns
silently. Am I doing something wrong?

##########################################
Class create C
C method unknown args {
if {$args eq "test"} {
puts "found test";
return
};
next;
}

C create obj;
obj test
> found test

obj xyz
> #nothing, no error
############################################
Thanks,

Victor

[Xotcl] Re: [Xotcl] Packaging question

Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM

From: <uwe.zdun_at_uni-essen.de>
Date: Mon, 11 Dec 2000 17:47:31 +0100 (CET)

>>>>> "LD" == Laurent Duperval <laurent.duperval_at_netergynet.com> writes:

LD> Hi,
LD> What is the equivalent of building a tclIndex file for xotcl classes? I want
LD> to build an app which is comprised of a whole bunch of modules. I'd like the
LD> modules to be automatically loaded when I call one of the classes defined in
LD> them. The way I do it now is:

LD> source "module1.tcl"
LD> source "module2.tcl"
LD> .
LD> .
LD> .

Hi,

we use nearly always tcl's package command with tclIndex files. Take a
look at the examples in src/lib and packages/ ...

e.g. xodoc.xotcl in src/lib declares:
  
  package provide xoDoc 0.82

which is used by makeDoc.xotcl:

  package require xoDoc

XOTcl uses an env variable TCLLIBPATH to customize the load path or
you can use auto_path. Same as with Tcl you have to run pkg_mkIndex,
when something changes.

Alternatively OTcl (and XOTcl) offers autoloading of classes (see
lib/testo.xotcl for an example -- search for autoload). But this has
too often turned out ot be problematic, because you don't have fine
grained control of how things are loaded. The abstraction into a whole
package seems to better fit the reusable component idea. And it
lets you build and load .xotcl, .tcl, and .so/.dll components in the
same way ... even if they're constructed from other components.

--Uwe



-- 
Uwe Zdun
Specification of Software Systems, University of Essen
Phone: +49 201 81 00 332, Fax: +49 201 81 00 398
zdun_at_xotcl.org, uwe.zdun_at_uni-essen.de

Re: [Xotcl] proper way to access xotcl classes

Created by hypermail2xowiki importer, last modified by Stefan Sobernig 02 Jan 2017, at 11:15 PM

From: Matthew Smith <chedderslam_at_gmail.com>
Date: Wed, 7 May 2008 13:09:35 -0500

Thank you for the help.

Now I am getting another error I don't understand.

invalid command name "my".

It seems like it is not getting to use XOTcl commands. Here is what I have:
----------------------------------------------------------
package require XOTcl
::xotcl::Class Stack
Stack instproc init {} {
    # Constructor
    my instvar things
    set things ""
}
Stack instproc push {thing} {
    my instvar things
    set things [concat [list $thing] $things]
    return $thing
}
Stack instproc pop {} {
    my instvar things
    set top [lindex $things 0]
    set things [lrange $things 1 end]
    return $top
}

set s1 [Stack new]
----------------------------------------------------------

On Wed, May 7, 2008 at 1:01 PM, Kristoffer Lawson <setok_at_scred.com> wrote:

>
> On 7 May 2008, at 20:54, Matthew Smith wrote:
>
>
> > ---------------------------------------------------------
> > How do I access the class methods(i guess they are called) from within
> > the tcl file?
> > The examples show this:
> > --------------------------------------------------------
> > # Create Object s1 of class Stack
> > % Stack s1
> > ::s1
> > % s1 push a
> > a
> > % s1 push b
> > b
> > % s1 push c
> > c
> > % s1 pop
> > c
> > % s1 pop
> > b
> > # Delete object s1
> > s1 destroy
> > --------------------------------------------------------
> > I have tried this:
> > set s1 [Stack]
> >
> >
> Either this:
>
> set s1 [Stack new]
>
> or
>
> set s1 [Stack s1]
>
> The first version gives you an automatically named object, which is
> probably what you usually want to do. You can also explicitly name objects
> with the latter version (something you cannot do with Java and stuff).
> Mostly you wont need to do this, but there are situations when it's useful.
>
> / http://www.scred.com/
> / http://www.fishpool.com/~setok/<http://www.fishpool.com/%7Esetok/>
>
>
>

Next Page