Weblog Page

From: Victor Mayevski <vitick_at_gmail.com>
Date: Tue, 29 Nov 2011 09:39:42 -0800

Hello Gustaf,

What would be a good way to define a constant/immutable
property/variable in Next?


Thanks

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Fri, 24 Jan 2003 16:16:46 +0200 (EET)

On Fri, 24 Jan 2003, Gustaf Neumann wrote:

> we could provide an option -bind <varname> to the new instproc to allow
> the user to specify a local or a per-object or global variable name,
> but
> this does not provide reference counting at all. i have started some
> time ago
> to work on reference counting, and xotcl has some good prerequirements
> for this: we have tcl_objs for xotcl objects, they maintain already a reference
> count. the obvious idea is to destroy the object, when the reference count
> reaches 0. however, practically this showed to be quite tricky in the current
> implementation since the refcount = 0 condition happens in some unvonveniant
> situations... i have not given up on this, but it needs a bigger chunk of time to
> devote to this...

Yes, exactly. Obviously it's all just steps to make some things easier
while refcount based destruction is the absolute solution. However,
as you may have noticed from c.l.t, ref-count -based systems are really
nasty to get done properly. How would you propose to deal with the
situation where a reference is lost, because the object just happens to
be made into a string (ie. some command or procedure does not keep the
Tcl_Obj but just uses the data as a command). F.ex. when building
callback scripts and containing the object handle there, or as an array
key (I think array keys are still just considered to be strings and the
Tcl_Obj form is not retained).

I would absolutely love to see a solution to the above problems. Many
issues would just vanish in an instance.

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

From: Jeff Hobbs <jeffh_at_ActiveState.com>
Date: Fri, 30 Sep 2005 11:15:07 -0700

Zoran Vasiljevic wrote:
> Am 30.09.2005 um 19:28 schrieb Gustaf Neumann:
> >> What tools or tricks are useful for tracking down memory leaks in
> >> Tcl or XOTcl?
>
> Tricks? No tricks. Hard work and lots of money to spend on
> good memory analyzer (Purify), heh...
>
> And, watching "top" output for hours while doing "time {....}
> 100000" on some spots you *suspect* may be raining on your party!
>
> Honestly, this is one of the most
> ugly
> time consuming
> boring
> unproductive
> difficult
> stupid
> (... you name it ...)
>
> tasks you can imagine. Have been doing this for quite
> a few years already, so I know what I'm saying.

While I agree with difficult and sometimes boring, I find the
best way to not make it an unproductive and time consuming
task is to get a good memory analyzer, as stated. Purify
really is worth the price, when such problems arise. We have
a copy that I have used many times. Valgrind comes close,
finds different things, but I still prefer Purify. Valgrind
is free though, so there's not excuse not to try that.

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

From: Nicolas Boretos <nicolas_at_maich.gr>
Date: Thu, 15 May 2003 09:09:11 +0300

Hi,

I am fairly new to XOTcl and this list, but so far I like XOTcl..
Recently on clt, this was posted regarding tk widgets/framework

----snip---
I haven't looked recently. Tix is technically adequate, I suspect,
but there are cleaner ways of doing OO. My vote would be for
something based on XOTcl---it seems to have about the best performance
of the various OO frameworks, and it feels more like Tcl than (say)
[incr Tcl]. On the other hand, [incr Tcl] has a nice set of
megawidgets in [incr Widgets], so it's more nearly there.

Is there any thoughts on anything like this from the XOTcl team...

regards,

nicolas

From: Stefan Sobernig <stefan.sobernig_at_wu-wien.ac.at>
Date: Fri, 07 Mar 2008 14:56:50 +0100

Dear XOTcl community!

XOTcl is now available in the official Debian sid/unstable suite of
packages, starting with the most recent release (1.6.0)!
We are also confident that XOTcl will, therefore, be featured in
upcoming Ubuntu releases (probably in the second half of the year, i.e.
the post-8.04 release).

You will find the following XOTcl Debian packages:

xotcl (core)
xotcl-shells (xotclsh, xowish + man pages)
xotcl-dev (headers + static libs, i.e. stubs)
xotcl-doc (language reference + manual)
aolserver4-xotcl (AOLServer 4.0.10/4.5 module)

They are about to be spreaded to the Debian mirror network within the
next hours. For now, they can be found at:

http://ftp.debian.org/debian/pool/main/x/xotcl/

Over the last couple of weeks, we packaged and contributed XOTcl to
Debian sid/ unstable under the sponsorship of the Debian Tcl/Tk
maintainers. We would like to express our gratitude to the two chief
Debian Tcl/Tk maintainers, Sergei Golovan and Francesco Lovergine, who
supported and reviewed our packaging efforts.

Please, report package-related bugs through the Debian bug tracker system:
see http://www.debian.org/Bugs/Reporting

General requests should be send to the Debian Tcl/Tk mailing list:
see http://lists.alioth.debian.org/mailman/listinfo/pkg-tcltk-devel

Enjoy!

//stefan

-- 
Stefan Sobernig
Institute for Information Systems and New Media
Vienna University of Economics	
Augasse 2-6
A - 1090 Vienna
`- +43 - 1 - 31336 - 4878 [phone]
`- +43 - 1 - 31336 - 746 [fax]
`- stefan.sobernig_at_wu-wien.ac.at <mailto:stefan.sobernig_at_wu-wien.ac.at>
`- ss_at_thinkersfoot.net <mailto:ss_at_thinkersfoot.net>

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Thu, 08 Dec 2005 16:14:47 +0100

Murr, Florian schrieb:

>Yes, you are right, I overload the setter/getter method and expected
>naively that it just prints the puts-statement and works otherwise
>unchanged. [Should have read the manual more properly, I guess :-)]
>
>
for each parameter a method for getting and setting variables
registered. This
method is a "instparametercmd" implemented in C, which is very similar
to the
set method. This can be as well explained with the forwarder, which could be
used to implement the *parametercmds

   Class C
   C instforward x %self set %proc

now a method named x is defined, that calls "[self] set x" when issued. eg.

   C c1
   c1 x 123

here "c1 set x 123" is called, or in the following line "c1 set x" is
issued.

   puts [c1 x]

This behavior is more or less identical to

   Class C
   C instparametercmd x

or to

  Class C -parameter x

therefore, the instparamtercmd is strictly speaking not needed, but predates
instforward and is slightly faster, since everything is in C. The
parameters do
more, since they can be used to provide as well default values which are
used during initialization of objects.

anyhow, in all cases a method named "x" is defined.
When you define an instproc named x

  Class C
  C instproc x args {...}

you will overwrite the method "x", in a similar manner as
you can overwrite any tcl command, e.g
   proc if args { ...}

Therefore, there is no chance to do a next in these cases,
because the class has now the new method (instproc) instead
of the c-level implementation we had earlier.

Furthermore "next" works only when methods are shadowed, when
a same-named method is defined by a class/object earlier in the
precedence order. This can be achieved e.g. via mixins or filters.

therefore, in your example

>X instproc y {args} {
> puts "[self] y '$args'"
> my instvar y
> if {[llength $args]} { set y [lindex $args 0] }
> next
>}
>
>
the "next" is not doing anything useful, you should replace the
last line of your instproc by e.g. "return $y", such that .... [x1 y]
... works

hope this explains, how this works...

-gustaf neumann

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Sat, 10 Jul 2010 08:38:49 +0200

Hi Kristoffer and all

Am 09.07.10 16:11, schrieb Kristoffer Lawson:
> Now if I call [hello] from another object, I will get the object which called [hello]. Of course, if that object calls [do] instead of [hello], then [self callingobject] will end up being the same as [self]. [uplevel] doesn't help here as [self callingobject] will always return the same, whatever stack level I call it from (is this a bug or intentional?).
not sure, if it was intentional or not, but you observation is right.

the xotcl 0.* and 1.* series is based on an implementation with a
private call stack (in tcl versions
before the 8.5, there was no way to extend the tcl call-stack frames
with oo specific client-data,
tcloo needed this as well, an so tcl got it). the forthcoming 2.0
version has a unified stack
(among many other things), so much behavior does not have to
re-programmed in xotcl
(keeping two stacks on sync).

xotcl 2.0 has this problem magically solved (stefan's patch seems fine
as well for the 1.* series
from the distance).
> The reason I want to do this is that I have an access control system which calls something like [checkPermissions]. [checkPermissions] should just return and do nothing if the original calling object is equal to [self]. Now I end up having to passs [checkPermissions] a parameter with [self callingobject].
>
I am somewhat confused by your terminology. If you are looking for
access control management,
look for example at xoRBAC, which follows the role based access control
model, standardized
by the NIST
http://wi.wu-wien.ac.at:8002/home/mark/xoRBAC/index.html

the basic notion in access control is based on <subject> <pred> <object>
idea,
which subject (individual, user) is allowed to execute which operations
(pred)
on which objects.

 From later mails, it seems that you looking for calling-protection,
where the
basic question is: which object is allowed to execute which
functions/methods.
xotcl 2.0 has as well here some efficient built-in mechanisms to implement
"static" methods, that are designed to work with the basic xotcl object
model
(per-class cs. per object, mixins, ...). It costs essentially no
performance.
This is not a strong protection, but signals maybe unwanted patterns (from
a documentation and implementation point of view).

Is protection needed or not? For projects of small teams (1-2 persons),
there is in my opinion
very little need for that. for larger projects (10-thousands lines of
code, developers
with different skill levels), some mechanisms flagging the programmers
intentions
is useful. I was already thinking about optional mechanisms to force all
methods to be static by default unless they are defined as public. This
would
lead automatically to classes with defined primarily interfaces, but
this is still
just an idea, not sure how this would work out in practice. maybe the
option for this will make it into the release.

-gustaf

From: Aamer Akhter <aakhter_at_gmail.com>
Date: Mon, 4 Apr 2005 22:49:20 -0400

Gustaf,

inline

On Mar 29, 2005 5:36 AM, Gustaf Neumann <neumann_at_wu-wien.ac.at> wrote:
> Dear Aamer,
>
> the general problem is quite tricky, when one serializes and saves some
> objects
> (e.g. containing ::xotcl::__#0), ends and restarts xotcl, creates again
> global
> objects with 'new' and restores the saved state containing the object
> mentioned
> above. 'Serialize all' does not save objects from the ::xotcl namespace,
> but certainly
> people can use -childof...
>
> The most simple solution is to remember the highest allocated id with the
> saved state in serialize all, to provide a function to reset it and
> leave the problem
> to the programmer. But still, this is no good solution, if multiple save
> states are
> used and loaded in arbitary order.
>
> A better solution is to
> a) check in 'new', whether an object with the generated autoname
> exists already, and
> b) provide a wrapper for loading the serialized code that extracts all
> patterns
> of autonames, and remaps some or all symbols if necessary (for
> handling preexisting
> objects with autonames). This could be done by searching for
> autoname patterns
> during serialization and using similar to the -map option of the
> Serializer....;
> but still, this only works, when the autonamed objects are
> serialzed; for references
> in variables we would need a global map table, which is still
> depending on the
> restore order of the serialized code if multiple pieces are saved.....
>
> What are you trying? would (a) be sufficient for you? It is slightly
> slower than the
> current version, but i don't think it is worth adding another option to
> new for checking
> on demand...

hmm. for my current uses i've basically started keeping a string
variable and kept on appending to it the properties i wanted in my
object. at the time of creating the object, i do an md5 on the string,
and get a unique key that summarizes my needed properties. I name the
object the result of the md5. so across script runs the object (if it
has the same properties) has the same name). for the time being this
seems sufficient as i'm only serializing at specific checkpoints, and
at the time of these checkpoints none of the data in the object
refrences other objects.




>
> best regards
> -gustaf neumann
> Aamer Akhter schrieb:
>
> >I just tried this with 1.3.6 and it appears to be working. Sort of
> >related question, how do people handle the swizzling/unswizzling of
> >autogenerated object names (eg ::xotcl__#0) when restoring an object?
> >
> >
>
>

-- 
Aamer Akhter / aakhter_at_gmail.com

From: Gustaf Neumann <Gustaf.Neumann_at_wu-wien.ac.at>
Date: Mon, 12 Feb 2001 11:28:41 +0100 (CET)

>>>>> "CL" == Catherine Letondal <letondal_at_pasteur.fr> writes:
CL> Hi,

CL> Say I have the following class hierarchy:

CL> Class C0
CL> C0 instproc f args {
CL> puts "(C0) I am [self] class [[self] info class] in method [self proc]"
CL> }
CL> Class C1 -superclass C0
CL> C1 abstract instproc f args
CL> Class C2 -superclass C1
CL> C2 instproc f args {
CL> puts "(C1) I am [self] class [[self] info class] in method [self proc]"
CL> next
CL> }

CL> So, the method f is:
CL> - defined at the top of the hierarchy
CL> - abstract in the middle of the hierarchy.
CL> - redefined at the bottom

CL> When I run:
CL> C2 c2
CL> c2 f

CL> I get:
CL> (C1) I am ::c2 class ::C2 in method f
CL> Abstract method f args called

CL> and I cannot reach the top method?
CL> Is this on purpose?

 Hmm, actually kind of. It was on purpose that "abstract" should be
 used at the highest possible point in the class hierarchy, where the
 specified method makes sense (similar to an abstract class say in
 C++).

 For your example, i would really question whether this use of
 abstract is a good design.

 However, if you insist on this kind of class hierarchy, you might
 consider to redefine "abstract. Our implementation of abstract is very
 simple

=========================================================================
Object instproc abstract {methtype methname arglist} {
  if {$methtype != "proc" && $methtype != "instproc"} {
    error "invalid method type '$methtype', must be either 'proc' or 'instproc'."
  }
  [self] $methtype $methname $arglist \
      [list error "Abstract method $methname $arglist called"]
}
=========================================================================

 and can be redefined by any user. so "abstract" is not an integral
 language construct but more like a library function in XOTcl.

 best regards
 -gustaf

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Tue, 8 Apr 2003 01:25:41 +0300 (EEST)

I've been looking at Snit recently and there are definite benefits from
being able to use delegation -- it allows the combination of objects from
Snit with other object-like commands in Tcl (which there are definitely
quite a few of).

I believe XOTcl could possibly benefit from this extra style. Naturally it
would be really easy to do with filters and the unknown mechanism (as I
was thinking of doing with Tk at one point), but perhaps there could be
some use for an "official" approach to that. I'm not sure if this would be
seen as polluting XOTcl or making it overly complex (I still believe in
keeping things as simple as possible). Possibly it could
be provided as a pure-XOTcl capability.

Just a thought.

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