Weblog Page

From: Patrick Finnegan <finnegan.patrick_at_gmail.com>
Date: Mon, 11 May 2009 11:43:15 +0100

Is anyone in this group working on the Eclipse DLTK XoTcl Plugin?

From: Jeff Hobbs <jeffh_at_ActiveState.com>
Date: Tue, 30 Nov 2004 15:58:54 -0800

I'm not sure how many I've sent so far, but I hope this is
the last ;).

In addition to the previous, this corrects:

* CallStackGetFrame patch from Gustaf, exposed by HP build
* make doc on Windows now works (from cygwin build)

In doing test-core, the very end can sometimes complain
that xotcl::test isn't found - I think this is expecting
an installed version or something.

Also, 'make doc' on Windows catches one failure:

...z:\src\xotcl-1.3.3\tests\testx.xotcl
        error processing z:\src\xotcl-1.3.3\tests\testx.xotcl:
too many nested evaluations (infinite loop?)
    (procedure "getCommand" line 1)
    ::docdb26 ::StaticMetadataAnalyzer->getCommand
    invoked from within
"my getCommand c"
    (procedure "getCommand" line 25)
    ::docdb26 ::StaticMetadataAnalyzer->getCommand
    invoked from within
"my getCommand c"
    (procedure "getCommand" line 25)
    ::docdb26 ::StaticMetadataAnalyzer->getCommand
    invo...

So doing the doc on that pushes the stack limit I think,
as it takes a while on any platform for that file. I would
rewrite that proc to not be recursive - getCommand could
iterate ones over the string and break it into a list of
commands (as tkcon does).

We are still seeing some issues with 8.5 build/installs,
but I think they may be localized (and not as important at
this point).

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

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Thu, 16 Dec 2010 11:31:35 +0100

Dear Victor,

here is a scripted writeup to address your questions.

-gustaf neumann
===========================================================
package req nx::test
nx::Object create o

# The method setter registers an accessor method for instance
# variables. It provides "set" and "get" operations and value
# checking.

# Register accessor named x
o setter x

# Use the accessor method x as setter
# (set instance variable x to 1; returns 1)
? {o x 1} 1

# Use the accessor method x as getter
# (get the value of the instance variable x; returns 1)
? {o x 1} 1

# Define a setter with a value constraint
o setter x:int
? {o x 3} 3
? {o x a} {expected integer but got "a" for parameter "x"}

# The accessor function can be realized with some more
typing as well
# via the following method. So, the method "setter" does not
provide
# any additional functionality in terms of expressability of the
# language.

o public method y {value:int,optional} {
   if {[info exists value]} {
     return [set :y $value]
   } else {
     return [set :y]
   }
}

? {o y 3} 3
? {o y a} {expected integer but got "a" for parameter "value"}

# Why are accessor function at all provided since instance
variables
# can be accessed as well without these? In nx it is easy
for an
# object to access the own instance variables via variable
resolvers
# (variable names starting with a single colon), butmore work to
# access the variables of other objects. One can use e.g.
the method
# "eval" to execute a script in the context of an object
(and to be
# able to use the variable resolver).

? {o eval {set :x 2}} 2

# So, an accessor method makes the access of public
variables easy, it
# provides the value constraints, one can use interceptors for
# tracing, refinement, etc.

# Ok, why do we need attributes?

# Attributes (as defined by nx) provide all functionalities
provided
# by the setter methods plus
# - some attribute life-cycle management (e.g. default
values), and
# - arbitrary meta-data

# For example, we can define an integer attributed named "z"
with a
# default value.

o attribute {z:int 123}
# return the default value
? {o z} 123
? {o z a} {expected integer but got "a" for parameter "z"}

# The example above is an object specifc attribute. In most
# situations, attributes are defined on the class level.
Attributes
# are inherited to subclasses (setters certainly as well).

nx::Class create Employee {
   :attribute serial_number:int,required
}
nx::Class create Manager -superclass Employee {
   # Project names are upper case, provided as an list,
which might be
   # empty and are per default initialized to the empty list.
   :attribute {projects:upper,0..n {}}
}

Manager create joe -serial_number 4711

# What about the meta-data? I want to use e.g. very special
meta-data,
# such as e.g. time-stamps.

# The method "attribute" creates so-called slot objects,
which are in
# turn nx objects. These slot objects can be initialized
like all
# other nx objects in a scripted way.

nx::Class create C {
   # Create attributes "x" and "y" and script the
initialization of
   # these attributes.
   :attribute x {
     set :timestamp [clock clicks]
   }
   :attribute y {
     set :timestamp [clock clicks]
   }
   :create c1
}

# Print for every slot object the value of the timestamp, if it
# exists.
proc print_slots_and_timestamps {obj} {
   foreach slot [$obj info lookup slots] {
     if {[$slot eval {info exists :timestamp}]} {
       puts "$slot created at [$slot eval {set :timestamp}]"
     }
   }
}
print_slots_and_timestamps c1

#
# Ok. What if I want to use a time-stamp for every attribute
of my
# application without having to write this for every occurance?
#
# Well, use the force, luke. Remember, we have quite a powerful
# underlying framework, supporting e.g. mixin, dynamic call
# definitions, etc.

::nx::Attribute mixin [Class new {
   :method init {} {
     set :timestamp [clock clicks]
     next
   }
}]

nx::Class create D {
   # Create attributes "x" and "y" and script the
initialization of
   # these attributes.
   :attribute x
   :attribute y
   :create d1
}

print_slots_and_timestamps d1

#
# What if i want to use different kinds of attributes, such as
# e.g. persistent attributes and non-persistent attributes,
etc.? How
# can i define my on slotclasses if i need?
#
# Per default, attributes are of the class ::nx::Attribute.
One can
# certainly define subclasses of this class and specify
these classes
# during attribute creation. Since "attribute" is technically a
# method, the syntax is slightly different to the usual object
# creation.
#
# We define now "MyAttribute" as a subclass of
::nx::Attribute with an
# additional attribute named timestamp. The timestamp has
the actual
# timestamp as default.
#
::nx::MetaSlot create MyAttribute -superclass ::nx::Attribute {
   :attribute {timestamp "[clock clicks]"}
}

# Use this type of attribute:
nx::Class create E {
   :attribute x -slotclass MyAttribute
   :attribute y -slotclass MyAttribute
   :create e1
}

print_slots_and_timestamps e1

# A final question: i see that "attribute" is more powerful then
# "setter". Do I need as an enduser the method "setter" at all?
#
# No. I think, we could safely remove it from the default
method set
# for the final release.
#
# One other observation during this writeup: maybe
"slotclass" is to
# crude, we could use "class" or "type" instead (at some earlier
# state, we could not use technically "class"). We will
overthink
# this.

From: Kristoffer Lawson <setok_at_scred.com>
Date: Wed, 4 Aug 2010 03:42:56 +0300

This is really bad news, guys...

% package require XOTcl
1.6.2
% namespace import xotcl::*
% Class Foo
::Foo
% Foo instproc init {a} {puts $a}
% set a "-test"
-test
% Foo new $a
::xotcl::__#0: unable to dispatch method 'test' during '::xotcl::__#0 test'

In other words: it is totally impossible to pass in a value beginning with "-" to an XOTcl constructor using the normal instantiation methods. This means absolutely anything where you don't know what is going to be passed beforehand is at a huge risk, as obviously any text can thus call random methods. That is without doing the whole process manually (ie. alloc, init). And you'd have to do it almost always, to be safe.

Even if the usual Tcl "--" style was used, I still think that would not be enough, as practically speaking you'd have to use that every single time, making the code horribly ugly. It's just about acceptable for [switch], but not for a constructor, where people fully expect to be able to pass in any variable...

Please tell me I'm dreaming (it's almost 4am here)

-- 
Kristoffer Lawson, Co-Founder, Scred // http://www.scred.com/

From: Jeff Hobbs <jeffh_at_activestate.com>
Date: Fri, 03 Apr 2009 11:29:34 -0700

On 03/04/2009 11:24 AM, Victor Mayevski wrote:
> I really like that XOTcl is being included with ActiveState
> distribution, and even updates via teacup are working. But there is
> one issue - why is it that the rest of XOTcl packages (comm,
> serializer etc) are not being included?

The teapot is designed for individual packages (though they can have
dependencies). In building, it goes through the usual configure / make
/ install steps. XOTcl only packages up the core library when it does
that. The other packages would be best handled separately somehow.

Jeff

From: Artur Trzewik <mail_at_xdobry.de>
Date: Sun, 27 May 2001 15:16:31 +0200

Hi

TclJava was a good tip for implementing garbage collection in Xotcl.
(Thanks Kristoffer Lawson)
It overwrites the cmdType from native tcl.
It is a little dirty and it can make problems by new tcl version,
but I was implemented by SUN by tcl-gurus.
The same think I have done by xotcl - references.
and it works partially.

(new snapshoot)
http://www.xdobry.de/xotclref.tar.gz

example
Class A
set a [A newReference]
$a set a value
set a {}

the last procedure destroy the A object.
Other examples works fine too.

There are some problems.
1. It do not work by Classes with destroy method.
I suppose it is the problem by reference counting by xotcl stack.
I do not understand how it work.

2. The Garbage Collection procedures can be difficult made as
Xotcl-extension.

- The procedure doObjInitialization in not visible. At this time
 newReference do not accept any parameters. I am not so sure how I can
  implement the full object initialization with normal interface.

- xotcl.c use internal GetObject procedure this convert string to XOTclObject.
 I think it should use Tc_Obj as parameter. The most usage of this procedure
is
  GetObject(in, ObjStr(objv[1])
  So. The procedure can check the type of Tcl_Obj directly and get XOTclObject
  from XOTclObjectType or my new (XOTclReferenceObjectType).
  And also increment the tcl_obj counter if it use the object local.

Is there any internal Xotcl restrictions that makes xotclref impossible?

=========================================

 Artur Trzewik
 http://www.xdobry.de

=========================================

From: Zoran Vasiljevic <zoran_at_archiware.com>
Date: Thu, 21 Feb 2002 18:17:07 +0100

On Wednesday 20 February 2002 16:28, you wrote:

> we are working currently on various issues which we
> think are important for our 1.0 release:
>

Ok. The 1.0 is on the horizon :) This is good news!

> - speedup through byte-code support

I'd say, post a core-patch as-is on the website,
so people who'd like to use it can grab it from there.
I'm certainly going to try it, as soon as I get some
relief from the current pressure at work.

> - better components with introspection facilities

I'm already perfectly satisfied, but I'm sure
others would add something to this.

> - easy to use rel-db interface

I'm not using relational databases, so I can't
say much about it.

     - ...

Here I could add a thing :)

I'd like to see some kind of automatic object garbage
collection, for example, when an object gets defined
within a scope of a proc, I'd like it to get auto-destroyed
when this proc exits.

It could be something like:

Class foo
foo instproc init {args} {
    puts stderr "[self] comming"
    next
}
foo instproc destroy {args} {
    puts stderr "[self] leaving"
    next
}
foo instproc test {args} {
    puts "Hallo World"
}
proc dummy {args} {
    foo private fooVar ; # "private" might be a new constructor method
    $fooVar test
    return
}

When somebody calls "dummy" proc, a new "foo" object gets created
(the "private" method" and automatically destroyed when proc returns.
Can such thing be done with simple Tcl variable traces, hm?

>
> what do you think about the following variants:
>
> o proc m1 {} {
> [self] set x 123
> }
> o proc m2 {} {
> .. set x 123
> }
> o proc m3 {} {
> = set x 123
> }
> o proc m4 {} {
> => set x 123
> }
> o proc m5 {} {
> - set x 123
> }
>
> other ideas?

What about:

     o proc m6 {} {
       this set x 123
     }

The "this" command refers to the current object, like [self] does.

Cheer's
Zoran

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Wed, 31 Oct 2001 21:21:30 +0100

On Wednesday 31 October 2001 21:02, you wrote:
> IOW, if I would like to write a C-level extensions to XOTcl
> (which I desperately need to!) what functions from the
> xotcl.c file should be taken into consideration ?
>
> I know that the public API is (still) not supported
> but I'd need some solution pretty fast.
>
> Any ideas ?

 for the time being, please look into xotcl.h

 the basic functionality, that you will most likely need
 is realized though the following functions. These will be
 most likely stable over time. Let us know, if you need
 more functionality as available in xotcl.h

best regards
-gustaf


to create a class
extern int
XOTclCreateClass(Tcl_Interp* in, Tcl_Obj* name, XOTclClass* cl)

 
to create an object
extern int
XOTclCreateObject(Tcl_Interp* in, Tcl_Obj* name, XOTclClass* cl)


to access an object/class via its name
extern struct XOTclObject*
XOTclGetObject(Tcl_Interp* in, char* name)

extern struct XOTclClass*
XOTclGetClass(Tcl_Interp* in, char* name)


add a proc:
void
XOTclAddPMethod(Tcl_Interp* in, XOTclObject* obj, char* nm, Tcl_ObjCmdProc* proc,
               ClientData cd, Tcl_CmdDeleteProc* dp)

Add an insproc:
void
XOTclAddIMethod(Tcl_Interp* in, XOTclClass *cl, char* nm,
                Tcl_ObjCmdProc* proc, ClientData cd, Tcl_CmdDeleteProc* dp)



>
> Thanks,
> Zoran Vasiljevic
> _______________________________________________
> Xotcl mailing list - Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl

From: Eckhard Lehmann <eckhardnospam_at_gmx.de>
Date: Tue, 27 May 2008 22:33:31 +0200

Hi all,

instfilters and -guards are great features in XOTcl. Nevertheless there
is room for improvement...

In 99% of the cases one (I at least) creates a filter that needs to be
triggered only at a certain method. Even if one has several methods to
intercept, it is often easier to create separate methods and use guards
to trigger them.
Guards are great, but the overall picture of the code gets overly
complicated in such cases. Therefore I'd like to propose an argument
"-methods" to the filter command, that tells the filter to only be
triggered on execution of the methods in the corresponding list:

Class A
...
A instproc do1 {} ...
A instproc do2 {} ...
A instproc do3 {} ...

A instproc do1Filter {} ...

# trigger only at do1
A instfilter do1Filter -methods do1 ;# or -methods {do1 do3}

# rather than
A instfilter do1Filter
A instfilterguard do1 {[string eq [self calledproc] do1]}

Is such a feature already planned? If not, is there anything that speaks
against it?

-- 
Eckhard

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Wed, 18 Aug 2004 16:36:40 +0200

On Wednesday 18 August 2004 16:17, Kristoffer Lawson wrote:
> On Wed, 18 Aug 2004, Gustaf Neumann wrote:
> > * Nonpositional arguments for xotcl procs/instprocs; this is
> > a flexible way to check arguments, to provide defaults etc
> > for every xotcl proc/instproc. It uses a similar syntax as
> > ad_proc and ad_page_contract in OACS. See the tutorial for
> > more details.
>
> Interesting... I wonder if something like that could be TIPped into
> Tcl itself?

 sure, it can. It can be implemented as well fully in Tcl,
 as done in ad_proc (or ad_page_contract) in Open ACS.
 Uwe implemented a fast c-based version, borrowing the syntax
 from OACS.

> What about if I don't define any nonpositional arguments,
> can I pass arguments beginning with a dash? I kind of hope so, or
> otherwise it may be necessary to pass "--" everywhere, and it adds
> incompatibility with older XOTcls.

 one can define procs/instprocs with non-positional arguments
 and without. If you have nonposistional arguments defined, and
 you want to pass e.g. -a as "traditional" argument, you must use "--".

 Since existing scripts have no nonpositional arguments defined,
 nothing changed there, older scripts continue to work unmodified.

 -gustaf

>
> / http://www.fishpool.com/~setok/
> _______________________________________________
> Xotcl mailing list - Xotcl_at_alice.wu-wien.ac.at
> http://alice.wu-wien.ac.at/mailman/listinfo/xotcl

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