Weblog Page

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Wed, 28 Sep 2005 19:23:28 +0300

On 28 Sep 2005, at 18:49, Donal K. Fellows wrote:

>
> The TIP is (totally!) light on C-level API, largely because I've no
> idea
> what needs to go there. I'd even be happy (personally speaking)
> with an
> OO system that did not provide any C-level API at all. Other people
> will
> probably disagree. :-D

Well yeah, I'd disagree in the sense that if any OO framework goes
somewhere near the core, I'd like to see Tk being implemented in
terms of it (or indeed any other C-based extension which uses
objects). Not immediately, of course, but in the long run.

>
> BTW, I was wondering what happens when you do this in XOTcl (ignoring
> the syntax for now):
>
> class A derived from Object
> defines instproc foo
> class B derived from A
> defines instproc bar
> class C derived from Object
> defines instprocs foo, bar and move
>
> object D is a C with B mixed in
> call: D foo
> call: D move
>
> Which implementation of foo gets called first? Which implementation of
> move gets called first?

I believe C's foo gets called first, then A. There's only one
definition of move so that's easy , C:)

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

From: Scott Gargash <scottg_at_atc.creative.com>
Date: Wed, 16 Aug 2006 16:13:38 -0600

Gustaf Neumann <neumann_at_wu-wien.ac.at> wrote on 08/16/2006 03:06:18 AM:

> Scott Gargash schrieb:
> >
> > So I inserted my own exitHandler and that works in a single thread,
> > but when I have multiple threads, things get confused.
> >
> You have not told us, what "confused" means (other than: "i get an
> error") since your
> example works for me.

Sorry, I omitted that. My example gives the following error:

Error from thread tid00000C20
invalid command name "tclPkgUnknown"
    while executing
"tclPkgUnknown XOTcl {}"
    ("package unknown" script)
    invoked from within
"package require XOTcl"
User defined exit handler contains errors!
Error in line 2: target thread died
Execution interrupted.


My actual code doesn't give any consistent behavior. Sometimes it sort of works, sometimes it
generates corrupt data, and sometimes it dumps core.

> If you have multiple threads, and you want to control the order, in
> which the threads exit
> (and in which their exit handlers are called), you have to do this on
> your own
> as well (not using "exit", but your own shutdown command). Be aware of,
> that tcl tries to shutdown your threads on exit as well.


A ha, you've describe my problem (and also the solution I found). I have exit handlers in all the
threads, and I get inconsistent behavior. I wound up overriding exit to get things to exit in a
defined manner.

It was in the process of trying to reduce it down to a simple test case that I found the problem
(described above) on WinXP with just a single exit handler. Now, perhaps that's an real problem of
some sort also, but it sounds like I need to continue overriding "exit" to get the desired behavior
in the real codebase.

      Scott

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Wed, 04 Jul 2007 20:32:40 +0200

Thank you Atur for your introduction.
However, i have to add something at certain points:

Artur Trzewik schrieb:
> In early version of XOTcl perameter are just a clever shortcut for method
> Definition
> Class A -paramter a
>
> has leaded to method
>
> # setter and getter in one method
> # something like this
> A instproc a {args} {
> if {[llength $args]==0} {
> my set a
> } else {
> my set a [lindex $args 0]
> }
> }
this is only partially correct, since also in old xotcl versions
"parameters" were an abstraction to provide an accessor function
and to provide default values.
>
> It was pure XOTcl and also visible per info instbody.
> Now parameters are C-coded and probably faster.
the c-code provides an accessor function similar to the instproc
above (yes, it is about 7 times faster in C). The C-implemented
accessor function can be registered via "parametercmd"
(or "instparametercmd")

The accessor function above can be replaced by

  A instparametercmd a

and can be used via

  A create a1 -a 200
  puts [a1 a]

The "parametercmd" (without "inst") is used similar to a proc,
it registers an accessor function for a single object.

Note, that slots are much more powerful than these kind of
parameters, since they are an abstraction
for providing much richter meta-data for attributes and can be used
for required/non-required attributes, type checking, multi-valued
attributes, database attributes, html information (labels, etc), providing
meta-data for remoting (e.g. soap calls), and many more.
> Parameters are only syntactic sugar but you do not need to use it.
In XOTcl version since 1.5.0, parameters are syntactic suguar
for simplified access to slots. In prior versions, they were only
syntactic sugar for providing default values and accessor functions.

Strictly speaking, an application programmer does not have
to use parameter in the application program, therefore Artur is right.

While the application program does not have to *define* slots,
it is hard to do something useful in xotcl without *using* slots
since methods like "superclass", "class", "mixin" etc.
are implemented as slots.

-gustaf neumann

From: Nicolas Boretos <nicolas_at_maich.gr>
Date: Thu, 11 Dec 2003 11:45:26 +0200

jim wrote:

>i still wonder if there is a way to wrap some xotcl files into the exe
>so i dont have to rely
>on having the whole xotcl install on the users machine . since i am
>using just the very basic
>features of xotcl right now it seems that i wouldnt need all of those
>files.
>
>i have some documentation now with freewrap that explains this process
>i'm wondering about
>and i might be able to get it to work but dont know what xotcl files
>need to get wrapped.
>
>
Hi,

While I cant speak for freewrap, (its been years..), I think that the
whole point of "wrapping" is to avoid relying on having xotcl
installed on the users machine. Maybe I am missing something...

But anyway, I can speak for tclkit and starkits, maybe you could grab
the XotclIde starkit/pack and "unwrap it" and see whats is going on..
For sure, as a minimum, you would need to include the the xotcl dll, ~
120Kbytes. If you are using some of the xotcl library procs, eg comm,
then you would add those as well...
Let me know if you some quick instructions on getting starkits up and
running...

regards,

nicolas boretos

From: <uwe.zdun_at_uni-essen.de>
Date: Tue, 19 Dec 2000 18:12:36 +0100 (CET)

>>>>> "KL" == Kristoffer Lawson <setok_at_fishpool.com> writes:
KL> On Tue, 19 Dec 2000 uwe.zdun_at_uni-essen.de wrote:
>> we could also merge components that are split across files into one
>> documentation file. I'm not sure which solution is the best one ...
>> what do you think?

KL> I think the best behaviour would be a combination of the two given
KL> possibilities:

KL> Each code file does get its own documentation file, but there is one
KL> package documentation file that lists which files are part of the
KL> packages. This document file would then link to the per-file document
KL> files.

yeah, that sounds sensible. I take a look at how we can realize this
behavior conveniently ...

KL> On another issue we have made Debian packages of XOTcl (0.82, but 0.83 is
KL> on the way) if someone is interested.. They're not extensively tested but
KL> they seem to work on the machines here. Probably candidates for merging
KL> into the official Debian system at some later time.
>>
>> great! if you like to maintain Debian packages & have a web page for
>> them, we can link this page with the XOTcl download page?

KL> Yeah, we should still test them on a clean machine and if that works
KL> then we can stick them up somewhere. I'll get back to you once we've
KL> done that. There shouldn't be any major problems anyway. I just
KL> did a "dpkg -i" for the 0.83 package and except for a minor issue with
KL> pkgIndex.tcl it seems to be working.

ok. just drop us a note, when you're through with it

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

From: Kristoffer Lawson <setok_at_scred.com>
Date: Wed, 7 May 2008 21:15:39 +0300

On 7 May 2008, at 21:09, Matthew Smith wrote:

> Thank you for the help.
>
> Now I am getting another error I don't understand.
>
> invalid command name "my".

"my" is probably in the xotcl namespace. When I'm coding with XOTcl I
always start with the following:


package require XOTcl
namespace import xotcl::*

Then I have direct access to all XOTcl commands:

Class Stack

Stack instproc init {} {
   my instvar things
   # ...
}

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

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Wed, 18 Aug 2004 17:17:24 +0300 (EEST)

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

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

From: Artur Trzewik <mail_at_xdobry.de>
Date: Sun, 22 Apr 2001 14:02:55 +0200

Hallo

By building some Xotcl Class System I have following problem.
Consider the example


% Class A
A
% A proc test {} { puts "method test" }
% Class B -superclass A
B
% B test
test
%

I would expect by calling B test to invoke A proc test and not to create new
instance of B.
I know this bahavior from Smalltalk. It is very usefull for building special
creating method on class side or some method that not need a instance

For Example (getter for a system constant)

Class A
A proc getSystemPath {} { return \usr }

Class B -superclass A
B proc getConfigFile {} {
    return [file join [[self] getSystemPath] System.cfg]
}
This would create new Instance of B with name getSystemPath
Now I have to write:
B proc getConfigFile {} {
    return [file join [A getSystemPath] System.cfg]
}
or implement proc search on class side by myself

This was rather simple example but there are many examples in smalltalk
libraries for reasonable use of this bahavior.

Is there a chance to change it in next version?
It would make my system easier and cleaner

mfG
=========================================

 Artur Trzewik
 http://www.xdobry.de

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

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Wed, 16 Apr 2003 13:11:18 +0300 (EEST)

On Wed, 16 Apr 2003, Neophytos Demetriou wrote:

> Hi Michael (of nstcl fame right?),
>
> AFAICS, static member variables are not supported as a language
> construct but you can either have a variable in the "Chapters" class, e.g.
>
> Class Chapters
>
> Chapters set current_chapter 12345

In addition to this you can also use instvar to use a variable from
another object, like:

Class Foo
Foo set front 242

Foo instproc init {} {
  [self class] instvar front

  puts $front
}

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

From: Uwe Zdun <uzdun_at_k2.informatik.uni-essen.de>
Date: Thu, 28 Dec 2000 15:27:00 +0100 (CET)

Hi,

On Tue, 26 Dec 2000 seva_at_design.kiev.ua wrote:
>
> I split my application in several source files. Each of files
> implements one of fsm's or helper functions, and when I need to change logic
> of work, i simply source all files.
>
> There are several problems with this:
> 1) when I execute command Class Some, previous instance of this
> class deleted, and all objects move to ::Object class.

this behavior is intended: from a "programming language point of view" you
can not predict whether a destroyed class is going to be redefined or not.
There could be another class with the same name, but with different
semantics.

In cases like your application, that require a class redefinition, there
are several ways to tell the language to behave like this:

- you can use the filter, as you have done to overload create.
- you can use a subclass or a mixin to change create bahavior
- or you use introspection to find out which instances are currently
  there and re-class these instances after sourcing to the new classes
  (same-named) classes

Probably a combination would work here, like a instmixin on object that
checks whether a class-to-be-created exists. If yes all instances are
stored in a variable. After create, the instances are re-classed back
to the old class.

Or you build an instmixin tht simply does not execute the "create" on
certain existing classes?

It depends on your application case which solution is the best here ...

> This problem I solve by using filter for create command on ::Object (idea
> stolen from recoverypoint class :)) ). But with that second problem
> arrives:
> 2) when some instproc used as a filter, and redefined, it's filter become
> inactive. (so first problem arrives again, when I source recover.tcl which
> has recoverfilter definition)
> after setting filter again, all works as expected
>

for the same reason as we have to re-class exisiting instances, we have to
set the filters to an empty list, when the method is redefined (the same
is done for mixins, when the class is redefined). E.g., we can
not say that in any case with "Object instproc filter" the same method is
defined. But again you can easily change this behavior for certain cases
with a filter or instmixin or a subclass of Object, by redefining "mixin",
"instmixin", "filter", etc. so that they check whether a certain filter,
mixin, or instmixin is still there. A filter on Object is probably not the
best solution here, because it performs the check on every call in the
system. This is a heavy performance overhead. Presumably a mixin solution
is more well-suited, because it only checks for certain methods and can be
used object-specifically.

In your example code a "mixin" on "Class", that just checks the
Class->create method could be sufficient.

Hope this helps,

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