Weblog Page

From: Victor Mayevski <vitick_at_gmail.com>
Date: Wed, 25 Jul 2012 07:48:45 -0700

Hello Gustaff,

What is the reason for following error/behavior:

ClassX create c1; #ClassX has several subclasses
c1 delete method m1
Error: ::c1: cannot delete object specific method m1

I get a similar error for "c1 delete property p1"
Why am I not able to delete object specific methods/properties?

Thanks

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/