Weblog Page

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Thu, 3 Jan 2008 00:20:34 +0200

On 2 Jan 2008, at 23:46, Eckhard Lehmann wrote:

> Kristoffer Lawson schrieb:
>> You could just wrap it in a package that sets a Tcl [trace] for
>> normal commands combined with filters for the XOTcl stuff, just
>> checking to see if the command names match, if necessary. Or maybe
>> I've missed something here and I'm thinking to simple :-)
> The problem is that I need something that is like enterstep/
> leavestep for [trace], but for XOTcl. Filters do only intercept
> calls to XOTcl objects but not to Tcl proc's.

I understand that requirement. That is why I am suggesting you use a
combination of XOTcl filters and [trace]. It might be that even
[trace] is enough, if it catches all Tcl command calls (I haven't
looked at it). If not, have XOTcl filters for the XOTcl stuff and
[trace] for the rest?

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

From: Stefan Sobernig <stefan.sobernig_at_wu.ac.at>
Date: Fri, 27 Jul 2012 23:24:02 +0200

>>> installed the compile tools, and ran configure, but it broke because I
>>> apparently don't have a /usr/local/include/tcl8.5/tools/genStub.tcl ...
>>
>> From all I know, ActiveTcl does not provide a source installation
>> including private headers, genStub.tcl & friends. But you got your
>> answer already in
>> https://groups.google.com/forum/?fromgroups#!topic/comp.lang.tcl/APlqIM_kyKY.
>>
>
> FWIW, ActiveTcl does include internal headers, and I have compiled
> extensions using mingw against ActiveTcl without issue (though not tried
> xotcl recently).

Ah ok, my bad then. I will check it ...

Best
//stefan

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Mon, 17 May 2010 23:37:11 +0300

For the [ob info class] it specifies:

objName info class: Returns the name of the class of the current object.

Undoubtedly that should say "Return the name of the class of the
object". Ie. no "current". It is returning the class for objName,
after all.

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

From: David LeBlanc <whisper_at_oz.net>
Date: Thu, 4 Jan 2001 01:25:12 -0800

Hi;

I am so far unable to run any of the sample programs or get gdbm or qgdbm or
whatever to run. There seems to be many steps in installing xotcl that are
not described in the installwin readme.

I have installed the software, fixed a bug in the makefile.vc that causes
auto_path to be wrong in the built make file (INSTALLDIR is defined, but
INSTDIR is used in the lib path macro).

Then, I ran installwin.tcl.

Then, even though not in the instructions, I ran make.xotcl in the new
/tcl/lib/xotcl dir.

Then, I ran qgdbm0.3/install.tcl - something else not in the instructions,
but it looked right.

Now, whenever I try to run almost any example program (in awo etc.) I get
errors. In the case of awo/webdocument.xotcl it says it can't find
webagent.xotcl. This file is in the mos dir.

Trying to run any of the store files gets a very curious problem:
couldn't load library "K:\tcl\lib\tcl8.3\gdbm0.3\libtclgdbm.so": this
library or a dependent lib
rary could not be found in library path
    while executing
"load K:/tcl/lib/tcl8.3/gdbm0.3/libtclgdbm.so"
    ("package ifneeded" script)
    invoked from within
"package require -exact gdbm 0.3"
    (file "qgdbm.tcl" line 28)

Firstly, this is windows and the shared lib extension is "dll", not "so".
(the .so error is in tcl/lib/xotcl/qgdbm0.3/pkgIndex.tcl file - hard coded
shared lib extension. (Curiously, the pkgIndex.tcl in the sources doesn't
have this problem - in fact it looks completely different.)) Secondly
whatever extension you use, there is no libtclgdbm.dll or .so file anywhere!
I have a tclgdbm.dll, a libgdbm.dll and a gdbm.dll, but no libtclgdbm.dll.
Which is which and where should they go?

Another problem is with trying to run counter.xotcl in the
/tcl/src/xotcl/apps dir - again, I get a package not found error: in this
case, htmlplace.xotcl. It's almost like Xotclsh or XoWish don't do a
pkgIndex search in any of the lib/xotcl dirs or subdirs.

If anyone can tell me how to get all this running on windows I would be VERY
greatful.

Thanks,

Dave LeBlanc

From: Cristian Chaparro <cristian.chaparro_at_univ-perp.fr>
Date: Thu, 23 Nov 2006 17:24:09 +0100

Hi all,
Has anybody compiled xotcl to be used on a pocketpc with etcl?
Libraries, instructions... whatever info is welcome.
Thanks.

Cristian

-- 
Ce message a ete verifie par MailScanner
pour des virus ou des polluriels et rien de
suspect n'a ete trouve.
CRI Université de Perpignan

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Fri, 19 Oct 2001 09:08:19 +0200

---------- Forwarded Message ----------
Subject: Re: [Xotcl] xotcl and tclkit
Date: Fri, 19 Oct 2001 09:07:31 +0200
From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
To: Hal Heisler <hh_at_heisler.net>


On Thursday 18 October 2001 23:14, you wrote:
> Hello,
>
> I'd like to use xotcl with tclkit. When I try to load the distributed
> linux binary libxotcl.so I see undefined symbol: tclEmptyStringRep
>
> I have not tried building xotcl myself yet, perhaps that's what I need to
> do. Tclkit uses a tcl/tk 8.4 snapshot from cvs.
>
> Just wondering if anyone's been down this road.

 the xotcl binaries are built with tcl 8.3.2.
 therefore it should work without compiling only with
 8.3.

 however, when it is compiled with 8.4, it will work.

 best regards
-gustaf neumann

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

-------------------------------------------------------

From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Sun, 19 Mar 2006 16:04:17 +0200

On 19 Mar 2006, at 15:53, Gustaf Neumann wrote:

>
> One general observation about our discussion: it is often not
> clear, what "namespace"
> refers to, a "tcl namespace" or some kind of an abstract namespace.
> tcl-namespaces

OK, for the records when I've talked of namespaces I have meant Tcl
namespaces :-)

> Kristoffer Lawson schrieb:
>>
>> On 19 Mar 2006, at 14:09, Scott Gargash wrote:
>>
>>> xotcl-bounces_at_alice.wu-wien.ac.at wrote on 03/19/2006 04:08:40 AM:
>>>
>>> >
>>> > On 19 Mar 2006, at 00:12, Scott Gargash wrote:
>>> > >
>>> > > When would you need the namespace of the object?
>>> > I have only ever needed the namespace of an object
> you mean, you needed to use the explicit "requireNamespace", since
> namespaces are used all over in tcl as discussed in depth. as soon you
> define e.g. a child object or a proc for an object, a tcl-namespace is
> automatically added.

Yes, exactly. But also, from my point of view the implementation
could have been anything, tcl namespace or not, except for that
particular case which sometimes comes up.

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

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Thu, 17 Apr 2003 22:44:24 +0200

On Thursday 17 April 2003 20:11, Michael A. Cleverly wrote:
> Since every class is also an object, its possible to define both procs &
> instprocs for it. The instprocs define methods that objects of this class
> will have, while the proc (as I understand it) proc would define a method
> on the class object, but not for objects of the class. (Yes?)

 correct.

> However, during my interactive playing around trying different things I've
> found that as soon as I define a proc on the class object any subsequent
> use of [info classchildren] leads to a segfault.

 bingo. you found a bug. please apply the following patch to fix it.

> Is it better to avoid defining procs on the class object,
> ...

 The only limitation with procs in our current limitation is that
 one can't have procs and sub-objects with the same name, since
 both occupy the same slot in the namespace.

 in the following code, one can call the proc t both as "o::t" and "o t"
    Object o
    o proc t {} {puts x}

 When a childobject is created, it is refered to as well with o:t
    Object o::t
    o::t set x 1
    ...
 The creation of the object o::t detetes the same-named proc and vice versa.
 This make it easy to "donate" ordinary tcl procs/commands to an object:

   proc xxx {} {puts xxxx}
   ...
   rename xxx o::xxx

 now xxx is a proc of o, which can be called via:
   o xxx
   puts [o info procs]
  
> or am I misunderstanding when & where to use [info classchildren]?

 no, you are on the right track!
 all the best

 -gustaf

=======================================================================
--- xotcl.c~ 2003-04-16 19:13:53.000000000 +0200
+++ xotcl.c 2003-04-17 22:22:59.000000000 +0200
_at_@ -4911,7 +4911,7 @@
     if (!pattern || Tcl_StringMatch(key, pattern)) {
        Tcl_PushCallFrame(in, &frame, (Tcl_Namespace*)obj->nsPtr,0);
        childobj = GetObject(in, key);
- if (XOTclObjectIsClass(childobj)) {
+ if (childobj && XOTclObjectIsClass(childobj)) {
            Tcl_ListObjAppendElement(in, list, childobj->cmdName);
        }
        Tcl_PopCallFrame(in);

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

-- 
Univ.Prof. Dr.Gustaf Neumann
Abteilung für Wirtschaftsinformatik
WU-Wien, Augasse 2-6, 1090 Wien

From: Uwe Zdun <uzdun_at_k2.informatik.uni-essen.de>
Date: Tue, 9 Jan 2001 23:00:34 +0100 (CET)

On Tue, 9 Jan 2001, Catherine Letondal wrote:

>
> Hi,
>
> I have a question about documentation mechanisms in XOtcl. I would
> like to use introspection for documenting my application, but not
> for generating HTML files. As far as I have understood:
>
> - metadata is deprecated (http://media.wu-wien.ac.at/doc/tutorial.html#meta-data)
>

right. The metadata were not very powerful and as runtime constructs they
have always used performance & memory. The _at_ syntax is more powerful ...
 
> - _at_ object is a kind of /dev/null which has to be redefined somehow
>

right. But at the moment we haven't build a generic runtime structure for
the running program, but we will have that very soon ... the planned steps
are:
- fix the problems Kristoffer has identified
- extract a generic structure for runtime representation of metadata
- what now is xodoc will become the static file analyser building that
structure
- another component builds that structure during execution and allows
you to access/change it(*)
- makeDoc.xotcl will contain the HTML documentation tool based on static
analysation

You are probably interested in (*) ... we hope to get at the xoDoc issues
during the next 1-2 weeks (but we have to fix the diverse gdbm
(mainly of the windows port) problems first ... we're currently adding
another persistence store implementation ... that is really free &
that we hope to run/install on Win and on Unix well).

For the time being at least the syntax of _at_ (as described on this mailing
list before) should be quite stable.

> - xodoc does this but for HTML documentation
>
> So my question is: how do I use or not use _at_ for generating some kind of
> metadata, i.e data which can be found (and changed by the user if needed) during
> the application?

_at_ is intended to be extensibly interpretable. It uses a quite simple
syntax so its easy to build interpretations that parses the attached Tcl
lists. The following lines from xoDoc are a general way to do it:

Class XODocCmd -parameter {
  {xoDocObj ""}
}
XODocCmd instproc unknown args {
  [self] instvar xoDocObj
  if {[llength $args] > 1} {
     switch [lindex $args 1] {
      proc - instproc {
        return [eval $xoDocObj handleMethod $args]
      }
     default {
        switch [lindex $args 0] {
          _at_File {
            return [$xoDocObj handleFile [lindex $args 1]]
          }
          default {
            return [eval $xoDocObj handleObj $args]
          }
        }
      }
    }
  }
  puts stderr "Unknown documentation: '$args'"
}
XODocCmd _at_

you just have to put your application specific tags and interpretation
method into the switches ...

It is easy that every application can define its own behavior
for interpreting different kinds of metadata (and you can extend it with
new application specific tags). _at_ is just intended as a common place for
metadata/documentation inside of a program, that can be turned on and off
during execution.

All what XOTcl should provide is a common framework for documenting XOTcl.
Your application may document quite different things with _at_.

Eg. instead of just having the _at_File token, you can add new @XXX token ...
and the argument lists are just extensible key/value pairs

> Why is metadata deprecated?

We believe that _at_ can express everything you can express with
metadata, but with _at_ you can choose yourself if you want to use it or not
(metadata is a built-in language feature and can not be turned off). Since
_at_ is more powerful, we hope to get the core language smaller & easier
comprehensible, by only using _at_ ...

For now we hope that not too many people were using
metadata at all ... later it might get much more difficult to "clean up"
such problematic parts of language. We think "metadata" as it was, was not
a very intutive & elegant & general solution. I hope you haven't have a
large program part written with "metadata" ;) ... but the conversion to _at_
is not very problematic ...

Regards,

Uwe

From: Jeff Hobbs <jeffh_at_ActiveState.com>
Date: Sat, 10 Apr 2004 13:54:36 -0700

Gustaf Neumann wrote:
> - Jeffs suggestion was to use the TEA_* macros instead of the
> stuff we use currently. I was not aware of these new TEA macros.
> the sample extension (sampleextension-0.2) in http://www.tcl.tk/doc/tea/
> contains only SC_* macros, and no TEA_ at all. the same is with tcl8.4.6
> find tcl8.4.6 -type f | xargs fgrep TEA_
> On the other hadm it still uses SC_PROG_TCLSH, determined by
> find tcl8.4.6 -type f | xargs fgrep PROG_TCLSH
>
> By googling around, i found
> http://cvs.sourceforge.net/viewcvs.py/tcl/sampleextension/configure.in?rev=1.37
> which is quite different from the macros.
>
> so... i come to think that SC_PROG_TCLSH is currently the way to go,
> but TEA2 will at some time do everything better with new TEA_* macros

Actually the sampleextension-0.2 is years old, and I should remove
the entire www.tcl.tk/doc/tea/ area, since I haven't had time to
correct the old docs. Most major extension all use TEA2 now (some
use TEA3 in fact, which is relatively recent). SC_PROG_TCLSH is NOT
the way to go. Note that the core does not use TEA (Tcl Extension
Architecture) because it is not an extension.

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