Weblog Page

From: Kristoffer Lawson <setok_at_scred.com>
Date: Sat, 22 May 2010 11:37:37 +0300

On 22 May 2010, at 02:11, Victor Mayevski wrote:

>
>> As for the Ruby / Tcl thingy ... first I've ever heard of it. Got any
>> pointers to it?
>
>
> http://woof.magicsplat.com/woof_home

Cheers. Yes, I actually had heard of that before, but then couldn't
find it at one point and thought I probably mixed with something else.
I'll have another look at that.

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

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Thu, 18 Jan 2001 21:08:13 +0200 (EET)

On Thu, 18 Jan 2001, Kristoffer Lawson wrote:

> Yes, this is exactly why explaining, and even reproducing the
> problem is difficult. In any case, I do believe we probably have
> found a bug, as a method is being run and while it is run at some point
> it gets a message that [self] called after destroy, or something
> like that. Thus we've had to work around this in a rather complex
> fashion. I'll try to explain it as best I can:

Found the problem:

On the machine the guy is running, the version of XOTcl is 0.81, which
bugs in the case described. He's now upgrading...

Doh.


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

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Fri, 2 Mar 2001 02:28:02 +0200 (EET)

On Thu, 1 Mar 2001, Artur Trzewik wrote:

>
> I wrote the first Browsers now. It is the first attempt but it can
> be already used for developing (or browsing Xotcl)
> I named the application XotclIDE
> the tar archive can be downloaded from

Oh, this looks very interesting indeed. You've just done a lot of work
I was considering doing myself (like the Tk wrapper)! I've just taken
a brief look and it certainly looks useful.

If you're interested, we did a simple profiler tool using filters.
Might be something that could be mixed in somewhere?

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

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Mon, 5 Feb 2001 23:36:12 +0200 (EET)

On Mon, 5 Feb 2001, Gustaf Neumann wrote:

> Somehow, i have the feeling, that Kristoffer intended a class to the
> method "whatever". Why not use:
>
> Class Bar -superclass Foo
> Bar instproc init {} {
> next myArg
> [self] whatever niceSystem
> }

Because the "whatever" method should be called along with the object
creation -- and specifically before it takes place. Just as if I had
created an object of the superclass with -whatever in the init line.

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

From: Catherine Letondal <letondal_at_pasteur.fr>
Date: Tue, 19 Mar 2002 19:53:33 +0100

Hi,

I believe the only way to document code is now through the _at_ object
and the makeDoc.xotcl script, which uses several utilities from the
library/system directory (the old one was the metadata mechanism).
Am I right?

My question is about the introspective aspect of this feature: how
do you get the documentation for a class, method, ...?
By parsing its file?

Thanks a lot for any help,

-- 
Catherine Letondal -- Pasteur Institute Computing Center

From: Michael Schlenker <schlenk_at_uni-oldenburg.de>
Date: Thu, 01 Apr 2004 10:13:06 +0200

Catherine Letondal wrote:
> Kristoffer Lawson wrote:
>
>>On Wed, 31 Mar 2004, Alexandre Dehne wrote:
>>
>>
>>>In order to use biok, I have to install xotcl. My problem with xotcl
>>>installation is that my system is under Fedora and there is no tclInt.h
>>>file under this distribution (even with the tcl-devel package). Of
>>>course, I can uninstall the tcl package and install tcl manually but, by
>>>uninstalling tcl package, other packages are going out and that put me
>>>in trouble ...
>>
>>Well tclInt.h is internal Tcl stuff (unfortunately still required by
>>XOTcl). Does Fedora have a Tcl source package? Would be in that.
>>
>>I think Debian is now clever enough to include tclInt.h in the tcl dev
>>package, although naturally the best would be if external packages no
>>longer needed tclInt.h
>
>
> Dear Kristoffer,
>
> I don't understand your answer : do you mean that there should be no problem at all?
> But the file tclInt.h does not exist on alexander's disk although he has a tcl dev
> installed. Is there another source distribution for tcl dev?
> (sorry if this is not directly related to XOtcl, but is there a way to bypass
> this problem when compiling XOtcl?)

The file he needs is in the source rpm for tcl, not inside the tcl-dev
rpm. It is a header file internal to Tcl and not part of the public API
that an extension should use. The tcl-dev rpm probably contains only the
public part of the API headers, not the tcl private ones.

This is reasonable, but a problem for extensions integrating very
closely with Tcl (like XOTcl, Tk and some others).They can only be built
successful against a Tcl build directory, not against an installed Tcl,
unless the missing private Header files are put in the appropriate places.

So what he can do to get this to work:
1. Get the Tcl source rpm for his installed Tcl version.
2. unpack it, to get at the source and extract generic/tclInt.h to a
location where it can be found by the XOTcl build.
3. Build XOTcl

Michael

From: Josh Barton <Josh.Barton_at_usurf.usu.edu>
Date: Tue, 18 Nov 2014 17:17:55 +0000

How do I compile nsf/xotcl for x64 on Solaris instead of 32? I have tried simply specifiying -m64 but that doesn't seem to be enough.

bartonjd

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Thu, 05 Aug 2010 12:38:38 +0200

Am 05.08.10 12:21, schrieb Kristoffer Lawson:
> I need to check still what 2.0 does with:
>
> Car c1 $a
>
> where $a starts with a dash.
>
The next release comes with two flavors:
(a) XOTcl 2.0, which is mostly backward compatible,
(b) a new object system with a different syntax (among many other things,
    one cannot call arbitrary methods via dash syntax).

For XOTcl 2.0, the behavior for this example is like in XOTcl 1.* (it
has to be
for compatibility for many one-liners out there), for the new syntax,
you get an
error message (... and, by default, one has to use "Car create c1"
instead of
"Car c1", since the latter is dangerous as well).

-gn

From: Scott Gargash <scottg_at_atc.creative.com>
Date: Thu, 16 Mar 2006 03:25:20 -0700

Thanks for your time and patience in answering my questions.

Gustaf Neumann <neumann_at_wu-wien.ac.at> wrote on 03/15/2006 02:46:58 AM:

> Scott Gargash schrieb:
> >
> > Hello,
> >
> > Is it possible to change the -setter command associated with a
> > parameter at some point other than class definition?
> >
> one can use the method "parameter" at any time to add/redefine
> parameters (see below).

The issue with using the "parameter" method is that it changes the parameter definition class-wide,
which is undesireable. I'd like to change a parameters -setter property on a per-instance basis.
The intended class behavior is to use the default setter class wide at construction time, but after
an instance is fully constructed, each instance should use an overridden -setter. Ideally the per
instance -setter is directed to a instproc class.

Right now I have define the -setter property and have an instproc for the class that does the
standard behavior, but then in the constructor I define a "[self] proc" to redefine the
implementation of the -setter for that instance.

# This is what I do currently
Class create A -parameter {{foo -setter myfoo}}
A instproc init {args} {
  # [self] is valid so revector [my setfoo] to have sideeffects
  [self] proc myfoo {p v} {
    my set $p $v
    #do side-effects
  }
}
# no side effects at construction time
A instproc myfoo {p v} {my set $p $v}

This works (I get the behavior I desire), but it means I have to 1) define a proc that duplicates
the default behavior and 2) construct n identical copies of the implementation for the -setter proc,
when really I can get by with the default behavior and one copy of the override behavior shared
across all instances, just revectored the setter behavior once it's safe to do so.

# What I'd prefer
Class create A -parameter {foo}
A instproc init {args} {
  # [self] is valid, revector [self]'s foo setter from default to the side-effectful variant
  [self] parametercmd {foo -setter myfoo}
}
A instproc myfoo {p v} {
  my set $p $v
  # do side effects
}

Besides being more memory efficient, it seems to more clearly express my intent. As you say, a trace
would work, but traces tend to look and feel a bit like magic.

> the difference in speed is due to the fact that the default
> setter/getter method is implemented in C,
> whereas the tailored functions are in tcl. it is certainly possible to
> program a tailored getter method
> in C as well, but i doubt that this is worth the effort.

As you may have inferred from my questions, performance is an issue for my application. I'm hoping
to avoid having to drop into C (and XOTcl's native performance gives me hope, especially relative to
snit), but I'm prepared to move to C if and when I have to.

I've seen the part of the tutorial about wrapping C-extensions with XOTcl, but is there a
reference/tutorial for extending XOTcl in C? How would I go about reimplementing a method in C?
Can I just use the vanilla Tcl API or do I need to compile/link against XOTcl also?

One thing that has confused me so far is the "namespace on demand" concept. Where are instance
variables stored if not in a namespace?

% Object a
::a
% a set foo 123
123
% namespace exists a
0

Where does Object a's foo variable reside?

If I wanted to implement a method as a C function, how does the C function find the value of "[a set
foo]" via the Tcl API? I.e., what would I pass as the varname to Tcl_GetVar()? Or do I need XOTcl's
C API to look it up? Where do I install my C commands such that they are found automatically by
XOTcl's method lookup alogrithm?

Is this sort of info spec'd by XOTcl or is it implementation defined? Is this what
"requireNamespace" does? I've read the docs but I haven't really grokked it yet.

      Scott

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Tue, 11 Jul 2006 18:49:04 +0300

Have I missed something, or is there no easy way of turning asserts
off or on for all objects? It's common that during the development
phase you want all the asserts turned on and, perhaps for performance
reasons, turn them off when finished. I know it could be possible by
overwriting the create method, or whatever, but I was looking for
something... well ... less hacky.

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